Railbase
Browse documentation
GPTClaude

OPERATING RAILBASE

Migrate to company Vaults

Move an existing installation to separate company storage with a verified recovery boundary.

Updated

One runtime now uses a System Vault for shared identity and authority, with a separate encrypted Vault for each company. New installations create this layout. Existing installations need an explicit offline transfer with an accepted core release that supports company storage.

Transfer an existing installation

Preserve a consistent original Vault, external files, configuration and unlock material. Stop the runtime and use the same service identity and configuration:

railbase operator storage migrate-companies

Record the generation UUID. If interrupted, resume with that UUID:

railbase operator storage migrate-companies --generation <UUID>

The command verifies the source, document ownership, declared indexes, counters and external file references. Missing parents, unknown ownership and ambiguous counters stop the transfer. HTTP, background jobs and federation do not start. Original files remain intact. Only a verified generation is published through vault-layout.json; a broken pointer never silently falls back to stale data.

For older releases, the first startup converts the former schema catalogue and operator identities to the current schema catalogue and canonical users. It updates identity references across company Vaults before removing old identities, revokes old sessions and grants no additional company membership. Retired process history remains in closed archives that working APIs cannot access. Former approval matrices and their child records follow their company's Vault; installation history stays in System. The former schema editor and separate administrator sign-in stay retired.

Some old schema catalogues contain installation records with an explicitly empty company, such as initial reference data and installation events. These remain unchanged in a closed System archive, recorded in the migration report and inaccessible to working APIs. They are never assigned to a company by guesswork. An absent, malformed or conflicting owner still stops the transfer. Current schema catalogues continue to require strict company ownership.

Verify and recover

Start the accepted runtime and exercise sign-in, company membership, saved and reopened work, attachments, background work and company isolation. Take a full native backup and test restoration independently before removing any original:

railbase operator backup --out /protected-backups/installation.vault
railbase operator backup --restore /protected-backups/installation.vault
railbase operator storage compact --check-only

These commands require the service to be stopped. A complete encrypted bundle contains System, all physical company Vaults, local assets and identity material. Keep external unlock material separately. System alone is not a complete backup. On-premise scheduled backup remains disabled until enabled by the operator.

The retained original represents the moment of migration. It contains no later writes. Replacing the executable with an old version and reopening that original would lose visibility of later work; use a verified new recovery point instead. See Backups and restore for the recovery procedure.

Was this page helpful?Thanks for your feedback!