From download to file server.

Before you start

Plan three things before you run a file server: where the files live, where FileYard’s metadata lives, and how both will be backed up. A reverse proxy and TLS should sit in front of any instance exposed beyond a trusted network.

You will need:

• A Linux host or compatible container environment.
• A directory dedicated to the files FileYard may access.
• Persistent storage for the database and application state.
• A current, independently tested backup of important data.

Docker Compose

Docker Compose will be the shortest supported path once the container image and runtime contract are published. From the directory containing the project’s verified Compose file:

docker compose up -d

The final Compose example must come from the source repository. It will document the real image name, listen port, health check, user mapping, and required volume paths. This site does not invent those values.

When that file is available, review it before starting:

1. Bind the file library to the intended host directory.
2. Keep database and application state on persistent volumes.
3. Set generated secrets through the supported environment or secret mechanism.
4. Confirm the container user can read and write only the intended paths.
5. Put a TLS-terminating reverse proxy in front of public access.

Single binary

FileYard is designed to run as one Go binary. The binary deployment avoids a container layer and fits well with systemd, a dedicated service account, and explicit filesystem permissions.

The release page will provide checksums and supported architectures when binaries are published. A production service definition should use the exact flags from the same release rather than copying an unversioned example.

Configuration

Configuration is expected through command-line flags and environment variables. Keep secrets out of shell history and source control. Prefer a protected environment file, system credential mechanism, or container secret.

The configuration reference will cover:

• Listen address and public URL.
• File and application-state paths.
• SQLite or PostgreSQL connection settings.
• SMTP for email delivery and email-based two-factor authentication.
• Optional OIDC identity-provider settings.
• Proxy awareness, IP allowlists, and trusted headers.
• Logging and retention choices.

Database choices

SQLite is the straightforward default for one server and a modest number of users. It keeps operations simple and makes the metadata store easy to locate.

PostgreSQL is optional for deployments that already operate it or need its operational characteristics. Switching databases does not move the underlying file library.

Back up and restore

A complete backup has two coordinated parts:

1. The ordinary file directories managed by FileYard.
2. The metadata database and application state for accounts, shares, settings, and history.

Quiesce writes or use the project’s supported export procedure so the two parts describe a consistent point in time. A backup is only complete after a restore has been tested on a separate path.

Update safely

Read release notes, create a fresh backup, and test the new version against a non-critical copy first. If a release includes a metadata migration, do not assume downgrading the binary will also reverse that migration.