Removing the public path to enterprise databases

The original databases ran on Railway and DigitalOcean. Those platforms reduced operational work, but each database still had a public network endpoint. Credentials controlled who could log in; the network itself did not prevent an internet host from reaching the database listener.

As the enterprise fleet grew, I wanted a stronger boundary: an application or developer should first need a route into the company network, then valid database credentials. Google describes private Cloud SQL connections as reachable without traversing the internet or using external IP addresses, and notes lower network latency than public IP.^[3]

This is defense in depth, not a replacement for authentication. A private IP or leaked database URL is not useful from the public internet by itself; the source also needs an authorized route into the VPC. Database credentials, VPN enrollment, and secret access remain independent controls that must all be revoked during offboarding.

The same boundary reduces the usefulness of accidental environment disclosure by unattended or auto-approved development agents. An agent may still read or print credentials available to its process, so the architecture does not make secret handling harmless. It does prevent a remote party from connecting with the private address unless they also obtain an authorized network path.

Production services use Cloud Run Direct VPC egress to reach Cloud SQL over private addresses.^[1] Google's Cloud SQL guidance describes this private path as a direct TCP connection through the VPC rather than a public-IP Cloud SQL Auth Proxy path.^[2]

Developers activate Tailscale, authenticate against the company-hosted Headscale control server, and receive only the routes required for Google Cloud private ranges. Monosg then supplies the environment configuration containing the private database address. The workflow stays familiar even though the reachable network has changed.

I completed the migration in June 2026. The technical cutover for each database required about one minute of downtime, but I spread the work across one week so every change could happen during an agreed off-hours window instead of forcing a single high-risk event.

For each workload, I prepared the private Cloud SQL destination, connected its Cloud Run service to the VPC, updated the database URL in Monosg, scheduled the brief switchover, and validated application traffic before moving to the next database. Developers only needed to install Tailscale and activate it when working with a database; their Monosg-based commands did not change.

All 21 enterprise databases now use private addresses. Backend traffic stays on the VPC path, and developer access requires both an active VPN route and the appropriate secret and database credentials. Removing VPN enrollment and Monosg access prevents an offboarded developer from establishing new sessions, subject to the normal limitation that previously copied credentials must still be rotated when required.

Latency was not benchmarked before the migration, so I do not claim a measured speedup. Google states that private IP provides lower network latency than public IP,^[3] and documents a maximum of 1 Gbps of Direct VPC egress per Cloud Run instance, compared with a 600 Mbps limit for bandwidth excluding Direct VPC egress.^[4] Those are platform limits—not observed application throughput—and connection pooling, query execution, and region placement still dominate many database workloads.