Open core, self-hosted, and the licensing logic

A lot of companies say they are open core. Most of them mean: the useful parts are closed; here is a free demo of a stripped-down version. When we say it, we mean something more specific. This post explains where the open-source line is in Portfork, why it is where it is, and what the practical implication is for you — especially the part that surprises people: the runtime that actually hosts your apps is the open part, not a teaser.

What is open source

These pieces are AGPL-3.0:

• The Portfork runtime. The local-first software that places an app, runs it on demand, scales it to zero between requests, and reaps it when idle. This is the engine. It is open source and free, today, forever, and it hosts unlimited apps on your own machine.
• The control surface. The dashboard, the CLI, and the MCP server your agents use to deploy and manage apps. It is the same code in self-host mode and Cloud mode; we build it from one repo.
• The local hosting path. Everything you need to run agent-built apps on your own hardware with lazy-start and idle-reap. No account, no network calls in the default configuration.

These pieces are commercial, source-available where it makes sense, private otherwise:

• The Portfork Cloud control plane. The multi-tenant orchestration layer that schedules per-app microVMs, hands out stable URLs, manages billing and account lifecycle, and delivers always-on uptime. This is what your subscription pays for.
• The microVM fleet operations. The managed compute, networking, and secret injection that make Portfork Cloud always-on and isolated.

Why AGPL-3.0

There were two real choices: MIT and AGPL-3.0. We picked AGPL.

MIT would mean a cloud provider could fork the runtime, host it as a SaaS, and never give anything back. We watched that pattern play out in the database market in the 2010s and we did not want a re-run with our project.

AGPL is the strongest copyleft that still survives a normal commercial adoption pattern. If you run Portfork internally inside your company, the AGPL is the same as the GPL — you do what you want. If you offer Portfork to others as a hosted service, AGPL requires you to make your modifications available on the same terms. That is the deal.

Practically, AGPL means:

• Developers can fork, modify, and self-host the runtime without asking us. The license already permits everything they reasonably need.
• Companies that want to build a competing managed host on top of Portfork have to keep their modifications open. That is fine. The control plane is the moat, not the runtime.
• Portfork’s own users get the strongest possible portability guarantee. If we go away, the runtime and the control surface are open source and AGPL-licensed. You keep hosting your apps.

The same artifact runs in both places

The piece that is unusual: the app you run locally on Open Source Portfork is the same artifact you push to Portfork Cloud. There is no rewrite, no separate cloud packaging, no migration.

We made this call deliberately. Three reasons:

1. The product is on-demand hosting. A Cloud-only product would be a worse version of the value we sell. The whole pitch is that an app that runs twice a day should be cheap and always reachable. That has to include the option to run it entirely on your own machine.
2. The technical work is the same. We already build the runtime as the thing that hosts apps for our own Cloud. Shipping it as the open-source local host is a marginal-cost decision, not a strategic one.
3. It changes the economics of trust. A developer who can already self-host is far more relaxed about pushing to Portfork Cloud. The exit ramp is real, not a marketing claim.

What this means in practice

If you are on a Cloud tier and Portfork Cloud goes down — or goes away entirely — you can run the same apps on Open Source Portfork on your own machine. The artifacts are identical. Your agents keep deploying through the same CLI and MCP server.

If you are a developer who wants to inspect what is going on inside the runtime, the code is on GitHub today and you can build it yourself. You bring your own model access either way, so there is no inference markup: the runtime hosts the app, your provider serves the model.

The licensing line we drew, in one sentence

The software that hosts your apps is open source. The work of running it for you reliably, always-on, in isolated microVMs that scale to zero is what you pay for.

We think that is the honest version of open core.

Try Portfork on the free Open Source edition. When you are ready for always-on, pricing is here.