Pick where Midplane runs
- Cloud
- Self-host
Midplane Cloud connects over the public internet, so this path fits an instance that already has a public endpoint — commonly a dev or staging instance. It requires all of:
- Publicly accessible set to Yes on the instance (Connectivity & security in the RDS console).
- The instance’s subnets are public — a route table with a route to an internet gateway.
- A security group inbound rule allowing TCP on your database port.
Could not connect. Check the host, port, and that the database accepts connections from the internet.Use the right endpoint
RDS and Aurora hand you more than one hostname, and the choice is a safety control in its own right.
Pointing an analysis agent at a reader is the cheapest safety win available here: table access is your policy ceiling, and the replica is a second, physical floor underneath it.
Create a least-privilege role
Don’t use the master user — it holdsrds_superuser, and Midplane operates on top of whatever privileges the connection carries. Connect as the master user once, then:
IAM database authentication doesn’t fit. IAM auth issues a token that expires after 15 minutes, and Midplane stores one encrypted connection string per database. Use password authentication for the Midplane role, and rotate it from the credential pane when you need to.
TLS
Checkrds.force_ssl in your parameter group. Set to 1, RDS rejects any connection that isn’t encrypted — so a connection string without sslmode will fail at connect time rather than silently downgrade.
sslmode=require encrypts without verifying the certificate (libpq semantics, since engine 0.15.0). To verify against Amazon’s CA, download the global RDS trust bundle and point at it:
sslmode=require is the practical setting there; self-host can mount it and use verify-full. See connecting to your Postgres for the failure modes.
Next steps
Deploy self-host
Run Midplane inside your own VPC.
Write a policy
Grant the reads and writes your agent actually needs.