/data volume. This is a distributed filesystem that is shared across all your apps and runners, linked to your fal account. Files written to /data persist between requests, across runner restarts, and across deployments. Use it to store model weights, datasets, configuration files, and any other data your apps need.
The /data volume is the primary mechanism for avoiding repeated downloads during cold starts. When a new runner starts and calls setup(), it can load model weights from /data instead of downloading them from scratch. Because the volume is backed by a multi-layer cache (local NVME, distributed datacenter cache, and a global object store), subsequent reads are fast even on fresh nodes. For downloading files and model weights to /data, see Downloading Models and Files.
Using /data in Your App
The /data directory is automatically mounted on every runner. Files you write there persist until you delete them. A common pattern is to check whether a file already exists before downloading it, so that only the first runner pays the download cost.
/data. Subsequent invocations, even those on new runners after the previous one shut down, skip the download and load directly from the cached files.
For HuggingFace libraries, fal automatically sets
HF_HOME to /data/.cache/huggingface, so all downloaded models from transformers, diffusers, and huggingface_hub are persisted without any extra configuration./data is shared across all runners, you should be careful when multiple runners write to the same path simultaneously. The recommended pattern is to write to a temporary file beside the final destination, then use os.rename to move it into place. This makes the operation quasi-atomic and prevents other runners from reading an incomplete file.
from_pretrained() calls do), the sequential loading process does not take full advantage of the filesystem’s parallel capabilities. You can speed it up significantly by pre-reading all the files in parallel before loading, which forces chunks into the local cache:
Uploading Files to /data
Outside of a running app, you can upload files to /data through the dashboard, CLI, REST API, or a one-off function.
The Dashboard > Files page provides a visual interface for dragging and dropping files, uploading from URLs, organizing folders, and managing your stored files.
From the CLI, use fal files commands:
/data before deploying your app), use a @fal.function that writes directly to the filesystem:
/data, so the downloaded file is immediately available to all your apps.
How It Works
The/data volume is mounted at the same path on every runner in your account. It is eventually consistent, meaning that a file written by one runner may take a moment to appear on another runner in a different datacenter, though within the same datacenter propagation is nearly instant.
Under the hood, each file is split into 4MB chunks identified by their hash and saved to a global object store. A metadata layer tracks the mapping between file paths and chunks, making operations like renames atomic and fast. The volume features two caching layers: a local cache on the node using RAID 5 NVME drives (10-15 GB/s), and a distributed cache across all servers in the datacenter using a 100 Gbps network (6-8 GB/s). A cache miss at both levels falls through to the backing object store (1.5-8 GB/s). This is why parallel reads are so much faster than sequential ones: each chunk can be fetched from a different cache node simultaneously.
When your app generates output files (images, videos, audio) and returns them through
fal.toolkit.Image or fal.toolkit.File, those are uploaded to fal’s CDN and returned as public URLs. CDN files are separate from /data storage. To control how long CDN files are retained, see Media Expiration. For small key-value data (configuration, cached API responses, session state), fal also provides KVStore which offers faster access for data up to 1.9MB per value.