Operate a Mirket installation
Understand the facility-isolated runtime, configuration boundary, health checks, and recovery expectations.
- For
- Operator
- Reading time
- 11 min
- Updated
- August 16, 2026
Before you start
- Shell access to the installation host, the checked-out immutable release, and the installation environment file.
- Access to service logs, the backup destination, and a protected backup passphrase file.
You are done when
- docker compose --env-file .env -f compose.yml ps reports the expected services running and health-enabled services healthy.
- API and Socket /health/live and /health/ready checks respond successfully.
- The most recent encrypted backup has passed the repository restore drill.
If something goes wrong
- Do not overwrite a failed deployment or backup. Preserve logs, the exact release digest, environment path, and command output.
- Restore only from a verified encrypted archive and follow the accepted facility recovery window and runbook.
Know the deployment boundary
- One installation serves one educational facility.
- Application processes, PostgreSQL, Redis, and object-storage namespaces are isolated between facilities.
- Customer configuration is mounted at runtime rather than baked into immutable application artifacts.
Respond to an operational report
Validate configuration before changing state
Run docker compose --env-file .env -f compose.yml config --quiet, then inspect docker compose --env-file .env -f compose.yml ps and the API and Socket live and ready health endpoints.
Identify the affected service and window
Collect the application, role, route, timestamp, visible recovery state, and relevant service logs without requesting unnecessary user content.
Use repository-owned backup commands
Run pnpm ops:check, then create the coordinated encrypted backup with pnpm ops:backup and explicit absolute environment, output, and passphrase-file paths.
Prove recoverability
Run pnpm ops:restore-drill against the produced archive with the same explicit passphrase and environment inputs. Completion requires verified checksums and successful disposable PostgreSQL restores.
Recover with reversible actions
Prefer documented service restart, retry, and verified restore procedures. Preserve evidence and take a verified backup before upgrades or schema intervention.