Skip to main content

The Hidden Complexity of Dokku Networking: A Tale of Redis and DNS

· 2 min read
Max Kaido
Max Kaido
Architect

Today, we faced a classic example of the hidden complexity in Dokku's networking model. What seemed like a simple task - connecting a NestJS application to Redis - turned into an adventure through container networking, DNS resolution, and service discovery.

The Challenge​

Our Mercury Bot service needed to communicate with both Redis and ChromaDB on the same network. Simple, right? Not quite. The initial setup led to DNS resolution errors:

Error: getaddrinfo EAI_AGAIN dokku-redis-mercury

This cryptic error message was just the beginning of our journey into Dokku's networking internals.

The Root Cause​

Dokku's networking model, while simple on the surface, has some quirks:

  1. Services are created with default network settings
  2. Network changes require service recreation
  3. DNS resolution depends on proper network configuration
  4. Service linking doesn't automatically handle network alignment

The Solution​

The fix required several steps:

  1. Unlinking and destroying the existing Redis service
  2. Creating a new Redis service with the correct initial network
  3. Relinking the service to the application
  4. Restarting the application to pick up new configuration

Why This Matters​

This experience highlights a broader issue: while Dokku excels at simplifying deployments for small to medium applications, its networking model can become a bottleneck as your infrastructure grows more complex.

Top 3 Alternatives to Dokku​

1. Kubernetes (k3s)​

Pros:

  • Production-grade container orchestration
  • Advanced networking with CNI
  • Rich ecosystem of tools and integrations
  • Better service discovery and DNS resolution

Cons:

  • Steeper learning curve
  • More resource intensive
  • Requires more initial setup

2. Docker Swarm​

Pros:

  • Simpler than Kubernetes
  • Built-in service discovery
  • Easy scaling and load balancing
  • Native Docker compatibility

Cons:

  • Limited advanced features
  • Smaller ecosystem
  • Less active development

3. Nomad​

Pros:

  • Simple yet powerful
  • Supports multiple workload types
  • Excellent service discovery
  • HashiCorp ecosystem integration

Cons:

  • Smaller community than Kubernetes
  • Requires additional components for full functionality
  • Less managed service options

Conclusion​

While Dokku remains an excellent choice for simple deployments, teams should carefully consider their networking requirements as their infrastructure grows. The alternatives listed above offer more robust networking models and better service discovery mechanisms, albeit at the cost of increased complexity.

For our specific use case, k3s would be an ideal middle ground - offering Kubernetes' robust networking model without the full complexity of a traditional Kubernetes deployment.

Lessons Learned​

  1. Always specify initial networks when creating Dokku services
  2. Document network dependencies clearly
  3. Consider future scaling needs when choosing a container platform
  4. Test service communication patterns early in development

Remember: the simplest tool isn't always the best choice - it's about finding the right balance between simplicity and capability for your specific needs.