The operating model: one accountable operator, and a boundary in writing
Before a regulated organization evaluates a platform, it counts. How many contracts, how many SLAs, how many parties on the call at 03:00 when it is not yet clear whether the fault is in the database, the cluster or the hypervisor. A stack assembled from four suppliers loses to a simpler one under a single operator, and that comparison is usually settled before anyone opens the architecture diagram.
So this page gives you the count, and then the boundary that makes the count real.
One contract, and it covers the infrastructure
One contract covers the services you pick from the Application Catalog, the platform they run on, and the compute, storage and network underneath. One SLA, up to 99.99%, under Swiss law. One invoice.
The infrastructure is part of it because VSHN procures it. Cloudscale, Exoscale or another provider you approve supplies the capacity on VSHN's contract, and you never negotiate, monitor or chase a second supplier for it.
If you would rather keep your own cloud subscription, keep it. Plenty of enterprises have committed spend, an existing agreement or an internal rule that says the tenant is theirs. VSHN then operates inside your subscription and the provider invoices you for the capacity. Nothing else about the arrangement changes: same services, same SLA, same on-call engineers. It is a choice about procurement, not about who is accountable for operations.
One escalation path
You open one ticket, with VSHN, in any language you already use with us. Around the clock, staffed from Switzerland.
Under the default arrangement, the provider relationship is ours, so the provider ticket is ours to open and drive, and you get one thread rather than three. This matters most in the case you are actually buying insurance against: an incident where the layer at fault is not yet known. Nobody asks you to diagnose it first in order to find out whom to call.
The boundary, in writing
An operating model that only says "we take care of it" turns every incident into an argument about scope. Here is the split, and it goes into the service description rather than being settled while something is down.
| VSHN operates | You keep |
|---|---|
| The Kubernetes or OpenShift platform: control plane, cluster components, upgrades | Your application code and the container images you build |
| The catalog services on it: databases, identity, secrets, messaging | Your schemas, your realms, your policies, your data |
| Patching, version upgrades and change management for everything in the two rows above | The decision on when your own release goes out |
| Backups, restore tests and the evidence that they ran | Your retention and classification requirements |
| Monitoring, alerting and 24/7 on-call for the platform and the services | Alerting on your own application's business logic, unless you buy that too |
| Capacity planning, and the provider relationship when VSHN procures the infrastructure | Approving the provider and the region |
The rule behind the table is authority, not technology. A platform change that breaks something is ours to fix, so we apply it without asking. Only your test suite knows whether your product survives a bumped dependency inside your own image, so that stays yours.
Where the boundary is
The claim on this page is about the application platform, and it stops where our authority does.
VSHN owns no datacenter. Buildings, power, cages and the physical network are a provider's business, and on a scope that includes them there is a party in the chain who is not us. VSHN does not operate Windows or MS SQL estates. The WAN between your sites is not ours either.
Where a scope covers those things, the honest shape is a general contractor who holds them with VSHN named for the platform, and we will say so rather than adding a fourth logo to a bid that already has three. A buyer counting interfaces is right to count ours.
What this means for a tender
If your target operating model asks for continuous operational responsibility with as few interfaces as possible, that phrase describes what this page is: one accountable operator from the infrastructure interface upward, with the split documented rather than discovered.
What it does not describe is a general contractor for an entire IT estate. Asking one supplier to carry a datacenter, a Windows estate, a network and an application platform produces either a consortium, which is the interface problem again, or a prime who subcontracts most of it, which is the same problem with a nicer cover page. The version worth buying is a small number of parties who each hold something whole. For the application platform, that is us.
Related reading: sovereignty covers jurisdiction, ownership and the CLOUD Act; compliance covers the evidence an auditor asks for, including ISO 27001 and the ISAE 3402 Type II report.