For platform and infrastructure architects
Three shapes exist here, and choosing between them is not a feature comparison. It is a decision about who patches it, who is on the rota, who holds the credentials, and how far it sits from the pattern your estate is standardised on. Each is described with the cost it lands on your team, not the cost it saves ours.
A platform standard is expensive to build and cheap to erode. Years go into getting an estate onto one pattern — one way to authenticate, one way to deploy, one way to observe, one rota — and each individual exception is defensible on the day it is granted. The cost is paid later by an engineer who joins after everybody who made the decision has moved on.
Which is why the questions an architect asks are not the ones a demonstration answers. Does it fit the pattern. Who patches it. Who is paged when it degrades at three in the morning. Does it need an inbound path. Does it need a privileged agent on a host. Can it be built from a pipeline or does it need somebody clicking through an installer.
The appliance is the shape everyone regrets. It arrives as an image, it runs a distribution nobody else in the estate runs, its updates arrive on the supplier’s cadence, the patching story is theirs, and after a while it is the one box nobody wants to touch because nobody remembers how it was configured. Every architect reading this has one.
Meanwhile the pressure to accept a shape comes from a business sponsor with a date. The architect is asked to approve an exception quickly, the trade is real, and the person asking will not be carrying the consequence. Saying no has an immediate visible cost and saying yes has a deferred invisible one, which is the same asymmetry that produced the last exception.
And the shape frequently gets chosen before anybody reads what it requires. A commitment is made to run something inside the estate, and only afterwards does it emerge that it needs an outbound path to a service nobody approved, a privileged account on a host, or a database version two behind what the estate runs.
The shape that satisfies the strictest reviewer is also the one that places the most operating burden on the platform team — and a supplier who presents them as equivalent has sold a decision the team who inherits it would have made differently.
The shared service is the default. It is operated entirely by us, your team runs nothing, patching and paging are ours, and the trade is that compute and scheduling are shared with other organisations and the region is ours to operate. For most buyers this is correct and the rest of this page is unnecessary; for a buyer whose review turns on shared compute or on a territory, it is not.
Dedicated tenancy separates the running instances rather than only the records. Your organisation’s workload runs on infrastructure not shared with another customer, still operated by us, still patched and paged by us. It removes the shared-compute objection and does not remove the question of whose estate it sits in. It costs more and it costs your team nothing.
Running inside infrastructure you already operate is the shape that satisfies the strictest reviews, and it is the one this page is most careful about. Your region, your network position, your identity provider, your logging, your backup policy, your patch cadence, your rota. Everything that made the other two easy becomes yours. That is not a footnote — for many organisations it is the whole decision, and it should be made by the people who will carry the rota rather than by a sponsor with a date.
What that shape requires from your estate is stated before anybody commits rather than discovered during installation: a container runtime you already run, a database you already operate, an outbound path to your own identity provider, and nothing else that is not yours. There is no privileged agent to place on a host. There is no inbound exception to request. It is built from your pipeline rather than installed by clicking, and it is scannable by your tooling rather than exempt from it.
What is deliberately not offered is an appliance image running a distribution of ours. That shape is the one architects regret and the one that ages worst, and refusing to sell it costs opportunities with organisations that specifically asked for one. It is refused anyway, because the box nobody wants to touch is a real cost that lands on a named engineer three years from now.
Who carries the rota — measured by a written statement per shape naming which organisation is paged at three in the morning.
What the shape requires from your estate — measured by the requirements list — runtime, database, outbound paths — read before commitment rather than during installation.
Whether an inbound path or a host agent is needed — measured by a written no, checkable against what your network actually observes during a trial.
Whether it is built or installed — measured by deploying it from your own pipeline in a trial, without anybody clicking through an installer.
Whether your scanner reaches it — measured by running your own tooling against it and receiving results rather than an exemption request.
How far it sits from your standard — measured by counting the exceptions your platform standard would have to record for it.
no appliance image running a distribution of ours is offered, and that refusal closes opportunities with organisations that asked for one. Running inside your estate places the patching, monitoring, backup and rota burden on your team and that is a real cost rather than a footnote. Dedicated tenancy separates instances and does not change whose estate they sit in. An independent SOC 2 Type II attestation is in progress and no report exists yet.
The requirements are ordinary on purpose: a container runtime and a relational database of versions your estate already runs, and an outbound path to your own identity provider. Anything beyond that is a design failure rather than a documented requirement, and the list is given before commitment rather than during installation.
There is no privileged agent to install on a host, no inbound exception to request, and no request to be excluded from your scanning or your configuration management. Those three requests are the ones architects hear most often and each is a finding on its own; not making them is a smaller claim than it sounds and it is worth stating because so few suppliers can.
Where it runs in your estate, updates arrive as artefacts your pipeline promotes rather than as a supplier-initiated change. A supplier who can change what is running inside your boundary without your change record seeing it first has an authority nobody granted, and it is the property that quietly makes an assessment stale.
An appliance image running a distribution of ours would win deals. It is the shape a certain kind of buyer asks for by name, it looks like control, and it ages into the one box nobody in the estate wants to touch — patched on a supplier’s cadence, configured by somebody who left, and running an operating system nothing else in the estate runs. It is refused, and refusing it costs opportunities.
The reason it is on this page rather than in a conversation is that an architect can then rely on it. A refusal stated publicly is one a later sales conversation cannot quietly reverse, and this page governs if anything of ours later suggests otherwise.
On the estate-hosted shape, the honest framing is that it is more work for your team than the alternatives, in patching, monitoring, backup and rota. That belongs in the decision rather than in a footnote, and for organisations whose review does not actually turn on it, the shared service is the better answer and we will say so.
Every property here is designed rather than independently attested. A SOC 2 Type II attestation is in progress and no report exists yet; it is an attestation with a scope and a period rather than a certification. We hold neither a FedRAMP authorization nor a FedRAMP certification and claim no equivalency, which architects working on federal programmes should have before they invest effort.
Read the requirements list first, because a shape chosen before anybody read it is the origin of most platform exceptions. If the list contains something your estate does not already run, that is the conversation, and it is much cheaper before a date exists.
Ask who is paged, per shape, in writing. It sounds obvious and it is the question most often answered informally and then discovered at the first degradation, when the answer becomes whoever is nearest.
Ask what happens to updates in your estate. If a supplier can change what runs inside your boundary without your change record seeing it first, your assessment goes stale silently and your configuration management has a hole it will not report.
And record honestly which shape the review actually requires. A team that chooses the estate-hosted shape because it feels safer, without a review finding that requires it, has bought a rota nobody costed.
One deployment into a sandbox in your own estate, built from your pipeline by your team, to establish what it requires and what it does not ask for.
A sandbox build answers the questions a demonstration cannot. Does it come up from your pipeline. Does your scanner reach it. Does anything ask for a privileged account or an inbound path. Does the outbound traffic match the written list. Each is observable rather than assertable.
Watch the network during it, and compare what you observe against the requirements list you were given. That comparison is the most informative hour in this whole evaluation, because a description and a behaviour are two different artefacts and only one of them is true.
Then decide the shape deliberately with the rota question answered in writing. If the review does not actually require the estate-hosted shape, the shared service is the better answer and choosing it is not a compromise.
No, and that refusal closes opportunities with buyers who ask for one by name. An appliance ages into the box nobody in the estate wants to touch — a distribution nothing else runs, updates on a supplier’s cadence, and a configuration nobody remembers because the person who made it left. Every architect reading this has one. What is offered instead is a deployment built from your own pipeline using a runtime and a database your estate already operates, which is the same control without the orphan.
Nothing privileged, and no agent. The requirements are a container runtime and a relational database of versions your estate already runs, plus an outbound path to your own identity provider. No inbound exception is requested, and there is no request to be excluded from your scanning or your configuration management. Those three asks are the ones architects hear most often and each is a finding on its own — verify it during a sandbox build by watching the network rather than by accepting this paragraph.
It depends entirely on the shape and you should get it in writing before a date exists. On the shared service and on dedicated tenancy, we are — your team runs nothing and carries no rota. Inside your own estate, your team is, along with the patching, the monitoring and the backups. That is the real cost of the shape that satisfies the strictest reviews, and it belongs in the decision rather than discovered at the first degradation when the answer becomes whoever happens to be nearest.
They often do, and it is worth checking whether the review actually requires it before your platform team inherits a rota. If the finding is about shared compute, dedicated tenancy resolves it without moving the operating burden. If it is about a territory or about a boundary your organisation has already authorized, the estate-hosted shape is the right answer and the cost is worth paying. What we will not do is let a preference be recorded as a requirement — we would rather recommend the shared service and be right than sell the expensive shape and be resented.
As artefacts your pipeline promotes on your maintenance window, visible to your change record before they take effect. A supplier able to change what runs inside your boundary without your change record seeing it first holds an authority nobody granted, and it is the mechanism that quietly makes an assessment stale — the system you assessed and the system running are no longer the same thing, and nothing reported the divergence. Test it during a trial by promoting one update and checking your own change record captured it first.