A team picked up the open-source gateway, self-hosted it, wired it to their SSO, and put it in front of their production databases. No sales call, no onboarding, no contract. Over a couple of months they scaled to around twenty thousand governed database sessions a week, and held there.
Then, weeks in, they turned on governance themselves.
This is what open-source access governance looks like when a team chooses it on their own.
Yes, and not as an experiment. This team self-hosted hoop.dev, wired it to their identity provider over SSO, and routed their database access through it. A couple dozen engineers, traffic sustained over more than two months, still running today.
The shape of the usage says production, not trial. Most of the access was automated, the programmatic traffic that comes from pipelines and services, with a smaller layer of people connecting by hand. Tens of thousands of sessions a month do not come from kicking the tires.
What does a serious open-source deployment look like?
It looks like infrastructure. One gateway in front of the team's databases, every connection passing through it, identities tied to the company's SSO so each session belongs to a real person or a real service.
A governed session is the unit: one authenticated connection through the gateway, recorded and attributable. This team went from a few hundred a week to around twenty thousand, and the number held at the top. That is the shape of a tool a team has come to depend on.
Does governance have to be pushed top-down?
No. For the first several weeks, this team ran without it. Access flowed through the gateway and was audited, but no policy governed it.
Then, in a single week, they turned on guardrails and applied them across their connections. From that point most of their sessions ran on guardrail-protected connections, and they stayed there. Nobody from hoop.dev prompted it. They reached for governance on their own, weeks after the gateway had already earned a place in their stack.
That order is the whole point. Governance did not arrive first, as a gate to get past. It arrived after the platform had proven useful, as something the team chose to add.
What is a guardrail here?
A guardrail is connection-level policy: a rule set a team attaches to a connection, applied to every session that runs on it. You set it once, and the connection is covered from then on.
What matters in this story is not any single rule. It is that a free team, already dependent on the open-source gateway, decided governance was worth turning on, and covered most of their traffic with it by choice.
How do we know this, and what it does not tell us
Worth answering plainly. This comes from product metrics, not from anything inside a session: things like session counts, connection types, client version, and which features a team has switched on, such as guardrails. It does not include the contents of a session. hoop.dev does not collect the queries that ran or the data they touched, and a team can anonymize or turn analytics off entirely. We have not spoken to this team, and we are not naming them.
So treat it as a blind, aggregate story. It tells us what a deployment did, not who they are or why they did it. One deployment is a data point, not a trend. And turning on guardrails is a decision to govern, not a claim about anything that did or did not happen on their connections.
The point
The best argument for governance was not a slide. It was a free team that owed us nothing, no contract and no pitch, deciding they wanted it anyway. Build a floor worth standing on, and people ask for the walls themselves.
hoop.dev is open source. Start where they did: self-host it free, wire it to your SSO, and put guardrails on your database access.
GitHub | Docs
MIT-licensed, SOC 2 Type II, CNCF member.