On-Premise Is Not a Downgrade

1. The claim

The industry describes on-premise work in the vocabulary of loss. Legacy. Regression. Enterprise tax. That vocabulary is not neutral, and it produces a specific engineering failure: teams build for the cloud, ship, and then attempt to subtract their way to an on-premise release. Subtraction is where the cost is. Almost every hour I have watched burned on sovereign delivery was spent removing an assumption that had been free to avoid at the start and expensive to remove later.

The claim is narrow and it is about ordering. Sovereignty adopted as a constraint before the first architectural decision costs roughly what any other constraint costs. Sovereignty adopted as a port costs several multiples of that, and the multiple grows with the age of the codebase.

2. The assumption ledger

What actually changes between a public cloud estate and an air-gapped one is a list. It is shorter than the folklore suggests, and each entry has a known design response.

That last row is the one that decides whether a sovereign product is viable. Every other entry is an engineering problem. The operator is a design problem, and the failure mode is a system that is correct and unoperable.

3. Why the constraint pays back

The interesting result is not that these responses are achievable. It is that each of them is independently good practice, and a team that adopts them under sovereign pressure ends up with a cloud build that is measurably better than the one they would have shipped without it.

  source  ->  reproducible build  ->  signed bundle
                                          |
                     +--------------------+
                     |                    |
                 public cloud       air-gapped site
                 (same bytes)        (same bytes)
                     |                    |
                 config as data      config as data

Three specific payoffs, in the order I have seen them arrive.

3.1. Dependency honesty. A build that must run with no egress cannot pretend about what it depends on. Transitive fetches, implicit base images and “it works on the runner” all fail immediately rather than in year three.

3.2. Reproducibility becomes non-optional. Shipping a bundle to a site you cannot reach means the bundle has to be the whole truth. That forces reproducible builds, which in turn makes cloud incidents diagnosable, because the artifact in production is byte-identical to one you can rebuild.

3.3. Configuration stops living in the environment. When the environment cannot be inspected, configuration has to be data that travels with the deployment and can be diffed. This removes a large class of cloud incidents whose root cause is a variable set by hand in a console two years ago.

Figure 2. The shape of the cost, not its magnitude. I do not have defensible figures for the ratios and will not invent them; see docs/PLACEHOLDERS.md.

4. What this looks like as a rule set

• One artifact. If cloud and on-premise builds differ, they differ in configuration data, never in code paths selected at build time.
• Every managed dependency behind an owned interface, with a self-hosted implementation running in CI on every commit.
• The supply chain is offline-first. Vendored, hashed, and verifiable without a network. A build that needs the internet is a build that cannot ship to a bank.
• Upgrades are signed bundles with a tested rollback, applied by a stranger, in one maintenance window, with no interactive prompts.
• Capacity is stated as the point at which the system fails, not as a target it meets. The operator needs to know where the edge is, because they cannot add nodes.
• The runbook is a deliverable, versioned with the code, and it is wrong until somebody who did not write the system has followed it end to end.

5. The strongest objection

6. What this paper does not claim

On-premise is not cheaper. Total cost of ownership is usually higher, and the customer is usually paying it deliberately, for reasons of jurisdiction, audit or counterparty risk that have nothing to do with engineering. Nothing here says cloud teams are undisciplined, only that the sovereign constraint removes the option of skipping the discipline, which is a different and much weaker statement about them.

The assumption ledger in Section 2 is not complete. It is the list I have needed so far, across six sites, and every new estate has added to it.