The missing middle in code hosting

Ask a team where their code lives and you get one of two answers. Either a vendor runs it, or they run it themselves. There is remarkably little in between, and both answers cost more than the people choosing them expect.

I have been on both sides of this. Right now I am building Basekick Git because I got tired of the choice.

Side one: everything is managed, and nothing is yours

Managed hosting is genuinely good. You get pull requests, review, CI, and an onboarding flow measured in minutes. For most of the last decade this was the obviously correct default, and I would still pick it over a weekend spent configuring a server.

The bill arrives later, and it is not the invoice.

You inherit an outage you cannot do anything about. When the provider goes down, your team stops merging. Not because anything of yours broke, but because the part you do not run is the part that failed. You refresh a status page and wait. There is no runbook, because there is nothing to run.

The storage is not yours. Your repository objects sit somewhere you cannot name, under keys you do not hold, governed by an access policy you did not write. This is fine right up until an auditor, a customer security review, or a jurisdiction asks a specific question about it, and every honest answer starts with “I would have to ask the vendor.”

The terms move. Privacy policies get revised. Data-use clauses get widened. Increasingly the widening is about training models, and the mechanism is opt-out rather than opt-in, which means the default is participation and the burden is on you to notice. That is the part I object to most. Not that the option exists, but that keeping your own code out of someone else’s training corpus is a manual chore you have to repeat every time the terms are rewritten.

None of this requires anyone to be a villain. It follows from one structural fact: the collaboration layer and the infrastructure are sold as a single thing, so buying the first means surrendering the second.

Side two: you run it, and now you run everything

So you self-host. Now the repository is unambiguously yours. This is a real answer, and for some teams it is the right one.

It is also much larger than “install Git.” What you have actually signed up for:

1. Identity. SSO, or LDAP, or OIDC. Onboarding, offboarding, and the permission audit somebody will eventually ask you for.
2. A database. With backups. With tested restores, which is a different and less popular activity than backups.
3. Certificates. Issuance, renewal, and the 2am expiry that takes down pushes for everyone because a cron job failed quietly in March.
4. A web server and the app itself. Upgrades, migrations, and reading release notes for breaking changes before a Tuesday maintenance window.
5. Runners. Capacity, isolation, and the cleanup job that stops disks filling.
6. Monitoring for all of the above. Because a self-hosted service nobody watches is just an outage with a longer time-to-detection.

That is not a weekend. That is a standing obligation, and it lands on the same engineers you hired to ship your actual product. I run infrastructure daily and I still think this is a bad trade for most teams. The failure mode is not dramatic; it is that maintenance quietly becomes somebody’s half-time job forever.

The two piles are not the same kind of thing

Here is the observation the whole product rests on.

Look at what you get from the managed side: pull requests, inline review, branch protection, status checks, activity feeds, project discovery. Every one of those is a collaboration feature. They are about people agreeing on changes.

Now look at the self-hosting pile: identity, storage, certificates, runners, backups, monitoring. Every one of those is an infrastructure concern. They are about operating a system.

These are different problems. They have different failure modes, different expertise, and different reasons to care where they live. There is no technical law binding them together. They are bundled because that is how the products were built, and we have lived with the bundle so long it reads like physics.

It is not physics. It is a packaging decision, and packaging decisions can be undone.

What sitting in the middle actually means

Basekick Git separates the two. The collaboration layer is managed, so you get pull requests, review, branch protection, and CI coordination without operating anything. The infrastructure stays yours.

Concretely:

• Repository objects live in your storage, under your keys and your access policies. Not a copy synced to your bucket. The bucket is where they are.
• Runners live on your machines: your Kubernetes clusters, your cloud instances, your GPUs, the Mac minis under a desk, whatever is inside your network.
• For stricter requirements, a private data plane, where Git operations and code processing stay entirely within your security boundary.
• Plain Git underneath. Standard commands, no proprietary client, nothing exotic in the object format.

The test I hold this to is the ugly one: what happens when you want to leave, or when we are the ones having a bad day? Revoke our access and you still have standard Git repositories in storage you control, plus an export of the collaboration data. Not a migration project. Not a support ticket. The repository was already yours the whole time; losing us costs you the pull request UI, not your code.

That is the actual claim. Not “we are cheaper” or “we are faster.” Your code should outlive whoever is hosting the conversation about it.

Where this is

Basekick Git is in early access while I build it in the open. If your team is weighing a managed host against a self-hosted one and finding both answers unsatisfying, that is the exact conversation I want to be having right now, and the feedback shapes what ships.

You can join early access, or just email me and tell me which half of this you think I have wrong.

There is a longer post coming about the architecture: what it takes to keep repository objects in someone else’s bucket while still serving fast reads, and what that costs. That one has diagrams.