A second SaaS should only add what belongs to it

When you launch a second SaaS, you discover something unpleasant: almost everything that makes the first one reliable has to be built again. The backups, the monitoring, the certificates, secret management, the release procedure, the evidence you owe a client or an auditor.

If each project rebuilds them its own way, you don't end up with three solid products. You end up with three products, three different security levels, and none of them genuinely held.

So the map below answers a single question: in a deployed SaaS, what belongs to the project, and what gets built once for all of them?

One clarification before we start

This is a target architecture. It is written down decision by decision — ADR-014 to ADR-034 in the Sluis repository, public, each one carrying the alternatives ruled out and the questions still open — and it is being validated step by step. It is not in production yet.

I'm publishing it at this stage precisely so it can be argued with before it sets. An architecture you only show once it's built is an architecture nobody can correct any more.

Reading the map in thirty seconds

It reads along two axes (labels in French; click to enlarge):

The background color says where each component lives — and therefore what powers it has. Zone 1, orange, is production: exposed to the internet, through the HTTP entry point only. Zone 2, blue, is trust and monitoring: never exposed, reachable through a private tunnel with two-factor authentication. Zone 3, green, is offline and external: whatever is authoritative. And outside the zones, in grey, is where things are built and approved.

The box color says who each component belongs to. Purple is specific to the SaaS, recreated for every project. White is common: built once, inherited by all of them.

If you remember one thing: adding a SaaS adds purple boxes only. All the white is already there.

Three zones, three rules

The zones aren't decoration. Each one carries a traffic rule, and it's those rules that protect you — not the tools that populate them.

Production only ever asks. It asks for a certificate, for a data key, or it emits a metric. It never reads anything in the trust zone that would make it self-sufficient. The consequence is the only one that matters to you: production holds the encrypted data, the trust zone holds the key that opens it, never both in the same place. An attacker who takes production leaves with ciphertext.

The trust zone writes to production only through the approved path. No permanently open admin session on the servers. Every change goes through git, then human approval, then the reconciler.

Whatever is authoritative is append-only. Write-locked backups, the evidence log, an external witness hosted elsewhere. Even an attacker holding production and the trust zone at the same time couldn't rewrite history: they could neither delete the backups nor doctor the logs.

That's the rule I put above all the others: no single component holds everything.

What belongs to each SaaS, and why

The purple is what carries a project's data and its business logic. It is isolated for two reasons, and the second one bears directly on your legal obligations.

Containment. Compromising SaaS A yields nothing on SaaS B: different space, different database, different storage, different vault rule, different certificate.

Erasure. Each person has their own encryption key, kept in a key store separate from the database. Erasing a person — the GDPR right to erasure — means destroying their key. Their data then becomes unreadable everywhere it still lingers: live database, replicas, archives, backups.

The gain is substantial, and rarely stated: you no longer have to hunt a person down row by row inside backups you specifically don't want to modify. And because the key store's backups are kept for less time than the data backups, the key retention period sets a maximum erasure delay — one you can publish in your privacy policy, and actually meet.

The trade-off is owned rather than hidden: the erasure window isn't zero. Between destroying the key and the expiry of the last backups that contained it, time passes. That delay gets published; it doesn't get concealed.

What is common to all, and why

The white is everything that is expensive to do properly and done badly when redone per project: the certificate authority, the master-key vault, the monitoring, the approval chain, out-of-region backups, the external witness, evidence collection.

Built once, it serves everything. And more importantly it improves once for everything: the day the monitoring learns to catch a new failure mode, every product benefits the next day.

It's also what makes a high compliance ambition sustainable for one person. I target the Essential level of the Belgian CyberFundamentals framework for my products — I explain elsewhere why that target. Rebuilding those measures project by project would be impossible. Inherited from the platform, they become a fixed cost, not a per-project cost.

The path of a release

Follow the left-hand column of the map, top to bottom:

1. The Foyer skill generates the project's files. It does not execute them.
2. Sluis checks that the repository honors the contract. It does not write the files. Whoever writes doesn't execute; whoever executes doesn't write.
3. The release is first run against the ephemeral second production.
4. The deployment gate runs its checks: configuration free of drift, monitoring alive, recent backup with a successful restore, signed images. Yes or no — no "almost".
5. A human approves, with a signature the machine cannot produce on its own.
6. Immediately before execution, the gate is replayed. If anything changed between approval and execution — a backup that failed in the meantime, monitoring that went quiet, a configuration that drifted — the deployment stops and the approval is voided. Nothing is retried automatically: a human re-approves, knowing what changed.
7. The reconciler applies the approved commit, and only that one.
8. A dated report goes to the evidence archive: who approved, when, which commit.

The principle behind those eight steps fits in one sentence: whatever asks cannot approve. Neither the AI agent nor Sluis holds what it takes to ship on its own.

Three choices that surprise people

Staging is real production, restored every night. Every night, production is restored elsewhere from the off-site backup, key store included, and a sample of the data is decrypted there. The restore test therefore happens every day, not once a year in a panic — which is precisely the gap I pointed at when reviewing an existing server's security, where the restore had never been proven from somewhere else. The next day's release is rehearsed there on real data. That copy has no network egress to third parties, it is protected like production, and it is destroyed each morning. If the restore fails, or simply doesn't run, an alert fires. Load testing and acceptance happen elsewhere, on fake data.

The AI agent gathers and proposes; it never acts alone. The body of an alert can be written by the attacker. An agent that reads that text while holding permissions to act is an entry point, not a productivity gain. Here it assembles the evidence and drafts a proposal; a human decides. It's the same human-stop principle as governing AI inside an organization.

Every recurring task signals its own success. A backup that stopped running makes no noise at all. So silence must never mean "all is well": each task emits a success signal, and it's its absence that raises the alarm. That's also why the external witness lives at a different provider — if the whole platform goes down, monitoring included, someone still has to notice.

What it costs, and the limits

I'm not going to sell you this as free.

• More moving parts. A trust machine, a server for the executor, a witness at another provider, backups in another region. That's the price of "no single component holds everything".
• A ceremony. Hardware keys, signatures, approvals: every release asks for a human gesture. That's deliberate, and it has a cost.
• Owned trade-offs. The vault auto-unlocks using the provider's key management service: you gain unattended restarts, but the critical secret moves to them. And on a VPS, the provider retains access to the machine's memory — the vault protects against compromise of production, not against the provider.
• One person holding all of it. Hence the insistence on automation, and on alerts that fire when something did not happen.

The roadmap has eight steps, each usable on its own. The first three — identities and keys, trust machine, first VPS recipe — are enough for a first production release. Steps 4 to 7 — replicated and archived database, one-key-per-person encryption, nightly second production, replayed gate and evidence — make it defensible at the Essential level. The eighth, moving to a cluster, waits until growth justifies it.

And in your case?

If you have several projects, or you're planning a second one, three questions are worth the detour:

• What have you already built twice that should have been common?
• Conversely, what did you share and now regret, because an incident on one project reached the others?
• Is your staging restored from your actual backups — or do you simply believe they work?

That third one, in my experience, produces the longest silences.

It's all open source, MIT licensed. The detailed decisions, with the alternatives ruled out and the questions still open, are in the docs/adr folder of the Sluis repository. If you'd like to look at what this map would mean for your projects, or dig into one zone in particular, let's talk.