Scolah / Legal

Architecture & Data Flow

Effective 16 October 2026Version 1.0Scolah, Inc.

This page describes the components of Scolah Compass Platform (“Platform”), where each runs, and every connection between them. It is the technical basis for the Data Residency statement.

1. Components

Component Runs on Operated by Role
Portal Scolah Scolah Web interface at platform.scolah.com
Platform API Scolah Scolah Holds desired state, catalog, encrypted installation secrets, usage, audit log. Reached at api.scolah.com.
Release signing key Scolah (managed secret store) Scolah Ed25519 key that signs every bundle and every revision
Bundle registry Scolah’s container registry Scolah Scolah’s container images and Helm charts
Agent Your server or cluster You run it; Scolah publishes it Connects out to the Platform, verifies and stages bundles, decrypts sealed secrets, runs deployments and backups
Operator (Kubernetes only) Your cluster You run it; Scolah publishes it Re-verifies each bundle independently, applies it into an isolated namespace, creates read-only credentials between installations
Edge Your server The agent Reverse proxy that terminates HTTPS for installations with a public domain
Installations Your server or cluster You The applications and their databases, object storage and files

2. Data Flow

Scolah Compass Platform data flowThe agent on the customer’s server makes outbound HTTPS calls to the Scolah Platform API, which returns desired state, signed bundles and sealed secrets. Application data stays inside the customer infrastructure. Optional flows go to an AI service, an email provider and a customer-designated backup store.Scolah control planeoperated by ScolahPortalplatform.scolah.comPlatform APIdesired state · catalog · usage · audit loginstallation secrets (encrypted)api.scolah.comRelease keyEd25519 signerImage registryghcr.ioAgent telemetry (optional)agent logs and metrics onlyYour infrastructureyour servers · your country · operated by youScolah agentverifies signaturesdecrypts sealed secretsoutbound onlyOperatorKubernetes onlyre-verifies each bundleapplies to namespaceInstallationsCompass and catalog applicationsDatabasesPostgres, MongoFile storageuploads, IDsApp servicesAPIs, web UIsapplication data stays hereEdge (HTTPS)only if you give an installation a public domaininbound 80/443 from your users① status · health · usage② bundles · sealed secrets③ image pulls④ agent telemetryOnly if you turn them on⑤ Scolah-managed AI (Scolah-hosted models)⑥ AI provider your own LiteLLM calls⑦ Your own mail server, if you set one⑧ Backup store you designate (encrypted)⑨ Public certificate authority (domain names only)only ⑤ and ⑩ pass through Scolah-operated systemsEvery arrow from your infrastructure startsinside it. Scolah cannot open a connection in.always onoptional, customer-enabled
# Flow Initiated by Contents Protection
① Agent → Platform API Agent Heartbeats, server capabilities, installation status and health, deployment progress, precheck results, backup metadata TLS. Every request signed with the server’s Ed25519 key.
② Platform API → Agent Agent’s request Desired state, signed bundles, sealed secrets, lifecycle and backup instructions TLS. Bundles and revisions signed with the release key. Secrets sealed to the server.
③ Server → registries Your server Container image downloads Images pinned by version or digest in a signed bundle
④ Agent → Scolah telemetry Agent The agent’s own logs and metrics TLS
⑤–⑨ See Data Residency Your applications or agent As listed there Varies by provider
⑩ Applications → Scolah, for notifications Your applications Recipients and message content. See notifications TLS
— Your users → Edge → Installations Your users Application traffic TLS with certificates from a public certificate authority or your own

3. Enrolling a Server

  1. An organisation admin creates a server in the portal and receives a single-use enrolment token. It expires after 24 hours, and the Platform stores only its hash.
  2. The agent generates two key pairs on the server: Ed25519 for signing its requests and X25519 for receiving sealed secrets. Private keys never leave the server.
  3. The agent sends the token and its two public keys. The Platform returns its release public key, which the agent pins. The operator pins the same key separately, from its own Helm values.
  4. From then on, every agent request is signed. Requests from a blocked server are refused.

4. Deploying and Changing an Installation

  1. A portal user chooses an application, version, size and server.
  2. The agent runs a read-only precheck on the server and reports the result. Changes that would fail are blocked before they start.
  3. The Platform publishes a new signed revision. The agent downloads it and the named bundle, and checks the bundle’s signature and the SHA-256 fingerprint of every file. It refuses the bundle if any file is changed, missing or extra.
  4. On Kubernetes, the operator verifies the signature and digest again before applying anything. The agent cannot persuade it to apply an unsigned bundle.
  5. The agent decrypts the sealed secrets and writes them where only the installation can read them: a 0600 file, or a Kubernetes Secret in the installation’s namespace.
  6. The agent reports progress and final health back to the Platform.

Upgrades follow the same path and take effect only after a user confirms them. If an upgrade fails, the Platform reverts the desired revision to the previous one.

5. Isolation on Kubernetes

Each installation runs in its own namespace with:

  • A default-deny ingress NetworkPolicy, allowing traffic only from inside the namespace and from the ingress controller
  • A limited set of allowed object kinds: workloads, services, config, secrets, volumes, ingress and network policies. Bundles cannot create cluster-wide roles, admission webhooks or custom resource definitions.
  • Its own credentials. A connection to another installation receives a separate read-only account, created by the operator and deleted when the connection is removed.

Outbound traffic from installations is not restricted by default, because many applications need to reach external services. You can add your own egress policy.

6. Disaster Recovery

When enabled, the agent takes encrypted backups with restic and stores them in an object store you designate. The backup data goes directly from your server to that store; the Platform receives only metadata (snapshot IDs, sizes, timings). By default, every snapshot is kept for 48 hours, then one per day for 30 days. We recommend an object store with Object Lock (write-once) enabled.

7. If the Platform Is Unavailable

Installations already running keep running. They do not depend on the Platform to serve users. While it is unavailable, you cannot deploy, upgrade or change installations, and the portal does not show their health.