Open source, eventually.
Where we stand, what changed since we first wrote this page, and why you shouldn't take our word for it.
Last updated September 1, 2026
The short version
deploybase intends to be open-sourced under AGPL-3.0: the full platform, self-hostable. That is a real goal. It is also not close. We are a small team building the platform itself, and we would rather say "eventually, no date" than promise a quarter we will miss.
An update in the spirit of this page: in early 2026 we open-sourced our CLI and MCP server under Apache 2.0. Since then, development moved into our private monorepo and the public repositories stopped receiving updates. We could leave the "open source" label on them. It would be technically true and practically misleading. So today, nothing we ship is meaningfully open source, and this page says so.
What's public today
Two repositories exist on Codeberg. Both are frozen snapshots from spring 2026, not maintained projects. The maintained versions live in our private monorepo.
deploybase CLI
Command-line deploy tool. Open-sourced under Apache 2.0, then development moved into our monorepo. The public repo is a snapshot, not the current tool.
Snapshot on CodebergMCP Server
MCP server for managing deploybase from AI agents. The public repo is v1.x; the maintained server (v2.2, 33 tools) is closed source today.
Snapshot on CodebergWhy AGPL-3.0
Prevents free-riding
If someone takes our code and offers it as a competing hosted service, they must share their modifications. This is why Grafana, Cal.com, and Plausible chose AGPL.
OSI-approved
AGPL is real open source — not "source available" like BSL or SSPL. It's recognized by the Open Source Initiative and accepted by most enterprise compliance teams.
Forkable
If we ever break trust, anyone can fork the last AGPL version and continue. That's the point — the license protects you from us.
Community contributions stay open
AGPL ensures that improvements made by anyone — including us — stay available to everyone. No proprietary extensions of the core.
The trust problem
Every company says they're committed to open source. Here's what happened to some of them:
Elasticsearch switched from Apache 2.0 to SSPL — after explicitly stating the core would remain Apache 2.0. AWS forked it as OpenSearch.
HashiCorp switched Terraform from MPL 2.0 to BSL after a decade of championing open source. OpenTofu was forked within days by 140+ organizations. IBM acquired HashiCorp a year later.
Redis changed from BSD (15 years) to SSPL. The Linux Foundation launched Valkey — 83% of large Redis users adopted it within a year. Redis eventually added AGPL back, but the damage was done.
We can't promise we won't do the same thing. No founder can — and anyone who says otherwise is either naive or selling you something. What we can do is choose a strong license from day one, explore ownership structures that make license changes structurally difficult, and build enough trust through actions that breaking it would be self-destructive.
Judge us by what's shipped, not what's promised.
Roadmap
Next is in motion. Later has no dates attached, on purpose: we will not pretend to a schedule we do not have.
Done
- CLI open-sourced under Apache 2.0 on Codeberg
- MCP server open-sourced under Apache 2.0 on Codeberg
- First releases (v0.1.0) published with cross-platform binaries
- CI/CD pipelines on Woodpecker CI — automated testing and releases
- All major integrations behind swappable interfaces (CDN, payments, auth)
- This page — public commitment with honest FAQ
- Honest update: CLI and MCP development moved back into the private monorepo, public repos frozen (mid 2026)
Next
- A public /open page with live platform metrics (builds, bandwidth, forms, domains)
- Publish what it costs to run deploybase
- Decide what to do with the frozen Codeberg snapshots (archive with a pointer, or refresh)
Later
- Add AGPL-3.0 LICENSE and CONTRIBUTING.md
- Open the full repository on Codeberg
- Docker Compose self-hosting (PostgreSQL + backend + frontend + builder)
- Local CDN adapter (filesystem + nginx, no Bunny.net required)
- Docker-based build runner (no Kubernetes required for self-hosting)
- Helm chart for Kubernetes self-hosting
- Explore steward-ownership / stichting structure
Self-hosting
The goal is a self-hostable deploybase via Docker Compose — the same way Plausible, Sentry, and Supabase do it. One file, a few environment variables, and you're running your own instance.
The architecture already supports this. CDN, payments, and auth are all behind swappable interfaces — self-hosters can use local file storage instead of Bunny.net, skip payments entirely, and bring any OIDC provider (Keycloak, Auth0, self-hosted Zitadel).
The main engineering work is a Docker-based build runner (replacing Kubernetes Jobs) and a local CDN adapter. This is planned, not imminent.
FAQ
These are the questions we'd ask if we were evaluating a small company's open source commitment. We tried to answer them honestly.
Why not open source everything today?
Honest answer: focus. We are a tiny team and our time goes into making the platform good enough that companies can move off American cloud providers now. We also learned something the first time: we open-sourced the CLI and MCP server, then let the public repos go stale while the real development happened privately. Half-open is worse than closed, because it looks like abandonment. When we open the platform, it will be maintained in the open, not mirrored into the open.
Why AGPL and not MIT?
Competitive protection. MIT would let Amazon or any large provider take the entire codebase, host it, and compete without contributing anything back. AGPL prevents that — if you modify deploybase and offer it as a service, you have to share your changes. It's the same license Grafana, Cal.com, and Plausible use. We admire Cal.com's radical transparency and want to follow a similar path. AGPL is also OSI-approved, which means it's "real" open source — not the source-available-but-not-really licenses that have caused so much damage to trust in the industry.
Should I trust this promise?
No. Not blindly. Elastic promised Elasticsearch would stay Apache 2.0 — then switched to SSPL in 2021 (AWS forked it as OpenSearch). Redis was BSD-licensed for 15 years — then went SSPL in 2024 (the Linux Foundation forked it as Valkey). HashiCorp championed open source for a decade — then switched Terraform to BSL in 2023 (OpenTofu was forked within days). Every one of those companies said they were committed to open source. Judge us by actions, not words. And we already have a mark against our own name here: we open-sourced our CLI and MCP server, then moved development back into our private monorepo and let the public repos freeze. This page said "open source" for months while that was true. We have corrected it, and that correction is the only credibility we can offer: when reality changes, this page changes. Judge us by that.
What if you get acquired?
We're not planning to sell. We're actually exploring steward-ownership structures — like a Dutch stichting (foundation) that holds a controlling share and prevents the company from being sold or its mission changed. Ghost does this through a nonprofit foundation. Plausible uses steward-ownership via the Purpose Foundation. We're new to this and still figuring out the right structure, but the intent is to make acquisition impossible by design, not just by promise.
What if deploybase shuts down?
If we run out of money, we will give customers a proper deadline to migrate (minimum 90 days) and open source everything — the full platform, infrastructure configs, all of it. Your data and your sites should never be held hostage by a company's financial situation.
Will self-hosted have the same features as cloud?
We will strive for that. Having worked with open-core products ourselves, few things are more frustrating than basic security features locked behind enterprise pricing. SSO is a security baseline, not a luxury — we don't want deploybase to end up on sso.tax. The cloud version will always be more convenient (managed CDN, managed builds, automatic updates, support), but we don't want to artificially cripple the self-hosted version to force upgrades.
Will enterprise features (the /ee directory) be expensive?
Enterprise features that don't exist yet (things like SAML SSO, audit logging, advanced RBAC) will live in a separate /ee directory under a commercial license. But we've seen too many open-core companies gate basic features behind enterprise tiers to extract maximum revenue. Our north star: if a feature improves security or is needed by small teams, it stays in the open core. The /ee tier is for features that genuinely only matter at organizational scale.
Why Codeberg instead of GitHub?
deploybase is built on the premise that European companies need European infrastructure. It would be hypocritical to host our source code on a Microsoft-owned platform in the US. Codeberg is a German non-profit running Forgejo (a community fork of Gitea). We may add a GitHub mirror for discoverability.
Can I contribute?
Not right now. The frozen Codeberg repos are not accepting contributions, and the platform repo is private. When we open the full repository we will have a CONTRIBUTING.md and a CLA that lets us maintain the /ee directory separately, but the CLA will not give us the right to relicense your contribution away from AGPL.
What's stopping you from changing the license later like everyone else?
Legally? Nothing. That's the uncomfortable truth. No company can make a binding promise about future licensing decisions — anyone who tells you otherwise is either naive or lying. What we can do: (1) choose AGPL from day one so there's never a downgrade to justify, (2) explore steward-ownership to remove the financial incentive for license changes, and (3) build enough trust through actions that changing the license would be self-destructive. The AGPL also means that even if we did change the license, the last AGPL version can be forked freely.
Questions?
If you have questions about our open source plans, licensing, or self-hosting roadmap — reach out.