Scrydon
Architecture

Architecture

How Scrydon is laid out across your cluster — trust zones, subsystems, traffic crossings, and where to look for what.

Scrydon is a customer-deployed Kubernetes platform. This section is the architectural reference for the system you're running.

Trust zones

Three zones, with the boundary between them explicit and configurable:

ZoneOwnerWhat lives there
ScrydonScrydon (the vendor)License Server (license.scrydon.com). The single endpoint your cluster phones home to. No customer data flows here.
CustomerYou — your Kubernetes clusterThe entire Scrydon platform: ingress, auth, agentic workflows, analytics, ontology, document storage, and (optionally) a customer-owned GPU pool for self-hosted inference.
External VendorsThird parties — OpenAI, Anthropic, Microsoft, Azure OpenAI, AWS Bedrock, ElevenLabs, Microsoft Graph, …Cloud LLM / embeddings / STT / TTS / GPU APIs. Reached from the customer zone only when you opt in by installing an integration.

Slim view

The picture to put in a deck:

Traffic across zones

Only three crossings exist:

DirectionRequired / Opt-inPurpose
Customer → ScrydonRequired for licensed operation (license traffic only)Daily license validation (POST /api/license/validate, 30-day grace window).
Customer → External VendorsOpt-in per integrationCloud LLM / embeddings / STT / TTS / GPU / Microsoft Graph — resolved through the integration registry. Never hardcoded.
User → CustomerRequiredAll product traffic — chat, documents, voice. Terminates at Traefik in your cluster.

No data crosses Customer → Scrydon other than the license heartbeat. No data crosses Customer → External Vendors unless your organisation explicitly installs and selects that integration.

Subsystems

How a request flows

A typical request — "the user asks the chat agent a question that requires looking something up in a managed table" — touches a handful of subsystems in this order:

  1. Traefik terminates TLS and routes to Platform (auth + session).
  2. Platform authenticates the user, evaluates the policy registry, and forwards to Agentic.
  3. Agentic executes the workflow. The Agent block dispatches its LLM call through Cortex.
  4. Cortex picks the model — self-hosted inference, or an external cloud vendor — and returns the response.
  5. The agent calls a tool that reads a managed table. Analytics projects the typed result through the Ontology layer (if the workflow uses one), applying DLP labels and column masking on the way out.
  6. The response streams back to the user via the same path.

Every step is authorised, every cross-service call is mutually authenticated, and every sensitive operation lands in the audit log.

  • Deployment — install Scrydon on your cluster (Helm, Azure Marketplace, air-gapped Zarf).
  • Security — DLP, authorisation, secrets, audit, mTLS, ingress hardening.
  • Compliance — ISO 27001 / 42001, EU AI Act, GDPR, SOC 2, SecNumCloud, NIST, CRA, AIUC-1.
  • Platform — identity, workspaces, settings, licensing.
On this page

On this page