n8n binary data: filesystem, database or S3, and what 3.0 changes

n8n stores the files your workflows handle (attachments, images, PDFs) as binary data, and on a regular self-hosted instance it writes them to disk in ~/.n8n/storage by default. You pick the location with N8N_DEFAULT_BINARY_DATA_MODE: filesystem (the default), database (the default in queue mode), or s3/azure on Business and Enterprise plans. n8n 3.0 removes the old in-memory mode and renames the ~/.n8n/binaryData folder to ~/.n8n/storage, which stops n8n from starting if both folders exist.

We checked each case on November 2, 2026: on n8n 2.45.7 (the current stable release) with a fresh install, an older install that still uses binaryData, and in-memory mode, and on the 3.0.1 beta with the same data.

The short version

• Default: filesystem on a single instance, database in queue mode, per the 2.46.3 source. Some n8n docs pages still say the default keeps data in memory; that's out of date.
• Folder: new installs use ~/.n8n/storage. Installs that still have ~/.n8n/binaryData keep using it on 2.x, with a deprecation warning at startup.
• n8n 3.0: renames binaryData to storage on first start, and refuses to start if both exist. N8N_DEFAULT_BINARY_DATA_MODE=default (in memory) is ignored and n8n falls back to filesystem.
• What to do now: mount the whole /home/node/.n8n folder (not just binaryData), make sure only one of the two folders exists, and remove N8N_DEFAULT_BINARY_DATA_MODE=default if you set it.

The binary data modes

Why the default moved away from memory: n8n's binary data docs warn that keeping binary data in memory "can cause crashes when working with large files." n8n's 2.0 breaking changes made filesystem the default in regular mode and database in queue mode.

Queue mode

n8n's docs say filesystem mode isn't supported with queue mode, because workers and the main instance don't share a disk. The source sets database as the default when EXECUTIONS_MODE=queue, so you only need to act if you want S3 instead.

S3 (Business and Enterprise)

Per n8n's external storage docs, S3 needs a licensed Business or Enterprise instance ("n8n won't start in s3 binary data mode without a valid license"), isn't available on n8n Cloud, and is configured with:

services:
  n8n:
    environment:
      - N8N_DEFAULT_BINARY_DATA_MODE=s3
      - N8N_EXTERNAL_STORAGE_S3_HOST=s3.us-east-1.amazonaws.com
      - N8N_EXTERNAL_STORAGE_S3_BUCKET_NAME=<your-bucket>
      - N8N_EXTERNAL_STORAGE_S3_BUCKET_REGION=us-east-1
      - N8N_EXTERNAL_STORAGE_S3_ACCESS_KEY=<access-key-id>
      - N8N_EXTERNAL_STORAGE_S3_ACCESS_SECRET=<secret-access-key>

n8n leaves pruning of S3 data to the bucket, so the docs call a lifecycle rule that deletes old objects "required unless you want to preserve binary data indefinitely." The docs mention S3-compatible services such as Cloudflare R2 and Backblaze B2, but say n8n doesn't officially support them.

What we saw on n8n 2.45.7

We ran a published workflow (Webhook, then Convert to File) that creates a file on every run, in Docker with the data volume mounted at /home/node/.n8n.

• Fresh install: with no binary data settings, n8n wrote the file to disk at ~/.n8n/storage/workflows/<workflow-id>/executions/<execution-id>/binary_data/, next to a .metadata file. There was no binaryData folder.
• Older install with binaryData: when ~/.n8n/binaryData already existed, 2.45.7 kept writing there and logged at startup:

Deprecation warning: The storage directory "/home/node/.n8n/binaryData" will be renamed to "/home/node/.n8n/storage" in n8n v3. To migrate now, set N8N_MIGRATE_FS_STORAGE_PATH=true. If you have a volume mounted at the old path, update your mount configuration after migration.

• In-memory mode: with N8N_DEFAULT_BINARY_DATA_MODE=default, new runs wrote nothing to disk, and the startup log listed the variable under deprecations: "In-memory binary data storage (default mode) will be removed in a future version."

What n8n 3.0 changes

n8n's 3.0 breaking changes page lists two binary data changes. We started the 3.0.1 beta on copies of the same data to see them.

The storage folder is renamed

On first start, 3.0 renames ~/.n8n/binaryData to ~/.n8n/storage. On our older-layout copy, 3.0.1 did this silently: the instance came up, and binaryData was gone, replaced by storage.

If both folders exist, 3.0 doesn't guess. Our copy with both folders stopped with:

StoragePathError: Both /home/node/.n8n/binaryData and /home/node/.n8n/storage exist, so n8n cannot tell which one holds your data. Move the contents of /home/node/.n8n/binaryData into /home/node/.n8n/storage, remove /home/node/.n8n/binaryData, then start n8n again.

How both folders end up existing: a volume mounted directly at binaryData plus an empty storage folder, or a backup restored next to a newer folder. The Migration Report on 2.x checks for this ("Both storage directories exist") and for a pending rename ("Storage directory will be renamed"), according to the 2.46.3 source. Our Migration Report guide covers how to read it.

In-memory mode is ignored

On 3.0.1, N8N_DEFAULT_BINARY_DATA_MODE=default no longer counts. The instance still started, logged Invalid value for N8N_DEFAULT_BINARY_DATA_MODE ... received 'default'. Falling back to default value., and wrote the next run's file to ~/.n8n/storage. That matches the breaking changes page: instances on default "switch to filesystem on upgrade." Make sure the disk behind your data volume has room for it.

How to get ready

1. Check your setting. If N8N_DEFAULT_BINARY_DATA_MODE=default is in your environment, change it to filesystem (or database in queue mode) now, and watch disk usage for a few days.
2. Check your folders. docker compose exec n8n ls /home/node/.n8n. If you see only storage, there's nothing to do. If you see only binaryData, it will be renamed on the 3.0 upgrade. If you see both, merge them before you upgrade.
3. Rename early if you like. On 2.x, N8N_MIGRATE_FS_STORAGE_PATH=true renames binaryData to storage now. If storage already exists, 2.45.7 refuses with Failed to migrate ... because /home/node/.n8n/storage already exists, the same conflict 3.0 stops on.
4. Fix volume mounts. If you mount a volume directly at /home/node/.n8n/binaryData, mount the whole /home/node/.n8n instead, or mount the volume at storage, or set N8N_STORAGE_PATH to the old path, as the breaking changes page suggests. Don't set N8N_STORAGE_PATH and the older N8N_BINARY_DATA_STORAGE_PATH to different values: the 2.46.3 source rejects that combination at startup.
5. Back up both the database and the data folder before the upgrade. Our one-way upgrade guide has the steps.

Binary data is pruned together with execution data, per n8n's docs, so EXECUTIONS_DATA_MAX_AGE and related settings also decide how long files stay on disk. If you're still on an npm install, switch to Docker first; our Docker Compose guide mounts the whole data folder, which avoids the mount problem above.