Trust · Deployment

Shared cloud, dedicated cloud or your own infrastructure

Standard deployments use the same application release. Shared managed hosting is included in SaaS; dedicated hosting reserves a SkyRoster cluster for your organisation. Bespoke code outside the standard supported release requires dedicated SaaS, as does requested isolation.

configured

The three shapes

What you operate, and what we operate, in each

Shape	Who operates the cluster	Shared with other customers?	Where your data sits
Shared managed cloud	We do, on Microsoft Azure in the EU.	Yes, with a separate identity realm and database for each customer.	In our infrastructure, in your own dedicated database.
Dedicated cluster	We do, on infrastructure reserved to your organisation.	No. The cluster itself is not shared with another customer.	In a reserved SkyRoster cluster; exclusive physical Azure hosts are a separate arrangement.
Your own infrastructure	Your operations team, on your own Kubernetes cluster.	Irrelevant. It is your hardware.	Entirely inside your own chosen infrastructure and jurisdiction.

For self-hosting, the documented, currently-run path uses MicroK8s, Canonical's lightweight Kubernetes distribution, on Ubuntu, with pinned-version upgrades rather than automatic ones, so your operations team controls exactly when the underlying platform changes. We ship the approved release's container images plus deployment manifests and database migration scripts that accompany every release; running them is your team's responsibility, the way it is for any software you host yourselves. On-premises patches, updates and upgrade rights require an optional support contract; without one, your perpetual licence remains valid for the version you hold.

Multi-tenancy

One identity realm and one database per tenant

Each customer organisation gets its own realm in the identity server and its own separate database. A tenant's data physically resides in its own database rather than sharing one table with everyone else behind a tenant-id column, so a query cannot cross tenant boundaries by accident, because there is no shared row it could accidentally return. A small, separate registry database holds only which tenants exist and their connection settings, never any tenant's business data. Which identity realm and which database a request belongs to is derived from the login token itself, not from a header a client could set.

A dedicated cluster is a straightforward variant of this same model, not a different architecture: the realm-per-tenant, database-per-tenant design is what makes reserving a whole cluster to one customer a configuration choice rather than a separate product to build. Dedicated SaaS includes one production environment and a modest UAT environment within agreed capacity. It runs no other SkyRoster customer's workloads; it does not promise an exclusive physical Azure host or unlimited processing capacity.

verified

When dedicated SaaS is required

Bespoke code outside the standard supported release requires dedicated hosting, including existing bespoke code. A change accepted into the standard supported release does not automatically require it; engineering confirms the release path during scoping. Requested isolation also uses dedicated hosting. Ordinary configuration, data migration, training and standard-module choices do not themselves require it. The offer states capacity, concurrency, storage, backup retention, region and the UAT allocation. Additional capacity, environments, regions, disaster recovery and specialist connectivity are separately quoted.

The initial dedicated-hosting commitment is 12 months from the agreed milestone when the environment is available for customer use. Hosting operations, monitoring, platform maintenance, daily backups, restore operations and standard release deployment are included, independently of optional user support. Customer-specific code maintenance and compatibility work are scoped separately. Hosting prices and commercial terms →

How a release reaches you

Built once, promoted, not rebuilt per environment

Infrastructure and application state are declared in configuration held in version control and continuously reconciled against what is actually running, so what is deployed can always be compared against what was intended. A release candidate's container images are built once; moving that candidate toward production only re-tags the same images, it does not rebuild them, so what eventually reaches a live environment is byte-identical to what was validated earlier in the pipeline. Two independent, named approvals, one confirming the release works, a separate one confirming it is the right behaviour for the business, both have to pass before a release is cut. A customer-specific build follows this promotion process within its own approved release; it is not represented as identical to every standard customer's build.

Every database schema change ships as a paired upgrade script and its own rollback script, pinned to the release that introduces it. The migration runs automatically as part of the deployment, on the shared configuration database and on every tenant's own database, rather than as a manual step someone has to remember.

Backups and replication

What actually happens when something fails

The primary datastore runs as a multi-node replica set, with replicas placed so that no two of them ever land on the same physical node. The identity server's own database runs as a separately replicated cluster with automatic primary election: if the current primary node fails, the replication manager detects the outage, promotes a new primary, and the connection layer in front of the database routes new connections to it automatically. The former primary rejoins as a standby once it is back, without a person having to intervene for that specific handover to happen.

Backups run as scheduled jobs, per tenant, writing to storage outside the cluster itself so a cluster-level failure does not also take the backups with it. A new tenant's deployment is not signed off as complete until a backup has actually been downloaded, unzipped, and confirmed to contain real data, not just confirmed to have completed without error.

verified

Disconnected and air-gapped environments

What the architecture supports, stated carefully

The self-hosted path is built so that nothing in the core application, the database, the message queue, the cache, or the identity layer requires reaching the public internet at runtime. Container images are pulled from a registry that can be mirrored into a fully disconnected one.

That is a description of the architecture, not a claim about a completed deployment. We are not reporting that a fully air-gapped environment has been run in production; we are describing what the design supports. If your environment requires this, say so early: it changes registry mirroring and how updates reach you, and it is worth a specific conversation rather than a line on this page.

Service commitments

The standard SaaS commitment and other deployment arrangements

The rest of the trust section

Mechanism

Bring us a month that went wrong.

Start with a 20-minute discovery call to discuss your operation and priorities. We can then arrange a tailored working session with your roster and rules.

Book a discovery call

Booking opens a 20-minute discovery call. A tailored working session is arranged afterwards.

Send a question instead