Deploy and Host Dragonfly on Railway

Deploy Dragonfly on Railway to get a modern, high-performance Redis-compatible in-memory data store running in minutes. Self-host Dragonfly as a drop-in Redis replacement with 25x more throughput and 80% less memory usage on the same hardware.

This Railway template deploys Dragonfly with a persistent volume at /data for snapshot durability, password authentication via DFLY_requirepass, and a TCP proxy for external connections. Dragonfly runs on port 6379 and is wire-compatible with any Redis client.

Getting Started with Dragonfly on Railway

Once deployed, Dragonfly is immediately available via the TCP proxy endpoint shown in your Railway dashboard. Connect using any Redis client — redis-cli, ioredis, redis-py, or your framework's Redis driver.

To connect externally, use the TCP proxy URL from your Railway project settings. The connection string format is redis://default:@:. For service-to-service connections within Railway, use the private domain: dragonfly.railway.internal:6379.

Test the connection with:

redis-cli -h  -p  -a  PING
# Expected: PONG

Set your first key to verify everything works:

redis-cli -h  -p  -a 
> SET greeting "Hello from Dragonfly"
OK
> GET greeting
"Hello from Dragonfly"

About Hosting Dragonfly

Dragonfly is a modern in-memory data store built from the ground up in C++ with a multi-threaded, shared-nothing architecture. It serves as a drop-in replacement for both Redis and Memcached, supporting ~240 Redis commands and all Memcached commands.

• 25x throughput over Redis on equivalent hardware (3.8M QPS on a single node)
• 80% lower memory for the same dataset size — no memory spikes during snapshots
• Multi-threaded — scales vertically with CPU cores, unlike single-threaded Redis
• Wire-compatible with Redis (RESP2/RESP3) and Memcached protocols
• Built-in persistence via RDB-compatible snapshots with scheduled cron-based backups
• Unified caching with an adaptive eviction algorithm when cache_mode is enabled

Why Deploy Dragonfly on Railway

• One-click deploy with persistent storage and TCP proxy pre-configured
• No Redis licensing concerns — BSL 1.1 is free for self-hosted use
• Dramatically lower memory cost than Redis for the same workload
• Any Redis client or framework integration works without code changes
• Private networking for secure service-to-service connections within Railway

Common Use Cases for Self-Hosted Dragonfly

• Application caching — Drop-in replacement for Redis cache layers in Django, Laravel, Rails, or Express apps with lower memory costs
• Job queues — Compatible with BullMQ (Node.js), Sidekiq (Ruby), and Celery (Python) for background task processing
• Session storage — TTL-based key expiry for web session management at scale
• Pub/Sub messaging — Real-time event streaming with microsecond latency for chat, notifications, and live dashboards

Dependencies for Dragonfly on Railway

• Dragonfly — ghcr.io/dragonflydb/dragonfly:latest (currently v1.38.0)
• Volume — Persistent storage mounted at /data for snapshot durability

Environment Variables Reference for Dragonfly

Deployment Dependencies

• Docker image: ghcr.io/dragonflydb/dragonfly
• GitHub: dragonflydb/dragonfly (30k+ stars)
• Official docs: dragonflydb.io/docs
• Docker Hub: dragonflydb/dragonfly

Hardware Requirements for Self-Hosting Dragonfly

Dragonfly allocates 1 IO thread per CPU core by default. On Railway, set DFLY_proactor_threads=4 to avoid exceeding container thread limits.

Self-Hosting Dragonfly with Docker

Run Dragonfly locally with Docker:

docker run -d --name dragonfly \
  -p 6379:6379 \
  -v dragonfly-data:/data \
  ghcr.io/dragonflydb/dragonfly:latest \
  --requirepass mysecretpassword \
  --dir /data \
  --dbfilename dump \
  --proactor_threads 4

Or use Docker Compose:

services:
  dragonfly:
    image: ghcr.io/dragonflydb/dragonfly:latest
    ports:
      - "6379:6379"
    volumes:
      - dragonfly-data:/data
    command: >
      --requirepass mysecretpassword
      --dir /data
      --dbfilename dump
    ulimits:
      memlock: -1

volumes:
  dragonfly-data:

Dragonfly vs Redis — Which to Self-Host?

Dragonfly excels for vertical scaling on a single node. Redis is better suited for horizontal clustering across many nodes.

How Much Does Dragonfly Cost to Self-Host?

Dragonfly is free to self-host under the BSL 1.1 license. You can run it on any infrastructure without licensing fees — the only cost is your server resources. The BSL restriction only applies if you sell Dragonfly itself as a competing managed database service.

Dragonfly Cloud (managed) starts at ~$11/month. On Railway, you pay only for compute and storage — typically $5-15/month for moderate workloads.

FAQ

What is Dragonfly and why self-host it on Railway? Dragonfly is a modern Redis-compatible in-memory data store with 25x better throughput and 80% less memory usage. Self-hosting on Railway gives you full control over your data with one-click deployment and persistent storage.

What does this Railway template deploy for Dragonfly? The template deploys a single Dragonfly service with a persistent volume at /data for snapshot durability, password authentication, and a TCP proxy for external Redis client connections.

Why does Dragonfly need a volume on Railway? The volume at /data stores RDB snapshots so your data survives container restarts and redeployments. Without it, Dragonfly runs in ephemeral mode and all data is lost on restart.

Can I use Dragonfly as a drop-in Redis replacement on Railway? Yes. Dragonfly supports RESP2/RESP3 protocols and ~240 Redis commands. Any Redis client library (redis-py, ioredis, Jedis, go-redis) works without code changes. Just point your REDIS_URL to the Dragonfly connection string.

How do I connect other Railway services to self-hosted Dragonfly? Use Railway's private networking: redis://default:@dragonfly.railway.internal:6379. Set the connection URL as an environment variable on your app service using Railway's reference format: ${{Dragonfly.DFLY_requirepass}} for the password.

Does Dragonfly support BullMQ and Sidekiq job queues? Yes. Dragonfly is tested and compatible with BullMQ (Node.js), Sidekiq (Ruby), and Celery (Python) for background job processing. No configuration changes needed beyond pointing the Redis URL to Dragonfly.