Skip to content
Guides

Operate a Mirket installation

Understand the organization-isolated runtime, configuration boundary, health checks, and recovery expectations.

For
Operator
Reading time
11 min
Updated
September 10, 2026
Organization analytics, rebuilt daily from recorded course events, with small courses hidden to protect student privacy.

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.
  • Every optional module has a matching Compose profile and application flag, and every disabled module stays absent from its role workflow.

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 your organization’s accepted recovery window and runbook.
  • When one optional service fails, preserve the base LMS and diagnose that service’s readiness, credentials, origin, and logs before restarting it. Never copy access tokens, request headers, email addresses, or child facts into diagnostics.

Know the deployment boundary

  • One installation serves one organization.
  • Application processes, PostgreSQL, Redis, and object-storage namespaces are isolated between organizations.
  • Customer configuration is mounted at runtime rather than baked into immutable application artifacts.

Respond to an operational report

  1. 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.

  2. Identify the affected service and window

    Collect the application, role, route, timestamp, visible recovery state, and relevant service logs without requesting unnecessary user content.

  3. 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.

  4. 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.

  5. 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.

Choose optional modules explicitly

Each optional module needs both its persisted Compose profile and its matching application flag. Run config --quiet before startup; a mismatch must stop the installation before migrations or optional initialization.

  • Parent access uses the parents profile with PARENT_MODULE_ENABLED=true. The administrator must still choose Enable Parent portal; restoring operator availability never re-enables that organization setting.
  • Chat uses the chat profile with CHAT_ENABLED=true. A Matrix outage must leave LMS sign-in and non-chat work available while Chat shows recovery feedback.
  • Document editing uses the documents profile with ONLYOFFICE_ENABLED=true. An outage must preserve protected course files and their original download while the workspace offers Try again.
  • Live conferences use the live profile with LIVEKIT_ENABLED=true. Admission or service failure must block conference access without weakening current account, role, course, or Session checks.

Continue with