Skip to content
Self-Hosting

Self-hosting Classroom Token Hub

This page is an orientation document for an operator running a private v2 instance. It is not a substitute for the normative deployment and security documents linked below.

Before you deploy

Runtime boundaries

Classroom state is class-scoped and must be accessed through the canonical context pipeline. Do not bypass the application with ad-hoc writes to ledger, obligation, entitlement, or policy tables. State-changing behavior belongs to the owning FEAT and must carry its required idempotency and audit evidence.

The application is not an offline data store. The service worker deliberately keeps authenticated routes network-only so one class’s live data cannot be served to another class from a stale cache.

Configuration and secrets

Set environment variable names from the deployment and security specifications for the target environment. Never copy secret values into the repository, documentation, logs, screenshots, or issue reports. Keep lookup peppers, encryption keys, session secrets, audit keys, and database credentials in separate secret lifecycles as specified by the security contracts.

Operational evidence

A successful setup command is not deployment or launch certification. Record, at minimum, the deployed revision, migration result, health checks, integration configuration checks, backup/restore evidence, and the controlled browser test result. Use the public status service and the application’s bounded health routes according to the production runbook.

Recovery and rollback

Follow the runbook for rollback and database recovery. Do not infer database safety from a database name, and do not delete or reset a target until its exact host, service relationship, revision, owner, and backup state have been verified.

Edit canonical source on GitHub

Last updated: 2026-09-17