Deploy & the fleet

Forge is delivered as an image you pin. Your instance runs a version you chose, on infrastructure you control, and it moves when you decide it moves.

That is a different relationship from a SaaS, and it comes with different promises.

Upstream and downstream

The product evolves upstream, through our own environments and gates, and then descends to instances. Instances are siblings, not tiers: each is a whole Forge on its owner’s infrastructure. There is no central database with everyone’s data in it, and there is no instance that is secretly the “real” one.

Two rules hold across the whole fleet:

Code goes down; data never goes sideways. A new kernel version travels to your instance. Your data stays where it is. Nothing is ever moved between instances.

Forward-only from go-live. Once an instance is live, it moves forward. Migrations are written to be applied, not reversed — because a reversal that touches real orders is a data-loss event with a friendly name.

What pinning actually means

You pin an image version. Upgrading is a deliberate act: you choose the version, you choose the moment. Nobody upgrades you overnight, and nobody can.

⚠️ The kernel lock is physical — you run the image you pinned. The decision layer’s lock is one of process: your decisions are yours, and it is on you not to break your own contract with them.

Never fork the kernel

You can customise a great deal — apps, custom fields, decisions, your own storefront. All four sit outside the part that moves, so all four survive upgrades.

Forking is the one thing that does not. The moment your kernel diverges, every upgrade becomes a merge, and the cost compounds forever.

If the seams do not reach far enough for something you need, that is worth telling us: a genuinely neutral primitive can go into the kernel and then ships to everyone. That is the trade — reciprocity rather than a private branch.

The contracts are frozen

The types that define the port do not break. New commands appear, new fields appear, existing shapes keep working. Where something genuinely must change, it is a versioned, deliberate act with a migration path — not a silent redefinition.

The operating principle is the one Linux uses: don’t break userspace. Your integration is userspace.

Your storefront and admin are yours to replace

They ship as a reference implementation. If you replace them, they stop being our problem and become yours — and the kernel does not notice, because they were always just consumers of the port.

That is the intended outcome for anyone who customises heavily: own the front, keep the kernel, keep the upgrades.