Architecture

The whole platform — control plane included — inside your boundary.

sCloud is not a console in someone else's cloud managing servers in yours. Every layer, from identity to the update service, runs on hardware you own.

Reference architecture

Five layers, one boundary.

People and pipelines reach a control plane that you host. Identity and policy decide what happens; services run on your hardware.

  1. 01

    People and automation

    Operators, project teams and your pipelines. People authenticate with sAxess PRO Cards or FIDO2; automation uses scoped API credentials that are themselves governed by policy.

  2. 02

    Control plane

    The console, the public API and the update service. It runs on your servers, inside your network — never in a Serenity cloud — and keeps working with no internet connection.

  3. 03

    Identity & policy

    sCloud Identity (SSO), role-based access per organisation and project, quotas, the critical-action approval engine, the keys-and-secrets store and the audit log.

  4. 04

    Services

    Virtual machines, managed Kubernetes, application hosting, managed databases and S3-compatible object storage. Each project gets its own private networks.

  5. 05

    Your hardware

    Compute, storage and network on servers you already own or buy. sCloud pools them; you keep physical custody.

How requests move

Three flows every security review asks about.

Sign-in, critical actions and updates — each one stays inside your environment.

Signing in

  1. 1A user opens the console, CLI or one of your apps.
  2. 2sCloud Identity asks for a sAxess PRO Card or a FIDO2 authenticator — no password.
  3. 3The card verifies the fingerprint and signs a one-time challenge.
  4. 4sCloud Identity issues a short-lived session scoped to that user's roles.

Authorising a critical action

  1. 1A request — from any interface — matches an approval policy and is held.
  2. 2Each required approver reviews the exact action and signs it on their card.
  3. 3Once the policy is satisfied (for example 2 of 3), the action runs.
  4. 4The action and every signature are written to the audit log together.

Updating the platform

  1. 1Serenity publishes a release bundle signed with its release key.
  2. 2You download it, or carry it into an air-gapped site on offline media.
  3. 3sCloud verifies the signature before anything is installed.
  4. 4A rolling upgrade proceeds server by server, under your change window.

Production readiness

What we test, and how it behaves when things fail.

The evidence technical buyers ask for. Detailed test reports and certified configurations are shared under NDA during scoping.

  • Tested cluster size

    The largest cluster we run end to end, in our lab and in customer proofs of concept.

  • VM & Kubernetes scale

    Virtual machines, Kubernetes clusters and nodes per installation, measured under sustained load.

  • High availability & failover

    Control-plane services are replicated across servers. VMs on a failed host restart on healthy ones; live migration moves them for planned maintenance.

  • Recovery objectives

    Managed databases recover to any point in time. The control plane is backed up and can be restored, including to a second site.

  • Upgrade process

    Signed, rolling upgrades: one server at a time, with workloads moved off it first — no platform-wide maintenance window.

  • Supported workloads

    Linux and Windows virtual machines, upstream Kubernetes for containers, and managed databases.

  • Supported servers

    Standard rack servers from mainstream vendors. Certified configurations are published with each release.

  • Storage & network

    Replicated software-defined storage on the servers' own disks, and isolated private networks per project on your existing switching.

  • API coverage

    The console is built on the public API. Anything you can click, you can script — through the API, CLI or Terraform.

Call salesRequest a quote