Dear Railway Support Team,

I am writing to report a critical connectivity issue between my n8n service (Service Name/ID: n8n-item) and my PostgreSQL database service (Service Name/ID: within my Railway project (Project ID: [c74ec12d-1655-4bf1-aee1-ad9b801265a5]).

Problem Summary:

My n8n service is unable to establish a stable connection to the PostgreSQL database. The primary symptom is ECONNREFUSED errors in the n8n worker logs when attempting to connect to a specific IPv6 address for the PostgreSQL service. As a result, n8n cannot load any of my previous workflows or data, and the database connection indicator in the Railway UI for the n8n service is continuously spinning (not turning green). This issue became prominent on May 13, 2025.

Key Observations and Timeline (all times approximate TRT, UTC in logs):

1. n8n Worker Log Errors (May 13, 2025):

   • Around 12:47 PM TRT (09:47 UTC), n8n worker logs consistently show: connect ECONNREFUSED fd12:a02d:b29b:0:2000:3a:71bc:2711:5432

   • Around 1:20 PM TRT (10:20 UTC), during a worker restart sequence, logs showed:

     • Connection terminated due to connection timeout

     • Connection terminated unexpectedly

   • Shortly after the worker reported "ready" (n8n Version: 1.90.1), it received a SIGTERM and shut down, indicating instability.

2. PostgreSQL Service Status (May 13, 2025):

   • PostgreSQL logs from the same timeframe (around 12:47 PM TRT / 09:47 UTC) clearly indicate that the database server started, performed automatic recovery from an improper shutdown, and was database system is ready to accept connections on both IPv4 (0.0.0.0:5432) and IPv6 (:::5432).

   • The PostgreSQL logs also showed the message: PostgreSQL Database directory appears to contain a database; Skipping initialization, suggesting that existing data should still be present.

   • A minor entry invalid record length at 0/1EA36270 was noted during redo, but recovery completed successfully.

3. n8n Environment Configuration:

   • Database connection variables in n8n are configured using Railway's template variables:

     • DB_TYPE="postgresdb"

     • DB_POSTGRESDB_HOST="${{Postgres.PGHOST}}"

     • DB_POSTGRESDB_PORT="${{Postgres.PGPORT}}"

     • DB_POSTGRESDB_USER="${{Postgres.POSTGRES_USER}}"

     • DB_POSTGRESDB_PASSWORD="${{Postgres.POSTGRES_PASSWORD}}"

     • DB_POSTGRESDB_DATABASE="${{Postgres.POSTGRES_DB}}"

   • User management is enabled: N8N_USER_MANAGEMENT_DISABLED="false" (this was changed from true during troubleshooting, followed by a redeploy).

   • Other relevant n8n settings include: EXECUTIONS_MODE="queue", N8N_RUNNERS_ENABLED="true", and Redis is configured for queuing using Railway's template variables (e.g., ${{Redis.REDISHOST}}). The Redis service itself reports "Deployment Online" in the Railway UI.

   • N8N_ENCRYPTION_KEY is set.

   • ENABLE_ALPINE_PRIVATE_NETWORKING="true" is set.

4. PostgreSQL Service Environment Configuration (as provided by Railway):

   • PGHOST="${{RAILWAY_PRIVATE_DOMAIN}}"

   • PGPORT="5432"

   • POSTGRES_USER="railway"

   • POSTGRES_PASSWORD="IWTlBzRrjAElWFYkWNwGpmRXngG3YqWf" (actual password)

   • POSTGRES_DB="railway"

Core Issue:

The evidence strongly suggests that while the PostgreSQL service is running and ready for connections, the n8n worker processes cannot establish a network connection to it. The ECONNREFUSED error occurs when n8n tries to connect to the IPv6 address fd12:a02d:b29b:0:2000:3a:71bc:2711:5432, which is presumably the resolved address of ${{Postgres.PGHOST}} from within the n8n worker's environment.

Specific Request:

Could you please investigate the network connectivity between my n8n service container (Service ID: [Your_n8n_Service_Name_Or_ID]) and my PostgreSQL service container (Service ID: [Your_Postgres_Service_Name_Or_ID])?

Specifically, I would appreciate it if you could look into:

• Why connections from the n8n worker to the PostgreSQL service at the IPv6 address fd12:a02d:b29b:0:2000:3a:71bc:2711:5432 are being refused, despite PostgreSQL reporting it is listening.

• How the ${{Postgres.PGHOST}} variable (and also the Postgres service's own ${{RAILWAY_PRIVATE_DOMAIN}} variable) is resolving from within the n8n worker's network environment.

• Any internal network policies, firewall rules, or routing issues on the Railway platform that might be preventing this connection.

I am also aware of a ValidationError: The 'X-Forwarded-For' header... in my n8n primary logs and plan to address this by setting the appropriate N8N_TRUST_PROXY variable, but I believe this is secondary to the critical database connectivity issue.

This problem is preventing me from accessing my n8n instance and workflows. I am available to provide any further logs or information needed.

Thank you for your time and assistance.

Sincerely,