Running Wafrn on Shared Infrastructure: A Guide to Multi-Service Hosting with Caddy

The Dream: One Post, Multiple Platforms

The appeal of the fediverse is real. Post once, reach your audience across BlueSky, Mastodon, Lemmy, and other decentralized platforms simultaneously. Wafrn promises exactly this—a unified publishing dashboard that handles the cross-posting complexity. But like many powerful open-source tools, it comes with deployment assumptions that don't always match real-world hosting scenarios.

The catch? Wafrn's default setup is built around a single-tenant assumption: spin up a dedicated server, run the Docker container, and let Caddy handle everything. For developers already juggling multiple services on a shared VPS—perhaps running WordPress, a few microservices, or legacy applications—this all-or-nothing approach creates friction.

The Standard Path (And Why It Breaks)

Wafrn's recommended deployment is straightforward on paper:

1. Docker container with built-in Caddy reverse proxy
2. Automatic HTTPS provisioning via Let's Encrypt
3. ATProto account support (required for BlueSky federation)

The problem emerges when you need Nginx or another web server already managing your domain. Here's the architectural clash: Wafrn relies on Caddy's automatic HTTPS certificates for ATProto account verification. This isn't cosmetic—it's a protocol requirement. The ActivityPub and ATProto specifications validate that the entity making federation requests actually controls the domain through certificate ownership.

When you already have a web server listening on port 443, you can't simply add another one. Port conflicts aside, certificate management becomes a nightmare when multiple services vie for control of the same domain's SSL chains.

The Hybrid Solution: Caddy as Sidecar Proxy

Rather than replace your existing web infrastructure, you can run Caddy and Wafrn as a dedicated, isolated service that sits behind your primary reverse proxy.

Here's the architecture:

Client (BlueSky, Mastodon, etc.)
    ↓
Your Domain (nginx/reverse proxy on :443)
    ↓
Internal Network
    ↓
Caddy + Wafrn (handles ATProto certificate validation)

The flow works like this:

1. External traffic hits your primary web server on your domain
2. Your primary reverse proxy forwards Wafrn-specific routes (e.g., /wafrn/*) to the internal Caddy instance
3. Caddy manages its own certificate chain for ATProto verification on subdomains or via token-based validation
4. Wafrn handles federation with full protocol compliance

This approach preserves your existing infrastructure while isolating Wafrn's specific requirements.

Converting from Nginx to Caddy: Where AI Helps (And Hurts)

If you decide to migrate your primary reverse proxy from Nginx to Caddy—a legitimate simplification—AI-powered code conversion tools can accelerate the process. Converting a typical Nginx config to Caddyfile syntax is mechanical enough that LLMs handle it well in one pass.

However, configuring Wafrn to work in this hybrid setup requires domain-specific knowledge that AI tools struggle with:

• Understanding ATProto's certificate pinning requirements
• Knowing which Wafrn environment variables control proxy behavior
• Debugging federation failures when configuration is slightly off
• Recognizing when a suggestion creates security gaps

The practical lesson: Use AI tools for straightforward format conversions (Nginx → Caddy), but treat their suggestions for novel architecture modifications as a starting point, not gospel. You'll likely spend more time debugging AI-generated configs than writing from scratch, especially for edge cases.

The DIY Path: Documentation for Your Setup

If you've tackled this configuration yourself, you've likely learned where Wafrn's deployment docs assume too much and where real-world hosting diverges from the happy path. The community benefits from documenting these gaps.

Publishing your configuration—whether as a fork with updated instructions, a separate guide, or a community-maintained deployment template—helps the next developer avoid 2–3 hours of trial-and-error. Consider contributing to Wafrn's official docs or hosting a public reference configuration on GitHub/GitLab.

Key Takeaways for Self-Hosting Wafrn

1. Understand the protocol requirements: ATProto federation isn't optional—it requires valid certificates tied to your domain.

2. Don't assume the default deployment fits your infrastructure: Dedicated servers are simpler, but shared hosting is more cost-effective and common.

3. Use Caddy as a sidecar service: Run it isolated from your primary web server, letting it handle Wafrn's specific needs.

4. Convert configs, don't auto-architect: Use AI for format translations, not infrastructure design.

5. Document and share your solution: Others will benefit, and you'll have a reference for your next project.

What's Next?

If you're running a similar setup—multiple services on a shared VPS with specific protocol requirements—think of Wafrn's architecture as a template. The same pattern applies to other federation-aware applications that need certificate control: isolate their proxy layer, let them manage their own TLS, and bridge through your primary reverse proxy.

Want to explore self-hosted alternatives to cross-posting tools, or dive deeper into ATProto and ActivityPub federation? Let us know in the comments, and happy self-hosting.

Self-hosting complex applications requires careful attention to networking, SSL/TLS, and protocol compliance. At NameOcean, we support developers and small teams running multi-service infrastructures with reliable domain management and DNS that plays well with decentralized protocols. Whether you're running Wafrn, Mastodon, or a custom federation application, solid domain infrastructure is the foundation.