The internal hostname won’t work
Railway’sDATABASE_URL points at the private network:
*.railway.internal resolves only from services inside the same Railway project, on Railway’s private IPv6 network. It doesn’t resolve from your laptop, and it doesn’t resolve from Midplane Cloud. Private address space is rejected before a connection is attempted, so Test connection reports:
Option 1 — expose a TCP proxy
Railway databases are private by default. To reach one from outside, open the Postgres service’s Settings → Networking and add Public Networking. Railway creates a TCP proxy and populates a second variable:sslmode=require and paste it into Connect Postgres in the dashboard.
Option 2 — run Midplane inside the project
If you’d rather not expose the database at all, self-host Midplane as a service in the same Railway project. The internal hostname then resolves normally, the database stays private, and your agents connect to Midplane’s endpoint instead of to Postgres. This keeps the number of publicly reachable things at one, and the thing that’s public is the layer that parses SQL and enforces policy — rather than the database itself.Create a least-privilege role
Railway hands you thepostgres superuser. Connect once with it and create a role for Midplane:
read and grant writes per table later — see table access.
Next steps
Connect your agent
Wire up Cursor, Claude Code, or any MCP client.
Write a policy
Grant the reads and writes your agent actually needs.