Docker — Blixt

Before you install

Configure at least one bucket and make sure your credentials are working. See the documentation from your cloud provider for details. Here's our quick starter guide.

If mounting with NFS or SMB, make sure the client software is installed:

macOS — NFS and SMB are installed by default.
Linux — install NFS tools (nfs-common) or SMB tools (cifs-utils).
Windows — SMB is available by default. For NFS, enable the NFS client in Windows Features.

Install Docker and download image

Install Docker.
Pull the latest image from Docker Hub. Our images support both Intel and ARM architectures.
```
docker pull blixtfs/standard:latest
```

Configure your setup

Fill in the fields below and the commands will update automatically.

Data directory Local path for cached metadata, data, and logs. Must be outside the Docker filesystem. For production, use a separate disk. Bucket(s) One or more buckets, space-separated.

s3:// — AWS S3
gs:// — Google Cloud Storage
azure:// — Azure Blob Storage
oci:// — Oracle Object Storage
r2:// — Cloudflare R2
minio:// — MinIO

Credentials file (optional) Path to a credentials file on your host. Leave empty if using environment variables, GCE/GKE default credentials, or gcloud application default credentials. See our guide for details. Cloudflare R2 takes no credentials file. Fill in the fields below instead — they become -e environment variables on the command.

Cloudflare R2 credentials (optional)

R2 has no credentials file, so these are passed to the container as environment variables. Anything you leave empty is left off the command. Nothing here leaves your browser — the command is assembled on this page.

Account ID From the R2 overview page. The S3 endpoint is derived from it, and setting it turns the R2 backend on. API token Only for change notifications, and a different credential from the keys below. Needs Account:Queues (Edit) and Account:Workers R2 Storage (Edit). Access key ID The R2 API token's S3 access key ID. Secret access key Its secret access key. Keep the finished command out of shell history and version control.

Run the container — command line

Everything on one command. Good for a first run and for throwaway containers.

docker run -d --name blixt \
  -p 2049:2049 \
  -v /tmp/data:/data \
  blixtfs/standard:latest s3://my-bucket

Run the container — YAML configuration

A deployment you intend to keep is easier to manage as a file. Save the following as config.yaml in your data directory, where the container reads it as /data/config.yaml:

The command then carries the mounts and nothing else:

Settings are read from the file first, then the environment, then the command line, so each layer overrides the one before it. That is the escape hatch for secrets: leave the R2 keys out of the file and pass them as -e CLOUDFLARE_ACCESS_KEY=... on the command instead. A file that does hold them is worth a chmod 600 and a place outside version control.

Mount the share

Mount the share from any client using NFS.

macOS — use the noresvport option for user-initiated mounts:

mount -t nfs -o vers=4,noresvport localhost:/ MOUNT_POINT

Linux: