The question this pattern answers

"How do we run a multi-app product reliably — and repeat it everywhere?"

• Fred is four cooperating apps plus a stateful backbone — not a single container.
• Getting it running once is easy. Getting it reproducible, auditable and safe to change is the real work.
• A deployment must answer: where does state live? who can break what? how do we roll back? how do we do it again in the next environment?

The wall is never the demo. The wall is operating it, repeatably, under governance.

Two repositories, one clean split

Separate what the product is from how & where it runs

The product team ships images and a reference chart. The platform team owns the environment. Neither leaks into the other.

The product: four apps + a backbone

What actually gets deployed

• A control / API service — sessions, lifecycle, governance, metrics: the platform's API surface.
• A knowledge service — ingestion, retrieval and content lifecycle (RAG): an API plus an async worker.
• An agent runtime — runs the tool-using agents.
• A web UI — for end users and operators.

Four stateless services. Every one depends on a stateful backbone they do not own: Postgres, OpenSearch, Keycloak, OpenFGA, Temporal.

The core idea: two layers + secrets

Match the deployment mechanism to the risk and the change-rate

One product, two governance models. The split is the whole pattern.

Foundation — the part you protect

It holds your data and your identity, so you change it rarely and on purpose

• It remembers — your data, your accounts and your permissions live here. Lose it and the loss is real.
• Everything leans on it — every app depends on it; it is shared, and it must stay stable.
• You change it deliberately — rare, reviewed changes — never as a side effect of shipping an app.
• You set it up once, then leave it alone — it's the stable base every app, and every future install, relies on.

A new account system, a new database, a new public address is a foundation decision — made on purpose, not by accident.

Apps — shipping a change means writing it down

The deployment is a decision recorded in git, not a manual operation

• Git holds the wish — one line says which version of each app should run.
• The controller keeps reality matched to the wish — and flags any gap on its own.
• To ship, change one line; to undo, restore the previous one — always recorded, always reversible.

Write the change down and the system makes it real. This can run fully automatically; for now each change is approved on purpose.

The boundary — built to install anywhere

Soon Fred runs on a customer's own infrastructure, so the apps must not depend on ours

• The apps don't know which platform they run on — they reach the Foundation (database, login, and the rest) by fixed names, never by a specific machine or cloud. On a customer's platform those same names are all that must exist; the apps are untouched.
• Apps use the Foundation; they never build it — creating the database, the accounts and the public web address is the platform owner's job. On the customer's infrastructure their team provides the Foundation, and the apps plug straight in.
• The dependence runs one way — apps need the Foundation, never the reverse — so you set up the Foundation first, then place the apps on top.
• The payoff — putting Fred on new infrastructure is a re-install, not a rebuild: recreate the Foundation, point the apps at it, done.

Same apps, any infrastructure — because they never depend on a particular one.

Why this is the corporate pattern

Five properties every regulated deployment needs

• Blast-radius isolation — an app deploy cannot touch the database. The dangerous, stateful layer is small and rarely touched.
• Velocity with safety — apps iterate via GitOps; infra moves slowly and deliberately.
• Clear ownership — the platform team owns the Foundation; app teams own the Apps.
• Disaster recovery — wipe and re-sync the whole Apps layer from git in minutes; back up only the Foundation.
• Portability — a new environment is a new values overlay + secret source, not a new design.

Same code, same pattern — from a sample instance to sovereign cloud.

The road to corporate-grade

The same pattern, turned up for each environment and classification

A concrete backlog already exists for the team — see the deployment-factory RFC.