Cell: the dedicated stack is a fortnight

01 · What one copy contains

Some parts split cleanly. Some cannot be split at all

"Their own instance" sounds like one thing. It is really about eight things, and they do not all behave the same way.

Jargon, once: each customer is a tenant. One customer's complete private copy is a cell. Amazon calls a fully shared setup a pool, a fully separate one a silo, and a deliberate mix of the two a bridge.1 This is a bridge.

Everything inside the amber line is theirs, inside its own fenced network (a VPC). Everything below it is shared, and mostly cannot be unshared

The dashed boxes are the ones people forget. Sign-in, outside services, the investors' app server and the update pipeline are shared whether or not the contract mentions them, so the contract should mention them.

Three of those are worth explaining, because they are the ones that surprise people.

Logins. Every customer can have their own sign-in setup inside one shared account.23 Giving each one a genuinely separate account later is painful: every user gets a new ID, every company has to update its sign-in link, and rescuing saved passwords may need help from the vendor.24 So this is a day-one decision, not a later one.

Outside services. Limits from AI providers, email services and market data belong to your company account, not to each customer. Ten copies calling the same service still count as one customer to that service. Splitting that means ten separate contracts, not ten separate settings.

The investors' app. The people on the phone app are investors, and one investor might follow five companies that live in five different copies. So the app talks to one shared server, and that server becomes the single reader with a key to every copy. The keys only allow reading, and only of the pages meant for investors. When the app needs to save something (a question for a company, say) the server does not reach into that copy's database. It knocks on the copy's own front door, its API, and lets the copy do the writing. Section 04 shows the moving parts.

Worth being honest about: the fence is about networks, not buildings. Each copy's private network keeps every other customer out, and the wiring enforces that. But all the copies still run in your cloud account, on Amazon's machines, managed by your team.3 A customer who needs their copy to live in their own account is asking for a different, more expensive product.

The customer who has customers

One case breaks the picture above. Some buyers are agencies: an investor-relations firm might look after twelve listed companies at once. Their copy is private to them, but inside it they are running twelve clients.

So the dividing line is the firm, not the company, and the app still has to keep those twelve apart inside the private copy. That changes the customer list, the login setup, how usage is billed, and whether one of those twelve can ever be moved out on their own. None of the research covers this, because nobody asked about it. If your first private customer is an agency, work this out before writing any code, because it changes the shape of the data rather than a setting.

02 · Ten copies, one update

Why one stuck copy stops the whole fleet

Scroll through this bit slowly. It is the single most important thing on the page, and it is the reason a fleet needs rules that one app never does.

Ten copies, all running the same update. Same code, same settings, same data changes.

current version updating data change done stuck waiting

Clean-up step: waiting

The same thing, without the animation

One sealed record per update names the exact code and data changes that go together. Nothing ever ships as "whatever is newest".

It goes out in waves. One copy first, then a few, then the rest. A wave that fails stops the ones behind it.

Nine copies finish the data change. The tenth gets stuck. Those nine keep working, because the old code still understands the new data.6

So the last step, the one that deletes the old data, is held back on all ten. That hold is what stops the ten copies drifting apart.

The trick underneath is called expand and contract: add the new thing first, let both the old and new versions work for a while, and only delete the old thing once every copy has caught up.6

It costs four releases where a single app would need one. That is the price of a fleet, and it is what lets copy number ten sit on old code for a fortnight without anyone noticing.

Each copy also needs its own progress log, so a half-finished job restarts from 60% rather than from zero. With one database you can just run it again. With ten you cannot.

03 · How an update travels

One sealed record, released in waves

The mistake is letting each copy update itself whenever it notices new code. Then ten copies are running ten slightly different things and nobody can say what any customer actually has.

Every wave has to pass before the next one starts, and the last step waits for everyone

GitLab runs its private customers roughly this way: a set update window rather than a version each customer picks.32 33

The sealed record is just a list. The exact code version, the exact API image, the settings version, the data changes, and which older versions it is still compatible with. The update system sends that same record to every copy rather than telling each one to fetch the newest code.

04 · Fix first

Four things to sort out before the second copy exists

A Scheduled jobs

Apps run jobs on a timer: fetch prices, send digests, tidy up. NestJS registers those inside the app itself, and it has no way of knowing another copy is running the same job.7

Inside one copy that is already handled here, with one machine doing the timed work. Across ten copies it is not. Ten copies all calling the same outside service at 9am look like one very rude customer to that service. Hosted timers have the same problem: one platform's docs say outright that jobs can overlap and the same one can be delivered twice, so build them to be safe to run again.8

Fix: give each copy a slightly different start time, worked out from its name, so they spread out instead of arriving together. Then sort the jobs into the three piles: this-customer-only, everyone-once, and calls-an-outside-company.

B Settings

The app reads around 380 settings. That number sounds frightening and is not: the great majority are identical everywhere, like how much detail to write in the logs.

Only about 25 to 30 actually point at something belonging to one customer: their database, their cache, their web address, their storage.

Fix: one question for every new setting. Does it name something that belongs to this customer, or does it just change behaviour? Behaviour goes in the shared pile, where a code change reaches every copy on its own. Watch one trap: a changed shared setting only reaches a copy the next time that copy deploys, so a new required setting is itself a small fleet update.

C Who owns what data

Moving a customer into their own database means knowing exactly which records are theirs. Most records already say so. Some do not.

Files, queued jobs, cached results, saved templates. Any of those can be sitting under a name that looks global but really belongs to one customer.

Fix: do this as a written audit before any migration, not during one. Three lists: definitely theirs, definitely shared, and nobody is sure. The third list is the one that wrecks the timeline.

D The investors' app server

One server sits outside every copy and reads them all, because an investor's list of companies crosses copies. Today it opens one connection to one shared database. In a fleet, that stops working.

It needs the same customer list as everything else: look up which copy a company lives in, then open a read-only connection to that copy. Keep the busy connections warm and drop the idle ones.

Fix: one read-only key per copy, stored with the other secrets, and no write keys at all. Anything the app saves goes through the copy's own API. If a contract ever bans even read-only keys, switch to publishing: each copy pushes its investor pages onto one shared shelf, and the server reads only the shelf.

One reader, many copies, and it can only read

The server's keys open each copy for reading and nothing more. Saving anything means going through the copy's own front door, so every copy stays in charge of its own data. This is the one deliberate exception to "copies share nothing", and it is written down as one.

05 · Where the research argued

Five systems, one question, three real disagreements

When everyone reads the same manuals, agreement is cheap. The disagreements are the part worth paying attention to.

Two of them had old numbers

Two systems said Vercel allows 60 projects per code repository and 12 builds at once. They were quoting a real page from February 2026. By August it said 150 projects and up to 500 builds.10

Nothing was made up. The page simply changed, and it changed in the direction that makes this plan easier. It is a neat example of why somebody has to open the important links by hand.

Settled by rechecking the source

They disagreed on where the API should live

One said move it next to the database on the existing servers, so the traffic never crosses the public internet. Another pointed out that Fly.io actually recommends one app per customer and hands you separate secrets and networking for free.11 12

Both are right, and the tie-break is not technical. If the contract demands a private network, move it.5 If not, staying put means one command to create a copy and one to delete it. Start there and measure again after a few months.

Decided · AWS, every copy in its own network · section 10

Nobody could find the evidence everyone wanted

All five looked for teams who built private copies for customers and later regretted it. All five found nothing, and said so.

That gap is real. Taking back something a customer paid for is embarrassing to write about, and teams who do simplify tend to describe it as a redesign rather than a mistake. So every warning on this page is reasoned from how the pieces work, not from someone else's scar.

Unresolved · treat warnings as reasoning

06 · What it costs

Mostly people, not servers

Servers are the cheap part at the sizes a small team will reach. The expensive part is somebody's attention every time anything ships.

At one copy the cost is almost entirely people. Servers only overtake somewhere between three and ten

people servers

The numbers behind this chart

Upper-end monthly figures from one research system's planning model. People are priced at US$100 an hour, against 12 hours a month at one copy rising to 70 at twenty-five.
Copies	Servers	People	Total
1	US$500	US$1,200	US$1,700
3	US$1,500	US$2,000	US$3,500
10	US$5,000	US$4,000	US$9,000
25	US$12,500	US$7,000	US$19,500

This is a planning guess the author labelled as one, not a measured bill. It also assumes copies share the existing database servers, which is the assumption that would move it most.

Read the shape rather than the numbers. The first copy is nearly all people cost, which is why the second copy is nowhere near half the price of the first.

Asked what to charge, the five systems disagreed by about four times

What each one actually said

Named by letter, because the point is the spread rather than which one to believe. Where a system answered in Australian dollars or per year, we converted at A$1 to US$0.65 and divided by twelve. That sum is ours, not theirs.
System	As stated
A	US$2,000 to US$4,000 a month
B	About US$4,000 a month at one to three customers
C	A$60,000 a year minimum, A$100,000 to be worth doing
D	A$8,000 to A$12,000 a month plus setup
E	US$25,000 to US$30,000 a year on top of the normal price

Every one of these is a guess about how many hours a month the fleet eats, dressed up as a price. Nobody publishes that hours figure for any system on the market, and four of the five said so when asked. They were also pricing a simpler setup than a fully separate one, so treat the range as a floor.

One small mercy: Vercel bills its team fee per team rather than per project, so a second customer's website layer adds almost nothing.16 For comparison, one analytics company lists its enterprise tier from US$20,000 a year with private hosting charged on top.13 Two of the tools built to manage fleets like this start at US$999 and US$2,000 a month before you deploy anything at all.14 15

07 · The build and update system

Build it rather than buy it, for one dull reason

Most tools sold for this assume everything you run is a container managed by Kubernetes. Here a copy is plain AWS pieces: a network, machines, a database, files and web addresses, stamped and updated together. And Amazon's own product for this exact job is shutting down, which says how thin this market is (section 10).

Four of the five research systems landed on the same answer without conferring: use Pulumi's programming interface, with one separate setup per customer.17 It already runs here, it can preview, update, refresh and delete each customer on its own, and it can check whether anything has been changed by hand behind its back.18 A copy that fails stays failed on its own instead of taking the others with it.

The alternatives fail on checkable grounds rather than taste. Terraform's own documentation warns its workspaces are the wrong tool when each deployment needs separate credentials, which is exactly what per-customer means.19 The Kubernetes-native option does real staged rollouts but only speaks Kubernetes.20 And the commercial platforms aimed at this mostly solve a harder problem: installing into the customer's own cloud account, with cluster sizes to match.21

One rule: deleting a customer is never one button. Two of the research systems flagged it as a top failure, and one platform's own docs admit that deleting a cluster can leave stray resources behind.22 Stop the traffic, check the export, and only destroy data after a person has decided.

08 · The legal bit

In Australia the law does not require any of this

Buyers often say a private copy is required by regulation. Usually it is not. It is something their buying team wants, which is a perfectly good reason, but a different one.

What the rules actually say, and whether a private copy changes the answer

Rule	What it really asks for	Does a private copy satisfy it?
Privacy, sending data overseas	Take reasonable care with anyone overseas who handles the data. There is no rule saying it must stay in Australia25	No Contracts, encryption and picking an Australian region already do it
Serious invasion of privacy	A court case is possible for deliberate or reckless serious breaches. Carelessness is not enough26	Partly It raises the stakes of a leak between customers, which is the best real argument for separate databases
Banking and insurance rules	Tell the regulator before relying on an important overseas supplier. It binds the customer, not you27	No But expect audit rights, incident deadlines and an exit plan in the contract
Stock exchange disclosure	Market-moving news must not leak before it is announced28	The real case Unannounced drafts sitting in a shared database is where the concern is genuine rather than reflex
Government work	A formal assessment against a government security manual29	Different product This is the run-it-in-their-cloud conversation, with a matching price

A reading of published regulator and exchange material for planning purposes. Not legal advice.

Worth checking: "keep it in Australia" covers more than the database. Backups, logs, build files, sign-in records, outgoing email and anything sent to an AI model all count, and Vercel's own compliance page says platform data is copied around the world for resilience.30 Also confirm where the code actually runs, because the default region may not be the one you assume.31 A separate copy fixes none of that. A map of where data goes does.

09 · The rules to hold

One copy is a deployment. Two identical copies are a fleet. Two different copies are a mess

The danger is not the first private customer. It is the first contract clause that lets the second one be built differently from the first. After that, every update has to be thought about twice.

These are the clauses to refuse, and they are commercial rather than technical:

A customer choosing when to take a security fix, with no deadline
Code written for one customer only
Settings or templates edited by hand on one copy
Anything set up by hand that cannot be rebuilt from the standard recipe
A separate phone app build as part of the normal package
What to sell instead: a fixed update window, agreed in advance, with emergency fixes exempt. ClickHouse does something similar, supporting only the current release with a short grace period34

Accept the first five and the update system stops being an internal tool and becomes a service business. That is a different company, and it is worth deciding whether you want to be it before the first contract rather than after the third.

The installer is part of the product too. One vendor shipped two releases in January 2026 that broke customer upgrades through a packaging change, then fixed it by pinning the older version.35 Another warns that a clustered upgrade has to be cut to a single machine, because two machines changing the same data at once produces wrong answers.36 Whatever runs your data changes needs the same care as the app.

10 · The platform

One landlord: everything on AWS

Everything runs under one landlord: Amazon's cloud, AWS, where the database already lives. Every copy sits inside its own fenced network, and one recipe stamps them all.

Two reasons. Fences: AWS lets each copy live in its own private network, called a VPC, with no road between one fence and the next. Separation stops being a promise in a contract and becomes a fact about the wiring. And fewer doors: when the app, the database and the files all live in one place, there are fewer gaps between landlords to guard. That reach now covers the side services too. Sign-in, email, the monitoring screens and the long-term archive all run on AWS as well, so there are fewer outside accounts to secure, pay for and hold keys to.

The same map, on AWS: one signpost, fenced copies, one factory

The customer list moves to AWS DynamoDB, a small database that lives outside every fence, so it still answers when a copy is down. The front desk, sign-in routing, runs on AWS EKS like everything else.

The investor pages fit in without a special case. A company's investor page, free or paid, is served by whichever copy owns that company: free portals by the big shared copy, paying customers' portals by their own. The signpost, AWS Route 53, points the page's address, or the company's own domain, at the right copy. Documents and decks a company shares come from its own files, delivered fast through CloudFront with links that expire, and they never touch another company's storage.

The app has more doors than a login page, and each one has a place on this map. The whole websites the app can build for a company are served from that company's own copy, just like its investor page. The little charts a company embeds on its own site ask the shared front desk which copy to fetch from, then read only that one. A reply to a company's email address comes in through AWS SES and is walked to the copy that owns it. A calendar connection's answer from Google or Microsoft lands at the front desk carrying a sealed note that says which copy it belongs to. The desktop app on a staff member's Mac knocks on the same front desk as the browser. And the heavy jobs, building a deck, a spreadsheet or a page, turning a recording into text, run as short-lived workers inside the owning copy's fence, then vanish. Nothing on this list gets to skip the fences.

The update system is mostly assembled, not written, for a checkable reason. Amazon had one product aimed at exactly this job, AWS Proton, and it is being shut down: closed to new customers since October 2025, gone by October 2026.37 So the factory is Pulumi as the recipe, Argo CD to walk each sealed update through the copies in waves, and a small staff console to watch it all.

One decision is deliberately not final. The databases stay real MongoDB, run on AWS machines the team already knows how to run. Amazon's ready-made lookalike, DocumentDB, grew much closer to the real thing in its latest version.38 It only gets used if the whole test suite passes against it first. The sign-in service is on the same kind of trial. It moves from Auth0 to Amazon's own, called Cognito, because the move can be gentle: each person walks across on their next sign-in, password and all, instead of everyone being reset at once.39 The whole thing is rehearsed on a test copy first. If the rehearsal fails, staying with Auth0 is the fallback. The move itself is a slow swap, not a leap: the shared copy goes first, proves itself for weeks, and only then are private copies built from the new recipe.

11 · How this was made

Where this came from, and what it cannot tell you

What ran

One question with twelve parts, sent to five separate research systems at the same time and kept apart rather than merged. Two ran locally, three were paid services. 277 sources between them, about US$20.

What was read

All five reports, start to finish, before any of this was written. Not the summaries. A merged summary shows what the reports did not have in common, which is a different thing from what they found.

What was checked

Every link in the two most important reports was opened. 35 of 37 and 47 of 50 worked; the failures were one paywalled article, one government file that timed out and two broken addresses. Nothing was invented. Two Vercel limits the reports disagreed on were looked up by hand.

Who is responsible

Luke Rhodes set the question, chose the framing and reviewed the page. The research, writing and build were done by Claude Code under that direction.

The question changed after the research ran

This matters for how you read everything above. The research was asked whether to offer private copies at all, and which cheaper halfway option would do. It recommended against fully separate copies, on cost grounds. That decision has since been made the other way, for commercial reasons.

The mechanics still hold, because how you run a fleet does not depend on why you have one. Two things shift: the cost figures price the cheaper version and should be read as a floor, and a separate website project moves from unnecessary to required. The original recommendation is kept on the page rather than quietly dropped, because a write-up that only contains arguments for its own conclusion is not worth much.

One part arrived after the research too: the investors' app server that reads every copy, in section 04. The panel was never asked about it, so that design is reasoning from how the pieces work, not evidence from the reports. The same goes for section 10: the decision to move everything to AWS came after the research ran, so its time-sensitive facts, Proton's shutdown, DocumentDB's new version and Cognito's walk-across sign-in migration, were looked up at the source rather than taken from the panel.

What this page cannot tell you

How many hours a month a fleet actually costs. Asked for directly. Nobody publishes it, vendor or otherwise. So every people-cost number here is an assumption.
Whether shared setups pass big-company security reviews. Those results are confidential in every case, in both directions.
Any first-hand account of a team who tried this and went back. Searched for by all five, found by none.
Customers who have their own customers. Every system answered for one company per copy. An agency running several clients from one copy was never in the question.
Real prices for the enterprise options. Sales-call only, which is exactly the cliff that could change the cost model completely.

About the page itself

One animated section, in part 02, because ten separate update timelines are genuinely hard to hold in your head and the picture does that work. Every step of it also exists as plain text underneath, so skipping ahead never loses anything. No 3D, because nothing here is about shape or space. One file, no web fonts, nothing loaded from anywhere else except the animation library.

Sources

Every figure on this page opens

Numbered by first appearance. All accessed 10 August 2026.

Silo, pool and bridge modelsAWS Well-Architected SaaS Lens · defines the three tenancy models and the deliberate mix · vendor architecture guidance
The bridge modelAWS, SaaS Tenant Isolation Strategies · establishes that isolation is a per-resource decision and pooled-with-siloed-data is a normal pattern · vendor whitepaper
Logical separation case studyAWS · a case where logical separation plus dedicated tenancy met the intent of physical isolation for many workloads · vendor whitepaper
Secure Compute is now self-serveVercel changelog, 7 January 2026 · private networks, regional placement and dedicated egress addresses, on the enterprise plan · vendor release note
Data versioning patternMongoDB manual v8.2 · schema versioning for gradual migration without downtime, the basis of expand and contract · vendor documentation
Task schedulingNestJS documentation · schedules register at application bootstrap and run in that process; the options provided are process-local · framework documentation
Managing cron jobsVercel, updated 28 January 2026 · states that jobs can overlap and events can be delivered more than once, and recommends locking plus idempotency · vendor documentation
LimitsVercel, updated 3 August 2026 · unlimited projects, 150 projects per Git repository, up to 500 concurrent deployments, 100 cron jobs per project, 1,000 environment variables per environment · vendor documentation
Why one app per userFly.io · the platform's own recommendation of app-per-customer, for per-app secrets, logging, scaling and network segmentation · vendor guidance
Machines API, apps resourceFly.io · programmatic app creation and deletion, region selection and named private networks · vendor API documentation
PricingMetabase · enterprise tier from US$20,000 a year, with single-tenant hosting charged additionally · vendor pricing
PricingOmnistrate · US$999 a month minimum for a managed control plane, before customer workload infrastructure · vendor pricing
PricingReplicated · Builders at US$2,000 a month plus per-licence fees · vendor pricing
PricingVercel · Pro at US$20 a month per team including one deploying seat, charged per team rather than per project · vendor pricing
Automation APIPulumi · programmatic stack lifecycle intended for wrapping infrastructure deployment inside a higher-level application · vendor documentation
Drift detectionPulumi · scheduled drift detection and remediation, including an explicit expect-no-changes assertion · vendor documentation
WorkspacesHashiCorp · warns that CLI workspaces are inappropriate where deployments require separate credentials and access controls · vendor documentation
ApplicationSet specificationArgo CD · rolling sync with label-selected waves and a maximum update count, stalling on an unhealthy application · open-source documentation
Bring your own cloud requirementsNorthflank · minimum 12 vCPU and 24 GB per cluster, and no full deinstallation process for the key-management variant · vendor documentation
PricingPorter · per-vCPU and per-GB platform pricing excluding cloud cost; its documentation also warns that cluster deletion can leave dangling resources · vendor pricing
Organizations overviewAuth0 · organisation-specific login and per-organisation enabled connections, with published entity limits · vendor documentation
How to clone a tenantAuth0 support, 4 November 2025 · no direct tenant transfer; export and import through the management API, with password hashes possibly needing vendor assistance · vendor support documentation
APP 8, cross-border disclosureOffice of the Australian Information Commissioner · reasonable steps and accountability for overseas recipients; no data localisation rule · regulator guidance
Statutory tort for serious invasions of privacyOffice of the Australian Information Commissioner · commenced 10 June 2025; requires intentional or reckless conduct and a serious invasion · regulator guidance
Prudential Standard CPS 230Australian Prudential Regulation Authority · operational risk management and material service provider obligations, in force 1 July 2026 · prudential standard
Guidance Note 8, continuous disclosureASX · treats market-sensitive information and cyber incidents as disclosure questions rather than prescribing infrastructure · exchange guidance
Cloud assessment and authorisationAustralian Cyber Security Centre · assessment of provider controls against the Information Security Manual, relevant to government procurement · government guidance
Security and complianceVercel, updated 21 January 2026 · states that platform data is globally replicated for resilience, with regional failover · vendor documentation
Configuring function regionsVercel · function execution region selection and the platform default · vendor documentation
AWS Proton document historyAWS · Proton closed to new customers 7 October 2025 and reaches end of support 7 October 2026; deployed infrastructure keeps running, the orchestration layer goes away · vendor documentation, fetched 11 August 2026
Amazon DocumentDB 8.0AWS · DocumentDB 8.0 supports MongoDB API 6.0 to 8.0 drivers, with in-place upgrades from 5.0 (April 2026), a serverless option (May 2026) and 46 further operators in 8.0.1 (July 2026); still API-compatible rather than MongoDB itself · vendor announcements, fetched 11 August 2026
Migrate user Lambda triggerAWS · Cognito can validate a user against an existing sign-in system on their first login and import them seamlessly, password included, so a whole user base moves one person at a time with no forced reset · vendor documentation
Internal releases for single-tenant instancesGitLab handbook · the single-tenant fleet runs behind mainline with security releases folded in, on a maintenance window rather than customer-chosen versions · vendor engineering handbook
Maintenance policyGitLab · the release and patch cadence the dedicated fleet is scheduled against · vendor policy documentation
Support services policyClickHouse, 8 June 2026 · managed products support the current release, with a limited grace period for designated customers · vendor support policy
Embedded Cluster release notesReplicated · versions 2.13.1 and 2.13.2 broke upgrades through a Helm server-side apply change; 2.13.3 pinned the previous major version to restore compatibility · vendor release notes
UpgradingMetabase · clustered upgrades must be reduced to one node because a single client takes the migration lock, and running old and new nodes against a changing schema can produce incorrect behaviour · vendor documentation

Building one copy is easy.
Running ten is the hard part.

In short

Build order