Deploy & Host LFSX | (Just Updated) Git LFS Server for GitHub, GitLab, Gitea and Forgejo, Repo Allowlist

Deploy and Host LFSX on Railway

Built for an LLM agent to deploy and use. The deploy form has no fields to fill and a fresh deploy is locked down: it serves no repository at all until you set which ones. LFSX is an open-source, self-hosted Git LFS server for GitHub, GitLab, Gitea and Forgejo. Your Git clients keep pushing large files with their normal forge token, and the objects land on a Railway volume you own.

About Hosting LFSX

This template runs one service, lfsx: a single Rust binary with no database, storing LFS objects on a volume mounted at /var/lib/lfsx. LFSX has no user accounts. A client sends the token it already uses to clone, and the server asks the forge what that token may do on the repository, so the forge stays the only place permissions are managed.

Locked by default. Upstream serves every repository on the forge unless LFSX_ALLOWED is set, which on github.com means anyone with an account could store files on your disk. This template generates LFSX_ALLOWED as a random owner that no account has, so every repository answers 404 until you replace it with your own list, such as acme/* or acme/assets,partner/media. The metrics page is moved to private port 9090, so /metrics answers 404 on the public domain.

Using it. Set LFSX_ALLOWED to your repositories, then in a clone run git config lfs.url https://YOUR_DOMAIN/acme/assets (or set it in .lfsconfig) and push as usual. GitHub is the default forge. For GitLab, Gitea or Forgejo add LFSX_AUTH (gitlab, gitea) and the forge API address (LFSX_GITLAB_API_URL or LFSX_GITEA_API_URL) to the service.

Agent contract

Public URL: https://RAILWAY_PUBLIC_DOMAIN (the generated domain of the lfsx service; also in the variable LFSX_PUBLIC_URL)
Private URL: http://lfsx.railway.internal:8080
Credentials: a personal access token from your own forge (not template variables)
Auth: the template variable LFSX_ALLOWED decides which repositories are served; send the forge token as the Basic auth password (any username) or as a Bearer token on /{org}/{repo}/...; a request without a token or with a wrong token answers 401, and a repository outside LFSX_ALLOWED answers 404
Health: GET /health returns 200 (GET /ready too)

#!/bin/sh
# needs: LFSX_PUBLIC_URL and LFSX_ALLOWED (variables of the lfsx service); also curl
H="Content-Type: application/vnd.git-lfs+json"
B='{"operation":"upload","transfers":["basic"],"objects":[{"oid":"b94d27b9934d3e08a52e52d7da7dabfac484efe37a5380ee9088f7ace2efcde9","size":11}]}'
R="${LFSX_ALLOWED%%,*}"; R="${R%\*}probe"
curl -s -w "\nhealth: %{http_code}\n" "$LFSX_PUBLIC_URL/health"
curl -s -o /dev/null -w "metrics on the public port: %{http_code}\n" "$LFSX_PUBLIC_URL/metrics"
curl -s -o /dev/null -w "repository not on the allowlist: %{http_code}\n" -X POST -H "$H" -d "$B" "$LFSX_PUBLIC_URL/not-allowed/probe/objects/batch"
curl -s -o /dev/null -w "write without key: %{http_code}\n" -X POST -H "$H" -d "$B" "$LFSX_PUBLIC_URL/$R/objects/batch"
curl -s -o /dev/null -w "write with wrong key: %{http_code}\n" -u "x:wrong-token" -X POST -H "$H" -d "$B" "$LFSX_PUBLIC_URL/$R/objects/batch"

A fresh deploy prints ok, health: 200, metrics on the public port: 404, repository not on the allowlist: 404, write without key: 401 and write with wrong key: 401. After you set LFSX_ALLOWED to your own repositories, a request with a valid forge token to POST /{org}/{repo}/objects/batch answers 200 with upload links.

Why Deploy LFSX on Railway?

Railway is a singular platform to deploy your infrastructure stack. Railway will host your infrastructure so you don't have to deal with configuration, while allowing you to vertically and horizontally scale it.

By deploying LFSX on Railway, you are one step closer to supporting a complete full-stack application with minimal burden. Host your servers, databases, AI agents, and more on Railway.

Agent-ready - no deployer fields, a contract block and one script that proves health, the refusals and the allowlist.
Locked by default - no repository is served until you list yours in LFSX_ALLOWED.
Data survives redeploys - objects sit on a volume at /var/lib/lfsx.
Pinned - the upstream image is pinned by digest.
No per-gigabyte LFS pricing - store large files for GitHub, GitLab, Gitea or Forgejo repositories on your own volume.

Common Use Cases

Large binaries for a Git repository - game assets, design files, datasets and models without the forge's LFS quota.
A shared LFS store for CI - build agents push and fetch artifacts with their existing forge tokens.
Self-hosted forge storage - give a Gitea or Forgejo instance a separate LFS endpoint.
Moving off paid LFS bandwidth - point lfs.url at your own domain.

Dependencies for LFSX Hosting

The lfsx service with a volume, created by the template. A custom domain is optional.

Deploy LFSX | (Just Updated) Git LFS Server for GitHub, GitLab, Gitea and Forgejo, Repo Allowlist