Configurable
Trust · Deployment
Choose where your roster runs.
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.
Three deployment options
Compare hosting and operating responsibilities.
| 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. | Determined by your infrastructure configuration. | 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, under the self-hosted arrangement. 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
Separate tenant databases and identity realms.
Each customer organisation has a separate identity realm and database. A separate registry holds tenant connection settings. Requests are routed to the tenant using the login token. Review tenant routing, access controls and isolation tests as part of deployment acceptance.
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.
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
Review the release and update process.
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
Plan for recovery.
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.
Disconnected and air-gapped environments
Assess a disconnected environment.
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.
A fully air-gapped production deployment has not been established. If you require disconnected operation, include registry mirroring, update delivery and external-service dependencies in a dedicated technical assessment.
Service commitments
Agree capacity and service commitments.
Read next
Related security and deployment information
Technical detail
Security
Authentication, the internal call gate, and encryption of stored documents.
Technical detail
Data protection
What personal data is held, the audit trail, and how residency follows the shape above.
For your team
The IT security desk
Technical evaluation questions covering deployment, access and data protection.
Choose a deployment model to evaluate.
Outline your infrastructure, capacity and service requirements in a 20-minute discovery call. We’ll identify the deployment option and technical questions to assess in a follow-up evaluation.