[{"data":1,"prerenderedAt":1190},["ShallowReactive",2],{"blog-en-\u002Fen\u002Fblog\u002Fredis-in-production-managed-vs-self-hosted":3,"blog-en-surround-\u002Fen\u002Fblog\u002Fredis-in-production-managed-vs-self-hosted":1177},{"id":4,"title":5,"author":6,"body":7,"category":1159,"cover":1160,"date":1161,"description":1162,"draft":1163,"extension":1164,"lastReviewed":1160,"meta":1165,"navigation":1166,"path":1167,"readingTime":1168,"seo":1169,"sitemap":1170,"stem":1171,"tags":1172,"__hash__":1176},"blog_en\u002Fen\u002Fblog\u002Fredis-in-production-managed-vs-self-hosted.md","Redis (and Valkey) in production: managed vs self-hosted in 2026","HeroCtl team",{"type":8,"value":9,"toc":1129},"minimark",[10,27,32,52,56,59,62,68,75,79,83,89,95,101,104,110,115,120,123,129,134,139,142,148,153,164,168,171,217,221,224,228,231,264,267,271,274,288,295,299,313,316,320,354,357,361,364,378,385,389,392,474,477,481,484,490,496,503,506,510,513,545,548,552,559,562,566,871,875,878,904,908,911,937,941,944,965,975,978,981,985,1010,1024,1030,1039,1045,1051,1057,1063,1067,1070,1076,1079,1112,1125],[11,12,13,14,18,19,22,23,26],"p",{},"The question \"managed or self-hosted Redis?\" became another question at the end of March 2024. That's when the company behind Redis switched the license from Apache 2.0 \u002F BSD to a combination of RSAL with SSPL — a pair of \"source available\" licenses designed to prevent cloud providers from offering Redis as a service without commercial licensing. The reaction was quick: the Linux Foundation launched ",[15,16,17],"strong",{},"Valkey"," as a direct fork from the last BSD version, with AWS, Google, and Oracle backing the development. In parallel, projects that already existed — ",[15,20,21],{},"KeyDB"," and ",[15,24,25],{},"Dragonfly"," — started appearing more frequently in benchmarks of companies reassessing their stack.",[28,29,31],"h2",{"id":30},"tldr","TL;DR",[11,33,34,35,38,39,41,42,44,45,47,48,51],{},"In 2026, \"Redis in production\" became a category with four implementations disputing the same protocol: ",[15,36,37],{},"Redis OSS"," (BSD pre-2024 or RSAL post), ",[15,40,17],{}," (BSD, drop-in via fork), ",[15,43,21],{}," (multi-thread, old fork), and ",[15,46,25],{}," (BSL, rewritten from scratch in C++). Self-hosting any of the four costs between R$30 and R$130 per month on Hetzner VPS. The managed path costs from R$75 (ElastiCache micro) to R$1,000\u002Fmonth (13 GB instance), plus Upstash with serverless billing varying US$0–100\u002Fmonth. For Brazilian startup with MRR below R$200k, ",[15,49,50],{},"self-hosted Valkey"," on its own cluster saves between R$300 and R$1,500 per month compared to managed, eliminates RSAL license exposure, and maintains full compatibility with Redis clients. Switching the stack after adopting the commercial version is real pain — starting with the OSS-friendly version is the bet with the lowest exit cost. This post compares the four products, the three managed paths (ElastiCache, Upstash, Redis Cloud), and the minimum configuration to run Valkey in production without losing sleep.",[28,53,55],{"id":54},"the-short-story-of-the-license-change","The short story of the license change",[11,57,58],{},"Before March 2024, \"Redis\" was the dominant OSS cache: BSD, gigantic ecosystem, present in any stack that had ever fit the word \"Rails\" or \"Node\" on a résumé. The commercial vendor — Redis Inc, formerly Redis Labs — lived well off the managed product and the paid modules (Search, JSON, TimeSeries).",[11,60,61],{},"Then came the announcement: version 7.4 onward would ship under RSAL + SSPL, no longer BSD. In practical terms, the change directly targeted AWS, Google, and Azure. The internal reading from those who produce open source software was different: \"if it happened to Redis, it can happen to any VC-funded project\". It was the third recent case — after Elastic in 2021 and MongoDB in 2018 — where a project that seemed consolidated changed the rules.",[11,63,64,65,67],{},"The Linux Foundation was quick. Five days after the announcement, ",[15,66,17],{}," was formed as a fork of the last BSD version (7.2.4), with independent governance and weighty backers: AWS, Google Cloud, Oracle, Ericsson, Snap. In just over a year, AWS had already migrated ElastiCache's default engine to Valkey. Google Memorystore followed. In 2026, Valkey stopped being \"experimental fork\" to become a growing reference — with 7.x and 8.x versions already incorporating its own optimizations that weren't even offered to Redis OSS.",[11,69,70,71,74],{},"The operational lesson for those choosing cache today: ",[15,72,73],{},"the mainstream moved",". There's no longer the inertia of \"no one was fired for choosing Redis\" — the question in the architecture interview became \"why Redis and not Valkey?\". And the honest answer, in most cases, is \"habit\".",[28,76,78],{"id":77},"what-are-the-four-products-disputing-this-market","What are the four products disputing this market?",[80,81,37],"h3",{"id":82},"redis-oss",[11,84,85,88],{},[15,86,87],{},"The original."," Versions before 7.4 are still under BSD and remain usable indefinitely — no one revokes a license retroactively. Versions 7.4 onward ship under RSAL\u002FSSPL.",[11,90,91,94],{},[15,92,93],{},"Pros",": still huge community, battle-tested in production for over a decade, richer ecosystem (modules, integrations, books, talks). Almost every client library tested against Redis OSS first.",[11,96,97,100],{},[15,98,99],{},"Cons",": the RSAL prevents offering-as-a-service without commercial licensing. For those operating Redis for internal use, that's irrelevant — the restriction is about resale. The real risk is strategic: if the vendor changed the license once, they can change it again. Adopting Redis OSS in 2026 means betting that the next critical feature will descend to the open branch, and not stay in the commercial product.",[80,102,17],{"id":103},"valkey",[11,105,106,109],{},[15,107,108],{},"The Linux Foundation fork."," Took the code from 7.2.4 BSD and kept developing. Drop-in replacement at the protocol level: no client needs to change a line of code to swap Redis for Valkey.",[11,111,112,114],{},[15,113,93],{},": permanent BSD guaranteed by neutral governance (it's not a company, it's a foundation). Big backers align incentives to keep the project healthy. Technical parity with Redis 7.x and growing development speed.",[11,116,117,119],{},[15,118,99],{},": the brand is still being built — some third-party plugins and very specific SDKs still only list \"Redis\" in the README. In 2026 that's increasingly cosmetic, but it can show up in old integrations needing minor adaptation.",[80,121,21],{"id":122},"keydb",[11,124,125,128],{},[15,126,127],{},"The multi-thread fork."," Has existed since 2019, was acquired by Snap in 2022, lives today as Snap-Telemetry project. The architectural difference is fundamental: Redis OSS and Valkey are single-thread by design (one main thread processes all commands). KeyDB runs multi-thread by default.",[11,130,131,133],{},[15,132,93],{},": on CPUs with 4+ cores, KeyDB delivers 2 to 3 times more throughput than single-thread Redis on the same hardware. API is compatible, so the client doesn't change. For CPU-bound workloads with high volume, it's the obvious choice.",[11,135,136,138],{},[15,137,99],{},": smaller community, pace of adopting new Redis features usually lags quarters behind. Some new Redis features (Functions, certain extensions) take time to appear in KeyDB.",[80,140,25],{"id":141},"dragonfly",[11,143,144,147],{},[15,145,146],{},"The rewrite."," Not a fork — it's a new implementation in modern C++, with hash table designed for cache (not Redis's generic structure), using io_uring on Linux for asynchronous I\u002FO. Compatibility at the protocol level, not at the code level.",[11,149,150,152],{},[15,151,93],{},": claims of 25× throughput in specific benchmarks (heavy pipelines on modern hardware). Real memory efficiency — 2 to 3 times more data in the same RAM as Redis. No implicit GIL of single-thread; scales vertically on a machine with 32+ cores.",[11,154,155,157,158,163],{},[15,156,99],{},": BSL (Business Source License) license — stays closed for 4 years before becoming Apache 2.0. It's exactly the same license pattern that caught other projects in the orchestration industry by surprise, which we covered in our post on ",[159,160,162],"a",{"href":161},"\u002Fen\u002Fblog\u002Fwhy-we-built-heroctl","why we built HeroCtl",". Some commands still incompatible with Redis in edge cases (complex Lua scripts, certain cluster operations).",[28,165,167],{"id":166},"which-to-choose-for-a-new-project-in-2026","Which to choose for a new project in 2026?",[11,169,170],{},"The short decision tree:",[172,173,174,184,192,200,209],"ul",{},[175,176,177,180,181,183],"li",{},[15,178,179],{},"Sensible default",": ",[15,182,17],{},". Permanent BSD, Redis parity, client doesn't need to change, future guaranteed by big backers. There's no technical reason to prefer Redis OSS for a new project in 2026.",[175,185,186,180,189,191],{},[15,187,188],{},"Critical performance",[15,190,25],{},", if the application sustains above 100k operations per second and the team accepts the BSL license risk.",[175,193,194,180,197,199],{},[15,195,196],{},"Multi-thread without rewrite",[15,198,21],{},", if the bottleneck is CPU on big hardware and the team prefers not to migrate to Dragonfly.",[175,201,202,180,205,208],{},[15,203,204],{},"Extreme simplicity (1 VPS, low volume)",[15,206,207],{},"Redis OSS 7.2.4 BSD"," still works perfectly. Crystallized as a stable version; will run on any Debian\u002FAlpine for the next five years without complaining.",[175,210,211,180,214,216],{},[15,212,213],{},"Migrating from Redis Labs managed",[15,215,17],{}," is drop-in. Zero code changing. Migration is only operational — replication, DNS swap, rollback if necessary.",[28,218,220],{"id":219},"managed-vs-self-hosted-the-math-without-frills","Managed vs self-hosted: the math without frills",[11,222,223],{},"The numbers below are list price in May 2026, R$5\u002FUSD exchange rate.",[80,225,227],{"id":226},"aws-elasticache","AWS ElastiCache",[11,229,230],{},"Grows in steps per instance:",[172,232,233,243,249,258],{},[175,234,235,239,240],{},[236,237,238],"code",{},"cache.t4g.micro"," (1 GB): about US$15\u002Fmonth = ",[15,241,242],{},"R$75\u002Fmonth",[175,244,245,248],{},[236,246,247],{},"cache.t4g.small"," (2 GB): US$30\u002Fmonth = R$150\u002Fmonth",[175,250,251,254,255],{},[236,252,253],{},"cache.r6g.large"," (13 GB): about US$200\u002Fmonth = ",[15,256,257],{},"R$1,000\u002Fmonth",[175,259,260,263],{},[236,261,262],{},"cache.r6g.xlarge"," (26 GB): about US$400\u002Fmonth = R$2,000\u002Fmonth",[11,265,266],{},"Multi-AZ doubles the price (replica in another zone). Automatic backup is included. Real Multi-AZ failover is the main argument — you pay not to have to think about it.",[80,268,270],{"id":269},"upstash","Upstash",[11,272,273],{},"Serverless billing per command:",[172,275,276,279,282,285],{},[175,277,278],{},"Free tier: 256 MB, 500k commands\u002Fday",[175,280,281],{},"Pay-as-you-go: US$0.2 per 100k commands",[175,283,284],{},"For startup with medium volume (10M commands\u002Fday): about US$60\u002Fmonth = R$300\u002Fmonth",[175,286,287],{},"For app with low peak: can stay between US$0 and US$10\u002Fmonth",[11,289,290,291,294],{},"The unique operational advantage: ",[15,292,293],{},"zero pre-allocated capacity",". If the app sleeps, the bill sleeps. For Vercel\u002FCloudflare Workers, it's the natural complement. For sustained and predictable load, it ends up more expensive than ElastiCache.",[80,296,298],{"id":297},"redis-cloud-direct-offer-from-redis-inc","Redis Cloud (direct offer from Redis Inc)",[172,300,301,304,310],{},[175,302,303],{},"Essentials Plan 30MB: free",[175,305,306,307],{},"Pro Plan 5GB single-region: about US$50\u002Fmonth = ",[15,308,309],{},"R$250\u002Fmonth",[175,311,312],{},"Pro Plan 10GB multi-AZ: about US$120\u002Fmonth = R$600\u002Fmonth",[11,314,315],{},"Includes commercial modules (Search, JSON, TimeSeries) that don't exist in Valkey or Redis OSS. If you use those modules, there's no direct alternative — it's Redis Cloud or buy commercial license and self-host.",[80,317,319],{"id":318},"self-hosted-on-hetzner","Self-hosted on Hetzner",[172,321,322,332,338,348],{},[175,323,324,327,328,331],{},[15,325,326],{},"CPX21"," (3 vCPU, 4 GB RAM, 80 GB SSD): €7.99 = ",[15,329,330],{},"R$44\u002Fmonth",". Fits 2 GB Valkey with room to spare.",[175,333,334,337],{},[15,335,336],{},"CPX31"," (4 vCPU, 8 GB RAM, 160 GB SSD): €13.99 = R$78\u002Fmonth.",[175,339,340,343,344,347],{},[15,341,342],{},"Cluster of 3 CPX21 for Valkey + Sentinel HA",": 3 × €7.99 = €24\u002Fmonth = ",[15,345,346],{},"R$130\u002Fmonth",".",[175,349,350,353],{},[15,351,352],{},"Cluster of 3 CPX31 for serious data",": €42\u002Fmonth = R$230\u002Fmonth.",[11,355,356],{},"For DigitalOcean, Linode, Vultr, multiply by approximately 1.5×. For AWS EC2, multiply by 2×. But in any case it stays cheaper than the equivalent managed.",[80,358,360],{"id":359},"practical-difference","Practical difference",[11,362,363],{},"For 8 GB cache workload with replication:",[172,365,366,369,372,375],{},[175,367,368],{},"ElastiCache Multi-AZ: ~R$1,000\u002Fmonth",[175,370,371],{},"Redis Cloud Pro Multi-AZ: ~R$600\u002Fmonth",[175,373,374],{},"Self-hosted Valkey on 3× Hetzner CPX31: R$230\u002Fmonth",[175,376,377],{},"Single-node Valkey on 1× Hetzner CPX31 + S3 backup: R$80\u002Fmonth",[11,379,380,381,384],{},"Whoever chooses the managed path pays ",[15,382,383],{},"3 to 10 times more"," for the same throughput. The difference is what you buy with that: contractual SLA, automatic multi-AZ failover, absence of 3 a.m. pager. For a small team, that may be worth the price. For a team that already operates Linux servers in production, it usually isn't.",[28,386,388],{"id":387},"minimum-production-grade-valkey-stack","Minimum production-grade Valkey stack",[11,390,391],{},"Configuration that withstands real production without theater:",[172,393,394,400,409,424,430,436,442,448],{},[175,395,396,399],{},[15,397,398],{},"Container or systemd service on dedicated VPS."," Don't share the machine with the application — cache and app compete for RAM, and when it goes wrong it goes wrong for both at the same time.",[175,401,402,408],{},[15,403,404,407],{},[236,405,406],{},"maxmemory"," configured"," between 50 and 70% of available RAM. Leaving memory for the system and network buffers is more important than having the last megabytes for cache.",[175,410,411,180,416,419,420,423],{},[15,412,413],{},[236,414,415],{},"maxmemory-policy",[236,417,418],{},"allkeys-lru"," if pure cache mode (throw out old keys when full). ",[236,421,422],{},"noeviction"," if storage mode (queue, sessions) — there prefer write error to silently losing data.",[175,425,426,429],{},[15,427,428],{},"AOF persistence"," if the load is job queue (Sidekiq, BullMQ, Resque). Without AOF, a restart loses any job that was queued but unprocessed. RDB is insufficient in that scenario because snapshot is periodic.",[175,431,432,435],{},[15,433,434],{},"Sufficient RDB"," if the load is pure cache (Rails cache, Django cache). If restarting losing cache only means \"slow request for a few seconds while it warms up\", AOF is unnecessary overhead.",[175,437,438,441],{},[15,439,440],{},"Async replication to standby"," on a second node. Manual failover with internal DNS swap is acceptable for many cases. Automatic failover costs Sentinel or Cluster.",[175,443,444,447],{},[15,445,446],{},"AOF + RDB backup to S3"," or compatible, daily. Restic or rclone solve well.",[175,449,450,453,454,457,458,461,462,461,465,461,468,461,471,347],{},[15,451,452],{},"Monitoring"," with ",[236,455,456],{},"redis_exporter"," exporting to Prometheus + alerts on Grafana or similar. Critical metrics: ",[236,459,460],{},"connected_clients",", ",[236,463,464],{},"used_memory",[236,466,467],{},"evicted_keys",[236,469,470],{},"keyspace_hits\u002Fmisses",[236,472,473],{},"latency_percentiles",[11,475,476],{},"This setup runs comfortably on CPX21 (R$44\u002Fmonth) serving 50k+ ops\u002Fs sustained for average Brazilian app.",[28,478,480],{"id":479},"sentinel-or-cluster","Sentinel or Cluster?",[11,482,483],{},"Question that confuses many teams coming to Redis for the first time.",[11,485,486,489],{},[15,487,488],{},"Sentinel",": 1 master + N replicas + 3+ sentinel processes monitoring. Automatic failover when master falls — a sentinel detects, the sentinels vote, a replica becomes master, clients receive new endpoint via discovery. All on a single shard — the entire dataset fits on one node.",[11,491,492,495],{},[15,493,494],{},"Cluster",": dataset partitioned into 16384 slots distributed across 3+ masters. Each master has its own replicas. Multi-shard, horizontal capacity scaling — you can have 100 GB total with no individual node holding more than 20 GB.",[11,497,498,499,502],{},"The practical rule: ",[15,500,501],{},"Sentinel is enough up to ~100 GB dataset",". Above that, Cluster is necessary. For most Brazilian startups, Sentinel is the right choice for simplicity — Cluster adds real complexity (key needs hashtag for multi-key operations, Lua scripts get restricted to a slot, some clients have bugs in cluster mode).",[11,504,505],{},"Don't use Cluster for status. Use Sentinel until the metric forces.",[28,507,509],{"id":508},"sidekiq-bullmq-and-friends-patterns","Sidekiq, BullMQ and friends patterns",[11,511,512],{},"Real use, not marketing diagram:",[172,514,515,521,527,533,539],{},[175,516,517,520],{},[15,518,519],{},"Sidekiq Ruby",": Redis needs AOF. Without AOF, any crash loses queued jobs that haven't yet been picked up. Sidekiq Pro adds \"reliable fetch\" that improves — but the backstop is still AOF.",[175,522,523,526],{},[15,524,525],{},"BullMQ Node",": similar. AOF essential for durability. BullMQ uses data structures that depend on Redis transactional atomicity — restart without AOF can leave queue in inconsistent state.",[175,528,529,532],{},[15,530,531],{},"Resque Ruby",": the father of all. AOF necessary for the same reasons.",[175,534,535,538],{},[15,536,537],{},"Pure cache (Rails.cache, Django cache, Laravel cache)",": can run without AOF, RDB sufficient. Losing cache on restart is acceptable.",[175,540,541,544],{},[15,542,543],{},"Pure pub\u002Fsub",": doesn't even need persistence. Pub\u002Fsub is fire-and-forget by design.",[11,546,547],{},"Mixing cache and queue use on the same Redis works — just configure AOF (the \"worst case\" load determines). But for serious workload, separating into two instances (one for cache without AOF, another for queue with AOF) is cleaner. Operationally cheap if there's already an orchestrator running.",[28,549,551],{"id":550},"is-elasticache-sao-paulo-reliable","Is ElastiCache São Paulo reliable?",[11,553,554,555,558],{},"Yes — 99.99% contractual uptime SLA, multi-AZ in São Paulo region (",[236,556,557],{},"sa-east-1","), automatic backup, tested failover. Latency from Brazilian app to ElastiCache São Paulo stays at 1-3ms, indistinguishable from local Redis for most workloads.",[11,560,561],{},"The weak point isn't technical reliability, it's cost and lock-in. AWS Brazil charges about 30% more than North American regions for the same resource. And migrating from ElastiCache to another provider later involves dump\u002Frestore + coordinated cutover — not apocalypse, but it's weekend work.",[28,563,565],{"id":564},"comparison-table-12-criteria","Comparison table: 12 criteria",[567,568,569,595],"table",{},[570,571,572],"thead",{},[573,574,575,579,581,583,585,587,590,592],"tr",{},[576,577,578],"th",{},"Criterion",[576,580,37],{},[576,582,17],{},[576,584,21],{},[576,586,25],{},[576,588,589],{},"ElastiCache",[576,591,270],{},[576,593,594],{},"Self-hosted Valkey",[596,597,598,624,648,670,695,716,738,759,782,806,829,850],"tbody",{},[573,599,600,604,607,610,612,615,618,621],{},[601,602,603],"td",{},"License",[601,605,606],{},"RSAL\u002FSSPL (7.4+)",[601,608,609],{},"BSD",[601,611,609],{},[601,613,614],{},"BSL → Apache 4 years",[601,616,617],{},"Commercial AWS",[601,619,620],{},"Commercial Upstash",[601,622,623],{},"Permanent BSD",[573,625,626,629,632,634,637,639,642,645],{},[601,627,628],{},"Threading",[601,630,631],{},"Single",[601,633,631],{},[601,635,636],{},"Multi",[601,638,636],{},[601,640,641],{},"Single (engine 7)",[601,643,644],{},"Serverless",[601,646,647],{},"Configurable",[573,649,650,653,656,658,660,663,665,668],{},[601,651,652],{},"Redis client compat.",[601,654,655],{},"100%",[601,657,655],{},[601,659,655],{},[601,661,662],{},"95%+",[601,664,655],{},[601,666,667],{},"100% (subset of commands)",[601,669,655],{},[573,671,672,675,678,680,683,686,689,692],{},[601,673,674],{},"Baseline throughput",[601,676,677],{},"100k ops\u002Fs",[601,679,677],{},[601,681,682],{},"250k ops\u002Fs",[601,684,685],{},"1M+ ops\u002Fs",[601,687,688],{},"depends on inst.",[601,690,691],{},"depends on plan",[601,693,694],{},"100-250k ops\u002Fs",[573,696,697,699,702,704,706,708,711,714],{},[601,698,428],{},[601,700,701],{},"Yes",[601,703,701],{},[601,705,701],{},[601,707,701],{},[601,709,710],{},"Yes (snapshot)",[601,712,713],{},"Managed",[601,715,701],{},[573,717,718,721,723,725,727,729,732,735],{},[601,719,720],{},"Replication",[601,722,701],{},[601,724,701],{},[601,726,701],{},[601,728,701],{},[601,730,731],{},"Multi-AZ",[601,733,734],{},"Multi-region",[601,736,737],{},"Yes (manual config)",[573,739,740,743,746,748,750,752,755,757],{},[601,741,742],{},"Automatic failover",[601,744,745],{},"Sentinel\u002FCluster",[601,747,745],{},[601,749,745],{},[601,751,494],{},[601,753,754],{},"Built-in",[601,756,754],{},[601,758,745],{},[573,760,761,764,767,769,771,773,776,779],{},[601,762,763],{},"Cost 8GB\u002Fmonth (R$)",[601,765,766],{},"80 (VPS)",[601,768,766],{},[601,770,766],{},[601,772,766],{},[601,774,775],{},"1000 (Multi-AZ)",[601,777,778],{},"300-500",[601,780,781],{},"80-230",[573,783,784,787,790,793,795,798,801,804],{},[601,785,786],{},"Lock-in",[601,788,789],{},"Medium (license)",[601,791,792],{},"Low",[601,794,792],{},[601,796,797],{},"Medium (BSL)",[601,799,800],{},"High (AWS)",[601,802,803],{},"High (Upstash API)",[601,805,792],{},[573,807,808,811,814,817,819,821,824,827],{},[601,809,810],{},"Premium modules",[601,812,813],{},"Paid",[601,815,816],{},"N\u002FA",[601,818,816],{},[601,820,816],{},[601,822,823],{},"Add-on $$",[601,825,826],{},"Limited",[601,828,816],{},[573,830,831,834,837,839,841,843,846,848],{},[601,832,833],{},"Operational",[601,835,836],{},"You",[601,838,836],{},[601,840,836],{},[601,842,836],{},[601,844,845],{},"AWS",[601,847,270],{},[601,849,836],{},[573,851,852,855,857,860,862,864,867,869],{},[601,853,854],{},"SLA support",[601,856,813],{},[601,858,859],{},"Community",[601,861,859],{},[601,863,813],{},[601,865,866],{},"Included",[601,868,866],{},[601,870,836],{},[28,872,874],{"id":873},"when-managed-still-makes-sense","When managed still makes sense",[11,876,877],{},"Honesty is the defense mechanism of any technical recommendation. There are four profiles where paying for managed is the right choice:",[172,879,880,886,892,898],{},[175,881,882,885],{},[15,883,884],{},"Team without operational capacity for Redis cluster."," If no one in the company knows how to debug a master that no longer responds, or interpret RDB fork latency, or take care of AOF backup — paying AWS to do that is rational. It's not an excuse, it's division of labor.",[175,887,888,891],{},[15,889,890],{},"Compliance requiring SOC2\u002FISO certified vendor."," Audit asking for \"certified vendor X\" doesn't accept \"we run Valkey on a Hetzner VPS\". The path is ElastiCache, Redis Cloud, or similar with certifications in the contract.",[175,893,894,897],{},[15,895,896],{},"Volume needing instant scale."," Application going from 100 req\u002Fs to 100k req\u002Fs in 5 minutes due to viral campaign — Upstash's serverless path is where it shines. Self-hosted needs reserved capacity beforehand; serverless grows on the fly.",[175,899,900,903],{},[15,901,902],{},"Fully serverless application."," If the app runs on Vercel or Cloudflare Workers and Redis also needs to be serverless by billing model, Upstash is practically the only sane option. Connecting edge functions to a Redis on VPS implies bad cold start.",[28,905,907],{"id":906},"when-self-hosting-is-obvious","When self-hosting is obvious",[11,909,910],{},"And four profiles where paying managed is waste:",[172,912,913,919,925,931],{},[175,914,915,918],{},[15,916,917],{},"Startup with R$10k–R$200k MRR optimizing cost."," The difference between R$80\u002Fmonth and R$1,000\u002Fmonth of cache is 1% of total cost of a small SaaS; it's also 11 hours of dev person-hour salary. Worth doing the math.",[175,920,921,924],{},[15,922,923],{},"Predictable workload."," If cache volume grows 10% per month, there's no advantage in serverless scaling. Reserved capacity on VPS is cheaper and more predictable.",[175,926,927,930],{},[15,928,929],{},"Team has 1+ person comfortable with Linux\u002FDocker."," If there's already someone who operates Postgres, nginx, Docker — Redis\u002FValkey is easier than any of them. Learning curve is days, not weeks.",[175,932,933,936],{},[15,934,935],{},"Already have own cluster."," If the company runs an orchestrator (HeroCtl, Coolify, similar platform) with spare nodes, Valkey becomes just another job. Marginal cost close to zero — you already pay for the nodes.",[28,938,940],{"id":939},"heroctl-as-infrastructure-for-valkey","HeroCtl as infrastructure for Valkey",[11,942,943],{},"For those operating HeroCtl, running Valkey in production is a short configuration exercise. A ~30-line file describes a job with:",[172,945,946,949,952,955,958],{},[175,947,948],{},"Official Valkey 8.x container",[175,950,951],{},"Replicated named volume between nodes (data survives kill -9 of server)",[175,953,954],{},"Reserved resources (RAM and CPU) with hard limits",[175,956,957],{},"Health check on Valkey ping",[175,959,960,961,964],{},"Internal routing between services (the app talks to ",[236,962,963],{},"valkey.servico.local"," without exposing port to the internet)",[11,966,967,968,971,972,974],{},"Automated AOF + RDB backup to S3-compatible is available in the ",[15,969,970],{},"Business"," plan — without setting up external restic, without manual cron on the host. Valkey metrics come out via ",[236,973,456],{}," running as sidecar and appear in the internal Prometheus (already included as a job of the cluster itself, no external stack).",[11,976,977],{},"Sentinel failover is integrated with the orchestrator's control plane: if the Valkey master node falls, the cluster detects in around 7 seconds and the replica is promoted. The app's configuration is updated via service discovery — no manual redeploy.",[11,979,980],{},"For a startup with 4 servers running the orchestrator, this setup replaces entire ElastiCache Multi-AZ at zero marginal cost (the servers are already there). The real monthly difference is the salary-equivalent of one person, depending on the size of the operation.",[28,982,984],{"id":983},"questions-we-get","Questions we get",[11,986,987,990,991,461,994,461,997,461,1000,461,1003,461,1006,1009],{},[15,988,989],{},"Is Valkey compatible with Redis client libraries?","\nYes, in 100% of practical cases. The protocol is identical — ",[236,992,993],{},"redis-cli",[236,995,996],{},"node-redis",[236,998,999],{},"ioredis",[236,1001,1002],{},"redis-rb",[236,1004,1005],{},"redis-py",[236,1007,1008],{},"go-redis",", all work without changing a line. What changes is just the endpoint. In 2026, several libraries already announce explicit support for Valkey in the README, but that's cosmetic — the protocol is the same.",[11,1011,1012,1015,1016,1019,1020,1023],{},[15,1013,1014],{},"Can I migrate from managed Redis Labs to self-hosted Valkey without downtime?","\nYes, with replication. Configure Valkey as Redis Labs replica (",[236,1017,1018],{},"REPLICAOF host port","), wait for sync (a few minutes to hours depending on dataset), promote Valkey to master (",[236,1021,1022],{},"REPLICAOF NO ONE","), do internal DNS cutover, decommission Redis Labs after observation period. Real error window is seconds during the swap.",[11,1025,1026,1029],{},[15,1027,1028],{},"Is Dragonfly worth the BSL risk?","\nDepends on the company's horizon. BSL converts to Apache 2.0 after 4 years by the standard model — so today's code will be open by 2030. The risk is that the company behind it (DragonflyDB Inc) follows the path of Redis Inc and makes the conversion less friendly. For workloads that demand performance Valkey doesn't deliver (above 500k sustained ops\u002Fs), Dragonfly may be the right choice despite the risk. For the rest, Valkey is more conservative.",[11,1031,1032,1035,1036,1038],{},[15,1033,1034],{},"How much RAM does a Redis with 1 GB of useful data consume?","\nPractical math: 1 GB dataset occupies between 1.3 and 2 GB of real RAM (structure overhead, fragmentation, client buffers, replication backlog). Configuring ",[236,1037,406],{}," at 60% of available RAM is a safe rule — 4 GB instance fits ~2.5 GB of useful data with room to spare.",[11,1040,1041,1044],{},[15,1042,1043],{},"Does Sidekiq really need AOF? Sidekiq docs say it can run without.","\nThe docs say it technically runs. In production, without AOF, any unexpected restart loses queued jobs that were in the buffer. For \"welcome email\" queue, you discover when customer complains. For \"recurring billing\" queue, you discover when the accountant complains. AOF is cheap (5-10% I\u002FO increment), the cost of not having it is large.",[11,1046,1047,1050],{},[15,1048,1049],{},"Cluster vs Sentinel for app processing 50k jobs\u002Fday?","\nSentinel. 50k jobs\u002Fday is 0.6 ops\u002Fs average — fits in 100 MB of Redis RAM. Cluster is overkill by an order of magnitude. Sentinel solves automatic failover with 1 master + 1 replica + 3 sentinels (3 sentinel processes on separate VPSes, can coexist with other things).",[11,1052,1053,1056],{},[15,1054,1055],{},"Does ElastiCache São Paulo have good latency for app running in São Paulo?","\nYes, 1-3ms p99 within the same AZ. The problem isn't latency — it's cost and lock-in. Latency only becomes a topic if the app is on another provider (Hetzner FSN, DigitalOcean NYC) trying to talk to ElastiCache São Paulo — there it rises to 130-200ms and the argument disappears.",[11,1058,1059,1062],{},[15,1060,1061],{},"How to back up self-hosted Valkey to survive disaster?","\nThree layers. First: persistent AOF on local disk (survives restart). Second: daily RDB snapshot copied to S3-compatible storage (Wasabi, Backblaze B2, Cloudflare R2 — all cheaper than AWS S3 for this case). Third: weekly snapshot copied to another storage provider (second region, second vendor). Restic or rclone do the work. Total storage cost for 4 GB Valkey backup: about US$1\u002Fmonth.",[28,1064,1066],{"id":1065},"closing","Closing",[11,1068,1069],{},"In 2026, \"Redis in production\" became a question with more nuance than it had in 2023. The original product's license changed, the Linux Foundation fork matured, multi-thread alternatives are standing, the serverless offering has a real use case. Choosing among the four implementations and the three managed paths is honest exercise — there's no single answer.",[11,1071,1072,1073,1075],{},"Our default recommendation for Brazilian startup in 2026: ",[15,1074,50],{}," on its own cluster, Sentinel mode, AOF on if there's queue, monitoring with Prometheus. Cost in the R$80–R$230\u002Fmonth range, against R$600–R$2,000\u002Fmonth for equivalent managed alternatives. Full compatibility with any Redis library. No exposure to RSAL license. Reversible migration if it becomes a problem.",[11,1077,1078],{},"To stand up this stack:",[1080,1081,1086],"pre",{"className":1082,"code":1083,"language":1084,"meta":1085,"style":1085},"language-bash shiki shiki-themes github-dark-default","curl -sSL https:\u002F\u002Fget.heroctl.com\u002Finstall.sh | sh\n","bash","",[236,1087,1088],{"__ignoreMap":1085},[1089,1090,1093,1097,1101,1105,1109],"span",{"class":1091,"line":1092},"line",1,[1089,1094,1096],{"class":1095},"sQhOw","curl",[1089,1098,1100],{"class":1099},"sFSAA"," -sSL",[1089,1102,1104],{"class":1103},"s9uIt"," https:\u002F\u002Fget.heroctl.com\u002Finstall.sh",[1089,1106,1108],{"class":1107},"suJrU"," |",[1089,1110,1111],{"class":1095}," sh\n",[11,1113,1114,1115,1119,1120,1124],{},"And to read in parallel: ",[159,1116,1118],{"href":1117},"\u002Fen\u002Fblog\u002Fpostgres-in-production-managed-vs-self-hosted","Postgres in production: managed vs self-hosted"," (same analysis for the database) and ",[159,1121,1123],{"href":1122},"\u002Fen\u002Fblog\u002Fhow-much-to-host-a-brazilian-saas-2026","How much does it cost to host a Brazilian SaaS in 2026"," (the consolidated math of the whole stack).",[1126,1127,1128],"style",{},"html pre.shiki code .sQhOw, html code.shiki .sQhOw{--shiki-default:#FFA657}html pre.shiki code .sFSAA, html code.shiki .sFSAA{--shiki-default:#79C0FF}html pre.shiki code .s9uIt, html code.shiki .s9uIt{--shiki-default:#A5D6FF}html pre.shiki code .suJrU, html code.shiki .suJrU{--shiki-default:#FF7B72}html .default .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}html .shiki span {color: var(--shiki-default);background: var(--shiki-default-bg);font-style: var(--shiki-default-font-style);font-weight: var(--shiki-default-font-weight);text-decoration: var(--shiki-default-text-decoration);}",{"title":1085,"searchDepth":1130,"depth":1130,"links":1131},2,[1132,1133,1134,1141,1142,1149,1150,1151,1152,1153,1154,1155,1156,1157,1158],{"id":30,"depth":1130,"text":31},{"id":54,"depth":1130,"text":55},{"id":77,"depth":1130,"text":78,"children":1135},[1136,1138,1139,1140],{"id":82,"depth":1137,"text":37},3,{"id":103,"depth":1137,"text":17},{"id":122,"depth":1137,"text":21},{"id":141,"depth":1137,"text":25},{"id":166,"depth":1130,"text":167},{"id":219,"depth":1130,"text":220,"children":1143},[1144,1145,1146,1147,1148],{"id":226,"depth":1137,"text":227},{"id":269,"depth":1137,"text":270},{"id":297,"depth":1137,"text":298},{"id":318,"depth":1137,"text":319},{"id":359,"depth":1137,"text":360},{"id":387,"depth":1130,"text":388},{"id":479,"depth":1130,"text":480},{"id":508,"depth":1130,"text":509},{"id":550,"depth":1130,"text":551},{"id":564,"depth":1130,"text":565},{"id":873,"depth":1130,"text":874},{"id":906,"depth":1130,"text":907},{"id":939,"depth":1130,"text":940},{"id":983,"depth":1130,"text":984},{"id":1065,"depth":1130,"text":1066},"engineering",null,"2026-05-20","Redis changed its license in 2024, Valkey was born as an OSS fork, Dragonfly hits benchmarks. In 2026, choosing cache is no longer choosing Redis — it's choosing between 4 products. Honest analysis with costs.",false,"md",{},true,"\u002Fen\u002Fblog\u002Fredis-in-production-managed-vs-self-hosted","13 min",{"title":5,"description":1162},{"loc":1167},"en\u002Fblog\u002Fredis-in-production-managed-vs-self-hosted",[1173,103,1174,1175,1159],"redis","cache","self-hosted","yY3ROe_Afo2prSU4Eu_g3AmHDl997tSuL6uAW4GbUDo",[1178,1183],{"title":1179,"path":1117,"stem":1180,"description":1181,"date":1182,"category":1159,"children":-1},"Postgres in production: managed vs self-hosted, the honest math","en\u002Fblog\u002Fpostgres-in-production-managed-vs-self-hosted","RDS starts at US$15\u002Fmonth — ends at US$500. Self-hosting starts at $0 — ends waking you up at 3 a.m. How to decide between the two without lying to yourself.","2026-04-15",{"title":1184,"path":1185,"stem":1186,"description":1187,"date":1188,"category":1189,"children":-1},"Render vs Railway vs Fly.io: Brazilian comparison 2026","\u002Fen\u002Fblog\u002Frender-vs-railway-vs-fly-io","en\u002Fblog\u002Frender-vs-railway-vs-fly-io","The three hosted PaaSes Brazilian devs most use to escape Heroku. Each has a different tradeoff. Honest analysis of when to stay on each and when to move to self-hosted.","2026-02-12","comparison",1777362202404]