Self-host Leera: installation, setup, and the next steps

Self-hosting should begin with a clear installation path and a plan for operating the result. Leera provides a bundled deployment and initial setup wizard. The time required depends on image downloads, the host, DNS, and service configuration; treat a working production instance as a verified outcome rather than a fixed number of minutes.

Prepare the server and hostname

The documented setup needs a Linux host with root or sudo access, at least 2 GB RAM and 25 GB disk, and ports 80 and 443 available for the bundled proxy. The README’s AI-assisted provisioning example starts with 2 vCPU and 4 GB RAM. Measure actual use before sizing a larger installation.

For HTTPS, wait until the domain’s DNS A record resolves to this server before installing: certificates are requested on first start. Docker is not a prerequisite. The installer offers to install Docker Engine and the Compose plugin if they are missing. Review the public self-hosted README and installation script before running it with administrative privileges.

Choose an installation path

With terminal access to your server, copy and run the documented installer:

curl -fsSL https://raw.githubusercontent.com/leera-app/leera-selfhost/main/install.sh | bash

Enter your domain when prompted for automatic HTTPS. Leave it blank only for a local or LAN evaluation over plain HTTP. Image downloads can take a few minutes. The installer stores the application configuration in ~/leera, including the .env file that holds instance secrets.

For an unattended install, replace pm.example.com with your domain after its DNS record is live. This also approves installing Docker when it is missing:

LEERA_DOMAIN=pm.example.com LEERA_INSTALL_DOCKER=yes bash -c "$(curl -fsSL https://raw.githubusercontent.com/leera-app/leera-selfhost/main/install.sh)"

An AI agent with terminal access can follow the same process. Copy the complete installer prompt for Codex, Claude Code, Cursor, or another compatible agent. The prompt covers AWS, GCP, an existing server, or local evaluation; it asks for approval before paid resources or DNS changes, keeps secrets out of chat, and verifies HTTPS before handing over the instance.

Know what is running

The standard deployment includes the Next.js web app, Rust API, schema migrator, PostgreSQL, SeaweedFS object storage, and Caddy reverse proxy. Redis is not a prerequisite for this bundle.

The bundled reverse proxy routes the public origin to the right service. When an existing nginx or another proxy already owns ports 80 and 443, use the installer’s external-proxy mode and forward all requests to bundled Caddy at 127.0.0.1:8080. Keep Leera’s routing there; duplicating individual API, MCP, storage, or streaming routes in your own proxy can break them. Your proxy handles TLS in this mode, and inbound project email is not supported. Follow the README’s external-proxy instructions.

Complete setup and required services

Open the URL printed by the installer and create your account immediately: the first account created becomes the instance administrator. Complete the setup wizard and confirm the instance URL. Registration is optional for core manual workflows; AI creation of issues, test cases, and projects requires free registration and follows the instance license allowances. Standard Self Hosted uses Leera branding. White-label Self Hosted and Enterprise hide the Leera name and vendor links, apart from the sidebar’s desktop app download (server releases after 1.3.0), which names Leera Self-Hosted on every self-hosted plan once the desktop apps are released; the AI lotus icon stays the same across all plans. Review custom branding entitlements on the current pricing page.

Configure SMTP for notifications and test delivery. Standard Self Hosted can use the configured Leera relay for invitations and login codes when enabled and available, or your own mail service. White-label and Enterprise require instance SMTP and never use that relay. Review that choice if the deployment has network restrictions.

AI features need a configured provider and enabled model. Follow the configuration path supported by the installed version. Self-hosting the application does not mean an external model provider or connected AI client processes data on the same server.

Back up the whole recovery set

Keep the matching database dump, secret key, and environment configuration together, plus object storage for uploaded files. A database dump without its corresponding key cannot recover encrypted settings correctly. Copy backups away from the instance and test a restore on a separate host.

cd ~/leera && ./install.sh --backup

The backup includes leera.dump, secret_key, .env, and a best-effort copy of storage/. Check that uploads were captured and copy the entire directory off the server. To restore a copied backup on your recovery host, replace /path/to/backup with its directory:

cd ~/leera && ./install.sh --restore /path/to/backup

Upgrade and check the instance

Review the backup and upgrade workflow before maintenance. The README’s upgrade command takes a pre-upgrade backup, pulls images, applies migrations, and restarts the stack:

cd ~/leera && ./install.sh --upgrade

Image rollback and data restoration are different operations; database migrations are not automatically undone by returning to an older image. Keep enough disk space for both old and new images; the updater refuses to start with less than 3 GB free.

Check the reported version and container status after installation or an upgrade:

cd ~/leera && ./install.sh --status

Inspect application logs when diagnosing a problem:

cd ~/leera && docker compose logs -f api web

Make someone responsible for the service

Document the operator, backup location, recovery procedure, and maintenance routine. Keep the standard self-hosted API at one replica because its realtime hub runs in process. Teams with Kubernetes requirements can review the repository’s Helm guidance and the operating responsibilities that remain.

The detailed deployment and operations guide covers evaluation, external connections, restoration, and the checks to complete before inviting the whole team.