marulaDocs
Documentation menu

Operator tasks

Audience: site operator — you run the instance. You have shell access, you own the backup and the upgrade window, and you get the call when it is down.

You are not the workspace admin. Admins configure boards, email routing and people. You keep the process up, the data recoverable and the front door correct. Where the two overlap, this page says so.

"Stand it up"

  • Run the local demo stack — a seeded copy on one machine, for trying the product before you bet a client on it.
  • The local stack — services and ports, profiles, the migration-owner vs RLS app-role split, container hardening, and the secrets you must set.
  • Run one process instead of two — for a demo or a one-box install.
  • The deploy descriptor — every runtime parameter in one machine-readable place, which is what an automated deployment reads.

"Put it on the internet"

Reverse proxy and TLS is the page to read before the first DNS record. It covers the required upstream routes, the streamed live leg and why it must not be buffered, upload size limits, Direct-mode ACME against Cloudflare Edge mode, origin IP-range lockdown, and the trusted-proxy settings that make a resolved client IP mean anything.

"Back it up, and prove the backup works"

  1. Backup and restore — pg_dump, object storage, restic or WAL-G for point-in-time recovery.
  2. Rehearse the restore into a scratch database. The same page has the verify steps, and a restore you have not run is a hope rather than a backup.
  3. Alert on archive silence. The runbook names the specific failure: an archive pipe that breaks keeps logging as if it worked.

"Upgrade"

"Watch it"

  • Database observability — the query mix and the slow tail, the EXPLAIN signal, and scheduled maintenance inside PostgreSQL.
  • Observability — the optional OpenTelemetry profile (Tempo, Loki, Grafana) plus status monitoring, and the endpoint variable that turns export on.
  • Watch your self-hosted services — container health probes, the ClamAV quarantine view, and links to the dashboards.
  • Perf program — the budgets and the harness, if you want to measure your install against a recorded baseline instead of guessing.
  • Capacity model — how many agents one instance serves, from measurements.
  • Worker cadence — which loops run how often, and what a small install can trim.

"Mail is being refused, or scanned wrong"

"Run models on our own hardware"

  • Local AI — why weights stay outside the container image, and how the ollama profile serves transcription and embeddings.
  • Manage AI access — the switch that decides whether any of it is reachable, which is an admin decision, not yours.

"It is down"

  1. Troubleshooting — symptom first, with the checks in the order that separates a proxy problem from an application problem.
  2. Backup and restore — the restore path, if the database is the part that is gone.
  3. Self-hosted services — the health probes that say which container is unhappy.

Not documented yet

This is the thinnest area on the site, and the gaps are worth naming plainly.

  • Incident runbooks: no page walks an outbox backlog, an undelivered email queue, a dead-letter pile, or Postgres or Valkey being unavailable. The observability page says what is exported; it does not say what to do when a metric is bad.
  • Alert rules: nothing in the docs ships a recommended threshold or an alert definition. A dashboard panel is not an alert.
  • Retention and RPO/RTO: no page states how long data is kept, what the backup window guarantees, or what a restore costs in time.
  • The restore drill is manual. Nothing schedules it or proves it ran.

Documentation © 2026 Marula, licensed CC BY 4.0. Marula is a trademark. View source

For site operator — you run the instance. You have shell access, you.