> ## Documentation Index
> Fetch the complete documentation index at: https://rapidreview.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Self-hosting overview

> What you run, what you give up, and which of the two self-hosted shapes — a local brain or a full hosted-style deployment — you want.

The hosted brain runs the same open-source code. Self-host when you need data residency, an air-gapped lab, or to hack on Merv itself.

## Two shapes

| Shape               | Local brain                                                                | Full deployment                                                                                             |
| ------------------- | -------------------------------------------------------------------------- | ----------------------------------------------------------------------------------------------------------- |
| Runs                | `merv-http` on your machine, SQLite + local blobs                          | Docker Compose: `control` (FastAPI brain), Postgres, MinIO/S3, management SSH key                           |
| Auth                | None — every request is the implicit local principal; the UI skips sign-in | Required by default: Supabase Auth verifier, project membership, OAuth for clients, `mk_` keys for machines |
| Clients connect via | `http://127.0.0.1:8787/mcp`                                                | `https://your-brain.example.com/mcp` behind TLS                                                             |
| Sandboxes           | Yes, if you give the brain provider credentials                            | Yes, via a provider env file kept outside the checkout                                                      |
| Good for            | Trying Merv, developing on it, one person                                  | A team, a lab, anything reachable by more than one machine                                                  |

Both use the same topology as hosted: every agent client talks straight to one brain over HTTP; the browser UI talks to the same brain. No local MCP proxy, and the brain never receives your checkout — agents send explicit ids, metadata, and the bytes they choose to submit.

## What you take on

* TLS termination and a trusted network boundary (the brain itself serves plain HTTP on 8787).
* Managed Postgres, object storage, backups, lifecycle rules.
* A secret manager and a rotation procedure for the management key and provider credentials.
* A cleanup scheduler (`POST /api/admin/cleanup` from cron) and alerting.
* A separately deployed UI with explicit CORS origins.
* End-user auth before any public or multi-tenant use.

<Warning>
  The reference deployment in `merv/deploy/` is a worked example, not a managed service or a production security boundary. Keep an open (`MERV_REQUIRE_AUTH=0`) stack on a trusted operator network only.
</Warning>