Teams that run their own ClickHouse® clusters usually do it for a reason: control. They want the database on their own infrastructure, their data under their own policies, and no surprises about where it goes. So it has always struck me as odd when those same teams reach for a hosted, third-party admin tool that sends their query metadata off to someone else's servers. If you self-host the database, it makes sense to self-host the tool that manages it. Here is the case for that, and how to do it well.
Why self-host the admin tool
The data argument is the obvious one. An admin tool sees your schema, your queries, often your results. For teams under data-residency rules, or just teams that prefer their data not to leave their network, sending all of that to a hosted service is a non-starter. Self-hosting keeps it on your infrastructure, full stop.
But there is a quieter argument I find just as compelling: dependency. A hosted admin tool is a dependency on someone else's uptime and someone else's roadmap. If their service is down, you are managing your database blind. If they change their pricing or pivot their product, you adapt on their schedule. A self-hosted, open-source tool removes that. It runs as long as you run it, and you can read the code to know exactly what it does.
For a tool whose whole job is to have privileged access to your production database, both of those arguments matter a lot.
What self-hosting actually involves
The good news is that self-hosting a tool like CHOps is straightforward, because it is designed for it. You run it on your own infrastructure, next to your cluster, and point it at your ClickHouse® nodes. It talks to ClickHouse® over the standard HTTP interface, the same one your applications use. There are no agents to install on your database servers, which is important, because the last thing you want is to install extra software on the machines running your production database.
So the model is simple: one service you run, reaching your cluster over the interface it already exposes. If the tool can reach the cluster, it can manage it. If it cannot, nothing happens. There is no third party in the path.
Connecting it safely
A few practices make a self-hosted admin tool a security asset rather than a new risk.
Run it inside your network, not exposed to the public internet. It needs to reach your cluster and your team needs to reach it, both of which can happen within your private network or VPN. There is rarely a reason for it to be publicly reachable.
Give it a database user scoped to what it needs. The tool should connect with credentials that match its job, and ClickHouse®'s RBAC lets you scope that precisely. This is the same least-privilege thinking you apply to anything else touching the database.
Use its own access control for your team. Who on your team can do what through the tool is its own layer, on top of the database's permissions, so you can let analysts query without giving them the ability to change configuration.
The open-source dividend
Because CHOps is open source, self-hosting comes with a benefit that goes beyond control: you can see exactly what you are running. For a tool with privileged database access, being able to read the code, audit what it sends and where, and verify it does only what it claims is genuinely valuable. You are not trusting a black box with your production database. You are running software you can inspect.
This is the same principle that probably led you to self-host ClickHouse® in the first place. You wanted control, transparency, and no surprises. The tool you use to manage it should meet the same bar. If you run your own cluster, running your own open-source admin tool next to it is the consistent choice, and an easy one to make. The CHOps homepage covers what it can do once it is connected.
Anything touching a production database deserves care. Keep the tool inside your network, scope its database access tightly, and review the access you grant.
