Forum

Hello,

The issue has been resolved. During the server upgrade, the containerd metadata database became inconsistent with the actual image layer snapshots, causing all image pulls to reference a snapshot directory (snapshot 1975) that no longer existed.

I have reset the containerd metadata and cleaned up the old snapshot data. The PostgreSQL service is now running normally. Your data (PVC) remains unaffected.

Hello, the PostgreSQL issue has been resolved and it is now showing as running, but n8n still fails to restart.

Service ID: 69b142973d343ff352129589

Project ID: 69b14263e98fc0444aa984d5

Environment ID: 69b1426386eb1e388b2c2f4f

1. Background: After a server upgrade, n8n is unable to connect to PostgreSQL.
2. Symptoms: The n8n container starts, but continuously reports connect ECONNREFUSED 10.43.146.205:5432.
3. Troubleshooting performed:

• Environment variable configuration is correct.
• PostgreSQL service is running normally.
• Connection parameters are correct.

Service Status:

• Status: CRASHED
• Container keeps failing to restart.
• Startup probe failed: Startup probe failed: Get "http://10.42.0.11:5678/healthz": dial tcp 10.42.0.11:5678: connect: connection refused

Configured Connection Parameters:

• DB_TYPE: postgresdb
• DB_POSTGRESDB_HOST: service-69b142973d343ff35

Hello,

The issue with n8n is also due to the same containerd snapshot corruption. I have performed a more thorough cleanup (rebuilding the entire containerd state), and all services are currently re-pulling their images.

Since all images need to be re-downloaded from Docker Hub (n8n ~275MB, PostgreSQL ~150MB), it is expected to take a few minutes. The services will start automatically once the pull is complete. Please wait a moment.

n8n has also returned to normal, and all three services (PostgreSQL, n8n, runners) are currently running properly.

If there are no further issues, we will close this ticket.

The status shows 'Crashing/Restarting' shortly after being enabled. Additionally, clicking 'Reinstall' for these three components on the server does not trigger any response.

Hello,

The reason for the continuous service crashes is insufficient memory. Here is the current status of the server:

Server Specifications: 2C / 3.7GB available memory (no swap)

Current Memory Usage (after all services for the n8n project have been terminated):

• System components: ~137MB
• Second project services: ~208MB
• Other system overhead: ~1.8GB
• Remaining available: ~1.5GB

Requirements for starting the n8n project:

• PostgreSQL: ~150MB
• n8n: ~400-600MB (higher during startup)
• task-runner: ~200MB
• Total: ~800MB-1GB

n8n's memory peak during startup exceeds the available space, causing the startup probe to time out → container is terminated → repeated restarts.

It is recommended to upgrade the server to the 8GB specification. The current 4GB is insufficient to host both projects plus the system components simultaneously.

Is the 'other system overhead' caused by my N8N content? I originally had 30% RAM available with 2GB, but it suddenly became unusable on 6/1. I have already upgraded to 4GB; do I need to upgrade to 8GB?

Hello,

n8n has been successfully restarted, and all three services (PostgreSQL, n8n, task-runner) are currently running normally.

The previous crash was caused by a corrupted containerd during the upgrade process. After fixing it, the memory usage spiked during the service restart, leading to a crash loop. It has now stabilized.

If you encounter out-of-memory issues again in the future, you might consider moving the second project to another server to distribute the load.

It is still crashing and retrying, and it is not running properly. I paid to upgrade the server two hours ago, but it is still 2C4G, and my website is currently down. Also, I don't have a second project on my server. Please resolve this issue correctly and as soon as possible; I have already paid for the upgrade.

Hello,

The following issues have been resolved:

1. Residuals from deleted projects: A container from a deleted project was still running on your server, consuming approximately 200MB of memory. It has been cleared.

2. n8n restarted: All three services are currently running normally.

3. Upgrade to 8GB issue: Your upgrade failed due to an AWS snapshot creation timeout. The $6.30 fee has been automatically refunded to your account balance. If you would like to try the upgrade again, you can do so from the Dashboard.

4. Preventing future crashes: It is recommended to set a memory limit for your n8n service in the Dashboard (e.g., 1.5GB) to prevent memory spikes from affecting the operation of other services.

n8n keeps crashing after startup.

1. Please help me ensure the service actually stays running. Currently, it crashes within 20 seconds of startup, creating an infinite loop.
2. If it cannot be started, could you allow me to upgrade the server first to get n8n running? I don't want even the upgrade process to have issues.
3. If none of the above can be resolved, is there a way to export my existing data to migrate it to another server?

Hello, currently n8n is not running; only PostgreSQL and task-runner are active.

The core issue is that your services do not have memory limits set. n8n has a high memory peak during startup. Without limits, it consumes all available memory, gets killed by the system, and then enters an infinite restart loop.

Please go to the Dashboard and set memory limits for each service:

• n8n: 1.5GB
• PostgreSQL: 512MB
• task-runner: 256MB

After setting these, restarting n8n should allow it to run stably.

If it still crashes after these settings, we can assist in upgrading your server to 8GB (the previous upgrade failed due to an AWS snapshot timeout and has been refunded). The upgrade will incur a price difference; please confirm if you would like us to proceed.

It still doesn't work after configuration.

Please confirm the upgrade and handle it as soon as possible. I've been dealing with this for 3 days.

Hello, all services are currently running normally (n8n, PostgreSQL, task-runner, ingress controller, NATS, vector aggregator). The issue has been resolved without upgrading to 8GB.

Summary of issues:

1. Old processes remaining after the upgrade were occupying ports 443, 80, and 8222, preventing three system components from starting (already cleared).
2. n8n timed out when connecting to PostgreSQL during startup because the network was not fully ready during the system component recovery process; it recovered automatically after a few restarts.
3. The DB connection timeout has been increased from 60 seconds to 200 seconds to prevent this from happening again in the future.