Why MihraOps does not put a PaaS on your server

The case for a platform on the server

It is a strong case, so it goes first. A platform on the server is always awake: a push to Git can build and deploy at three in the morning without anyone’s laptop being open. It is reachable from any browser, including a phone. Several people can share it with their own logins. It can build images on the server, create a preview environment per pull request, and keep logs and metrics history in one place.

Coolify and Dokploy do all of this, they are open source, and they cost nothing beyond the server they run on. For many teams they are simply the right tool.

The panel is a second system

The cost is less visible. A platform on the server is an application of its own: a web interface, a database, background workers, an update schedule and its own security advisories. To manage containers it needs the Docker socket, which makes it root-equivalent on the host.

Its login page has to be reachable from wherever you want to use it, which usually means from the internet. So the server now runs your app plus an internet-facing, root-equivalent admin application that you also have to keep patched.

The test: what is left when the tool is gone

MihraOps applies one test to its own design: if the app disappeared tomorrow, what would be left on your server, and would it still make sense without us?

The answer is ordinary Docker. Your apps are normal containers. Compose stacks are normal Compose projects in ~/.mihraops/compose/<project>/ that run with docker compose by hand. A published domain is a normal Caddy container with its configuration in /opt/mihraops/caddy. Git and registry credentials you chose to save sit encrypted in ~/.mihraops/secrets. Unless you install the optional Agent described below, no MihraOps service runs on the server and there is no database of ours to keep alive.

That is not nothing, and the uninstall guide lists every path. But each piece is something you could have set up yourself, and none of it needs MihraOps in order to keep working.

Blast radius

Credentials end up wherever the control plane is. A platform that manages several servers from one of them holds an SSH key for each of the others, so compromising that one machine reaches all of them.

MihraOps keeps server access on the computers you work from. The SSH keys and passwords you use to reach your servers stay in your operating system’s encrypted storage; they are not stored on a server and never sent to us.

What does live on a server is limited to what that server needs to fetch its own code and images. Those credentials are encrypted with a key kept on the same server, which protects them at rest — not from someone who already has root there.

What this position costs

Stated plainly: no dashboard to check from a phone, no shared team logins, and no web interface on a computer where the app is not installed.

And some jobs cannot wait for you to open a window. For those — deploy webhooks, monitoring and email alerts — MihraOps has an optional Agent: a small container on the server that runs only the actions you configure, and that you can remove. It is a deliberate exception chosen per server, not the default shape of the product.

Who should install Coolify instead

1. 01A team in which several people deploy and need their own logins.
2. 02Anyone who wants push-to-deploy with builds on the server and a preview environment per pull request.
3. 03Anyone who manages servers mostly from a phone, or from machines they cannot install software on.
4. 04Anyone who would rather run one more service than install an app on each computer.

If that is you, the comparison page goes through the differences feature by feature, and it will not try to talk you out of it.