Coolify, Pangolin, and the parts you end up assembling

If you want to deploy apps onto machines you own and publish them from a network with no inbound route, there is a well-trodden path that does not involve us, and it is worth describing accurately before arguing with it.

The two halves

For deployment, Coolify is the obvious answer and deservedly popular. You point it at a VPS, connect a Git repo, and it builds and runs your containers with a good UI over Docker. If your world is one server or a handful of them running Docker, it is a better fit than what we build, and we would rather say so than pretend otherwise.

For reachability, Pangolin and Cloudflare Tunnel solve the ingress problem properly. An outbound connection from your network, a public endpoint at the other end, and traffic reaching a machine that has no inbound route. Pangolin in particular has grown quickly because the problem is real and its answer is clean.

Each is good at its half. The interesting part is what happens when you need both.

The seam

You now operate two systems that do not know about each other. Deploying a new app is a step in one and a step in the other. A hostname exists in one and a route exists in the other, and nothing reconciles them, so the failure mode is a service that is running and unreachable, or reachable and pointing at something that has moved.

Certificates are the clearest example. Whichever tool terminates TLS owns issuance and renewal, and the other one has to be told. It works. It is also a thing you maintain, and it breaks quietly at renewal time rather than at deploy time.

None of this is difficult in the way that distributed systems are difficult. It is difficult in the way that unowned integration points are difficult: fine on the day you build it, and expensive the day someone else has to change it.

Where the difference actually is

Coolify orchestrates Docker. That is a deliberate and defensible choice, and it is also a hard boundary: if your workloads run on Kubernetes, Coolify is not the tool, and no amount of configuration changes that. Dokploy is in the same position for the same reason.

So the honest split is not "better" and "worse". It is:

• One machine running Docker, one team: Coolify, and you will be happy.
• Several Kubernetes clusters, some in places that cannot be reached from outside, one console over all of them: that is the case we built for.

What that gets you is one system where the app, its managed database, its hostname and its certificate are the same object, and where publishing from an unreachable cluster is a property of the platform rather than a second product you wire in.

What we do not do

We do not create infrastructure. You bring the cluster; there is no button here that provisions nodes, and if you want that, an inward-connecting platform on a cloud account is a more direct answer.

We are also younger than either tool named above, with a smaller catalog and nobody's production traffic on us yet. If you are weighing a mature single-server tool against a newer multi-cluster one, that difference is real and belongs in the decision.