Deploy a local Lore Server¶
loreserver is the server component of the Lore version control system. It's the centralized source of truth for your repositories. The endpoint your team pushes to, clones from, and resolves conflicts through.
In this guide, you'll deploy local Lore Servers — with durable storage and a config you can tailor to your needs — using multiple deployment methods, so your team has a reliable place to land their work.
Prerequisites¶
- The
loreCLI on your PATH. See Install the Lore CLI. - Ports
41337(both TCP and UDP) and41339(TCP) free on the host. - OpenSSL, to generate the self-signed certificate.
Choose a path¶
The binary and Docker paths are mutually exclusive, and each is complete on its own — follow one top to bottom.
- Run from the binary: Fewer moving parts and native performance. Pick this to run
loreserverdirectly on the host. - Run with Docker: An isolated container. Pick this if you'd rather not put a binary on the host — but note the
linux/amd64emulation caveat on Apple Silicon in the build step.
Run from the binary¶
-
Get the binary.
Download the release build for your platform:
-
Run it with default settings.
Start the server:
Note
These are the default install locations. If you passed
--install-dir/-InstallDir(orLORE_INSTALL_DIR) when running the install script, use that path instead.Executed like this and with no config: The server runs in the foreground. It listens on port
41337for QUIC and gRPC (QUIC on UDP, gRPC on TCP) and on port41339for HTTP. It runs using a self-signed certificate regenerated on each restart, and stores the mutable and immutable stores in a temporary directory that the OS will clear on reboot. Great for a proof of concept or a demo, but not somewhere you want to store anything important.When done, stop the server (
Ctrl + C) and proceed to Step 3. -
Make it persistent.
At a minimum, a persistent Lore server needs its mutable and immutable stores written to a real location and a QUIC certificate that survives restarts. You can define both configurables in a
local.tomlconfig file that the server layers over its default configs.Create the server directory layout:
Generate a self-signed certificate valid for
localhost:Create the config file:
Create
/opt/loreserver/config/local.toml:Create
C:\loreserver\config\local.toml:This is the minimal recommended config for a persistent Lore server: it targets a persistent path for both stores and replaces the ephemeral QUIC certificate with your own.
With the config now defined, start the server and pass in the location of the config directory:
Note
For the full set of loreserver configurables and the
local.tomlfield reference, see the Lore Server config reference.
Run with Docker¶
-
Build the image.
This needs Docker (and WSL2 on Windows) and the Lore repository cloned locally. Building the image compiles the server, so it needs several GB of free RAM. From the repository root:
Note
On Apple Silicon or Windows (both arm64 and amd64), build and run with
--platform linux/amd64as shown. Thelinux/arm64server image targets AWS Graviton3 (SVE), an instruction set those CPUs lack. -
Run it with default settings.
Map both the TCP and UDP sides of port
41337and the HTTP port41339:The image stores data under
/datainside the container and generates an ephemeral certificate, so it starts with no config of its own and runs with auth disabled. Like the binary's defaults, this is meant to be a throwaway instance: the certificate is ephemeral, and the container data is lost when the container is removed. -
Make it persistent.
At a minimum, a persistent Lore server needs its mutable and immutable stores written to a real location and a QUIC certificate that survives restarts. The built container image is already configured to store loreserver data under
/dataand load additional loreserver config files from/etc/lore/config. To make it persistent: create a Docker volume for/dataso store data survives container removal, generate a QUIC certificate on the host, and create alocal.tomlthat points loreserver at it — then bind-mount both into the container.Generate a self-signed certificate valid for
localhost:Create a
local.tomlthat points the QUIC endpoint at it — the image already stores data under/data, so the certificate is the only loreserver config override you need:Stop the throwaway container, then run again with the certificate, the overlay, and a host directory mounted for the data:
docker stop lore-server && docker rm lore-server docker run -d --name lore-server \ -p 41337:41337/tcp \ -p 41337:41337/udp \ -p 41339:41339 \ -v "$PWD/cert.pem:/etc/lore/cert.pem:ro" \ -v "$PWD/key.pem:/etc/lore/key.pem:ro" \ -v "$PWD/local.toml:/etc/lore/config/local.toml:ro" \ -v ~/lore-data:/data \ lore-serverdocker stop lore-server; docker rm lore-server docker run -d --name lore-server ` -p 41337:41337/tcp ` -p 41337:41337/udp ` -p 41339:41339 ` -v "${PWD}/cert.pem:/etc/lore/cert.pem:ro" ` -v "${PWD}/key.pem:/etc/lore/key.pem:ro" ` -v "${PWD}/local.toml:/etc/lore/config/local.toml:ro" ` -v "$env:USERPROFILE\lore-data:/data" ` lore-serverYour data now persists in the mounted host directory and the certificate is stable across restarts. For everything else you can put in
local.toml, see the Lore Server config reference.
Check the server is healthy¶
The same probe works for both paths. In a second terminal:
A healthy server returns HTTP/1.1 200 OK with an empty body.
See also¶
- Install the Lore CLI — get
loreon your PATH. - Quickstart — the full core loop using
lorecli with a local server. - Lore Server config reference — every config field plus the multi-host, replication, auth, and plugin-backend surfaces this guide omits: the path to production.