lastlight-server

Install & configure a Last Light server

A Last Light server runs the agent and a docker-compose stack on a host. It needs: Docker, a GitHub App (so it can act on repos), a model provider API key, and a list of repos it's allowed to manage. Configuration lives in a private overlay at instance/ (a config.yaml plus secrets/.env + secrets/app.pem).

Your job: gather the inputs, get the working directory in place, write the config, then build and launch. Prefer the deterministic file-writing path below (fully automatable) over the interactive wizard.

1. Check prerequisites

Run these and report anything missing before continuing:

docker info >/dev/null 2>&1 && echo "docker: ok" || echo "docker: NOT running"
git --version; node --version
command -v lastlight >/dev/null && lastlight --help >/dev/null 2>&1 && echo "lastlight: installed" || echo "lastlight: missing"

• Docker must be running.
• If lastlight is missing: npm i -g lastlight.

2. Gather inputs from the user

Ask for each of these (don't guess). Group the questions; explain what each is for.

Required

• GitHub App — App ID, Installation ID, and the path to the App's private key .pem file. (If they don't have a GitHub App yet, point them at GitHub → Settings → Developer settings → GitHub Apps; it needs webhook + repo contents/issues/pull-requests/checks permissions, plus workflows (read & write) so it can merge/push PRs that touch .github/workflows/ — e.g. dependency PRs bumping GitHub Actions versions. Recommend actions (read) too — a different permission from workflows: it lets the fix workflow read the actual Actions job logs instead of only check annotations. It is optional, so an app without it still works; the CI evidence is just weaker, and the prompt says so. Recommend commit statuses (read) as well — again distinct from checks: it covers the classic statuses external CI posts (CircleCI, Jenkins), and without it CI is judged on check runs alone. They install it on their repos to get the Installation ID.)
• Domain — the public hostname for webhooks/dashboard, e.g. lastlight.example.com. Ask whether to use the bundled Caddy for automatic TLS (default yes). The GitHub App webhook URL will be https://<domain>/webhook.
• Managed repos — one or more owner/repo the bot is allowed to act on. The bot ignores any repo not listed.
• State database — SQLite (recommended, the default) or an external Postgres. SQLite is a file in the agent-data volume with nothing to run; answering it writes no config at all, which is deliberate (the slot resolving by absence is what lets STATE_DIR move the file). Choose Postgres only if the user already has a server — then they supply a postgres://user:pass@host:port/db URL, which the wizard writes to the gitignored instance/secrets/.env and never to instance/config.yaml (that file becomes a GitHub repo at the end of setup). The driver is detected from the host, not asked (*.neon.tech → Neon's serverless driver, else node-postgres). The wizard only TCP-probes the host; run lastlight server db check after the build for the full credential check. An existing SQLite deployment can move across later with lastlight server db migrate — no need to decide now.
• Model — a provider/model string (default anthropic/claude-sonnet-4-6), plus the matching provider's API key. Last Light is multi-provider: the provider/ prefix picks the provider and the model id follows, e.g. anthropic/claude-sonnet-4-6, openai/gpt-5.5, google/gemini-2.5-pro, openrouter/anthropic/claude-sonnet-4.5. Set only the one API-key env var that matches the provider you chose. Common ones:
  • anthropic/… → ANTHROPIC_API_KEY (sk-ant-…)
  • openai/… → OPENAI_API_KEY (sk-…)
  • openrouter/… → OPENROUTER_API_KEY (sk-or-…) — aggregator, reaches Anthropic/Google/xAI/… models through one key
  • google/… → GEMINI_API_KEY, mistral/… → MISTRAL_API_KEY, groq/… → GROQ_API_KEY, xai/… → XAI_API_KEY, deepseek/… → DEEPSEEK_API_KEY, and more (Cerebras, Hugging Face, Moonshot, NVIDIA, Fireworks, Together, Z.AI, Kimi, MiniMax).