Open Source Commitment

Built in the open.

Where we are, where we're going, and why you shouldn't take our word for it.

Last updated April 6, 2026

The short version

DeployBase will be open-sourced under AGPL-3.0. The full platform — frontend, backend, build system, infrastructure — will be publicly available and self-hostable.

Today, the CLI is open source. The rest is coming. This page explains what, when, why, and — most importantly — why you should be skeptical of everything I just said.

What's open today

Why 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:

2021

Elasticsearch switched from Apache 2.0 to SSPL — after explicitly stating the core would remain Apache 2.0. AWS forked it as OpenSearch.

2023

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.

2024

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.

I can't promise I won't do the same thing. No founder can — and anyone who says otherwise is either naive or selling you something. What I 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

Done

  • CLI open-sourced under Apache 2.0 on Codeberg
  • MCP server built with public API access (ready for extraction)
  • All major integrations behind swappable interfaces (CDN, payments, auth)
  • This page — public commitment with honest FAQ

Next

  • Add AGPL-3.0 LICENSE to the repository
  • Extract MCP server to its own public repository
  • Write CONTRIBUTING.md and contributor guidelines
  • Open the full repository on Codeberg

Later

  • 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 I'd ask if I were evaluating a small company's open source commitment. I tried to answer them honestly.

Why not open source everything today?

Honest answer: priority. I'm building my first SaaS and my time is better spent making the platform work well so companies can move off American cloud providers now — not in a couple of weeks. I also want to write proper contributor docs and set up the infrastructure for outside contributions. Rushing it would mean a worse experience for everyone.

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. I 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 me by actions, not words. The CLI is open source today. The full platform will follow. If I break this promise, fork it.

What if you get acquired?

I'm not planning to sell. I'm 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. I'm 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 I run out of money, I 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?

I will strive for that. Having worked with open-core products myself, few things are more frustrating than basic security features locked behind enterprise pricing. SSO is a security baseline, not a luxury — I 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 I 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 I've seen too many open-core companies gate basic features behind enterprise tiers to extract maximum revenue. My 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 yet — the repo is still private. When we open it up, we'll have a CONTRIBUTING.md with guidelines. We'll use a Contributor License Agreement (CLA) so we can maintain the /ee directory separately, but the CLA won't 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 I 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 I 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.