We are looking for an experienced DevOps engineer and n8n specialist to stabilize our self-hosted n8n production environment. The system is currently experiencing severe instability and frequent crashes, recently resulting in the loss of days of critical workflow development. The platform handles complex, high-stakes automation—including government API integrations and financial routing—and system reliability is non-negotiable.
The primary objective is to migrate the backend database from MySQL to PostgreSQL and implement a robust, crash-resilient architecture.
Key Responsibilities:
Root Cause Analysis: Diagnose the exact cause of the current n8n crashes (e.g., memory limits, database locking, or MySQL performance bottlenecks under heavy execution loads).
Database Migration: Execute a secure, zero-data-loss migration of the n8n execution data, credentials, and workflow configurations from MySQL to PostgreSQL.
System Optimization: Reconfigure the deployment architecture (utilizing Docker) for a high-load production environment. This includes optimizing n8n environment variables for execution processing, scaling, and database connection pooling.
Disaster Recovery: Implement automated, redundant backup protocols to guarantee no future loss of workflow configurations or execution histories.
Required Skills & Experience:
Deep expertise in self-hosted n8n architecture, scaling, and deployment best practices.
Proven track record of managing and migrating production databases (specifically MySQL to PostgreSQL).
Strong background in DevOps, Docker, server resource management, and workflow automation platforms.
Ability to implement aggressive execution pruning and database maintenance strategies to prevent future bloat.
I have 3+ years of experience working with n8n, including self-hosted environments, workflow optimization, and handling complex automation systems. I’ve worked on production workflows with API integrations, error handling, and system stability considerations.
While my primary focus is on building and managing n8n automation workflows, I’m comfortable working alongside DevOps setups and can support workflow optimization, execution handling, and system structuring to reduce failures.
I’m also a top supporter of the n8n community.
Happy to connect and discuss further — we can start with reviewing the current setup and identifying the root cause.
Email: muhammadmoosa.abc1@gmail.com
This sounds like a critical setup, especially with high-load workflows and production usage.
I’ve worked with self-hosted n8n environments handling complex automation flows, including debugging execution failures, optimizing workflows, and improving stability under load.
From your description, the crashes could likely be tied to execution load, database performance (MySQL bottlenecks), or server resource limits — so a proper root cause analysis would be key before any migration.
While I focus more on the n8n architecture and workflow optimization side, I can help diagnose the issues, support the migration process, and ensure the system is stable post-migration to PostgreSQL.
Happy to take a closer look at your setup.
Portfolio: Check out one of my recent automation setup here
I’ll be direct — this kind of instability in n8n usually comes from execution overload + MySQL bottlenecks + weak container/resource configuration. Migrating alone won’t fix it unless the architecture is corrected.
I specialize in self-hosted n8n systems running under production load, and I can help you stabilize this properly.
What I’ll handle:
Root cause analysis (crashes, memory, DB locking)
Safe MySQL → PostgreSQL migration (zero data loss)
Execution pruning + DB tuning to prevent future bloat
Backup & recovery setup (no more workflow loss)
I’ve built and deployed multiple automation systems handling high-volume APIs, AI workflows, and business-critical processes, so I understand the failure points in real-world setups.
Your n8n crashes are database-related. MySQL struggles with n8n’s queue processing and execution history tracking at scale.
PostgreSQL works better. Set up pgBouncer for connection pooling and configure execution history pruning to 7-14 days. These two settings prevent most crashes.
I’d also check your Docker memory limits. n8n needs more headroom than most people allocate, especially when processing multiple workflows simultaneously.
What’s your current worker count and execution retention period?
You’re right not to treat this as “just migrate MySQL to Postgres and hope.”
On a self-hosted n8n install like this, I’d start by freezing the blast radius, pulling the crash-window logs, checking execution-history growth, and reviewing Docker memory/restart settings before locking the cutover. PostgreSQL is likely the right end state, but if the current failure mode is execution overload + retention bloat + container limits, migration without a pre-cutover stabilization step just moves the bottleneck.
The first deliverable I’d propose is a written crash-triage + migration plan covering:
2. evidence checklist from compose/env/logs/DB size
3. staged MySQL → PostgreSQL cutover with rollback criteria
4. pruning + backup hardening after cutover
Two questions that would let me scope this honestly: are you currently running in main mode or queue mode, and what are your current worker count / execution-retention settings?
If useful, I can turn that into a concrete first-pass triage checklist before any production change.
Hey - this hits close to home because I manage a self-hosted n8n production environment right now and I’ve dealt with exactly these problems.
My current setup: n8n on Docker with Postgres backend, Grafana for monitoring, automated cron jobs for maintenance, Telegram alerts on failures. It runs 24/7 and handles real workloads - not test data.
On your specific issues:
Root cause diagnosis - in my experience n8n crashes on MySQL usually come from one of three things: execution table bloat (MySQL locks up on large tables), memory limits in the Docker container not matching the workload, or the default SQLite/MySQL backend just not being built for concurrent heavy executions. I’d check Docker logs, n8n execution stats, and MySQL slow query log first to pinpoint it
MySQL to Postgres migration - this is the right call. Postgres handles concurrent writes and large execution tables much better than MySQL for n8n. I’ve done database migrations before and I know the n8n schema. The approach: dump the data, transform the schema differences, import into Postgres, verify row counts and credential decryption, switch n8n config, test thoroughly before going live. Zero data loss is the only acceptable outcome
Docker optimization - I’d set proper memory and CPU limits, configure n8n environment variables for execution pruning (EXECUTIONS_DATA_MAX_AGE, EXECUTIONS_DATA_PRUNE), set up DB connection pooling, and separate the database container from the n8n container with proper networking
Disaster recovery - automated daily Postgres dumps to remote storage (I use Backblaze B2 with S3-compatible API), plus n8n workflow JSON exports via API on a cron schedule. Two independent backup streams so if one fails the other catches it
I also have experience with bash scripting for server management - I wrote a full db_sync_manager.sh for MySQL remote sync via SSH tunnel at my previous job, same principles apply here.
Government APIs and financial routing means zero tolerance for downtime - I understand that. I build with error handling first, not as an afterthought.
Portfolio: github.com/penkayone/n8n-automation-portfolio
Available to start immediately. Happy to do a quick diagnostic call where I look at your Docker setup and give you a preliminary assessment before we commit to anything.
I’ve read your project description, and honestly, it sounds like a classic n8n scaling bottleneck. When handling high-stakes automation like government APIs and financial routing, MySQL often fails due to locking issues during high-concurrency execution.
I specialize in stabilizing high-load n8n environments and I’m ready to take over the migration and architecture overhaul immediately.
My Roadmap to Stabilize Your System:
Emergency Audit & Root Cause: Before migrating, I’ll analyze your Docker logs and resource usage. Usually, the culprits are “Execution Data Bloat” and “Memory Leakage” from heavy workflows. I’ll implement immediate pruning to stop the crashes.
Zero-Loss Migration (MySQL → PostgreSQL): I will execute a structured migration of your credentials, workflows, and historical data to PostgreSQL. Postgres handles the n8n JSON-heavy workloads much more efficiently, and I’ll configure PgBouncer or connection pooling to ensure the DB never chokes.
Production-Grade Docker Setup: I’ll reconfigure your deployment using Worker Nodes if necessary (to separate the UI from the heavy processing) and optimize environment variables like N8N_EMAIL_MODE, EXECUTIONS_DATA_SAVE_ON_ERROR_ONLY, and memory limits to prevent the main process from crashing.
Bulletproof Disaster Recovery: I’ll set up automated, redundant backups (S3/Off-site) of both your DB and the .n8n folder, so even in a total server failure, you lose exactly zero minutes of development.
Why trust me with your high-stakes system? I am a developer at heart (JavaScript/Python/SQL) with a deep understanding of how n8n manages its execution stack. I don’t just “click buttons”—I understand the underlying architecture and how to optimize it for thousands of concurrent requests.
Self-hosted n8n under government + financial load, MySQL bottlenecks, memory-limit crashes — the diagnosis you want is not “tune three settings” but a staged migration plan with rollback at every step.
Sequence I would propose:
Pre-migration: capture 48–72 h of execution metrics, identify the top 10 workflows by memory footprint, isolate the MySQL queries that lock (execution_entity is the usual culprit)
Migration: PostgreSQL provisioned, schema imported, dual-write window where n8n writes to both DBs, validate row parity, cut reads, retire MySQL — with a documented rollback path at each gate
Post-migration: execution-pruning policy, connection pool tuned for Postgres specifically, automated backups on a 3-2-1 pattern (3 copies, 2 media, 1 off-site)
Docker: worker + webhook + main as separate services, resource limits set, health-probes that actually restart on hang
For government and financial data, secrets management on the worker boxes matters as much as uptime. I’ll walk through that alongside the migration plan on a call.
Reference repo I maintain (auditable, schema-validated pipelines; SQLite in the repo, Postgres-ready):
Book a 30-minute call this week and we’ll scope timeline and fixed-milestone pricing.
I would not start by touching the migration. If days of workflow work have already disappeared, the first useful paid pass is a short written triage pack that shows whether a cutover is safe.
What I would ask for: secrets-removed compose/env shape, crash-window logs, execution table counts, current backup or restore notes, and whether the instance is running main mode or queue mode.
What I would return: a crash-signal ledger, a migration-readiness checklist, and the restore-test or rollback blockers I would want resolved before MySQL to Postgres work begins.
That catches the boring failure modes before they become expensive: execution-history bloat, restart churn, missing restore proof, unclear credential boundaries, and no rollback criteria.
I work async and fixed-scope, so I am not the right fit if you need someone live inside production tonight. But if a written first pass helps, send the redacted details above and I can map the fixed paid triage sprint from there before any production migration or credential movement.
I can also show a small public proof shape for the triage ledger if you want to see the artifact format before sending anything sensitive.
I’m Muhammad Bin Zohaib — a Certified n8n Developer (Level 1 & 2) and AI automation engineer working primarily with self-hosted n8n systems, Docker deployments, AI agents, and production workflow infrastructure.
From your description, this looks less like a simple “n8n issue” and more like an architecture + execution stability problem. In most high-load n8n setups, the common failure points are usually:
MySQL locking/performance degradation under heavy executions
improper queue/execution mode configuration
memory exhaustion from large workflow runs
missing pruning/retention policies
Docker/container resource constraints
lack of backup/versioning strategy
I’ve worked on production automation systems involving:
WhatsApp APIs
financial and business process automations
AI workflow orchestration
high-volume execution pipelines
voice AI systems
external API integrations
For your setup specifically, I’d approach this in phases:
Full infrastructure + execution analysis
Review logs, execution patterns, Docker setup, DB health, queue mode, worker behavior, and resource utilization to identify the exact crash source.
Safe migration from MySQL → PostgreSQL
Preserve workflows, credentials, execution data, and environment configs with rollback protection and backup snapshots before migration.
Production hardening
Optimize:
execution mode
worker scaling
DB pooling
pruning
Docker resource allocation
environment variables
monitoring and recovery strategy
Disaster recovery setup
Automated backups, workflow version protection, and redundancy measures so workflow loss never happens again.
I’ve also built and maintained complex AI automation systems for clients across the UK, Germany, Canada, Singapore, Australia, and other regions.
Portfolio: 
Projects (with demos): 
WhatsApp: +92 3360327970