I picked Coolify for the fast setup. Eleven projects later I am moving to Kubernetes.

I put my personal projects on Coolify because it was faster to stand up than anything else I looked at, and because I wanted to see what a self-hosted PaaS actually felt like after years of writing Terraform for other people. Both of those were good reasons. It delivered on both.

It now runs eleven projects. Several PostgreSQL instances, Redis, Prometheus, Grafana. Somewhere in there it stopped being an experiment and became the thing my work lives on, and I didn’t notice the transition happening.

I noticed when the question changed. For a long time the question was how do I deploy this, and Coolify answers that well. Now the question is how do I move this, and that’s a different kind of question.

What moving actually takes

Coolify’s own documentation is clear about the first part: there’s no built-in way to migrate applications from one server to another. Not an omission in the docs. The feature doesn’t exist.

Moving an instance means moving four things by hand:

• The coolify-db container, which holds every project’s configuration.
• The APP_KEY out of the .env, because that database is encrypted with it and worthless without it.
• The SSH keys Coolify uses to reach your servers.
• The authorized keys those servers use to accept it.

Volumes are their own exercise: mount each one into a temporary container, tar its contents, copy the tarball out, delete the container. Then, on the far side, open the dashboard and redeploy each application so the containers come back against the restored volumes.

None of that is unreasonable for a tool of this kind. What it tells you is where the truth about your infrastructure lives, and here it is an encrypted Postgres container plus a secret in a dotfile.

The thing I actually miss

Not the migration. The review.

I can’t diff my infrastructure. There’s no file where eleven projects are described, so there’s nothing to open a pull request against, nothing to read in a year to find out why a container has the environment variable it has, nothing to replay onto a fresh host to see whether it comes back the same. The configuration is real and it’s correct, and it’s only inspectable by clicking through a web interface one project at a time.

This is the same defect I’ve written about in a different costume. One Terraform state file holding everything is dangerous because it makes the blast radius of any change the whole estate. A PaaS database holding everything is dangerous for the mirrored reason: there’s no radius at all, because there’s no change to review in the first place.

Permissions make it concrete. In Kubernetes, who may do what is a file. A Role, a RoleBinding, a securityContext, a NetworkPolicy. You can read it, diff it, reject it in review, and point at it during an incident. In Coolify, permissions are whatever the interface exposes, expressed as the state of some checkboxes, and the only way to audit them is to go and look.

What ArgoCD changes, and what it doesn’t

The reason Kubernetes with ArgoCD is where I’m heading isn’t that Kubernetes is better at running containers. For eleven projects it’s plainly worse: more moving parts, more to keep patched, more ways to be paged on a Sunday.

It’s that GitOps inverts where the truth lives, the same question I ended up at when I worked out what actually runs your infrastructure when you use SST: whichever layer holds the desired state is the layer you can review. The desired state of the cluster is a repository. Migration stops being a tarball procedure and becomes pointing a new cluster at the same repo. Extending stops being a sequence of clicks someone has to remember and becomes a diff someone can approve. Rollback is git revert.

I want to be honest about the cost, because the version of this argument you usually read isn’t. You’re trading an afternoon of setup for a system with a genuine learning curve, and you’re taking on the operational load of the control plane itself. If the only thing you need is eleven containers that stay up, that trade is bad and Coolify wins on every axis that matters.

The trade only makes sense once the questions you’re asking are about change rather than uptime. Mine have been for a while, and I was slow to notice.

Where the line falls

My honest reading, having been on both sides of it:

Coolify is right when the set of things you run is small enough to hold in your head, and when you’re the only person who needs to understand it. That isn’t a limitation; that’s most personal infrastructure, and a UI is a genuinely good interface for it. The speed I bought at the start was real, and I would buy it again.

It stops being right at the point where you need someone else to be able to reconstruct what you built, and that someone else is usually you, eighteen months later, with no memory of the checkboxes.

I haven’t moved yet. I’m writing this partly to work out whether the reasons hold up when I put them in order, and so far they do.

Next

The short version:

• Coolify has no built-in application migration. Moving an instance means the database container, the APP_KEY that decrypts it, both sets of SSH keys, and every volume by hand.
• The real cost isn’t the migration, it’s that there’s no file to diff, review or replay.
• Permissions in Kubernetes are a file you can reject in review. In a PaaS they’re the state of a form.
• ArgoCD is worth its overhead only when your questions are about change rather than uptime. For eleven containers that just need to stay up, it’s the wrong trade.

The next thing I want to settle is what the migration actually costs in hours, measured rather than estimated, because that number is the whole argument and I don’t have it yet. When I do, it will be here. If you have made this move with a comparable estate, I would like to know what it cost you, since every estimate I can find is written by someone selling one side of it.