Redis hosting is a deployment decision about where a Redis-compatible in-memory data layer runs and who owns its infrastructure, persistence, monitoring, scaling, and recovery.
For teams evaluating Redis hosting, the practical choice is usually between a managed Redis-compatible service and a self-hosted Redis server. Choose managed when you want less platform operations work. Choose self-hosted when you need host-level control, exact configuration, or a custom topology your managed service does not provide.
Raff Technologies supports more than 3,000 customers and 15,000 deployed VMs across cloud workloads. In our work with small teams, Redis becomes operationally important much earlier than expected because cache, queues, sessions, and rate limits can all become application dependencies even when none of them is the primary database.
Raff's live managed path is Valkey, a Redis-compatible in-memory data store, while teams that need direct Redis control can self-host Redis on a Raff VM. This guide explains how to choose between those paths. For use-case design after hosting is selected, read Redis Cache and Queue Strategy for SaaS Apps.
Redis hosting has managed and self-hosted operating models
The main difference between managed and self-hosted Redis hosting is operational ownership.
| Responsibility | Managed Valkey | Self-hosted Redis |
|---|---|---|
| Infrastructure provisioning | Provider | Your team |
| Host maintenance | Provider | Your team |
| Service deployment | Provider | Your team |
| Monitoring platform | Included to a defined scope | Your team builds or integrates it |
| Persistence platform | Service-defined | Your team configures it |
| Eviction policy | Service controls and customer configuration | Full customer control |
| Scaling workflow | Provider tooling | Customer process or automation |
| Root / OS access | No | Yes |
| Application keys and TTLs | Your team | Your team |
| Queue retry behavior | Your team | Your team |
| Session behavior | Your team | Your team |
| Recovery validation | Your team | Your team |
A managed service reduces host and service operations. It does not decide whether a cache key can be safely evicted, whether queue jobs are idempotent, or whether the application can recover when the in-memory layer is unavailable.
Self-hosting exposes more controls, but every added control becomes an ongoing maintenance responsibility.
The decision framework starts with workload criticality
Redis is often introduced as a cache, then gradually becomes a production dependency. Choose the hosting model from what happens when it fails.
| Decision signal | Managed Valkey usually fits | Self-hosted Redis usually fits |
|---|---|---|
| Redis supports production sessions or queues | Strong fit | Only with mature operations |
| Team wants provider-managed host maintenance | Strong fit | No |
| Root or OS access is required | No | Strong fit |
| Exact Redis configuration is required | Service limits apply | Strong fit |
| Custom modules or host agents are required | Verify service support | Strong fit |
| Team already owns Redis monitoring and recovery | Still useful | Stronger case for self-hosting |
| Simple development cache | Convenient | Also practical |
| Private application-to-cache connectivity matters | Strong fit when supported | Strong fit with private networking |
| Predictable memory sizing matters | Plan-based | VM-based |
| Team wants the lowest operational burden | Strong fit | More work |
Choose managed Valkey when the workload is compatible with the service and the team would rather spend engineering time on application behavior than on the cache host and service lifecycle.
Choose self-hosted Redis when a documented requirement needs root access, exact Redis configuration, custom modules, direct filesystem access, or infrastructure control.
The decision rule we use at Raff is simple: if Redis failure can break login, job processing, rate limits, or customer-facing latency, treat Redis as production infrastructure rather than a disposable helper process.
Managed Valkey fits production cache, queues, and sessions
Raff currently provides Managed Valkey as the managed Redis-compatible path in the database platform.
The public Managed Databases page positions Valkey for:
- application caching;
- queues;
- sessions;
- eviction-policy control;
- scoped application credentials;
- managed snapshots and recovery workflows;
- private application-to-database connectivity.
Valkey and Redis share substantial protocol and persistence compatibility, but teams should still test the exact client library, commands, modules, and persistence workflow they depend on before migration. Valkey's migration documentation specifically describes compatibility with Redis OSS 7.2 RDB/AOF formats and Redis OSS modules using the module API.
Managed Valkey is a strong fit when:
- the team does not want to patch an in-memory database host;
- cache or session availability affects users;
- queues must be monitored as production infrastructure;
- private connectivity and scoped credentials should be standardized;
- memory limits and eviction policies should be managed through a service interface;
- the application already uses Redis-compatible clients and can validate compatibility.
The application team still owns key naming, TTLs, queue retry policies, session expiration, rate-limit behavior, and the decision about what data can be safely evicted.
Self-hosted Redis fits workloads that need direct control
Self-hosted Redis on a VM gives the team operating-system and Redis configuration control.
That is useful when the workload requires:
- root access;
- exact Redis version and patch timing;
- custom
redis.confsettings; - direct RDB or AOF file access;
- custom backup tooling;
- custom modules;
- host-level monitoring agents;
- a specific memory allocator or OS tuning path;
- application and Redis placement controlled by the team.
The operational responsibility is larger than installation.
A production self-hosted Redis deployment must plan:
Host hardening + Redis installation + authentication / ACLs + private network access + maxmemory + eviction policy + persistence + monitoring + backups + restore tests + upgrades + incident response
For a secure implementation path, use How to Install Redis on Ubuntu 24.04. That tutorial keeps Redis on loopback by default, enables authentication, configures persistence and memory limits, and blocks public port 6379 access.
A self-hosted path can be cost-efficient when the team already operates VMs confidently and Redis is small or specialized. It becomes less attractive when the hidden work around monitoring, failover, recovery, and upgrades begins competing with product engineering.
Memory and eviction policy define cache reliability
Redis and Valkey are memory-first systems, so memory policy is part of application architecture.
When a configured memory limit is reached, the eviction policy decides what happens next. Redis documents policies that can evict keys based on recency, frequency, expiration status, or reject writes entirely.
This matters because not every Redis workload can tolerate eviction.
| Workload | Eviction tolerance | Hosting implication |
|---|---|---|
| Rebuildable read cache | Usually high | Managed or self-hosted both work |
| Sessions | Low to medium | Size memory and TTLs carefully |
| Rate limits | Medium | Eviction can change enforcement behavior |
| Locks | Low | Unexpected eviction can break coordination |
| Queues | Low | Job state should not disappear casually |
| Streams | Depends on retention model | Retention must be deliberate |
Do not mix a disposable cache and reliability-sensitive queues in the same instance without understanding the memory policy.
A useful separation is:
Cache workload -> eviction allowed -> short TTLs where appropriate Queue / session workload -> tighter memory limits -> persistence and recovery considered -> eviction behavior reviewed explicitly
The hosting model does not remove this design requirement. Managed services can provide the platform controls; the application still defines what data loss or eviction means.
Persistence changes the recovery requirement
Redis and Valkey support persistence mechanisms such as RDB snapshots and append-only files (AOF).
Valkey's official persistence documentation describes four broad options: RDB snapshots, AOF logging, no persistence, or RDB and AOF together. Redis documents the same core persistence models.
Use persistence according to the workload:
| Workload | Starting recovery model |
|---|---|
| Disposable cache | No persistence or limited snapshots may be enough |
| Sessions that can be recreated | Snapshot-based recovery may be sufficient |
| Queues or important short-lived state | Stronger persistence and tested recovery are justified |
| Durable business records | Keep the source of truth in a database designed for durable primary data |
Persistence is not the same as a complete backup strategy.
If losing Redis-compatible data causes customer-visible loss, define:
- what must survive;
- how much data loss is acceptable;
- how quickly the service must recover;
- where backups live;
- who restores them;
- when the last restore was tested.
For application architecture, Redis should usually support the durable database rather than quietly replace it.
Hosting cost includes operational ownership
A Redis hosting comparison should not compare only a managed plan with one VM.
Self-hosted cost includes:
VM resources + backup storage + monitoring + engineering time + maintenance + restore testing + incident response + spare capacity or replicas when required
Managed cost includes:
Managed database plan + optional availability / capacity features + application engineering + service constraints
The cheaper infrastructure line item is not automatically the cheaper production architecture.
A small development cache may be perfectly reasonable on one VM. A production session or queue layer may justify managed operations because the cost of an outage is larger than the difference between hosting models.
Use the same workload, recovery, and availability requirements when comparing both paths.
Raff supports managed Valkey and self-hosted Redis
Raff provides both operating models without presenting them as the same product.
The managed path is Valkey, which Raff describes as Redis-compatible and positions for caches, queues, and sessions. The current database console also provides a free Valkey entry point for evaluation and early integration work; confirm the live console for current eligibility and capacity before treating any free-tier limit as fixed.
The self-hosted path is a Raff VM, where the team can install Redis directly and control the operating system, configuration, persistence, modules, firewall, and backup workflow. Raff VM traffic uses 3 Gbps unmetered bandwidth, and private networking can keep application-to-Redis traffic away from the public internet.
The practical path is:
Need less Redis platform operations -> Managed Valkey -> validate client / command compatibility Need exact Redis or host-level control -> Self-host Redis on Raff VM -> own patching, monitoring, persistence, backups and recovery
Do not expose Redis publicly in either architecture. Managed deployments should use the service's scoped credentials and private or restricted connectivity. Self-hosted deployments should bind only to approved interfaces and enforce firewall rules around port 6379.
For role design after deployment, continue with Redis Cache and Queue Strategy for SaaS Apps.
Conclusion: choose Redis hosting from the responsibility boundary
Redis hosting is an operational decision as much as a performance decision.
Choose managed Valkey when your application needs a Redis-compatible cache, queue, or session layer and reducing host-level operations is valuable. Choose self-hosted Redis when exact Redis behavior, root access, custom modules, or host-level configuration is a documented requirement and your team can own the full lifecycle.
The safest choice is the one your team can monitor, recover, resize, and secure after Redis becomes production-critical—not only the option that is fastest to deploy today.