Getting n8n running in Docker takes one command. Keeping it running in production takes rather more: a persistent volume so workflows survive a restart, a backed-up encryption key so credentials survive a rebuild, valid HTTPS so webhooks resolve, and an upgrade path that does not lose data. This page is the checklist for doing that yourself. On Darwa none of it applies — you pick a plan, name the agent, choose a subdomain, and launch; there is no Dockerfile, compose file, or volume to configure.
Each of these is a common way a self-hosted n8n instance loses data or stops receiving webhooks. None are difficult individually; the work is remembering all of them.
Without a mounted volume for n8n's data directory, every workflow, credential, and execution disappears when the container is recreated. This is the single most common self-hosting mistake. Darwa provisions persistent storage as part of the plan, so there is no volume to mount.
Skip this entirely →n8n encrypts stored credentials with a key. If the key changes or is lost, every credential must be re-entered by hand. Back it up separately from the database.
View n8n hosting →Webhooks need a stable public HTTPS endpoint, and n8n must be told its own external URL or generated webhook links point at the container instead.
View n8n hosting →SQLite is the default and is fine for evaluation. For production, point n8n at Postgres so execution history and concurrent access behave predictably.
View managed databases →n8n releases frequently. Pin a version rather than tracking latest, read the breaking-change notes, back up before upgrading, and test on a copy first.
View n8n hosting →Concurrency is bounded by CPU and memory, not workflow count. Size the container for the busiest expected moment, not the average.
See plan resources →Self-hosting on Docker is a reasonable choice. It is worth going in knowing which tasks become permanently yours.
TLS certificates expire. An expired certificate silently breaks every inbound webhook, so renewal needs to be automated and monitored.
Back up the n8n database on a schedule and test a restore. A backup that has never been restored is an assumption, not a backup.
Read release notes for breaking changes, snapshot first, and upgrade deliberately rather than automatically.
Know when the container stops, the disk fills, or executions start failing. Discovering it from a colleague is the expensive path.
Execution history grows without bound by default. Set data-retention pruning or the volume eventually fills.
Keep the encryption key and database credentials out of the image and out of version control.
Almost certainly no persistent volume was mounted for n8n's data directory. Without one, the container's filesystem is discarded when it is recreated, taking workflows, credentials, and execution history with it. Mount a named volume and restore from a backup if you have one.
SQLite is the default and fine for evaluation or light personal use. For production, use Postgres: execution history grows quickly and concurrent access is more predictable on a real database server.
The usual causes are no valid HTTPS certificate on the public endpoint, or n8n not being told its own external URL, which makes it generate webhook links pointing at the container's internal address. Both must be correct before an external service can reach the workflow.
n8n encrypts saved credentials with it. If it is lost or changes between deployments, the stored credentials cannot be decrypted and every one must be re-entered. Back it up separately from the database, because a database backup alone is not enough to recover.
Around 1 GB of memory and half a vCPU is a workable starting point for light use. Memory-heavy nodes, large payloads, and overlapping executions raise it quickly, so size for peak rather than average.
Pin a specific version rather than tracking latest, read the release notes for breaking changes, back up the database and encryption key, then upgrade and verify. Testing on a copy first is worth the extra step for anything business-critical.
It removes this checklist entirely. On Darwa there is no Dockerfile, compose file, volume, or environment variable to configure: you choose an AI Agent plan, give the agent a name, pick the subdomain it answers on, and launch. Persistent storage, the generated encryption key, managed HTTPS, health verification, and backups come with the plan. Self-hosting on your own server remains cheaper on raw compute if you want to own the work above.
No. The install is one click from the agent catalog — pick a plan, name it, choose a subdomain, launch. Darwa runs the container for you and never asks for a compose file. Container details are shown read-only afterwards for diagnostics, so you can see what is running without having to manage it.