Resources · n8n integration

n8n Read/Write Files from Disk nodeConfigure Read/Write Files from Disk in n8n.

The n8n Read/Write Files from Disk node moves files in and out of the machine that runs n8n. It carries 2 operations: one reads a path or a whole pattern, the other writes a binary field back to disk. There is nothing to authenticate, and the paths you are allowed to touch depend on where n8n runs.

Try the Read/Write Files from Disk node on n8nSee the 2 operations

Verified Trustpilot reviews · AI, automation & growth agency

Why automate

What does the n8n Read/Write Files from Disk node actually do?

It reads or writes files from the computer that runs n8n. Reading turns a path, or a pattern that matches many paths, into binary data on the items leaving the node. Writing takes a binary field already sitting on an item and saves it as a real file. The node never starts a workflow on its own: a trigger runs first, then this node runs once for every item that reaches it.

The first scenario is the nightly pickup. A Schedule Trigger fires at dawn, File(s) Selector points at an export folder with a pattern, and every file that matches comes out as its own item, ready to be parsed and pushed into Google Sheets. One expression, a whole folder handled.

The second runs in reverse. An email attachment arrives through the Gmail node, and the write operation saves that binary field under a path built from the item, something like {{ $json.invoiceId }} in the file name. The tool that watches the folder picks it up seconds later, with no API in between.

The third is the rolling log. Two branches join through Merge, the node writes one line per run with Append turned on, and the file grows instead of being replaced. Text files take this well. Structured binary formats do not.

Pick a different node when the file has to survive. This one writes to the filesystem of the machine running n8n, so persistent storage belongs to a cloud storage node such as AWS S3, Google Drive or FTP. And when the file lives behind an HTTP API rather than on a disk, HTTP Request is the right tool, since it reaches any HTTP endpoint but nothing that speaks another protocol.

Now the limits, because they are where workflows break. On n8n Cloud the node only reaches paths under /home/node/; anything outside, /tmp/ or /data/ included, fails with an access error, the field placeholders are just examples to replace, files are not guaranteed to survive an execution, a worker restart or a redeploy, and /home/node/.n8n/ is reserved for n8n itself. Self-hosted, the node reaches whatever the n8n process reaches, unless N8N_RESTRICT_FILE_ACCESS_TO narrows it to a semicolon separated list of directories; starting with n8n 2.0 that variable defaults to ~/.n8n-files, so file operations elsewhere have to be allowed explicitly. In Docker the paths are the container's, not the host's, so host directories need to be mounted as volumes. Absolute paths, as n8n recommends. The n8n review covers how that hosting choice plays out day to day.

Actions

Which parameters does each operation need?

The Read/Write Files from Disk node exposes 2 operations. For each one: the node as you configure it in n8n, the required fields, and our field notes.

01

Read File(s) From Disk

read

What you see in n8n

Notes & use cases

This operation retrieves one or more files from the computer that runs n8n as binary data. One path reads one file, a pattern reads a folder in one pass.

Key parameters

  • File(s) Selector: required, the path or path pattern, forward slashes even on Windows (/home/user/Pictures/**/*.png). * stops at a path separator, ** crosses it.
  • Put Output File in Field: the output binary field holding the file, data by default.
  • File Name and File Extension: the name and the extension carried by the output binary.
  • Mime Type: the MIME type of the output binary, application/zip for an archive.
Use cases
a morning sweep of an inbound folder, every matching CSV handed to the next node as its own item.
02

Write File to Disk

write

What you see in n8n

Notes & use cases

Here the traffic goes the other way. The node takes a binary field already on the item and creates a file with it on the computer that runs n8n, extension included.

Key parameters

  • File Path and Name: required, the destination path plus the file name and its extension (/data/example.jpg), absolute as n8n recommends.
  • Input Binary Field: required, the name of the incoming binary field that holds the file, data in most workflows.
  • Append: on, the content is added to an existing file instead of creating a new one. Common on text files, not applicable to formats with a fixed binary structure.
Use cases
a signed PDF arriving on a webhook, dropped into a folder a local tool already watches.
Need help

Need help automating Read/Write Files from Disk with n8n?

A person reads every message.

FAQ

Questions people ask about this node

01Is the n8n Read/Write Files from Disk node included, on Cloud and self-hosted?
Yes. It is a core node shipped with n8n, so there is no install step and no extra cost on n8n side, on n8n Cloud as well as on a self-hosted instance running the Community Edition under the Sustainable Use license. The workflow itself is identical in both places. What changes between the two is not the node but the filesystem it can reach: Cloud confines it to paths under /home/node/, self-hosted gives it whatever the n8n process can reach, within the directories the N8N_RESTRICT_FILE_ACCESS_TO variable allows.
02What do you need to set up before it runs?
Nothing on the account side. The node has no credential and no Authentication selector, so there is no key to paste, no OAuth screen and no scope to grant. Two things still have to be true. A trigger has to run before it, a Schedule Trigger or a Webhook for instance, because this node reacts to incoming items instead of starting a workflow. And the path has to be reachable by the n8n process: on Cloud, under /home/node/, on a self-hosted instance, inside whatever N8N_RESTRICT_FILE_ACCESS_TO permits.
03What are the limits of this node?
It exposes 2 operations, read and write, and nothing else. Paths are the real constraint. On Cloud, anything outside /home/node/ fails with an access error, the directory /home/node/.n8n/ is reserved for n8n internal state, and files written there are not guaranteed to survive an execution, a worker restart or a redeploy, so nothing you need to keep should live on that disk. Self-hosted from n8n 2.0, N8N_RESTRICT_FILE_ACCESS_TO defaults to ~/.n8n-files. In Docker, paths are the container's, so host folders have to be mounted as volumes.
04When should you use another node instead?
Whenever the file has to outlive the execution. For persistent handling, n8n points to a cloud storage node such as AWS S3, Google Drive or FTP, and that advice matters most on Cloud, where the filesystem is ephemeral. Use this node when the file genuinely belongs to the machine running n8n: a mounted volume, a folder another local tool watches, a temporary working file inside one execution. And when what you are after sits behind an HTTP API rather than on a disk, HTTP Request is the node for it, since it calls any HTTP endpoint but nothing outside HTTP.
05n8n or Make for reading and writing files?
It depends on where the files are allowed to live. Make is a hosted automation platform with no self-hosting option, billed per operation, and its visual logic suits teams who want nothing to run on their own machines. n8n can be self-hosted with Docker or npm, which is exactly what this node assumes: the disk it reads and writes is a disk you control, mounted into the container you chose. If the files are confidential, or if volume would make per-operation billing painful, self-hosted n8n keeps both the data and the cost model on your side.
Hack'celeration Lab

Get our weekly integration tips.

No spam. Unsubscribe anytime.

Same platform

Other docs you might need on this stack.

Browse all integrations