One deployment per customer or one space per customer
Anyone building a product for several companies runs into the same decision, usually late: does each customer get their own deployment, or does everyone share one with the application keeping them apart?
It is decided once and conditions everything else: how much each new customer costs, what happens when one asks for their backup, whether you can update everyone at once, and what you answer when the biggest one demands that their data share a database with no one.
The two answers, both implemented
I don't talk about this in the abstract. I have both forms running, with their posts behind them: Konect runs one deployment per customer, and Zetesis Portal separates customers inside a single deployment.
| One deployment per customer | One space per customer | |
|---|---|---|
| Isolation | Physical: their database, their credentials, their realm | Logical: validated on every server query |
| New customer | One more deployment to operate | One more row |
| Updating | As many times as there are customers | Once |
| A customer asks for their data | It's their entire database | You have to extract it by filtering carefully |
| Customizing | Each one can run their own | Everyone runs the same thing |
| Where it hurts if you fail | In operating cost | In an unfiltered query |
What really decides it
The answer doesn't come from the table; it comes from three questions about your business.
The first is how many customers you expect. With ten large accounts, one deployment per customer is manageable and makes a solid sales argument. With five hundred, it becomes an operations platform you never budgeted for.
The second is whether customers will ask for different things. When a customer needs their own logic —a particular processing step, an integration no one else uses— the separate deployment stops being a cost and becomes what makes the deal possible.
And the third, the uncomfortable one: what happens if a query slips through unfiltered. With logical isolation, a failure like that shows one customer another's data. It's a perfectly manageable risk —you manage it by validating on the server, not in the interface— but there are sectors where that conversation can't be won with technical arguments.
Logical isolation stands or falls on access
If you choose space-per-customer, identity stops being an implementation detail. Permissions have to live at two levels —what you are in the platform and what you can do inside each space— and the second can't come signed in the token, because the same person has different roles in different spaces. I develop this in the post on centralized identity.
The rule you have to be able to demonstrate in an audit is simple to state and easy to break: scope is applied on the server, in the field, and a direct API request hits the same wall as the form.
How I work
I review what you already have before proposing anything. Often the decision is half made —logical isolation with one large customer who's already been promised their own deployment— and the job isn't choosing, it's tidying up what's there without stopping the product.
Out of that comes a short document with the recommendation, what each path costs to operate, and the order in which a migration would happen. If needed, I implement it; if not, your team has a thread to pull on.
When you don't need me
If you have one and a half customers, this decision isn't urgent: almost anything works, and over-designing it now is time you're not spending on landing the third customer.
And if you already have a clear answer that's working, don't touch it just to make it prettier. These migrations are paid in full and only pay off when there is a concrete pain behind them.
Who it's for
For whoever is building a product several companies will use and can still choose. And for whoever already chose, has grown, and is starting to feel the decision no longer keeps up —because each new customer costs too much, or because the biggest one asks questions that can't be answered with logical isolation.
Both forms, told
Konect: audio transcription and analysis
Zetesis Portal and PayloadAgents: how we built our SaaS
Platform architecture consulting
Search and agents over your own documentation
Coder: remote development environments with devcontainers for the whole team
Postiz: scheduling social media posts from your own server
Let's talk
Tell me how many customers you have today, how many you expect, and what the big ones are asking for. With that it becomes clear fairly quickly whether the separation you're running will hold what's coming.