The Bitwarden model: why I made the server AGPL and charge for hosting

When you're building a developer tool and you want to charge money for it, you have to decide where the line sits between what's open and what's not. The server for cmdock (a hosted TaskWarrior sync service) is AGPL-3.0. Every feature is available with no "community edition" that has half the endpoints missing and no enterprise binary with the good stuff behind a licence key. One binary that is fully open and available to self-host for free.

The commercial product is the hosting with the uptime, backups, push notifications, support. It's so that you don't have to think about SQLite WAL checkpoints at 2am. That's what you pay for and for those that have worked in IT long enough, you know that's worth paying for.

The licensing spectrum

Developer tools in 2026 sit somewhere on this spectrum:

Fully proprietary. You can't see the code and you either trust the vendor or you don't. Todoist, Things 3 and ClickUp work fine for consumer apps but it doesn't work when your data format is an established open standard and your audience runs Arch :)

Open core. The basic version is open source and the good features are behind a licence. GitLab pioneered this model. The problem is the line, where every feature decision becomes a licensing question. "Should audit logging be free?" "Is SSO a community feature?" The community feels nickelled and dimed and I spend engineering time trying to maintain two build pipelines.

BSL (Business Source Licence) has the source available but you can't run a competing hosted service. Sentry, CockroachDB, HashiCorp (sort of) fit this model. It's honest and transparent but it's not open source by any OSI definition. I'm not sure what the TaskWarrior community would think of that.

AGPL is fully open source. The network clause means that anyone who runs a modified version as a service must release their changes. You can self-host unmodified all day. The commercial moat is operations, not the code.

I settled on AGPL as being the right fit for me and I hope the community.

The moat is operations

Here's my thinking. A /metrics endpoint is a Prometheus scrape target and it's worthless without the Prometheus instance scraping it, the alerting rules interpreting it, the Grafana dashboards visualising it and the on-call rotation responding to the alerts.

The server exposes health checks, backup CLI subcommands, admin diagnostics and Prometheus metrics. All of that ships in the AGPL binary and a self-hoster gets everything the binary can do.

But the binary doesn't run itself. It doesn't configure TLS certificates or set up automated backups with 30-day retention or get someone out of bed when disk usage hits 80%. It doesn't handle the database migration when version 0.5 ships with a schema change.

That's the operations value of what a hosted service provides. And that's what lives in a separate private repository with deployment automation, infrastructure-as-code, monitoring configs and runbooks. The server is the product and the ops repo is the business.

Proof this works

This isn't a new model. Like most good things I've borrowed it from people who've proved it at scale.

Bitwarden password manager. The server was GPL (later moved to a custom licence but the principle held for years). Self-hosters can and do run Vaultwarden these days. Bitwarden grew to millions of paying customers because most people don't want to maintain a password server. The self-hosters were advocates who recommended Bitwarden to their non-technical friends and employers.

Grafana's visualisation server is AGPL. All plugins and all features are in the one binary. Grafana Labs makes money from Grafana Cloud which is hosted Grafana with managed Prometheus, Loki and Tempo. They're worth over $6 billion and the AGPL code didn't stop them making a successful business.

MinIO object storage is AGPL. Self-hosters can run it for dev and in their homelab. Enterprise customers pay for the commercial licence that gets them the support and managed offerings. The open source version generates the enterprise leads.

It's the same model you see all over the place. You give away the software and charge for running it reliably. Don't think of the self-hosters as lost revenue, they're actually your best promoters.

Self-hosters make the product better

There's a benefit to AGPL that the business model discussions usually miss, and that's the feedback.

Self-hosters tend to be demanding, right? They deploy on weird hardware and push edge cases you'd never think of and they'll tell you in detail when something doesn't work. They file issues with stack traces and they care about your project in a way that SaaS customers scrolling through a dashboard never will.

The cmdock server exists because of TaskWarrior. TaskWarrior exists because of an open source community that's been contributing and filing bugs and building tools around it for over a decade. The sync services that existed (inthe.am, FreeCinc) were community contributions too with people running servers for free because they cared about the ecosystem. They eventually shut down because the economics didn't work but the idea was right.

My thinking is that making the server AGPL is partly paying that forward. The TaskWarrior community gave me the tool I use every day and the least I can do is give them a sync server they can run themselves. They can read the source and trust isn't going to disappear behind a paywall when I hit some revenue milestone.

And practically? The self-hosters who deploy on a Raspberry Pi and a NUC and a Proxmox cluster are the ones who find the bugs. They're the ones who'll tell me the Docker compose doesn't work without a specific port exposed, or that the admin CLI crashes on ARM64, or that the backup command doesn't handle a full disk gracefully. That feedback makes the hosted version better for me and everyone.

There's something else I've noticed in the TaskWarrior community that I think is worth pointing out. People do want to pay for things that work. Not because they have to (they could self-host for free) but because they've watched inthe.am shut down and FreeCinc disappear and they understand what happens when a service has no revenue behind it. They'll subscribe to keep the lights on because they'd rather pay a few dollars a month than lose another sync service in two years.

And that's not charity. They get a reliable service they don't have to maintain and they get the confidence that it'll still be there next year because someone is being paid to keep it running. The subscription isn't just buying hosting, it's buying sustainability. I think that's a relationship worth building honestly and AGPL is how I start it.

Why not BSL?

I seriously considered BSL as it would have prevented a well-resourced competitor from standing up a competing hosted service using my code. That's a real risk with AGPL. Someone could fork the server, make zero modifications, and offer hosting competing with me.

But here are the things that tipped me toward AGPL.

Firstly, the AGPL network clause isn't nothing. If a competitor modifies the server and hosts it, they must release their modifications. That's a meaningful deterrent for anyone building proprietary features on top. Cloud providers in particular hate this requirement and that's why AWS doesn't touch AGPL projects.

Secondly, the TaskWarrior community is FOSS-literate. These are people who run their task management from a terminal. They'll notice if the licence has asterisks. "Fully open source, AGPL-3.0" is a clean message to those users. "Source-available, BSL 1.1, converts to Apache after four years" requires a paragraph of explanation and someone will still call it bait-and-switch.

Thirdly, the first-mover advantage matters more than code protection in a niche market. There's no funded competitor in the TaskWarrior sync space. The sync services that existed are dead, with inthe.am shutting down in January 2024 and FreeCinc in February 2023. The official taskchampion-sync-server has no authentication. I'm not defending against a well-funded competitor here. I'm trying to earn trust from a small community that's been burned by services shutting down.

AGPL is the trust signal to that community. BSL is a fallback I can switch to later if the market changes.

The two-repo boundary

The implementation is clean. Two repositories:

The boundary is: code that runs as the server process is AGPL. Code that operates the infrastructure around it is private.

This isn't a secret. I'll say it openly in the README. "We open-source the server. We don't open-source our deployment automation." Grafana and GitLab both do this. It's a well-understood boundary.

What I gave up

I've accepted that a funded competitor could legally fork the AGPL server, stand up hosting and compete with me on price. They'd need to release their modifications (AGPL Section 13) but if they make no modifications there's nothing to release. The defence is that operations expertise and first-mover reputation are harder to replicate than code.

There's also no code-level differentiation between the hosted service and a self-hosted instance. Every feature I build for paying customers is also available to self-hosters. The value proposition is purely operational. I'm betting that most developers would rather pay a few dollars a month than maintain a server, configure TLS, set up backups and troubleshoot WAL checkpoint stalls.

And the ops tooling developed privately can't benefit from community contributions. If someone in the community builds a better Grafana dashboard for the metrics endpoint I can't merge it into the private ops repo in the same way.

These are acceptable trade-offs for a solo founder pre-product-market fit (PMF). Engineering simplicity with one binary and one repo and one build matters to me more than defensive licensing at this stage. If the market changes the decision has a clear migration path to BSL. Not that I'm planning that or want that.

The decision framework

If you're building a developer tool and stuck on licensing, here's the framework I used:

Is your audience FOSS-literate? If yes, lean AGPL and hope the trust dividend is real.

Is your moat code or operations? If it's code then consider BSL or open core. If it's operations (hosting, uptime, support) then AGPL works because the code isn't the competitive advantage.

Are you pre-PMF? If yes then optimise for delivery simplicity and trust. Don't spend engineering time on dual build pipelines and feature flags. Ship one binary and earn customers with great service.

Is there a funded competitor? If yes then BSL might be necessary to prevent them cloning your service. If no then AGPL's network clause is sufficient deterrent.

For cmdock the answers were yes, operations, yes and no. AGPL was the obvious choice.

The server code is at github.com/cmdock/server. Self-host it, read it, fork it. And if you'd rather not think about backups there's a hosted version for that.