Self-hosted / Guide
Self-host Leera: installation, setup, and the next steps
Understand Leera’s bundled self-hosted deployment, setup wizard, email configuration, complete backups, and updates before bringing your team onto the instance.
At a glance
Leera’s installer assembles the application and its core services, but installation time depends on the server and network. Prepare a hostname, configure required services, verify a complete backup and restore, and assign an operator before moving production work.
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 uses a Linux host with administrative access and ports 80 and 443 available. A suggested small-team starting point is 2 vCPU, 4 GB RAM, and 20 GB disk; measure actual use before sizing a larger installation.
Point a domain at the server before setup when using the bundled automatic HTTPS configuration. The installer can offer to install Docker Engine and the Compose plugin if they are missing. Review Leera’s deployment overview, the release-specific instructions, and the script before running it with administrative privileges.
Know what is running
The standard deployment includes the Next.js web app, Rust API, schema migrator, PostgreSQL, MinIO object storage, and Caddy reverse proxy. Redis is not a prerequisite for this bundle.
The reverse proxy serves the public origin and routes API requests to the backend. If you use another proxy, also forward /mcp to the API so compatible AI clients can connect. Exposing the website alone does not verify that every route is configured correctly.
Complete setup and required services
The setup wizard confirms the instance URL and creates the instance administrator. Registration is optional in the documented setup; core self-hosted functionality remains available without it. Review branding and other licensed options separately on the current pricing page.
Configure SMTP for notifications and test delivery. Invitations and login codes can use the documented vendor fallback when enabled and available, or your own mail service. 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.
Review the backup and upgrade workflow before maintenance. Updates can be applied through the documented command flow or the optional configured updater. Image rollback and data restoration are different operations; database migrations are not automatically undone by returning to an older image.
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.