What happens if I'm not here
SimonSomeone evaluating Codebahn asked me a version of this: I love the idea, but I get stuck on a bus factor of one. What happens if something happens to you?
I run Codebahn alone. There is no team behind it, at least not now. If you are considering this service for your work, you should ask that question, and I should have a clear answer.
I don’t have a complete one. What I have is a list of the ways this could go wrong and an honest take on each. This is how I am thinking about it now, knowing that it will likely evolve over time. The continuity page tracks where things stand on each of these, updated as they change.
The ways this can go wrong
I die, or I’m in the hospital for three months. Nothing breaks on day one. The servers are paid for. Your repositories are there. Then the inbox goes unanswered. A security patch doesn’t get applied. Eventually a payment method expires and the infrastructure stops renewing. You’d find out by accident, weeks later.
This is the one I think about most, because it’s silent. No alarm, no notification. Things stop working slowly, and by the time you notice, you’re already behind.
I’m still here, but I’ve stopped. Burnout, a job offer, or losing interest while keeping the lights on. The same slow rot as the first, except someone is still telling you everything is fine. This one is harder to design around. I’d have to build the alarm, keep paying for it, and then not switch it off when I’m the thing it should be alarming about.
The money runs out. The easiest to talk about honestly, because runway is a number. I’m self-funded and have financial resilience. If the business isn’t covering its costs, I’ll know before you do, and I’ll have time to tell you.
Someone makes me an offer. I have a page arguing this is what happened to the alternatives. It would be dishonest to leave it off my own list.
I decide to stop. The most controllable version of this. The notice period is in the terms now: at least 90 days, in writing. Beyond that, I can execute an orderly wind-down, and make sure exports work and you have time to use them. The commitments I make here are the most credible, because I’m the one who’d be keeping them.
A dependency fails, or I have a security breach. Operational risk that any service faces. Worth noting it’s the first problem in different clothes: if I’m gone, who responds to the incident? Who tells you?
Something legal. Bankruptcy law does not care what my wind-down page says. The terms commit me to completing a switch within 30 days and keeping your data retrievable for at least 30 days after that. For Assurance and Custom customers, the Security and Exit Addendum adds that those commitments survive if the company stops trading, to the extent I’m able to perform them. That is a partial answer. I don’t know the full one. I’d rather write that down than pretend.
What doesn’t depend on me
Some of this has structural answers that hold regardless.
Your data is Git. Every clone you have locally is a complete copy of your repository history. The most important thing you store here is already distributed by design.
Codebahn runs Forgejo. If you need to move, you’re migrating between Forgejo instances, not converting between proprietary formats. Your CI pipeline files are YAML in your repo. Your issues, labels, milestones: they migrate with export/import. I’ve tested the round trip. Export from Codebahn, import to a self-hosted Forgejo instance. It works. The leaving page has the procedure: what comes out, in what format, and what doesn’t transfer cleanly.
Some things can’t be exported. CI secrets can’t be included for security reasons. Deploy keys, webhooks, runner configuration: these are tied to the service. That’s true of every hosted service, not a limitation specific to this one. What I can provide is a manifest: the complete list of what you have (names, not values), so you know what to recreate rather than discovering what’s missing. Today it comes in two parts. The export’s manifest.yml covers teams, members, and repositories. The names of secrets, deploy keys, and webhooks you pull from the API yourself.
You don’t have to wait for an exit scenario to use any of this. Forgejo supports push mirrors that keep a second host in sync automatically. A script that pulls your metadata via the API on a schedule gives you a recent copy of issues and configuration at all times. The more you do while things are normal, the less depends on the service being available when they’re not.
If you want the full picture, including the API calls, how to set up a self-hosted Forgejo instance with CI runners, and what to think through for each part of the migration, there is a guide for that.
What I’m working toward
These are the things I’m building or putting in place. None of them are finished. I’m listing them because the direction matters, and because I’d rather be held to a public list than a private one.
For the sudden scenarios: a continuity arrangement. A designated person with sealed access who can keep infrastructure running and notify customers. The scope would be limited. They wouldn’t run the business. They’d keep the lights on long enough for you to act.
For the financial scenario: paying for infrastructure by direct debit from a reserve that covers at least six months, with prepaid credit where a provider offers it, and the domain renewed years ahead. My main provider takes neither prepayment nor annual billing, so a funded account is the honest version of pre-paid runway. The goal is that the service keeps running long enough to matter even if nobody touches billing.
For the gap in exports: manifest exports for the things that aren’t in the dump. Not the secrets themselves, but the full map of what exists and where it’s wired. The difference between “figure out what we had” and “re-enter these values from our own vault” matters when time is a factor.
The bootstrapping problem
Part of this is circular.
The bus factor exists because I’m one person. A second person addresses the operator risk. Revenue funds proper on-call and support coverage. Enough customers justify data escrow with a third party.
I can’t hire before the business supports it, and some of you need these answers before it does. The approach is to close the gap with what’s available to a solo founder: continuity partnerships, automation, pre-payment, legal instruments. These answers will improve as the business grows, and I’ll keep posting about it as it matures.
What stays hard
Not all of this resolves with scale.
Acquisition risk exists for companies of any size. GitHub was acquired by Microsoft. Legal risk exists for any business entity. These aren’t solo-founder problems. They’re structural, and the mitigation is the same regardless of headcount: portable data, open formats, and the ability to leave.
The slow-rot scenario is the most resistant to structural fixes. A dead-man’s switch can detect that I’m gone. It can’t detect that I’m phoning it in. The signal for that is the release cadence, the patch response time, the quality of answers when you write in. Those are visible to you.