Proxy server doesn't start

Google Cloud Database
1

Hi everyone,

I’m trying to deploy my Nest.js backend to Cloud Run with a Postgres Cloud SQL instance.
The app runs fine locally and in Docker Compose, but on Cloud Run it fails with:

Error: connect ECONNREFUSED 127.0.0.1:5432
at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1637:16)

I’ve already:

  • Added my Cloud SQL instance under Connections → Cloud SQL connections in the Cloud Run UI.

  • Set environment variables:

    DB_HOST=127.0.0.1
DB_PORT=5432
DB_USERNAME=postgres
DB_PASSWORD=*****
DB_DATABASE=well-donny

  • Verified that the database works and is in the same region.

    But in the Cloud Run logs, I don’t see the usual message like:

    Cloud SQL Auth proxy starting...
Listening on 127.0.0.1:5432

    Instead, the container just retries the DB connection and crashes.

    It looks like the Cloud SQL Auth Proxy sidecar is not being injected into my service, even though the connection is configured in the UI.

    Question

    • How can I confirm that Cloud Run is actually attaching the Cloud SQL Proxy sidecar?

    • What could prevent the proxy from starting, even if the instance is listed under “Cloud SQL connections”?

    • Are there IAM or service account permissions that could block this?

    Thanks!

2

Hi CyrilSmith,

Let’s go through your question one by one:

  1. How can I confirm that Cloud Run is actually attaching the Cloud SQL Proxy sidecar?
  • You’re on the right track by checking the logs. One way to confirm if Cloud Run is attaching the Cloud SQL Proxy sidecar and if it’s starting correctly is by examining the detailed logs of your Cloud Run service.

Look for log entries that indicate the proxy’s initialization and its listening status. Typically, these will include messages like:

* Cloud SQL Auth Proxy starting…
* Listening on 127.0.0.1:5432

Since you’ve mentioned that these messages aren’t appearing, along with the ECONNREFUSED 127.0.0.1:5432 error, it’s a clear indication that the Cloud SQL Auth Proxy is either not being injected or is failing to start in your Cloud Run service.

  1. What could prevent the proxy from starting, even if the instance is listed under “Cloud SQL connections”?
  • A common cause could be insufficient IAM permissions for the Cloud Run service account. The account needs the Cloud SQL Client role to successfully authorize a connection to the Cloud SQL instance. There could also be other, less common issues, like a typo in the instance connection name (PROJECT_ID:REGION:INSTANCE_NAME) or a mismatch in the regions between Cloud Run and Cloud SQL.
  1. Are there IAM or service account permissions that could block this?
  • Yes, it’s possible. The lack of the Cloud SQL Client IAM role on the service account used by your Cloud Run service is one of the key reasons the proxy might not start. This role is necessary to give the Cloud Run service and the proxy sidecar it manages the authorization to connect to your Cloud SQL instance.

Additionally, you may want to check the following documentation, which might help with your issue:

3

Your application code is correctly configured to connect to 127.0.0.1. The problem lies in the environment, not your code.

Your action plan should be:

  1. Verify the Cloud SQL Admin API is enabled for your project.

  2. Confirm the Cloud Run service account has the Cloud SQL Client role in IAM.

  3. Double-check the Cloud SQL connection name in your Cloud Run service’s Connections tab. It must be project-id:region:instance-id.

  4. After verifying the above, re-deploy your Cloud Run service to create a new revision with the correct configuration. This forces a fresh attempt to attach the sidecar.

Following these steps should resolve the issue and you’ll see the Cloud SQL Auth proxy starting... message in your logs.