How to Install DragonflyDB on Ubuntu 24.04 — Modern Redis-Compatible In-Memory Store

In-memory data stores are the unseen workhorses of modern applications — caching sessions, queuing jobs, counting rate limits, and shaving milliseconds off every page load. For fifteen years that role belonged almost entirely to Redis. Today, DragonflyDB offers a modern alternative that speaks the same Redis protocol but is built from the ground up for multi-core hardware, delivering up to 25x higher throughput on the same VPS.

This tutorial walks you through installing DragonflyDB on Ubuntu 24.04, configuring it for production workloads, wiring in snapshots, replication, and TLS, and verifying compatibility with your existing Redis clients. By the end you will have a hardened Dragonfly node running on a CloudCore Starter VPS at EUR 7.99 per month — outperforming managed services that cost ten times as much.

Table of Contents

What is DragonflyDB?

DragonflyDB is an open-source, in-memory key-value data store compatible with the Redis and Memcached wire protocols. It was designed in 2022 to address a fundamental limitation of classic in-memory stores — single-threaded execution — using a modern shared-nothing architecture.

Each DragonflyDB process starts one proactor thread per CPU core. The keyspace is partitioned across these threads so that every key is owned by exactly one core. When a command arrives, the networking layer routes it to the owning thread, which executes the operation without locks, without atomic contention, and without cache-line bouncing. This design — often called "thread-per-core" or "shared-nothing" — is the same approach used by high-performance systems like ScyllaDB and Seastar, adapted for the Redis API.

The result is straightforward: on a modest 8-core VPS, DragonflyDB can sustain over one million operations per second with single-digit-millisecond p99 latency, while single-threaded Redis on the same hardware tops out near 150,000 ops/sec no matter how many cores you throw at it. DragonflyDB also ships with fork-less snapshots (no RAM doubling during BGSAVE), a built-in cache eviction mode that is both LRU and hash-density-aware, and native cluster-client compatibility without running a separate proxy.

Why Self-Host DragonflyDB?

Running DragonflyDB on your own VPS is a deliberate choice with concrete benefits over managed Redis offerings.

• Throughput per euro — A single CloudCore Starter VPS at EUR 7.99 per month running Dragonfly comfortably handles workloads that would cost 50-200 EUR per month on Redis Cloud, Upstash, or AWS ElastiCache. You keep the hardware savings on every request.
• No per-request pricing surprises — Managed providers meter commands, bandwidth, and data transfer. A self-hosted Dragonfly node serves unlimited requests within the VPS bandwidth allowance.
• Full data sovereignty — Session tokens, user identifiers, and cached API responses stay on infrastructure you control. No vendor has read access to your working set.
• Predictable latency — Co-locating Dragonfly with your app server on the same VPS (or the same datacentre) removes cross-region hops that add 20-80 ms to every cache hit on most managed services.
• Modern architecture without migration cost — Because DragonflyDB speaks Redis RESP, you swap the connection string and keep every client library, every Lua script, and every ops tool you already depend on.
• GDPR-friendly — EU-hosted VPS plus a store you fully own makes data-protection impact assessments far simpler than a US-SaaS Redis provider.

DragonflyDB vs. Managed Alternatives: Cost at a Glance

Prerequisites

Before you begin, make sure you have:

• A VPS running Ubuntu 24.04 LTS with root or sudo access
• At least 2 GB RAM (4 GB recommended for production caches)
• SSH access to the server
• An Ubuntu user with sudo — do not run Dragonfly as root

Recommended Plan: CloudCore Starter

For a dedicated DragonflyDB cache node, the CloudCore Starter plan is ideal:

- 4 vCPU cores

- 4 GB RAM

- 50 GB NVMe SSD

- Unmetered bandwidth

- EUR 7.99/month

Four proactor threads on Starter-class hardware deliver hundreds of thousands of ops/sec — more than enough for a mid-sized SaaS product.

Connect to your server via SSH:

ssh your-user@your-server-ip

Step 1: Update System Packages

Refresh the package index and apply outstanding security updates:

sudo apt update && sudo apt upgrade -y

If the kernel was upgraded, reboot before continuing:

sudo reboot

Reconnect via SSH after a minute.

Step 2: Install DragonflyDB via APT

DragonflyDB publishes an official APT repository at packages.dragonflydb.io. This is the cleanest install path for a dedicated VPS because it integrates with apt upgrade and the stock systemd.

Install the prerequisite packages:

sudo apt install -y curl ca-certificates gnupg lsb-release

Import the DragonflyDB GPG key:

curl -fsSL https://packages.dragonflydb.io/dragonfly.gpg | \
  sudo gpg --dearmor -o /usr/share/keyrings/dragonflydb-archive-keyring.gpg

Add the repository to your APT sources:

echo "deb [signed-by=/usr/share/keyrings/dragonflydb-archive-keyring.gpg] https://packages.dragonflydb.io/apt $(lsb_release -cs) main" | \
  sudo tee /etc/apt/sources.list.d/dragonflydb.list

Refresh the package index and install Dragonfly:

sudo apt update
sudo apt install -y dragonfly

The package installs:

• The dragonfly binary at /usr/bin/dragonfly
• A systemd unit at /lib/systemd/system/dragonfly.service
• The default configuration directory /etc/dragonfly/
• A dragonfly system user that owns the data directory /var/lib/dragonfly/

dragonfly --version

Expected output:

dragonfly v1.20.1
build time: 2026-01-14 08:22:41

Step 3: Install DragonflyDB via Docker (Alternative)

If your stack is containerised, use the official Docker image instead of the APT package.

Install Docker Engine if it is not already present:

curl -fsSL https://get.docker.com | sh

Pull and run DragonflyDB:

docker run -d \
  --name dragonfly \
  --restart unless-stopped \
  --ulimit memlock=-1 \
  -p 127.0.0.1:6379:6379 \
  -v dragonfly-data:/data \
  docker.dragonflydb.io/dragonflydb/dragonfly \
  --cache_mode=true \
  --maxmemory=2gb \
  --proactor_threads=4

Key flags:

• --ulimit memlock=-1 — removes the memory lock limit Dragonfly expects for best performance
• -p 127.0.0.1:6379:6379 — exposes the Redis protocol only on localhost; use a reverse proxy or a Docker overlay network for remote access
• -v dragonfly-data:/data — persists snapshots across container restarts
• --cache_mode=true — enables Dragonfly's hash-density-aware eviction when memory is full

Step 4: Configure dragonfly.conf

The apt package ships a minimal /etc/dragonfly/dragonfly.conf. Open it for editing:

sudo nano /etc/dragonfly/dragonfly.conf

Replace its contents with a production-ready configuration. Every line is a long-form flag — one flag per line, no -- prefix, no quotes.

# Bind address — 127.0.0.1 means localhost only. Use 0.0.0.0 for remote access
(only do so behind a firewall or TLS).
bind=127.0.0.1
Client-facing port (Redis-compatible).
port=6379
Memory budget. Dragonfly will evict or reject writes once this is hit.
Set this to roughly 75% of total VPS RAM, leaving headroom for the OS.
maxmemory=3gb
Enable cache mode: LRU-ish, hash-density-aware eviction. Turn this OFF if you
use Dragonfly as an authoritative data store rather than a cache.
cache_mode=true
Number of proactor threads. One per CPU core is the recommended default.
On the 4-core Starter plan, set this to 4.
proactor_threads=4
Data directory for snapshots.
dir=/var/lib/dragonfly
Snapshot interval — cron expression. Every 30 minutes is a sensible default.
snapshot_cron=/30    *
Log level: INFO in production, DEBUG while commissioning the box.
logtostderr=true
v=0
Require a password for clients. Generate a strong one with openssl rand -hex 32.
requirepass=CHANGE_ME_TO_A_LONG_RANDOM_STRING
Maximum number of concurrent clients.
maxclients=10000

Save and exit (Ctrl+O, Enter, Ctrl+X).

What Each Key Setting Does

• cache_mode=true — When memory hits maxmemory, Dragonfly evicts based on a combination of recency and hash-bucket density. This is superior to Redis allkeys-lru for mixed workloads because it keeps hot segments hot without rebuilding whole dictionaries. Use cache_mode=false if you need strict key persistence.
• proactor_threads — The number of shared-nothing workers. Each thread pins to a CPU core when possible. Never set this higher than the vCPU count on your VPS; too many threads causes context-switch thrashing.
• maxmemory — Measured in bytes; suffixes k, m, g are honoured. Leave ~25% of RAM free for the OS, snapshots, and replication buffers.
• snapshot_cron — Standard five-field cron expression. Dragonfly's snapshotting is fork-less, so unlike Redis you can snapshot frequently without memory spikes.

sudo chmod 640 /etc/dragonfly/dragonfly.conf
sudo chown root:dragonfly /etc/dragonfly/dragonfly.conf

Step 5: Manage the systemd Service

Reload systemd so it picks up any unit changes, then enable and start Dragonfly:

sudo systemctl daemon-reload
sudo systemctl enable --now dragonfly

Verify the service is active:

sudo systemctl status dragonfly

Expected output:

● dragonfly.service - DragonflyDB: A modern replacement for Redis and Memcached
     Loaded: loaded (/lib/systemd/system/dragonfly.service; enabled; preset: enabled)
     Active: active (running) since Thu 2026-04-16 09:12:03 UTC; 5s ago
   Main PID: 4218 (dragonfly)
      Tasks: 11 (limit: 14214)
     Memory: 48.2M
        CPU: 120ms
     CGroup: /system.slice/dragonfly.service
             └─4218 /usr/bin/dragonfly --flagfile=/etc/dragonfly/dragonfly.conf

Stream the logs to confirm the proactor threads came up:

sudo journalctl -u dragonfly -f

You should see lines similar to:

I20260416 09:12:03.412 main            Starting dragonfly df-v1.20.1
I20260416 09:12:03.412 init            maxmemory has not been specified. Deciding myself
I20260416 09:12:03.420 proactor_pool   Running 4 io threads
I20260416 09:12:03.428 listener        Listening on 127.0.0.1:6379
I20260416 09:12:03.430 main            DragonflyDB is ready to accept connections

Press Ctrl+C to exit the log tail.

Step 6: Verify Redis CLI Compatibility

DragonflyDB speaks the Redis wire protocol (RESP2 and RESP3), so the standard redis-cli client works unchanged.

Install the Redis tools package:

sudo apt install -y redis-tools

Authenticate and send a PING:

redis-cli -a 'CHANGE_ME_TO_A_LONG_RANDOM_STRING' PING

Expected output:

PONG

Run a short battery of commands to confirm core data types work:

redis-cli -a 'CHANGE_ME_TO_A_LONG_RANDOM_STRING' <<'EOF'
SET greeting "hello from dragonfly"
GET greeting
HSET user:1 name "Alice" plan "starter"
HGETALL user:1
LPUSH jobs "process-email" "send-invoice"
LRANGE jobs 0 -1
ZADD leaderboard 100 alice 92 bob
ZREVRANGE leaderboard 0 -1 WITHSCORES
INFO server
EOF

The INFO server output clearly identifies Dragonfly:

# Server
redis_version:6.2.11
dragonfly_version:df-v1.20.1
redis_mode:standalone
arch_bits:64
multiplexing_api:iouring
...

Note that Dragonfly advertises redis_version:6.2.11 for client compatibility reasons — libraries that gate on Redis version numbers will correctly negotiate protocol features.

Step 7: Enable Snapshots for Persistence

Dragonfly snapshotting is fork-less and shard-aware, meaning it will not double your memory usage like Redis BGSAVE can on large datasets. You already enabled it in Step 4 via snapshot_cron=/30 *, but you can also trigger manual snapshots.

Trigger a snapshot immediately:

redis-cli -a 'CHANGE_ME_TO_A_LONG_RANDOM_STRING' SAVE

List snapshot files:

sudo ls -lh /var/lib/dragonfly/

Expected output:

-rw------- 1 dragonfly dragonfly 1.2M Apr 16 09:20 dump-2026-04-16T09:20:01.dfs
-rw------- 1 dragonfly dragonfly 1.2M Apr 16 09:50 dump-2026-04-16T09:50:01.dfs

Dragonfly's native snapshot format is .dfs (DashTable snapshot) — a multi-file, shard-parallel format that loads across all proactor threads simultaneously at startup. If you need Redis-compatible .rdb files (for migration in or out), run:

redis-cli -a 'CHANGE_ME_TO_A_LONG_RANDOM_STRING' DEBUG RELOAD

For longer-term durability, back the /var/lib/dragonfly directory up to object storage with a simple daily cron job:

sudo tee /etc/cron.daily/dragonfly-backup > /dev/null <<'EOF'
#!/bin/bash
rsync -az /var/lib/dragonfly/ backup-user@backup-host:/backups/dragonfly/$(hostname)/
EOF
sudo chmod +x /etc/cron.daily/dragonfly-backup

Step 8: Set Up Replication

DragonflyDB supports native leader/follower replication over the Redis protocol. Use it for read scaling, hot standby, or a disaster-recovery replica.

On the Replica

Provision a second VPS, install Dragonfly the same way as the primary, and edit its /etc/dragonfly/dragonfly.conf:

bind=127.0.0.1
port=6379
requirepass=CHANGE_ME_TO_A_LONG_RANDOM_STRING
masterauth=CHANGE_ME_TO_A_LONG_RANDOM_STRING
replica_priority=100

Start the replica:

sudo systemctl restart dragonfly

Attach it to the primary (replace PRIMARY_IP):

redis-cli -a 'CHANGE_ME_TO_A_LONG_RANDOM_STRING' REPLICAOF PRIMARY_IP 6379

Verify replication is healthy on the replica:

redis-cli -a 'CHANGE_ME_TO_A_LONG_RANDOM_STRING' INFO replication

Expected output:

# Replication
role:replica
master_host:PRIMARY_IP
master_port:6379
master_link_status:up
master_last_io_seconds_ago:0
master_sync_in_progress:0

On the Primary

Confirm the replica connected:

redis-cli -a 'CHANGE_ME_TO_A_LONG_RANDOM_STRING' INFO replication

You should see role:master and connected_slaves:1.

Promoting a Replica

If the primary fails, promote the replica to leader with:

redis-cli -a 'CHANGE_ME_TO_A_LONG_RANDOM_STRING' REPLICAOF NO ONE

Point your application at the new primary's IP. For automated failover use a tool like HAProxy with TCP health checks or run your clients through a service mesh that can update the endpoint dynamically.

Step 9: Enable TLS

When Dragonfly is reachable beyond 127.0.0.1, TLS is non-negotiable. Generate a self-signed certificate (replace with Let's Encrypt for internet-facing nodes):

sudo mkdir -p /etc/dragonfly/tls
sudo openssl req -x509 -nodes -newkey rsa:4096 \
  -keyout /etc/dragonfly/tls/dragonfly.key \
  -out /etc/dragonfly/tls/dragonfly.crt \
  -days 365 \
  -subj "/CN=dragonfly.internal"
sudo chown -R dragonfly:dragonfly /etc/dragonfly/tls
sudo chmod 600 /etc/dragonfly/tls/dragonfly.key

Add these lines to /etc/dragonfly/dragonfly.conf:

tls=true
tls_cert_file=/etc/dragonfly/tls/dragonfly.crt
tls_key_file=/etc/dragonfly/tls/dragonfly.key
Require TLS for all connections; disable plaintext on 6379.
port=0
tls_port=6380

Restart Dragonfly:

sudo systemctl restart dragonfly

Connect with TLS using redis-cli:

redis-cli -h 127.0.0.1 -p 6380 --tls --cacert /etc/dragonfly/tls/dragonfly.crt \
  -a 'CHANGE_ME_TO_A_LONG_RANDOM_STRING' PING

Expected output:

PONG

Client libraries — ioredis, redis-py, go-redis — all accept TLS options; pass the CA certificate path or trust it at the OS level, and point the client at port 6380.

Performance Tuning

Dragonfly is fast out of the box, but a few tweaks push it further.

Pin proactor_threads to physical cores

Never exceed the vCPU count. On a 4-vCPU Starter VPS:

proactor_threads=4

Use iouring where supported

The Linux kernel 5.10+ included in Ubuntu 24.04 supports io_uring, which Dragonfly uses by default. Verify with:

sudo journalctl -u dragonfly | grep multiplexing_api

Look for multiplexing_api:iouring. If you see epoll instead, the kernel likely lacks io_uring support; upgrade.

Increase file descriptor limits

For high client counts, raise the per-service ulimit in a systemd drop-in:

sudo systemctl edit dragonfly

Add:

[Service]
LimitNOFILE=1048576

Save, then:

sudo systemctl restart dragonfly

Use pipelining in your clients

DragonflyDB benefits even more from pipelining than Redis because each pipelined request batch keeps an entire proactor thread busy. Group logically independent commands and send them in bulk when possible.

Benchmark with memtier_benchmark

Measure your actual hardware ceiling:

sudo apt install -y memtier-benchmark
memtier_benchmark -s 127.0.0.1 -p 6379 -a 'CHANGE_ME_TO_A_LONG_RANDOM_STRING' \
  --threads=4 --clients=50 --test-time=60 --data-size=256 --ratio=1:1

On a 4-vCPU Starter VPS, expect 300,000 to 700,000 ops/sec on this microbenchmark — an order of magnitude above Redis on the same hardware.

Troubleshooting

Viewing Logs

sudo journalctl -u dragonfly -n 200 --no-pager

Follow live:

sudo journalctl -u dragonfly -f

FAQ

Is DragonflyDB a drop-in replacement for Redis?

DragonflyDB implements the Redis RESP wire protocol and supports the vast majority of Redis commands — strings, hashes, lists, sets, sorted sets, streams, pub/sub, Lua scripting, transactions, and more. Most applications using redis-cli, redis-py, ioredis, lettuce, or go-redis connect to DragonflyDB without a single code change. A small number of niche commands and module-specific features (RedisJSON, RediSearch, RedisGraph) are either handled natively by Dragonfly or not supported — check the compatibility matrix at dragonflydb.io/docs before migrating a workload that leans heavily on Redis modules.

How much RAM do I need to run DragonflyDB?

DragonflyDB works comfortably on 2 GB of RAM for development and light caching workloads. For production you should size RAM to your working set plus roughly 20% overhead for fragmentation, snapshots, and replication buffers. The CloudCore Starter plan at EUR 7.99/month with 4 GB RAM and 4 vCPU is a strong starting point for a dedicated cache node handling tens of thousands of operations per second.

Does DragonflyDB really use a shared-nothing architecture?

Yes. DragonflyDB is built on a shared-nothing, thread-per-core model using a custom userspace scheduler. Each proactor thread owns a slice of the keyspace, eliminates most lock contention, and scales linearly with CPU cores. This is the single biggest reason Dragonfly pushes past one million ops/sec on a single modern server whereas Redis, which is single-threaded by design, plateaus much earlier no matter how many cores you give it.

Can I use DragonflyDB with existing Redis client libraries?

Yes. Point your existing client at the Dragonfly host and port — no driver changes required. The only area where you need to plan is failover: Dragonfly implements its own replication topology rather than Redis Sentinel, so if you previously relied on Sentinel for automatic failover, plan to use Dragonfly native replication plus a simple TCP health-check layer (HAProxy, keepalived, or a cloud load balancer) in your orchestration.

Is DragonflyDB cheaper than Redis Cloud or Upstash?

For any non-trivial workload, self-hosting DragonflyDB on a Starter VPS at EUR 7.99/month is dramatically cheaper than managed Redis services, which typically charge 30-150+ EUR/month for equivalent memory tiers and layer on per-request or bandwidth fees. Because Dragonfly serves more operations per core, a single EUR 7.99 node often replaces a managed cluster that would otherwise cost ten times as much — and you keep full control of the data.

How does DragonflyDB handle persistence?

DragonflyDB uses a fork-less, multi-shard snapshot algorithm called DashTable snapshotting. Snapshots are taken without blocking client traffic and without the memory-doubling that Redis RDB forking can cause on large datasets. Snapshots are written to the directory configured via dir in dragonfly.conf at the interval set with snapshot_cron. Dragonfly currently does not ship an AOF (append-only-file) log; for write-heavy durability requirements, combine replication with frequent snapshots and back up the snapshot directory off-box.

Can I run DragonflyDB in Docker instead of apt?

Yes. The official image is docker.dragonflydb.io/dragonflydb/dragonfly. Docker is a fine choice for containerised stacks or when you want to pin an exact version and keep the host OS clean. This guide shows both installation paths — apt for bare-metal simplicity and Docker for containerised deployments.

Next Steps

Now that DragonflyDB is running, extend your stack with these complementary guides:

• Compare with Redis — Read our Redis installation guide to understand the baseline Dragonfly improves on, and keep it handy if you need a single-threaded fallback for specific module workloads.
• Consider KeyDB or Valkey — KeyDB is a multi-threaded Redis fork that predates Dragonfly; Valkey is the community-maintained Redis fork created after the Redis license change. Both are legitimate alternatives if you prefer the classic Redis codebase over Dragonfly's ground-up rewrite.
• Memcached for simple caching — If all you need is a flat key-value cache with no persistence, Memcached remains a lean option and is also supported by the Dragonfly wire protocol for zero-migration drop-in.
• Add observability — Ship Dragonfly metrics via the /metrics endpoint (enabled by default on port 6379 via INFO ALL) into a Prometheus + Grafana stack on the same VPS.
• Back up to object storage — Pipe the daily rsync backup into an S3-compatible bucket for off-site durability.
• External documentation — The official DragonflyDB docs cover cluster mode, advanced flags, and migration playbooks in depth.

Ready to run DragonflyDB?

Spin up a CloudCore Starter VPS with 4 vCPU, 4 GB RAM, and 50 GB NVMe for just EUR 7.99/month, and follow this guide end-to-end in under twenty minutes.

Launch Your Starter VPS — unmetered bandwidth, EU-hosted, full root access.