[{"data":1,"prerenderedAt":159},["ShallowReactive",2],{"seo-verification":3,"blog-hosting-redis-on-a-vps-ma-en":6,"promo-bar-likely":158},{"google":4,"bing":5},"EycwPY2XMyTkVzas3n1ygeNJFGAH513qrMjfDljzsMQ","",{"key":7,"data":8},"blog-hosting-redis-on-a-vps-ma-en",{"id":9,"slug":10,"slugs":11,"title":15,"excerpt":16,"readTime":17,"views":18,"isPinned":19,"noindex":19,"publishedAt":20,"updatedAt":21,"category":22,"categories":28,"featuredImage":30,"bgImage":31,"posterImage":32,"relatedSolution":33,"intro":36,"sections":37,"ctaTitle":101,"ctaBody":102,"ctaButton":103,"ctaUrl":104,"relatedPosts":105},58,"hosting-redis-on-a-vps",{"fr":12,"en":10,"ar":13,"es":14},"heberger-redis-vps","استضافة-redis-على-خادم-vps","alojar-redis-en-un-vps","Hosting Redis on a VPS: the complete guide","Deploy Redis on your Cloud VPS: RAM\u002FCPU requirements, security (ACL, TLS), RDB\u002FAOF persistence, troubleshooting, and high availability.",10,0,false,"2026-04-23T00:00:00+00:00","2026-09-08T21:59:59+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},6,"Databases","bases-de-donnees","bg-teal-500\u002F10 text-teal-400","database",[29],{"id":23,"name":24,"slug":25,"color":26,"icon":27},null,"\u002Fblog\u002Fcovers\u002Fbg.svg","\u002Fblog\u002Fcovers\u002Fheberger-redis-vps-poster.svg",{"categorySlug":34,"appSlug":35},"databases","redis-stack","Redis is the Swiss Army knife of performance: cache, sessions, job queues, real-time counters, and pub\u002Fsub. Self-hosting it on a VPS gives you full control over memory and over the network between it and your app, without paying the premium of managed Redis offerings. This guide covers the full deployment — from security configuration to persistence, including troubleshooting the most common errors.",[38,42,52,55,80,83,89,92,95,98],{"type":39,"title":40,"body":41},"h2","Why self-host Redis on a VPS","Redis lives in memory: its performance depends directly on RAM and network latency. Managed offerings charge a high price for each GB of RAM and impose connection caps. On a VPS, you size the RAM according to your real needs, you freely configure `maxmemory` and the eviction policy (`allkeys-lru`, `volatile-ttl`...), and you enable RDB and\u002For AOF persistence depending on your tolerance for data loss. For an application cache, a job broker (Sidekiq, BullMQ, Celery), or a session store, a Redis placed right next to your application on the same private network eliminates inter-datacenter latency and drastically reduces cost.",{"type":43,"title":44,"items":45},"ul","The concrete benefits of a self-hosted Redis",[46,47,48,49,50,51],"Sub-millisecond latency if Redis runs on the same VPS or the same private network as your app.","Control of `maxmemory` and the eviction policy according to your cache or job-queue use case.","Persistence of your choice: RDB (snapshots), AOF (journal), or both for durability.","RAM cost without overcharging: you pay the VPS plan, not premium memory by the GB.","Free modules: RediSearch, RedisJSON, RedisBloom as needed.","No arbitrary cap on the number of simultaneous client connections.",{"type":39,"title":53,"body":54},"Hardware and software prerequisites","Since Redis is in-memory, it's the RAM that matters, not the CPU. For a modest cache or a session store, **1 vCPU and 1 to 2 GB of RAM** are enough — Redis open source has low CPU usage since it is single-threaded for commands (network I\u002FO is asynchronous). If Redis serves as a broker for thousands of queued jobs or stores multi-GB in-memory datasets, size the RAM to at least twice your target `maxmemory` to absorb the copy-on-write during RDB snapshots: during a `BGSAVE`, the child process may temporarily duplicate modified pages.\n\nOn disk, plan for at least 2× the size of your dataset if you enable RDB or AOF persistence, plus space for log rotation. On the software side: Ubuntu 22.04\u002F24.04 LTS, Docker and Compose v2, a persistent volume for AOF\u002FRDB if you enable persistence, and the `vm.overcommit_memory=1` setting on the host to avoid fork failures during backups. Disabling **Transparent Huge Pages** (`echo never > \u002Fsys\u002Fkernel\u002Fmm\u002Ftransparent_hugepage\u002Fenabled`) is also recommended: Redis explicitly warns about this at startup if it is active, as it can cause latency spikes and abnormal memory consumption.",{"type":56,"title":57,"steps":58},"steps","Deploying Redis with Docker in production",[59,62,65,68,71,74,77],{"title":60,"body":61},"Prepare the host","Install Docker, then set `vm.overcommit_memory=1` via `sysctl` to make snapshots reliable, and disable Transparent Huge Pages. Close port 6379 to the outside: a Redis exposed without a password is a classic target for cryptominers.\n\n```bash\n# Persistent via sysctl.conf\necho 'vm.overcommit_memory = 1' >> \u002Fetc\u002Fsysctl.conf\nsysctl -p\n# Disable THP\necho never > \u002Fsys\u002Fkernel\u002Fmm\u002Ftransparent_hugepage\u002Fenabled\n```",{"title":63,"body":64},"Write the docker-compose.yml","Declare a `redis:7-alpine` service with a custom command pointing to a `redis.conf` mounted as read-only. Enable `requirepass`, set `maxmemory` and `maxmemory-policy`, and mount a volume for `\u002Fdata` if you want persistence.\n\n```bash\nservices:\n  redis:\n    image: redis:7-alpine\n    command: redis-server \u002Fetc\u002Fredis\u002Fredis.conf\n    volumes:\n      - .\u002Fredis.conf:\u002Fetc\u002Fredis\u002Fredis.conf:ro\n      - redis_data:\u002Fdata\n    restart: unless-stopped\n    ports:\n      - \"127.0.0.1:6379:6379\"\nvolumes:\n  redis_data:\n```",{"title":66,"body":67},"Configure security","In `redis.conf`, security rests on several complementary layers. The first is **network binding**: `bind 127.0.0.1` or your private network IP — never listen on `0.0.0.0` without additional protection. The second is **authentication**: `requirepass YOUR_STRONG_PASSWORD` for Redis 6 and earlier; for Redis 7, prefer **ACLs** which allow creating users with granular permissions:\n\n```bash\nbind 127.0.0.1\nrequirepass YOUR_STRONG_PASSWORD\n# Redis 7 ACL: read-only user for your app\naclfile \u002Fetc\u002Fredis\u002Fusers.acl\n# Disable dangerous commands\nrename-command FLUSHALL \"\"\nrename-command CONFIG \"\"\nrename-command DEBUG \"\"\n```\n\nThe `users.acl` file can declare:\n\n```bash\nuser app_user on >PASSWORD ~* +@read +@write -@dangerous\nuser default off\n```\n\nFor encrypted remote access, enable **Redis native TLS** (available since Redis 6):\n\n```bash\ntls-port 6380\ntls-cert-file \u002Fcerts\u002Fredis.crt\ntls-key-file \u002Fcerts\u002Fredis.key\ntls-ca-cert-file \u002Fcerts\u002Fca.crt\n```\n\nAlternatively, an SSH tunnel or VPN is enough for most cases without TLS complexity.",{"title":69,"body":70},"Choose the persistence strategy","Redis offers two persistence mechanisms, which can be combined.\n\n**RDB (snapshot)**: Redis writes a dataset snapshot to disk at configurable intervals. Fast on restart, but you lose data written since the last snapshot in case of crash.\n\n```bash\n# Snapshot if 1 key changes in 900s, 10 keys in 300s, 10000 keys in 60s\nsave 900 1\nsave 300 10\nsave 60 10000\n```\n\n**AOF (Append-Only File)**: every write command is journaled. Safer, slightly slower. `appendfsync everysec` is the right trade-off: at most 1 second of data lost.\n\n```bash\nappendonly yes\nappendfsync everysec\nauto-aof-rewrite-percentage 100\nauto-aof-rewrite-min-size 64mb\n```\n\n**Combining RDB + AOF**: on restart, Redis uses the AOF (more complete), while RDB accelerates periodic full backups. This is the recommended strategy for critical job brokers.\n\nFor a **pure cache** where data loss is acceptable, disable persistence: `save \"\"` and `appendonly no` — you gain performance and disk space.",{"title":72,"body":73},"Connect your application","Launch with `docker compose up -d` and test with `docker compose exec redis redis-cli -a YOUR_PASS ping`. Point your application to the internal Docker network rather than a public IP, for both latency and security.\n\n```bash\n# Connectivity test\ndocker compose exec redis redis-cli -a YOUR_PASS ping\n# PONG\n\n# Check active configuration\ndocker compose exec redis redis-cli -a YOUR_PASS CONFIG GET maxmemory\n```\n\nFor applications on the same Docker host, use the service name as the host (`redis:6379`) rather than `localhost` or the public IP.",{"title":75,"body":76},"Monitor memory","Monitor `used_memory` and `evicted_keys` via `redis-cli INFO`. If evictions rise, increase the RAM or refine the policy. Set up an alert when memory usage exceeds 80% of `maxmemory`.\n\n```bash\n# Redis health overview\nredis-cli -a YOUR_PASS INFO memory | grep -E 'used_memory_human|maxmemory_human|mem_fragmentation_ratio'\nredis-cli -a YOUR_PASS INFO stats | grep -E 'evicted_keys|keyspace_hits|keyspace_misses'\n```\n\nA `mem_fragmentation_ratio` above 1.5 indicates significant fragmentation: a `MEMORY PURGE` or a rolling restart may help.",{"title":78,"body":79},"Logging in for the first time","Open the URL: RedisInsight appears straight away, WITHOUT asking for any credentials at all (you only accept the terms of use on the first screen), and your local Redis database is already accessible there for reading and writing. Do not attach a public domain to this interface without protection in front of it.",{"type":39,"title":81,"body":82},"Troubleshooting: the most common errors","Here are the errors you will most often encounter when running Redis on a VPS, with their cause and fix.",{"type":43,"title":5,"items":84},[85,86,87,88],"**`MISCONF Redis is configured to save RDB snapshots, but it's currently unable to persist on disk`** — Redis is attempting a snapshot but the fork fails. Cause: `vm.overcommit_memory` is set to 0 on the host. Fix: `sysctl vm.overcommit_memory=1` (permanent in `\u002Fetc\u002Fsysctl.conf`). If you use Docker, this parameter must be set on the **Docker host**, not inside the container.","**`ERR max number of clients reached`** — The number of simultaneous connections exceeds `maxclients` (default: 10,000). Common causes: misconfigured connection pool on the application side (Sidekiq, Laravel Horizon, etc.) or unclosed connections. Fix: increase `maxclients` in `redis.conf` and check the pool configuration on the app side. The command `redis-cli CLIENT LIST` lists active connections.","**OOM Killer kills the Redis process** — The Linux kernel kills Redis due to lack of free memory. Cause: `maxmemory` not set or too generous, combined with the copy-on-write of the RDB fork. Fix: set `maxmemory` to 60-70% of available RAM, choose an eviction policy (`maxmemory-policy allkeys-lru` for a cache, `noeviction` for a broker), and plan for 2× the dataset for the RDB fork. Monitor `\u002Fvar\u002Flog\u002Fsyslog` for `Out of memory: Kill process` messages.","**`Could not create server TCP listening socket 0.0.0.0:6379: bind: Address already in use`** — Another process is occupying port 6379. Identify it with `ss -tlnp | grep 6379` and stop it, or change the Redis port in your configuration. On VPS with a Redis instance installed via `apt`, the system service may conflict with your Docker container.",{"type":39,"title":90,"body":91},"High availability: Sentinel and Cluster","For critical workloads where Redis downtime is unacceptable, two solutions exist.\n\n**Redis Sentinel** is the high-availability solution for a master\u002Freplica architecture. Deploy three Sentinel nodes on three separate VPS: Sentinel monitors the master, detects failure, and automatically promotes a replica. Your applications connect via the Sentinel service rather than directly to the master — they are transparent to the failover. Sentinel suits most cases: cache, sessions, job brokers with durability.\n\n**Redis Cluster** partitions data across multiple nodes (horizontal sharding) and includes built-in high availability. It requires at minimum 6 nodes (3 masters + 3 replicas) and client-side adaptation. Reserve it for datasets exceeding a single server's RAM or workloads requiring very high write throughput.\n\nFor the vast majority of VPS use cases, **Sentinel on 3 nodes** is the right answer: simpler to operate, compatible with all standard Redis clients, and sufficient for datasets of a few tens of GB.",{"type":39,"title":93,"body":94},"Updates and Valkey as an alternative","**On versions.** Redis 7.4 is the current stable LTS branch (7.4.11 at time of writing). Redis 8 is the latest major GA version, released in May 2025, which also marked the adoption of AGPLv3 as a third license option — alongside the RSALv2 and SSPLv1 adopted in March 2024. For a migration from Redis 7.x to Redis 8, consult the official release notes: behavior changes in memory management and ACLs should be anticipated.\n\n**On licensing.** In March 2024, Redis Ltd. dropped the BSD 3-Clause license in favor of a dual RSALv2 + SSPLv1 license (not OSI-approved). In response, the Linux Foundation created **Valkey** on March 28, 2024 — a fork of Redis 7.2.4 under the BSD 3-Clause license, backed by AWS, Google Cloud, Oracle, and other founding members. Valkey follows an independent development trajectory and publishes its own releases. If your use case involves redistribution or license constraints, or if you want a 100% open-source fork in the OSI sense, Valkey is a direct alternative: APIs and protocols are compatible, and migration is generally transparent. A dedicated article compares the two projects in detail: \u003Ca href=\"\u002Fblog\u002Fvalkey-vs-redis-migration-2026\">Valkey vs Redis in 2026: should you migrate?\u003C\u002Fa>\n\nFor common private uses (application cache, job broker, session store on your own infrastructure), Redis 7.x or 8 remains fully usable without license friction.",{"type":96,"body":97},"tip","Monitor the `keyspace_hits` \u002F `keyspace_misses` ratio via `INFO stats`: a low hit rate means your cache is undersized or your TTLs are too short. For critical workloads, deploy Redis Sentinel across three VPS to obtain automatic failover: if the master goes down, a replica is promoted without intervention, and your applications are redirected via the Sentinel service.",{"type":96,"title":99,"body":100},"The official documentation","For advanced configuration and tool-specific options, refer to the \u003Ca href=\"https:\u002F\u002Fredis.io\u002Fdocs\" target=\"_blank\" rel=\"noopener noreferrer\">official Redis documentation\u003C\u002Fa>. This guide covers going live on a VPS; the vendor's documentation remains the reference for fine-tuning, major upgrades, and specific use cases.","Run Redis at full speed","The ServOrbit Cloud VPS with a Docker template and dedicated RAM gives you the latency and memory needed for a high-performance Redis, whether cache or job broker.","Deploy my Cloud VPS","\u002Fvps-cloud",[106,125,142],{"id":107,"slug":108,"slugs":109,"title":113,"excerpt":114,"readTime":115,"views":116,"isPinned":19,"noindex":19,"publishedAt":117,"updatedAt":118,"category":119,"categories":120,"featuredImage":30,"bgImage":31,"posterImage":122,"relatedSolution":123},56,"postgresql-on-a-vps-a-reliable-and-controlled-database",{"fr":110,"en":108,"ar":111,"es":112},"heberger-postgresql-vps","postgresql-على-خادم-vps-قاعدة-بيانات-موثوقة-ومتحكم-بها","alojar-postgresql-en-un-vps","PostgreSQL on a VPS: reliable, controlled database","Host PostgreSQL on a VPS: production config, pgBackRest backups, streaming HA, RDS\u002FSupabase\u002FNeon comparison and OOM troubleshooting.",9,1,"2026-04-25T00:00:00+00:00","2026-10-21T15:21:37+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[121],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-postgresql-vps-poster.svg",{"categorySlug":34,"appSlug":124},"postgresql-stack",{"id":126,"slug":127,"slugs":128,"title":132,"excerpt":133,"readTime":115,"views":18,"isPinned":19,"noindex":19,"publishedAt":134,"updatedAt":135,"category":136,"categories":137,"featuredImage":30,"bgImage":31,"posterImage":139,"relatedSolution":140},57,"hosting-mysql-on-a-vps",{"fr":129,"en":127,"ar":130,"es":131},"heberger-mysql-vps","استضافة-mysql-على-خادم-vps","alojar-mysql-en-un-vps","Hosting MySQL on a VPS: complete guide","Install MySQL 8.4 LTS on a VPS: prerequisites, security hardening, InnoDB performance, secure remote access, automated backups, and troubleshooting.","2026-04-24T00:00:00+00:00","2026-11-09T20:55:18+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[138],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-mysql-vps-poster.svg",{"categorySlug":34,"appSlug":141},"mysql-stack",{"id":143,"slug":144,"slugs":145,"title":149,"excerpt":150,"readTime":151,"views":18,"isPinned":19,"noindex":19,"publishedAt":152,"updatedAt":153,"category":154,"categories":155,"featuredImage":30,"bgImage":31,"posterImage":157,"relatedSolution":30},59,"hosting-mongodb-on-a-vps",{"fr":146,"en":144,"ar":147,"es":148},"heberger-mongodb-vps","استضافة-mongodb-على-خادم-vps","alojar-mongodb-en-un-vps","Hosting MongoDB on a VPS","Host MongoDB on your Cloud VPS: Docker deployment, replica set, authentication, indexing, and controlled backups.",3,"2026-04-22T00:00:00+00:00","2026-09-08T22:00:02+00:00",{"id":23,"name":24,"slug":25,"color":26,"icon":27},[156],{"id":23,"name":24,"slug":25,"color":26,"icon":27},"\u002Fblog\u002Fcovers\u002Fheberger-mongodb-vps-poster.svg",true,1794270421061]