By mid-March, the Matrix work had stopped being only about getting services to start.

The real question became:

How do I operate several related stacks without turning staging and production into a pile of special cases?

That led to two connected tasks:

  • a multi-stack backup model,
  • and a production-clone strategy based on the already working staging pattern.

Why I Wanted A Shared Backup Model

The stacks were separate, but the operational pattern was similar:

  • each stack lived under its own Unix user,
  • containers were rootless,
  • some stacks needed database dumps,
  • some only needed file backups,
  • and encryption plus upload should stay centralized.

That suggested a job-based backup model rather than one hand-written script per application.

The Useful Split

The cleanest split was:

  • application-level container commands run in the context of the owning stack user,
  • sensitive backup orchestration stays centralized,
  • and each job defines exactly which files and databases matter.

That model respects the same boundary I had been building everywhere else:

  • app ownership stays local,
  • control and oversight stay centralized.

Cloning To Production Without Redesigning

The production work followed the same principle.

I did not want a new architecture for production. I wanted a mechanical clone of the tested architecture with environment-specific values changed deliberately.

That meant:

  • same structure,
  • same service boundaries,
  • same secret flow,
  • same proxy pattern,
  • but different runtime values, identities, and data.

What Not To Copy Blindly

This was the most important operational rule from this phase:

copy structure, not accidental history.

That means config patterns are reusable. Live runtime state often is not.

Especially in identity-heavy systems, cloning the wrong state can create more confusion than a clean fresh environment.

Why This Phase Matters

A stack is not mature just because it serves traffic.

It starts becoming mature when you can answer questions like:

  • how do I back it up,
  • how do I rebuild it,
  • how do I promote the pattern to production,
  • and which parts are safe to copy versus regenerate.

That was the transition point in this Matrix work. It stopped being only deployment and became operations.