Uncloud

Container orchestration for developers who outgrew one server but refuse to learn Kubernetes. Honestly reviewed.

TL;DR

• What it is: Open-source (Apache-2.0) tool that connects multiple Docker hosts into a private WireGuard mesh network, letting you deploy and scale Docker Compose apps across servers without Kubernetes or Docker Swarm [README][website].
• Who it’s for: Developers and technical founders who know Docker Compose and need their app on more than one machine — for redundancy, capacity, or geographic spread — without the operational complexity of a full orchestrator [README].
• Cost savings: Fly.io, Render, and Railway charge per instance. A 3-node Uncloud cluster on Hetzner runs ~$12–15/mo with zero platform fees. Equivalent redundancy on Render starts at $30–60/mo and climbs [website].
• Key strength: Fully decentralized — no control plane, no quorum, no single point of failure. WireGuard mesh networking is automatic. Docker Compose is the config format, so there’s no new DSL to learn [README].
• Key weakness: Early-stage project with a single maintainer (~4,924 GitHub stars). Automatic rollback on failure is listed as “coming soon.” No web UI, no built-in monitoring, and no secrets management [README].

---

What is Uncloud

Uncloud is a lightweight container orchestration tool that solves a specific and common problem: you’re running Docker Compose on one server, it’s working fine, and then you need a second machine. Maybe the first is at capacity. Maybe you want the app to survive a server going down. Maybe you want servers in two regions.

At that point the options get ugly fast. Docker Swarm is semi-deprecated and carries trust baggage from Docker’s turbulent years. Kubernetes will solve your problem and then add seventy new ones. Managed PaaS platforms (Fly.io, Render, Railway) solve the ops problem but charge per instance, per region, per request — and the bill only ever goes up.

Uncloud’s answer: connect your machines into a WireGuard mesh network automatically, sync cluster state peer-to-peer, and let you deploy the same Docker Compose file you already have across as many machines as you want [README][website]. The GitHub description puts it plainly: “Bridging the gap between Docker and Kubernetes” [README].

The CLI is deliberately Docker-flavored. uc machine init initializes a server. uc run deploys a container. uc scale adds replicas. If you’ve used Docker, you can read what these commands do without opening the documentation [website].

The project is by Pavel Sviderski, licensed Apache-2.0, and sits at 4,924 GitHub stars. It surfaced in a December 2025 German cloud/ops newsletter as a “leichtgewichtiges clustering und container orchestration tool” — lightweight clustering and container orchestration tool — appearing alongside notes on Docker and Shopify infrastructure [4]. Community recipes and templates live in a companion uncloud-recipes repository [README].

---

Why people choose it

The use case is a specific developer frustration: Docker Compose works perfectly on one machine and then stops making sense the moment you add a second. Most multi-server alternatives either require deep Kubernetes expertise or offload infrastructure to a SaaS platform that charges per unit of compute.

Uncloud’s appeal is architectural. The WireGuard mesh is the core value — cross-machine container networking that would normally require a VPN setup, firewall rule auditing, and overlay network configuration happens automatically on uc machine init [README]. Containers get unique IPs and communicate directly across machines without opening extra ports [website]. For a developer who’s been manually proxying traffic between two servers, that’s the difference between “solved” and “three days of iptables debugging.”

The decentralized design matters beyond the architecture diagram. Traditional orchestrators maintain a control plane — a set of master nodes that hold cluster state. If the control plane goes down, you can’t deploy. Uncloud syncs state peer-to-peer; individual machines going offline doesn’t take the rest of the cluster with it [README][website]. For a 2–4 server setup, this is meaningfully simpler to reason about than Kubernetes etcd quorum.

The Docker Compose compatibility is underrated. Every other orchestrator requires you to learn their config format — Helm charts, Nomad HCL, Fly’s TOML. Uncloud uses the Compose spec you already know [README]. You’re not migrating your config, you’re just changing where the deployment goes.

---

Features

Based on the README and official documentation [README][docs][website]:

Networking:

• WireGuard mesh with automatic peer discovery and NAT traversal — no VPN config required [README]
• Containers get unique IPs for direct cross-machine communication [README]
• Built-in DNS server resolves service names to container IPs automatically [README]
• No extra firewall ports required for inter-container communication [website]

Deployment:

• Docker Compose format — the same compose.yaml you use locally [README]
• Zero-downtime rolling deployments [README][website]
• Automatic rollback on failure — listed as “coming soon” in the README [README]
• Remote management: control the entire cluster via SSH to any single machine [README][website]
• Docker-like CLI: uc machine init, uc run, uc scale [website]

HTTPS and ingress:

• Built-in Caddy reverse proxy handles TLS certificate provisioning via Let’s Encrypt [README][website]
• Managed DNS: *.xxxxxx.uncld.dev subdomains for public services, no external DNS required [README]
• Custom domains: point your DNS at the cluster, Caddy handles the certificate [website]

Images and storage:

• Unregistry integration: push Docker images directly to your machines without an external registry — transfers only missing layers [README]
• Persistent storage via Docker volumes managed across machines [README]

Infrastructure:

• Any Linux machine — cloud VMs, dedicated servers, bare metal, home server [README][website]
• Mix providers freely: one Hetzner server, one DigitalOcean droplet, one on-premises box in the same cluster [website]
• No control plane, no quorum requirement [README][website]

What’s not included: no web UI (CLI only), no log aggregation, no metrics or alerting, no secrets management beyond native Docker, no automatic rollback yet.

---

Pricing: SaaS vs self-hosted math

Uncloud itself is Apache-2.0 — no license cost [README]. The managed *.uncld.dev DNS service is operated by the same author as a companion project; current pricing for that service is not publicly documented [README]. You can avoid it entirely by pointing your own domain.

Managed PaaS comparison for a typical 2–3 service app:

Fly.io:

• Shared CPU VMs start at ~$3.19/mo (256MB RAM)
• A small 3-machine deployment: $10–30/mo for compute, plus bandwidth and storage
• Global anycast networking is a genuine advantage, but per-instance billing adds up fast

Render:

• Starter services from $7/mo (512MB RAM, no sleep)
• A 2-service app with managed Postgres: $30–50/mo minimum
• Private networking between services on Render requires their paid tier

Railway:

• Usage-based, roughly $5–20/mo for small workloads
• Easier to get started, harder to predict costs at scale

Heroku:

• Basic dynos at $7/mo each, Eco dynos sleep after 30 minutes
• Postgres add-on adds $5–50/mo depending on tier
• A simple 2-dyno app with database: $20–40/mo

Self-hosted with Uncloud on Hetzner:

• CX21 (2 vCPU, 4GB RAM): €3.79/mo ($4.20)
• Two CX21s for a redundant cluster: ~$8.40/mo
• Three CX21s for a multi-region setup: ~$12.60/mo
• Uncloud: $0
• Domain: ~$12/year if you don’t have one

Savings math: A 3-service app currently on Render at $40/mo = $480/year. The same workload on a 2-node Uncloud cluster: ~$100/year in VPS costs. That’s $380/year back, compounding as your usage grows. Managed PaaS pricing scales with resource usage; Uncloud pricing scales with however many VPSes you decide to run.

The hidden cost is your time — initial setup, OS updates, monitoring you configure yourself, and debugging when something goes wrong at 2am. Uncloud doesn’t manage any of that for you.

---

Deployment reality check

The quickstart from the official website is genuinely compact [website]:

# Install the CLI (macOS)
brew install psviderski/tap/uncloud

# Initialize your first server
uc machine init user@your-server-ip

# Deploy with automatic HTTPS
uc run --name my-app -p app.example.com:8000/https my-image:latest

# Add a second machine and scale
uc machine add user@second-server-ip
uc scale my-app 2

The server prerequisites: Linux, Docker installed, SSH accessible. Uncloud handles WireGuard setup, Caddy configuration, and TLS certificate provisioning automatically [README][website]. The demo screenshot in the README shows deploying the project’s own website to two remote machines from a local compose.yaml — that’s the intended workflow [README].

What works smoothly:

• Single-command machine initialization
• Cross-machine networking with no manual network configuration
• Deploying apps you already have Docker Compose files for
• HTTPS without touching Certbot or nginx config manually

Where you’ll hit friction:

• No automatic rollback yet [README]. A bad deployment requires manual intervention.
• Stateful workloads (databases) need volume placement planning. Postgres running on machine A can’t automatically migrate to machine B if A goes down.
• No web UI — every operation is CLI. Acceptable for developers, a blocker for non-technical users.
• The uncloud-recipes community repo exists but is sparse. Troubleshooting will mean reading source code or asking in Discord, not searching Stack Overflow.
• The managed *.uncld.dev DNS is convenient but represents an external dependency with no documented SLA.

Realistic setup times:

• Developer comfortable with Docker and SSH: 30–60 minutes to a running multi-machine cluster
• Developer new to multi-server setups: 2–4 hours including DNS configuration and troubleshooting
• Non-technical founder: this is not a self-service tool — you’d need someone to deploy it for you

---

Pros and cons

Pros

• Apache-2.0 license. No commercial use restrictions, no “fair-code” caveats, no licensing negotiation required to self-host, embed, or build on [README].
• No control plane. Fully decentralized — no master nodes to maintain, no quorum to lose, no etcd. Some machines going offline doesn’t take the cluster down [README][website].
• Automatic WireGuard mesh. Cross-machine networking that normally takes hours to configure correctly happens on uc machine init [README].
• Docker Compose compatibility. No new config format. Your existing compose.yaml deploys as-is [README].
• Unregistry. Push images directly to your machines without running or paying for an external registry [README].
• Mix any infrastructure. Cloud VMs, bare metal, home server — one cluster regardless of provider [website].
• Clean mental model. Fewer moving parts than Kubernetes or Swarm. The decentralized design is simpler to reason about when things go wrong [README].

Cons

• No automatic rollback yet. Explicitly listed as “coming soon” in the README [README]. Failed deployments require manual recovery.
• Single maintainer. At ~4,924 stars with no organization behind it, bus factor is one. Not the foundation you’d choose for a critical production system without a contingency plan [GitHub].
• CLI only. No web UI. Every operation is a terminal command. Non-technical users are excluded entirely.
• Thin ecosystem. Small community, limited recipes, limited third-party tooling. Troubleshooting at 3am means reading source code.
• Managed DNS opacity. The *.uncld.dev service has no documented pricing or SLA [README]. Convenient for testing; risky for production domains.
• No built-in observability. No log aggregation, no metrics, no alerting. Plan to deploy a monitoring stack separately.
• No secrets management. Docker secrets exist, but there’s no Vault integration or equivalent. Credential handling is entirely your responsibility.
• Early-stage. Several features are on the roadmap. You’re accepting the risk of API changes, undocumented behavior, and potential project abandonment.

---

Who should use this / who shouldn’t

Use Uncloud if:

• You’re running Docker Compose on one server and need to add a second machine without learning Kubernetes.
• You’re comfortable with SSH, CLI tools, and debugging Linux servers.
• You’re paying $50–200/mo on Fly.io or Render for a workload that could run on $15/mo worth of VPS.
• You want Apache-2.0 freedom with no commercial license risk.
• You want multi-region redundancy without a full orchestrator.

Skip it — use Coolify or CapRover instead — if:

• You want a web dashboard and Git push-to-deploy without touching a terminal.
• You’re a non-technical founder who needs someone to manage the infrastructure layer entirely through a UI.

Skip it — use k3s instead — if:

• You need production-hardened multi-node orchestration with a massive ecosystem.
• You need StatefulSet primitives, cluster autoscaling, or operator-managed databases.
• Kubernetes API compatibility matters (existing tooling, Helm charts, CI/CD integrations).

Skip it — use Dokku instead — if:

• You only need one server. Dokku is mature, stable, and well-documented for single-server Heroku-style deployments.

Skip it — stay on Fly.io or Render — if:

• You can’t afford the time to manage infrastructure yourself.
• Your compliance requirements demand a managed platform with documented SLAs.
• You’re early enough that paying $30/mo to avoid ops work is the correct business decision.

---

Alternatives worth considering

• Coolify — the most popular direct alternative. Web UI, multi-server support, Git integration, active community. If you want a dashboard, start here.
• CapRover — similar to Coolify, Docker Swarm-based, slightly more mature. More configuration required.
• Dokku — single-server, the original self-hosted Heroku. Mature, stable, opinionated. Use it if you need one machine, not many.
• k3s — lightweight Kubernetes. More complex, but battle-tested, enormous ecosystem, and Kubernetes API compatibility means everything CNCF works with it. The serious multi-server choice.
• Fly.io — managed PaaS using WireGuard for networking (similar concept to Uncloud, but fully hosted). Better developer experience than raw VPS, costs more than self-hosting.
• Render — straightforward managed deployments, no ops overhead, pricing scales predictably upward.
• Docker Swarm — built into Docker, still functional, but with an uncertain future after years of unclear Docker Inc. direction. New projects should pick k3s or Uncloud instead.

For the developer who wants to leave managed PaaS without going full Kubernetes: Uncloud vs Coolify is the honest shortlist. Coolify has a web UI and more features. Uncloud has a cleaner architecture (no control plane, true WireGuard mesh, decentralized state) and a simpler CLI-driven workflow. Pick Uncloud if you think in terminal commands. Pick Coolify if you want to avoid the terminal.

---

Bottom line

Uncloud is a focused, well-architected tool for a problem that a lot of developers hit and then struggle with: going from one server to two without taking on Kubernetes. The decentralized design, automatic WireGuard mesh, and Docker Compose compatibility are genuine advantages over the alternatives — not marketing claims. The cost math versus Fly.io or Render is straightforwardly in Uncloud’s favor once you have more than one service and a technical person to run it.

The honest caveat: this is early-stage software with a single maintainer, no automatic rollback, no web UI, and a thin ecosystem. It’s a project with the right idea and clean execution that needs more time and contributors to become the reliable, boring infrastructure you’d bet a production company on unconditionally. Use it on side projects and staging now. Keep watching — if the trajectory continues, it’s a tool worth serious production consideration in a year.

If deployment setup is the blocker, that’s exactly the kind of one-time infrastructure work upready.dev handles for founders who’d rather ship product.

---

Sources

1. Ethan Sholly, Self-Host Weekly (13 March 2026) — selfh.st. https://selfh.st/weekly/2026-03-13/
2. Ethan Sholly, Self-Host Weekly (20 March 2026) — selfh.st. https://selfh.st/weekly/2026-03-20/
3. andy, allesnurgecloud.com — “Cloudflare Ausfall, Fixit Week, Shopify Black Friday Rekorde & Vorbereitung, 8 Stunden Mythos, GitHub Exodus und mehr - #215” (7 December 2025). https://allesnurgecloud.com/newsletter/cloudflare-ausfall-fixit-week-shopify-black-friday-rekorde-vorbereitung-8-stunden-mythos-github-exodus-und-mehr-215/

Primary sources:

• GitHub repository and README: https://github.com/psviderski/uncloud (4,924 stars, Apache-2.0 license)
• Official website: https://uncloud.run
• Documentation: https://uncloud.run/docs