Quickstart

Midplane puts a safety layer between your agent and your Postgres database. Three ways to stand it up: Cloud (hosted, and the fastest way to a working setup — recommended), local (the MIT engine on your own machine, no account), or self-host (the whole app on your infrastructure). Whichever you pick, by the end you’ll have a protected MCP endpoint and a denied query to prove it.

Cloud · recommended
Local (npx)
Self-host

Go to app.midplane.ai and create an account with email and password, or Google.

Choose a region

Pick EU or US — it sets where your credentials and audit log live.

Your region is immutable — chosen once at sign-up, and every project inherits it. Pick the jurisdiction your data needs to stay in.

Connect Postgres

Click Connect Postgres and paste a connection string — that creates your first project, an MCP endpoint fronting one or more databases. Give Midplane a scoped, least-privilege role, not a superuser DSN. Pick a default access level and leave it at read to stay read-only; grant writes per table later.Not sure which connection string to paste, or what to grant the role? See connect your database — plus the per-provider guides for Supabase, Neon, RDS, and Railway.No database handy? Click Try the sample database to load a hosted, read-only demo Postgres in one click and watch an agent query through Midplane.

Connect your agent

Your project has a stable HTTPS endpoint, https://{eu|us}.midplane.ai/mcp. Paste it into your agent’s MCP config — you connect over tokenless OAuth (register, sign in once, no secret to copy), and Cursor, Claude Code, and Claude Desktop all connect the standard way. See connect your agent.

For CI or headless callers, mint a machine token instead — that token is a secret, shown only once. See tokens.

The MIT engine on its own — no account, no dashboard, no server of yours. It guards one database for an agent on this machine, and audits to a local file. Same enforcement engine as Cloud; less product around it.Prerequisite: Node 22.16+ or 24+ (or Bun 1.3+). npx ships with Node, so there’s nothing to install.

Add it to your MCP client

npx fetches the midplane package on first run. Claude Code, Claude Desktop, and Cursor all take this config shape:

{
  "mcpServers": {
    "midplane": {
      "command": "npx",
      "args": ["-y", "midplane", "server", "--stdio"],
      "env": { "DATABASE_URL": "postgres://user:pass@host:5432/db" }
    }
  }
}

Keep the connection string in the env block, never in args — a DSN on a command line leaks to ps aux and your shell history. Give Midplane its own least-privilege Postgres role: it governs which SQL runs, not what the role underneath it can reach. See connect your database.

A local development Postgres works here with no public endpoint — the engine runs on this machine, so localhost:5432 is genuinely local.

Restart your client

The Midplane tools appear once it reconnects. Nothing else to configure — the default is already reads allowed, writes and DDL denied, every query audited.

Grant writes, if you need them (optional)

npx -y midplane init introspects your schema over a read-only connection and writes a validated midplane.policy.yaml. Point at it by adding MIDPLANE_POLICY_FILE to the same env block. See the standalone engine for the full path.

Prerequisite: Docker (with Compose v2).

Clone and run

git clone https://github.com/midplaneai/midplane && cd midplane
./bin/self-host up            # → dashboard at http://localhost:3000

One command creates .env.self-host with generated secrets, pulls the image, and brings up Postgres and the dashboard. MIDPLANE_SELF_HOST=1 is preset; see the deploy guide for every variable and run method.

Back up .env.self-host and never rotate its secrets once data exists — the KMS key encrypts project DSNs and the token pepper backs machine tokens, so regenerating either bricks every stored credential. The script never regenerates a value that’s already set.

Open http://localhost:3000 and sign up once — the first email + password becomes the owner. Then connect a Postgres database to create your first project. Give it a scoped, least-privilege role; Midplane encrypts the DSN with your local key. Pick a starting table access level (read by default).

Inside the container, localhost is the container. For a Postgres on your host, use host.docker.internal (Docker Desktop) in the DSN, or put the database on the same Docker network.

Connect your agent

Point your agent at the project’s /mcp endpoint on http://localhost:3000, over the dashboard’s OAuth flow — or mint a machine token for headless callers. See connect your agent.

Claude Desktop rejects http://localhost (it requires HTTPS) — use the mcp-remote shim, shown in the per-agent guide. Cursor and Claude Code connect to the localhost URL directly.

Try it

Ask your agent to list the tables in your database — an allowed read that goes straight through. Now ask it to change a single row in one of those tables. The agent issues a bounded UPDATE … WHERE, and Midplane denies it before it runs: under the table_access rule, writes deny by default — even a one-row, surgical change — until you grant read_write on that table. Nothing is modified, and the attempt is audited. Then read both events back — the allowed read and the denied write, each tagged with the rule that decided it, and the denial recorded before the query would have run. On Cloud and self-host, open the audit log in the dashboard. Running locally, read it from the CLI:

npx -y midplane audit denies

2026-08-19T12:24:16Z DENIED table_access agent=midplane-cli qid=01M0CZNDFTRSNC2BW5FQ3YZWTF
  sql:    DELETE FROM users WHERE id = 1
  reason: Midplane denied this query because writes to table `users` are not allowed by the
          table-access policy (`users` resolves to `read`, which permits reads only). Another
          write to `users` will be denied the same way.
  intent: remove a test account

1 denial in the last 24h

Either way it’s the same record. See the audit trail.

Next steps

Connect your agent

Verified MCP configs for Cursor, Claude Code, and Claude Desktop.

Write a policy

Grant the reads and writes your agent actually needs.

Cloud vs self-host

Which to run, and how they compare.

Get started

Core concepts

Connect your database

Connect your agent

Writing policies

Cloud

Run it yourself

Security

Resources

Try it

Next steps

Connect your agent

Write a policy

Cloud vs self-host

​Try it

​Next steps

Connect your agent

Write a policy

Cloud vs self-host

Try it

Next steps