From a demonstration vault to a production one
This is a reinstall, not a setting. A demonstration installation becomes a production one by keeping the box and dropping the vault: the demonstration marker and its waiver come out of the environment file, the engagement key and every credential are rotated, and the deployment is reinstalled onto an empty vault. Every document, compartment and account the demonstration held is destroyed, and none of it is reversible.
Read what the demonstration deliberately weakens if you want the list of what you are leaving behind, and the startup sequence for the ordinary install this ends in.
What the conversion actually is
Keep the box, drop the vault. A deployment is a DEMONSTRATION installation exactly when its environment file carries the demonstration marker phrase, and a PRODUCTION installation when it does not (ADR-0042, ADR-0021) — there is no third state and no partial one. Converting means taking the marker and its waiver out of the environment file, rotating the engagement key and every credential, and reinstalling onto an empty vault. What you keep is the machine, the compose stack and the configuration you have already tuned. What you do not keep is anything the demonstration vault held. If this is a NEW machine rather than a demonstration you are converting, none of this page applies — install it normally from the startup sequence.
Why there is no in-place conversion
Flipping the marker over a populated vault would be one edit, and it is explicitly rejected (ADR-0042). The demonstration's six accounts were provisioned under waived first-login rotation, behind one shared inbox and one shared weak password that anybody in the room may have seen. A vault cannot retroactively acquire a security history it never had: keeping those accounts and their documents while calling the deployment production would put a demonstration-grade credential story under a production nameplate, and every later question about who could have read what would be answered from a provenance nobody can reconstruct. So the supported path destroys the vault instead, which is the honest version of the same act. Read this page to the end before you begin: there is no undo.
Step 1 — decide what leaves with the demonstration
Everything in the vault. The demonstration corpus, the two compartments, the six shared-password accounts, every document an audience uploaded while you were presenting, and the weakened settings themselves: all of it is an artifact of a posture the new installation never had, and none of it crosses over. Copy anything you actually need out through the ordinary interface first, signed in as an account allowed to read it, because after step 5 there is nothing to copy from.
Step 2 — decide whether the demonstration's audit trail is worth keeping
It does not survive step 5, and that is deliberate (ADR-0042): the command removes the deployment's DATA VOLUMES, and the separate audit instance's volume is one of them — it says so in as many words before it asks you to confirm. This is not the same rule as `demo_setup`'s own emptying, which genuinely never touches the trail (it lives in a physically separate database the rebuild does not connect to, ADR-0027) — that rule is about the rebuild command, not this one, and the two should not be read as one rule. The conversion's whole design is that nothing survives a teardown, and an audit trail of a vault you are about to erase is not worth a mechanism to keep: SkyKeep ships no audit-export command, and none is planned. If the demonstration's history matters to you for some other reason — a compliance record, a curiosity, whatever — copy the audit database your environment file names out with your own database tooling BEFORE you type the acknowledgment in step 5, the same ordinary precaution you would take before any other deliberate deletion. The trail the production vault keeps begins at its own first sign-in.
SKYKEEP_AUDIT_DB_HOST, SKYKEEP_AUDIT_DB_NAME # the instance to copy first, if you want it keptStep 3 — take the demonstration out of the environment file
Every command here reads the environment file SKYKEEP_ENV_FILE names, defaulting to .env — if your demonstration ran from a file of its own, that is the file to edit and the file the production deployment will come up from, and a production installation still running from a file named for a demonstration is how the next person to look misjudges what they are looking at. Clear the marker first: it is the single fact that makes an installation a demonstration one, so clearing it IS the declaration. Then clear the waiver beside it. The open-audit-view waiver is the only waiver the vault still reads (ADR-0024) — behind the marker it lets every signed-in account open the audit trail instead of administrators alone. A waiver phrase without the marker waives nothing at all, and that is exactly why it must not be left sitting there: whoever sets a marker on this deployment next would re-arm everything beside it in one edit, with no second decision. An environment file carried forward from an older demonstration may still name a sign-in waiver (SKYKEEP_DEMO_SIGN_IN_WITHOUT_CODE); delete that line too. The vault stopped reading it when the demonstration accounts began signing in on the password alone by ordinary policy (ADR-0023, superseded by ADR-0025), and a dead variable that reads like a live weakening is worth the two seconds. Clear SKYKEEP_DISPOSABLE_VERIFICATION in the same edit, and treat it as the most urgent line on this page. It is not a waiver and weakens nothing the vault does, so it is easy to read past — what it does is tell every future gate lane that this deployment may be EMPTIED (ADR-0048). Left set on a vault that is now real, a lane that names this compose project would shape and empty it and would be right to, because the deployment said so. Last, blank the demonstration's own configuration — its shared address and password, and the administrator passwords it used. Without the marker none of them does anything; a production environment file still has no reason to carry a password that has been on a slide.
SKYKEEP_DEMO_INSTALLATION=SKYKEEP_DEMO_AUDIT_VIEW_OPEN=SKYKEEP_DEMO_ADMIN_MFA_OFF=SKYKEEP_DISPOSABLE_VERIFICATION=SKYKEEP_DEMO_EMAIL=SKYKEEP_DEMO_PASSWORD=SKYKEEP_DEMO_ADMIN_BOOTSTRAP_PASSWORD=SKYKEEP_DEMO_ADMIN_PASSWORD=Step 4 — rotate the engagement key and every credential
Generate a fresh SKYKEEP_ENGKEY. An engagement key is generated per deployment and never reused across engagements, and a demonstration's key has been handled as demonstration material — copied between machines, pasted into a chat, left in a file whose name says demo. Rotating it is free at exactly this moment and at no other: no ciphertext survives step 5, so there is nothing to re-key and nothing to lose. Rotate the credentials beside it in the same edit — both database passwords, and the mail relay's account if the demonstration used one. Anything that was a demonstration secret is a secret with an unknown audience, and the point of this conversion is that the production vault inherits nothing from that audience.
python3 -c 'import secrets; print(secrets.token_hex(32))' # the new SKYKEEP_ENGKEYSKYKEEP_DB_PASSWORD, SKYKEEP_AUDIT_DB_PASSWORD # new values, never the demonstration'sSKYKEEP_SMTP_USERNAME, SKYKEEP_SMTP_PASSWORD # the production relay accountStep 5 — reinstall, and type the acknowledgment
One command, named for what it does. It prints what it is about to destroy — every document, compartment, user and session, and BOTH audit trails — and then waits for you to type wipe-all-data on its own line. Only that exact phrase proceeds: a mistype, an empty line, or a script piping nothing all refuse and leave the deployment untouched, and the phrase is deliberately neither a flag nor a setting, so that destroying a vault cannot be baked into a wrapper script's environment by accident. Then the containers and data volumes are removed and the deployment comes back up: migrations run from empty, and the front door and both dependency legs are checked before the command reports the vault up.
scripts/skykeep.sh reinstall_complete_wipes_all_dataStep 6 — pull the models again before anybody uploads
The model runtime's storage is one of the volumes step 5 removed, so the models this deployment had are gone with the vault. The startup check does NOT catch that: the dependency leg asks the runtime whether it is there, not whether it holds the models your environment file names, so a deployment with no models at all comes up reporting healthy. The first thing to fail would be an upload, which needs the embedding model — so pull them now rather than finding out with a customer's document. The command pulls exactly what this environment file asks for; it names no model of its own.
scripts/skykeep.sh pull_modelsStep 7 — the vault you get, and its first sign-in
Empty, and production-postured. No documents, no compartments, no demonstration accounts — the only account anybody can sign in as is the bootstrap administrator, reseeded with its published initial password under FORCED first-login rotation (ADR-0012), which is precisely the rule the demonstration was the documented exception to. The startup sequence's last step is the one to follow: sign in, be taken through the password change that also collects the account's email address, and let the vault refuse everything else until both are set. Then create the real people, each with their own address, from the admin console or the portal's invitation page. Nothing about the vault's ANSWERS changed in either direction across this conversion: the compartment predicates, the row-level-security backstop, both ingest scan gates and the completeness of the audit trail were never what a demonstration weakened.
The other direction does not exist
There is no production-to-demonstration path, deliberately (ADR-0042): a production vault is never weakened in place, and the demonstration installer enforces that by refusing on any deployment not already carrying the marker. If you want to demonstrate on a box that has held a production vault, tear that vault down deliberately — the same command as step 5, with the same typed acknowledgment — and then install a demonstration onto the empty deployment. And do not stand a demonstration up beside a production one instead: a customer machine hosts ONE installation, which is what keeps a demonstration's environment file, ports and model runtime from ever reaching a real vault.