> ## Documentation Index > Fetch the complete documentation index at: https://docs.crewship.ai/llms.txt > Use this file to discover all available pages before exploring further. # Operate Pages applications > Install, verify, back up and upgrade the offline Pages runtime. Pages applications are optional. Ordinary panel Pages do not need a build image or application runtime. The supported application browser is desktop Chrome or Edge; other browsers can use the Page panels. ## Install the matching compiler Use the server release's `tools/pages-build` directory: ```bash theme={null} docker build -t crewship-pages-build:local tools/pages-build docker image inspect crewship-pages-build:local --format '{{.Id}}' ``` Configure the reported immutable `sha256:…` ID, not a mutable tag. The compiler never pulls an image or installs project dependencies during a Page build. New builds verify that the image's SDK/compiler/dependency fingerprint matches the server. A mismatch is an installation error with an instruction to rebuild the image. The Go service needs `git` in PATH, access to Docker, and a protected absolute `CREWSHIP_PAGE_PROJECTS_PATH` outside agent/crew mounts. The service account must own the directory; source files must not be served as a public filesystem tree. The build container uses UID 1001 and receives no crew mounts or credentials. ## Configure the browser-facing origins Example configuration for an existing Go service: ```bash theme={null} CREWSHIP_PAGE_PROJECTS_PATH=/var/lib/crewship/page-projects CREWSHIP_PAGE_BUILD_IMAGE=sha256:REPLACE_WITH_LOCALLY_INSTALLED_IMAGE_ID CREWSHIP_PAGE_STUDIO_ORIGIN=https://studio.example.com CREWSHIP_PAGE_RUNTIME_ORIGIN=https://apps.example.net ``` Replace the example origins with domains you control. They must have different registrable site names: `studio.example.com` and `apps.example.com` are insufficient. Both origins need DNS and certificates trusted by the viewer's browser. Internal DNS/CA are acceptable when clients are configured to trust and reach them. Point the runtime reverse proxy at the same Crewship Go listener, preserving its runtime Host header. Route only `/api/v1/pages/runtime/bootstrap` on that host and return 404 for other paths. Do not strip or weaken Crewship's CSP/frame headers. The Studio origin uses the existing authenticated application proxy configuration. A hosts-file entry on the server is not browser DNS. Verify from a viewer machine: ```bash theme={null} curl --fail --head https://apps.example.net/api/v1/pages/runtime/bootstrap ``` Then open a published Page in supported Chromium and verify the iframe renders, its requests are confined, and the Stop control remains usable with a broken preview. A 200 on `/pages/{slug}` alone only proves the static shell is served. `CREWSHIP_PAGE_RUNTIME_DEVELOPMENT_SAME_ORIGIN=true` is a deliberate development exception, off by default. It must use exactly the Studio origin and shows an isolation warning. It is not a production substitute for the second site. ## Verify a clean installation Start with a fresh Crewship data directory and the normal administrator setup. Using an authorized owner/crew, create a Page with an existing local producer and a declared harmless routine. Then initialize the shipped starter, pack/save it, build it and explicitly review/publish it with the CLI or Studio. Commands and expected-revision flags are documented in [Page CLI](/cli/page). Run these checks before accepting the installation: ```bash theme={null} crewship page project fsck crewship page project history crewship page project publications ``` Check the application as a separate reader. Withdraw it or revoke the reader's access and verify that cached executable content disappears. Restart the service and confirm the draft/publication/receipt identities survive. Repeat with a fresh restore target using the existing Crewship workspace backup/restore workflow; source SQL without the Page project archive is intentionally rejected as incomplete. For repository verification, `bash scripts/test-pages-apps.sh` rebuilds the tools image, runs real Docker/API/MCP/seed checks and exercises the Go bootstrap in Chromium. It fails when required tests are skipped. It does not replace a real chat-agent authoring test or your deployment's DNS/TLS verification. ## Storage and recovery Storage quotas apply across a workspace. Retention keeps required draft, live and running-build roots plus bounded optional history; optional history can be reclaimed before saves/builds when storage is under pressure. Older Git ancestry is truncated at retained checkpoint boundaries without changing the retained commit hashes. Backups carry those boundaries and complete retained source trees. Administrators can reclaim eligible storage without removing active roots: ```bash theme={null} crewship page project compact ``` If optional history must be discarded immediately across this workspace: ```bash theme={null} crewship page project compact --discard-history --yes ``` The second command intentionally removes optional restoration history. Back up first if it must be retained externally. It preserves current drafts, live pointer receipts and running builds. If those active roots themselves fill the quota, reduce unneeded active Pages/content; repeating compaction cannot remove active data. Do not manually delete Git objects, source snapshots, artifacts or SQL pointers. `crewship page project fsck ` compares referenced source/artifact digests and checkpoint definitions with SQL. It prints diagnostics and exits nonzero on failed integrity checks; it does not silently repair data. Restore a verified backup or investigate the named root. Temporary build persistence failure is reported as `interrupted`; compiler diagnostics remain `failed` with their original error. ## Upgrade and rollback Before upgrade, take a complete workspace backup and preserve the current server binary/version and tools-image digest. Install the new server and its matching pinned compiler image as one release. Existing published artifacts continue to run; upgrade does not automatically rebuild or republish customer applications. Use an unpublished draft for a rebuild with the new profile. Compare the preview, SDK interactions and action declarations, then explicitly publish. If compilation fails, the previous publication stays live. Image fingerprint mismatch requires a matching image; do not disable the check or change the lockfile to work around it. V1 profile/SDK maintenance must keep existing source contracts compatible; a breaking change requires a new explicit profile and migration instructions. A portable source file does not promise byte-identical output on a different release. Keep old images for rollback, subject to your installation's security update policy. Publishing a Page freezes its UI and declared action binding, not a routine's code. The confirmation dialog and receipt expose definition drift. The routine runner continues to use the routine's current definition and scripts, so sensitive operation approval must also follow that routine's own governance.