Rackspace schemas

Concourse keeps a snapshot of each supported Rackspace MySQL database schema in the repository. An operator generates a snapshot on a laptop through the approved VPN, then commits it through a normal pull request. A Vercel deployment reads the merged snapshots. It never runs Drizzle Kit and never creates, reviews, or publishes a schema file.

Preview provides one audited connection check against mi_property_value_qa. Production provides an app-local verification report for each request. The browser asks for one merged registry entry at a time, in order, and the application saves each result before the next request. Both environments use the same reviewed Rackspace account and unencrypted transport in iad1.

Rackspace Production through VPN
  -> local generation
  -> generated files and receipt
  -> pull request, Git review, and CI
  -> exact Preview deployment and connection check
  -> merge
  -> Production deployment
  -> full-registry deployed verification

Use the operations page to generate or verify a schema. Read the security page before you enable Rackspace access. The operations page also lists the acceptance checks for a registry change.

Public interfaces

@concourse/rsdb lists its public entry points in its package manifest.

Contracts. @concourse/contracts/rackspace supplies browser-safe result schemas and types. RSDB and application code share them, and they load no database client.

Local generation. @concourse/rsdb/local-generation is a Node-only development interface. It owns the complete snapshot transaction: terminal input, the protected local configuration, MySQL discovery, Drizzle generation, TypeScript compilation, content scans, zero-row checks, receipts, registry updates, and in-process worktree rollback. The command accepts generate --config <absolute-path> and verify. It does not read application environment variables. It does not call Vercel, Turso, or GitHub. It reads the Git worktree status to reject overlapping edits, but it performs no Git mutation.

Runtime. @concourse/rsdb/runtime supplies deployed server operations. Deployed code must not import the local-generation entry point. It contains the RackspaceDatabaseConfig that database bindings read. Its environment field selects production or qa. In qa, a binding opens the _qa copy of an mi_ database and the Production copy of every other database. The glossary explains the QA copies. It also contains the connection inspection helper that Preview uses for its fixed QA target, and the registered-schema verifier that Production uses. The verifier rejects an unknown or differently cased database name before it opens a connection. It owns runtime creation and pool cleanup. If cleanup fails, a safe connection_close_failed failure replaces the tentative result.

The runtime import graph must not reach local generation, Drizzle Kit, TypeScript, Babel, Clack, filesystem mutation, or terminal and process control code. Import-boundary tests enforce this rule.

Database bindings. @concourse/rsdb/mi-property-value binds the registered mi_property_value database for typed reads and transactions. @concourse/rsdb/tredis-global-dynamic supplies the corresponding binding for tredis_global_dynamic. The RSDB guide owns its behavior and limits. ADR 0011 records why it exists.

The application has no generation, inventory, artifact, review, cleanup, publication, or gate interface. apps/concourse/lib/rackspace/ orchestrates a verification report, its audit events, and the admin page. The Application context records why the package stays independent of application persistence and framework code.

Source and registry

Production is the only source for a committed snapshot. One generation command selects one or more visible non-system databases. A missing registry name is added. An existing name is replaced in full. No command removes or renames another entry.

The registry is generated in binary database-name order. packages/rsdb/lib/runtime/registry.generated.ts is the source of truth for the list. Each database lives below packages/rsdb/generated/<database>/. That directory contains the complete generated schema, the complete DDL, and receipt.json.

The receipt manifest covers every file in the database directory except the receipt. It records safe hashes, counts, tool versions, and the time at which the generated content last changed. It does not record connection values, grants, local paths, object names as separate evidence, or deployment values.

Trust

The committed generation receipt proves that the committed bytes are consistent with each other. It is not signed and does not prove who ran the command. Git authorship, branch protection, CI, a complete diff review, and human pull request approval provide provenance.

The Concourse application database stores one row per verification report, its immutable registry snapshot, the ordered results prefix, and generic audit events. A report is failed as soon as a saved result fails, passed when every registry result passes, and incomplete only while no saved result has failed and the registry is not exhausted. A failed result stops the run. Reloading the page shows the saved prefix; starting again creates a fresh report from the first registry entry. The operations page explains the request sequence, concurrent duplicate behavior, and its one-minute platform limit.