Running in production

This page builds on the Install compose file.

UpdatingCopy Anchor Link

Pull the new images and recreate the containers:

docker compose pull
docker compose up -d

The API applies database updates on start, so there is no separate upgrade step. To stay on a specific version, set LOMIRI_TAG in .env to a release such as 1.2.3 (exact) or 1.2 (latest patch of 1.2). latest follows the newest release.

Connecting Wings nodesCopy Anchor Link

1. In Admin → Nodes, add a node with its domain name and resources.
2. Open the node. The Registration section lists what Wings needs: the node's UUID, the remote (your panel URL), the token ID and the token.
3. On the node, with Wings installed, write /etc/pelican/config.yml from those values and the node's daemon settings, then restart Wings.

debug: false
uuid: <UUID>
token_id: <Token ID>
token: <Token>
api:
  host: 0.0.0.0
  port: 8080 # Daemon port
  ssl:
    enabled: true # false when the node is behind a proxy or uses http
    cert: /etc/letsencrypt/live/node1.example.com/fullchain.pem
    key: /etc/letsencrypt/live/node1.example.com/privkey.pem
  upload_limit: 256 # Upload limit (MiB)
system:
  data: /var/lib/pelican/volumes # Base path
  sftp:
    bind_port: 2022 # SFTP port
remote: https://panel.example.com

systemctl restart wings

Once the node shows as online, create allocations for it and you're ready to deploy servers.

Using your own reverse proxyCopy Anchor Link

If you already run Traefik, nginx or another proxy, delete the caddy service (and its configs and volumes) from the compose file, publish the two containers on local ports, and route your domain like this:

• /api/* → the api container. Wings and API integrations call these paths.
• Everything else → the web container.

  api:
    ports:
      - "127.0.0.1:3000:3000"
  web:
    ports:
      - "127.0.0.1:3001:3000"

An nginx server block for that layout:

server {
    server_name panel.example.com;
    # listen 443 ssl; + your certificate settings

    location /api/ {
        proxy_pass http://127.0.0.1:3000;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }

    location / {
        proxy_pass http://127.0.0.1:3001;
        proxy_set_header Host $host;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

lomiri trusts X-Forwarded-For only from the proxies in TRUSTED_PROXIES. The default (loopback and private ranges) covers a proxy on the same machine or Docker network. If your proxy connects from a public address, list it there. See Configuration.

Scaling outCopy Anchor Link

Both containers are stateless, so you can run several replicas of each. Set scale on the api or web service and apply it:

  api:
    scale: 3

docker compose up -d

The bundled Caddy spreads requests across every replica. Background work is coordinated through the database, so only one API replica handles each job.

Backing upCopy Anchor Link

Everything lomiri knows lives in Postgres. Game server files live on your nodes, and their backups go wherever you point them (the node, or S3). Dump the database regularly:

docker compose exec -T postgres pg_dump -U lomiri lomiri | gzip > lomiri-$(date +%F).sql.gz

Restore into a fresh stack with gunzip -c backup.sql.gz | docker compose exec -T postgres psql -U lomiri lomiri before starting the API.