Deploy and Host Lore Server on Railway

Lore is Epic Games' open source version control system, built for projects that mix source code with heavy binary assets. It stores everything in a content-addressed Merkle tree, hydrates file content on demand, and keeps branch switching fast even when the repository holds gigabytes of textures, models, and audio.

This template runs loreserver, the central server your team pushes to and clones from, using Epic's latest official Linux release binary (resolved at build time and verified against GitHub's published sha256). It deploys in about a minute.

About Hosting Lore Server

The template deploys three pieces:

lore-server: the Lore server itself
lore-store: a Railway bucket holding your repository content. Bucket storage is $0.015 per GB-month with free egress, and you never resize it.
dynamodb: a DynamoDB-compatible metadata store (fragment, branch, and lock records) with a volume for persistence

This is the same storage split Epic uses in their own AWS setup: payloads in S3, metadata in DynamoDB. The metadata store is amazon/dynamodb-local, which is fine for a small team on a single node; point the server at real AWS DynamoDB later if you outgrow it.

Connect a client

Install the Lore CLI (instructions):

curl -fsSL https://raw.githubusercontent.com/EpicGames/lore/main/scripts/install.sh | bash

Find your server's TCP proxy address in the service's Settings tab under Networking. It looks like mainline.proxy.rlwy.net:12345. Then create your first repository:

mkdir my-project && cd my-project
lore repository create grpc://mainline.proxy.rlwy.net:12345/my-project

Commit and push:

lore stage --scan .
lore commit "First commit"
lore push

Teammates clone the same URL:

lore clone grpc://mainline.proxy.rlwy.net:12345/my-project

Use grpc:// URLs, not lore://

Lore's default lore:// scheme transfers file content over QUIC, which runs on UDP. Railway's proxy routes TCP only, so QUIC packets never arrive. With a grpc:// URL the client sends everything over gRPC on the TCP proxy instead. Same features, one caveat: traffic to the proxy is not TLS-encrypted. There is a Central Station thread discussing UDP support on Railway; if it ships, lore:// should work here too.

Before you invite the team

Authentication is off by default. Anyone with your proxy address can read and write every repository on the server. To require signed JWTs, set LORE__SERVER__AUTH__JWT_ISSUER and LORE__SERVER__AUTH__JWK__ENDPOINT to your identity provider's issuer and JWKS URL. The server config reference covers the details.
Lore is pre-1.0 and under active development. Epic ships new releases often; each build fetches the newest one, so redeploying updates the server.

Common Use Cases

Version control for a game project where textures, models, and audio dwarf the source code
A private Lore server for a small team evaluating Lore before committing infrastructure to it
A test server for building tools against Lore's APIs without touching your main deployment

Dependencies for Lore Server Hosting

Deployment Dependencies

EpicGames/lore: the Lore project and CLI releases
snowfall-games/lore-railway: the Dockerfile this template builds, which fetches Epic's latest release binary and verifies it against GitHub's published sha256
Lore documentation: CLI guides and the server config reference

Why Deploy Lore Server on Railway?

Running Lore yourself normally means a machine, TLS, storage sizing, and a metadata database. This template turns that into one click: repository content lands in a Railway bucket that grows with your project, metadata persists on a volume, and the server config wires itself together with reference variables. Every server setting stays overridable with LORE__-prefixed environment variables, for example LORE__SERVER__HTTP__PORT (boolean and numeric settings belong in TOML config; the env layer only carries strings). The only plain variable the template ships is PORT, which tells Railway's health check to probe the HTTP endpoint on 41339.