Exto Console Docs

Appearance

Platform Architecture ​

The Console is a control plane. It does not run your customers' workloads — those run on instances. Instead, the Console tracks who owns what, what should be running where, and what each customer is paying for.

This page is a conceptual map. It is intentionally light on implementation detail.

The data hierarchy ​

Customer ──┬── Tenants ── Users (assigned per tenant)
           ├── Plan (with meter limits)
           ├── Invoices, Payments, Credits
           └── Settings (auth, MFA, IdP, webhooks)

Instance ──┬── Tenants (provisioned here)
           ├── Services (running pods)
           └── Environment Variables (with overrides)

Diagram

Replace the ASCII tree with a clean architecture diagram showing Customer / Tenant / Instance / Plan / Meter and their relationships. Suggest a left-to-right layered diagram.

  • Customer. The company you sell to. The unit of contracting and billing. A customer has a plan, a billing contact, and a portal.
  • Tenant. A logical environment owned by a customer. Tenants are where the customer's own users sign in to use Exto's products. A customer typically has one tenant per environment (DEV, QA, PROD).
  • Instance. A hosted environment that runs tenants — a Kubernetes cluster or hosted backend. Instances have a region, capacity (max tenants), and a fleet of services with versioned Docker images.
  • Plan. A pricing template that defines included quantities per meter and overage rates.
  • Meter. A measurable unit of usage (api_calls, storage_gb, active_users). Plans bind meters to limits and prices.

How the surfaces relate ​

The Console exposes two UIs over the same data:

  • The Admin Console is the operator view. Operators see every customer, every tenant, every instance, every release. They can suspend, delete, move, migrate, override, and so on.
  • The Customer Portal is the customer view. Customer admins see only their customer's tenants, users, billing, and changelog. They can configure their own auth policy and invite users — but they cannot see other customers' data and cannot operate the underlying infrastructure.

Both surfaces use the same backend, the same auth, and the same audit log. Every action either surface takes is recorded against the actor that performed it.

The release pipeline ​

Releases are how new code and configuration reach instances:

  1. An operator creates a release — a versioned bundle of service images and/or environment-variable changes.
  2. The release flows through a pipeline of stages. Each stage groups one or more environments (e.g. DEV → QA → PROD). Within a stage, environments may deploy in parallel.
  3. Stages may require approval from designated SPOCs and an explicit trigger before progressing.
  4. The Console pushes the release to each matching instance. The instance agent acknowledges deployment, success, or failure.

The release configuration (managed services, pipeline stages, approval rules, SLA thresholds, escalation contacts) is global to the platform and lives on the Release Configuration page.

Identity ​

Sign-in is brokered by Zitadel. The Console never sees passwords directly.

  • Each customer organisation in the Console maps to a Zitadel org.
  • Each user belongs to one home org but can be granted access to other customers as a partner / portal user.
  • Customers can configure their own identity providers (Google, Azure AD, custom OIDC) and their own password and MFA policy, all through the Customer Portal.

What lives outside this guide ​

This guide describes what the UI does. The mechanics of how the Console talks to instances, how the agent pushes deployments, how Zitadel is configured, how migration jobs are executed, and the deployment topology of the Console itself are all engineering concerns. They live in the internal documentation.