From Windows Paths to Docker Environments: Fixing n8n SQLite Deployment

Delivering n8n Workflows to Production: The SQLite Path Problem

The ai-agents-admin-agent project needed a reliable way to deploy n8n configurations to a server, but there was a catch—all eight workflows contained hardcoded Windows paths pointing to a local SQLite database. When those workflows ran on the Linux server, they’d fail with no such table: users because the database file simply wasn’t there.

The core issue wasn’t about moving files. It was that n8n-nodes-sqlite3 expected the database path as a static string parameter in each workflow node. Every workflow had something like C:\projects\ai-agents\admin-agent\database\admin_agent.db baked into its configuration. Deploy that to a server, and it would look for a Windows path that didn’t exist.

The initial instinct was to use n8n’s expression system—storing the path as $env.DATABASE_PATH and letting the runtime resolve it. This works in theory: define the environment variable in docker-compose.yml, reference it in the workflow, and you’re done. Except it didn’t work. Testing through n8n’s API revealed that despite the expression being stored, the actual execution was still trying to hit the Windows path. The task runner process in n8n v2.4.5 apparently wasn’t receiving the environment variable in a way that the SQLite node could use it.

So the solution shifted to deploy-time path replacement. The local workflow files keep the $env expression (for development in Docker), but when deploying to production, a custom script intercepts the workflow JSON and replaces that expression with the actual server path: /var/lib/n8n/data/admin_agent.db. It’s a bit of string manipulation, but it’s reliable and doesn’t depend on n8n’s expression evaluation in the task runner.

The deployment infrastructure grew to include SSH-based file transfer, database initialization (copying and executing schema.sql on the server), and a configuration system with deploy.config.js defining path replacements for each environment. A dedicated migration system was added too, allowing incremental database schema updates without recreating the entire database each time.

But there was a twist near the end: even after deploying the corrected workflows with the right paths, old executions were cached in n8n’s memory with the wrong path. The stored workflow had the correct path, but execution data still referenced the Windows location. A restart of the n8n container cleared the cache and finally made everything work.

The lesson here is that static configuration in workflow nodes doesn’t scale well across environments. If you’re building tools that deploy to multiple servers, consider parameterizing paths, database URLs, and API endpoints at the deploy stage rather than hoping runtime expressions will save you. Sometimes the “dumb” approach of string replacement during deployment is more predictable than elegant expression systems that depend on runtime behavior you can’t fully control.

😄 Eight bytes walk into a bar. The bartender asks, “Can I get you anything?” “Yeah,” reply the bytes. “Make us a double.”