Dora NodaRailway's August 2026 changelog turned a standalone Redis service into a one-click high-availability cluster: Sentinel-managed failover with HAProxy connection routing, replica and proxy counts picked in the dashboard, staged changes with a cluster view. Here is the honest monthly accounting for a small 3-node cluster holding about 1 GB: roughly $55-80 on Railway's meter against roughly $18 on three flat-fee Hetzner VMs running the same Sentinel topology as Valkey. "Owned nodes" in this post means exactly that — three CX23-class cloud VMs (2 shared vCPUs, 4 GB RAM, 40 GB NVMe, €5.49/month each after the June 2026 Hetzner price adjustment) that you operate yourself.
The gap — about 4x at small scale, widening as the dataset grows — is the clearest current example of the managed-data-layer premium: every gigabyte of dataset meters three times (once per replica) at $10/GB/month, plus two proxy services, plus the conversion gotchas below. Whether that premium is worth it depends on how you value the five ops jobs in section 5 that a self-operated Valkey cluster does not do for itself.
| What you are comparing | Railway (metered) | Owned Hetzner nodes (flat) |
|---|---|---|
| Small Redis/Valkey HA, ~1 GB dataset, 3 data nodes | ≈ $55-80/month (math below) | ≈ $18/month (3 × CX23 at €5.49) |
| Same, dataset doubled to ~2 GB | ≈ $85-110/month (RAM meters 3x) | ≈ $18/month (same flat boxes) |
| Same, grown to 5 data nodes | ≈ 5/3x the 3-node meter | 5 × €5.49 ≈ $30/month |
| What the extra dollars buy | Failover, entry point, AOF, backups, patching handled | You handle all five (hours, not dollars) |
This post stays Redis-scoped: Railway's MySQL HA is a separate Group Replication template that went GA in September 2026, and we priced the whole managed-data bundle — Postgres patching, MySQL and Redis HA together — separately. What follows is the Redis convert flow torn down line by line.
What Convert to HA actually provisions
The conversion guide is refreshingly explicit about the resulting shape. Your original service becomes the primary, and Railway stages the rest as reviewable changes before anything deploys. Each piece maps to a meter line:
| Provisioned piece | What it is | What it meters |
|---|---|---|
| Data nodes (3, 5, 7, or 9 total) | Primary plus 2/4/6/8 replicas; every node runs a colocated Sentinel, so the voter count stays odd for quorum | Each node meters its own vCPU + RAM independently — replicas are not free riders |
| HAProxy entry points (1 or 2) | Separate proxy services that health-check every node and route clients to the current primary | Each proxy is a billed service; small at idle, growing with connection churn and throughput |
| Forced AOF persistence | The cluster always runs with append-only-file persistence so restarted nodes come back with data | Extra disk writes and volume usage on every node versus a cache-only standalone |
| Version pinning to your exact major.minor | Replicas sync via RDB snapshots, which are unreadable across mismatched versions | No direct charge — but it locks the cluster to Redis majors 7 or 8 and forbids :latest |
| Pre-conversion volume backup | Automatic backup of the database volume, expiring in 21 days | Short-lived storage, then gone |
The engineering underneath is genuinely solid: the open redis-ha template runs a small Rust supervisor over official redis plus HAProxy images, with deterministic config generation, hostname-based peer tracking that survives Railway IP changes on redeploy, and failover in roughly 5-30 seconds via Sentinel majority vote. Nothing about this teardown disputes the quality — it prices the bundle.
Two prerequisites deserve emphasis because they gate who can even click the button. First, the service must run the official redis image (or the template's own sentinel image, or the legacy Bitnami lineage) tagged at major 7 or 8, with no custom start command. Second — and this is section 4's whole subject — forks and bundles are explicitly excluded: Valkey and Redis Stack services cannot be converted.
The conversion's non-dollar costs
Railway's own confirmation dialog warns about the first two items; the docs spell out the rest. None of them is a reason to refuse HA. All of them belong in the migration plan:
- Active connections are dropped during conversion. There is a real cutover window: clients must reconnect against the new HAProxy endpoint. Most Redis clients reconnect by default, but anything with a single long-lived connection and no retry logic will feel this as an outage, not a blip.
- Connection endpoints change, and hardcoded strings will not follow. Railway auto-migrates variable references within your project to the new Redis HA service — but literal URLs baked into application code, other projects, external tools, or CI pipelines must be hunted down and repointed by hand. Every hardcoded
REDIS_URLyou ever wrote comes due at once. - Reverting keeps every deleted node's volume — still billing. Revert to standalone and the replicas' volumes stay in your project, unattached, counting toward storage billing. Deliberate (a revert never destroys data), but the cleanup is manual, and a later re-conversion provisions fresh suffixed volumes rather than reusing the kept ones.
- Reverting is only available while the original service is the primary. If a failover has moved the primary role elsewhere, you must
Make Leaderthe original node back first — the revert flow offers this, but it is a coordinated switchover with its own brief connection drop, on top of the revert itself. (The reverted service also stays on theredis-sentinelimage; swapping it back toredis:Xby hand drops the--requirepasswiring and breaks password auth.)
None of this is unusual for a managed topology change. It is, however, the opposite of zero-cost: the button is one click, the surrounding work is a checklist.
The Valkey exclusion
The docs state it plainly: forks and bundles (Valkey, Redis Stack) are not compatible with conversion. The machinery explains why — the template pins official redis majors, generates config for the redis-server binary, and versions RDB compatibility around it. A Valkey service simply never gets the High Availability section in its Config tab.
The context, in three sentences: Redis moved off the BSD license in March 2024. The Linux Foundation forked the last BSD release (7.2.4) as Valkey days later. Valkey has since grown into an independent BSD-licensed 8.x line, backed by AWS, Google, and Oracle, speaking the same wire protocol and running Sentinel with identical configuration. A team that already migrated to Valkey for licensing reasons cannot click Railway's HA button at all — which makes self-operated Valkey-plus-Sentinel not just the cheaper topology, but the only HA topology available to them on this stack.
That is the setup for the other side of the ledger.
The same topology for a flat fee
Three CX23-class VMs at €5.49/month each is €16.50/month — about $18. Included NVMe (40 GB each) holds AOF files with room to spare, and 20 TB of included traffic each means replication chatter and client connections cost nothing extra. If the dataset needs more RAM headroom, the ARM alternative is three CAX21 machines (4 ARM vCPUs, 8 GB RAM, €10.49/month post-hike) at roughly $34/month total — still less than half the metered cluster, because the June 2026 hike hit dedicated x86 hardest (+173% on CCX23) while shared and ARM tiers moved 30-40%.
So the hardware side is a solved equation. The real price is attention:
| Job Railway absorbs | Self-operated Valkey equivalent | Steady-state burden |
|---|---|---|
| Sentinel quorum + election | Three valkey-sentinel processes, quorum of 2, tested promotion | An afternoon to configure; a chaos drill per quarter to trust |
| Stable entry point | HAProxy pair (or client-side Sentinel-aware failover) | HAProxy config is small; client-side failover pushes the logic into every app |
| Persistence that survives restarts | AOF + RDB snapshot policy per node | One config decision, then disk monitoring |
| Backups before topology changes | Volume snapshots or valkey-cli --rdb dumps to object storage on a schedule | The dump job is 20% of the work; proving restores work is the other 80% |
| Security patch timeline | Track Valkey/Redis CVE releases, rebuild images, roll nodes | Hours per release, on someone else's calendar — managed fleets patch underneath you |
The last row is the moat at its most literal. Redis shipped authenticated-RCE-class flaws in 2026 that managed clouds patched silently while self-managed fleets scheduled their own upgrades. Valkey inherits the same exposure profile (same protocol surface, same C codebase lineage) without inheriting anyone else's patching staff. The meter charges for absence of pages, and this is the page it most reliably prevents.
Where the math moves
The 4x headline holds for the typical small case, but four variables move it — check each before generalizing:
- Dataset RAM dominates everything. This is the single most important sensitivity: on Railway HA, each gigabyte of dataset lives on all three replicas and meters at roughly $10/GB on each, so dataset growth costs ~$30/GB/month. On flat boxes the same growth costs $0 until you resize the VM. A 5 GB dataset is roughly $200/month metered versus the same $18 flat. RAM-heavy is where the premium compounds fastest.
- Replica steps multiply the meter linearly. Moving from 2 to 4 replicas (3 to 5 nodes) multiplies the data-node meter by 5/3 for extra read capacity and quorum margin most small teams never need. On owned nodes the same move adds €11/month.
- Proxy count and traffic are second-order. Dropping to one HAProxy saves one small service but reintroduces a single entry point — the thing HA was bought to remove. Public exposure adds TCP-proxy egress on top. Neither decides the comparison; size them after the data nodes.
- The Hetzner side has its own post-hike shape. Dedicated x86 (CCX23 at €85.99) is no longer the obvious database VM after June 2026; shared CX23 and ARM CAX21 are. A Valkey cluster does not need dedicated cores — it needs RAM and network stability — so the hike barely touches this topology. That will not be true for every workload you migrate alongside it.
The verdict rule: if your Redis holds under ~2 GB, your team has no on-call rotation, and a dropped-connections cutover is acceptable planned work, the meter is a fair price for never thinking about Sentinel quorum again. Past that — bigger datasets, an existing ops practice, Valkey already in the stack, or a fleet where three more small VMs are a rounding error — the failover bundle is the first line item a migration off Railway deletes, because it is the rare managed feature whose self-hosted equivalent is the same software, not a worse approximation.
That last point is why this example matters beyond Redis. Managed databases are an explicit bex non-goal — we will never run your database for you — and posts like this one are the honest version of that position: here is the exact ops burden leaving buys you out of, priced to the dollar, so you can decide with the invoice in one hand and the runbook in the other.
Bex.co is the open-source, AI-native Render alternative — push a git repo, get a running HTTPS service on machines you own. Star the repo on GitHub or deploy your first app today.
