Self-hosted / Project management / Operations
Self-hosted project management: deployment and operations guide
Evaluate and operate self-hosted project management with Leera: deployment requirements, HTTPS, email, AI configuration, complete backups, updates, and ownership.
At a glance
Self-hosting gives a team control over the project application’s infrastructure and an obligation to operate it. Evaluate the deployment alongside email, AI providers, backups, recovery, updates, and access. Leera supplies a bundled deployment; a reliable service still needs a named operator and a tested recovery process.
Self-hosted project management puts the application on infrastructure your organization operates. It gives you deployment control and responsibility for the service people depend on. Evaluate the choice by asking who will install, monitor, update, back up, and recover it, as well as where the data will live.
This guide explains the operational decisions behind self-hosted Leera. It uses the repository’s documented deployment as the product reference. Infrastructure examples are starting points, not capacity guarantees. Check the instructions for the release you intend to install before making production changes.
Decide what control you actually need
Write down the reason for self-hosting. It may be an existing infrastructure policy, a requirement to select a hosting region, integration with an internal network, or a desire to operate the complete application stack. A specific reason makes the trade-off easier to evaluate.
Then identify the service expectations. How long could the team work without the application? How much newly written data could it afford to reconstruct? Who responds if the server fails during a release? Those answers determine backup frequency, recovery preparation, and staffing more directly than the application’s installation time.
| Question | Cloud option | Self-hosted option |
|---|---|---|
| Who operates the application infrastructure? | The service provider, under its offering | Your team or its chosen operator |
| Who chooses the deployment environment? | Within the provider’s available options | Your team, within supported deployment requirements |
| Who performs instance recovery? | The provider manages its service recovery | Your operator needs a complete backup and procedure |
| Where do AI requests go? | Depends on configured product and providers | Still depends on configured providers and clients |
| What costs need review? | Subscription, allowances, and integrations | Hosting, storage, AI, licenses where applicable, and operations |
Neither column establishes compliance or availability on its own. If a contractual requirement drives the decision, verify the actual deployment and service terms that apply instead of treating a hosting label as proof.
Assign an operator before moving real work
Name a primary operator and a backup person. They need access to the server, domain configuration, backup location, and the team’s approved credential store. They also need time to perform maintenance.
Create an ownership note with the instance URL, deployment location, release version, support process, and recovery instructions. Keep enough of that note outside Leera that someone can find it while Leera is unavailable. The same applies to the credentials needed to restore the service.
Set an initial maintenance routine: inspect health, review backup completion, check disk growth, and review available updates. Give each action a responsible person and a clear result. “Operations owns it” becomes difficult to use when the person who installed the service is on leave.
For a trial, make the exit decision explicit. Decide what must be demonstrated before importing or recreating production work: successful login, required collaboration flows, file uploads, email behavior, backup restoration, and recovery ownership.
Understand the bundled deployment
Leera’s standard Compose deployment provides the web app, Rust API, a one-shot schema migrator, PostgreSQL, MinIO object storage, and Caddy as the public reverse proxy. It does not require Redis or a separate managed PostgreSQL service.
The documented starting point for a small evaluation is a Linux host with 2 vCPU, 4 GB RAM, and 20 GB of disk. Measure the actual workload before sizing a larger service. Attachments, activity, database growth, and AI-related work can change resource needs.
The installer can offer to install Docker Engine and the Compose plugin when they are absent. Organizations with a managed server baseline may prefer to install and configure Docker through that process first. Docker publishes its supported installation options in the Engine installation documentation.
Review Leera’s deployment overview, the instructions shipped with your release, and the installation script before executing it with administrative privileges. Record any changes from the supported configuration so future operators understand what they are maintaining.
Establish the public URL and HTTPS
Choose the hostname users will actually open and point its DNS record to the server. The documented setup expects ports 80 and 443 to be available for the bundled reverse proxy. Use the same intended origin when completing the setup wizard, because it affects links and authentication redirects.
Caddy can obtain and renew certificates automatically when the deployment meets its requirements. DNS, network reachability, hostname choice, and challenge configuration matter; automatic HTTPS does not eliminate those prerequisites. Refer to Caddy’s HTTPS documentation when diagnosing certificate problems.
The bundled stack routes application requests through one public origin. The API is not meant to be directly published on a host port. If your organization substitutes another reverse proxy, preserve the routes and security assumptions in the deployment configuration.
In particular, forward both /api and /mcp to the backend. The MCP endpoint is at the root path. Forwarding only /api can make the website appear healthy while AI clients receive a missing-page response from the web app.
Complete setup and verify the essential workflows
The initial setup wizard establishes the instance URL and creates the instance administrator. Registration is optional in the documented setup; skipping it does not disable core self-hosted functionality. Branding and other licensed capabilities should be evaluated separately against the current offering.
Use a small acceptance checklist before inviting the whole team:
- Sign in and confirm the configured origin is correct.
- Create a trial project and verify that another intended member can access it.
- Create and update an issue, then check realtime behavior in another session.
- Upload an attachment and verify that the appropriate member can retrieve it.
- Create a document and review its access settings.
- Check the email and AI workflows the team plans to use.
- Take a backup and complete a separate-host restore drill.
The checklist should reflect your intended use. A team depending on QA needs to exercise a case, plan, run, and result. A team depending on external AI clients needs to test the actual client and authentication flow it will deploy.
Configure email and map external connections
Email deserves a deliberate setup step. In Leera’s documented behavior, notifications require configured SMTP. Invitations and login codes can use a vendor mail fallback when enabled and available; operators can configure their own mail service or refuse the fallback. Test the paths you intend to use.
Review sender configuration and delivery at the recipient’s mailbox, not just a successful test submission. Keep mail credentials in the instance’s supported settings and document who can rotate them. A working login for the initial administrator does not prove that future invitations will arrive.
Map every outbound dependency: mail, model providers, external AI clients, license or update services where used, storage alternatives, and any integrations you enable. The map should say what information is sent and why. Avoid describing a self-hosted deployment as having no external traffic until the actual configuration has been examined.
AI features need a configured provider and enabled model. The available setup controls depend on the installed version and administrator access. Core non-AI workflows do not become dependent on a model merely because the application offers AI assistance.
Treat the backup as a complete recovery set
A database dump alone is insufficient for a complete Leera recovery. Preserve the matching secret key and environment configuration with the database, and back up object storage for uploaded files. The secret key is required to decrypt stored credentials and preserve the corresponding authentication setup.
The documented backup command, run from the installation directory, is:
./install.sh --backup
The backup directory includes the database dump, secret key, environment file, version information, and storage when captured successfully. Verify those outputs. Copy the completed set to a separate protected location so a server failure does not remove both the application and its only backup.
PostgreSQL supports logical backups while the database is in use; its SQL dump documentation explains the mechanism and its limits. Application recovery also depends on files and configuration outside PostgreSQL, so a successful database operation is only part of the check.
Define retention and access according to the information in the backup. Anyone who can read the matching environment and key material may have access to sensitive instance credentials. Keep backup access deliberate and ensure the recovery operator can obtain it when needed.
Prove recovery on a separate host
A restore drill is the most direct way to test whether the backup is usable. Prepare a separate host, follow the release-appropriate restore instructions, and restore a copied backup there. Do not test by replacing the only production instance.
After restoration, verify login, representative projects, uploaded files, and configured credentials. If the API reports a secret-key mismatch, investigate whether the key and database were captured together. Do not regenerate a key and assume encrypted settings will become readable.
Record the steps, elapsed recovery time, missing prerequisites, and the location of the backup used. Have the backup operator repeat the exercise when practical. Recovery should depend on a procedure the team can follow, not on the installer remembering undocumented choices.
Use the result to adjust the plan. If restoring uploads takes longer than expected, the recovery estimate needs to include it. If the backup cannot be reached without a credential stored only inside the failed application, change the access arrangement.
Upgrade with a clear rollback decision
Review release information and take a complete backup before upgrading. The documented command for refreshing the deployed bundle and applying an upgrade is:
./install.sh --upgrade --refresh-bundle
Refreshing the bundle matters when a release adds a service or configuration key. The optional updater can also support updates from Instance Settings. Its operational permissions include access to the host’s Docker socket; review the documented setup and disable that component if your operating policy requires command-driven updates.
Distinguish reverting application images from restoring data. An unhealthy upgrade can roll images back, but already applied database migrations are not automatically reversed. A data restore is a separate decision that can discard writes made after the backup.
Follow the backup and upgrade instructions shipped with the installed release. Database major-version upgrades need their own migration procedure; changing a container tag is not a complete migration plan.
Monitor the service within its supported shape
Monitor instance health, database and object-storage usage, certificate behavior, and backup results. Exercise a representative user path after a significant update. A process being alive does not establish that email, attachments, and collaboration all work.
Keep the standard self-hosted API at one replica. Its realtime hub runs in process; multiple API containers need a shared event mechanism before they can distribute updates reliably. If higher availability is required, evaluate the architecture deliberately instead of adding replicas and assuming the result is equivalent.
Finally, review current pricing and deployment options alongside the operating cost. Hosting, provider usage, backup storage, maintenance time, and applicable licenses all belong in the comparison. A successful self-hosted deployment is one the team can continue to operate, recover, and understand after installation day.
Frequently asked questions
What does self-hosted project management mean?
The project management application runs on infrastructure your organization operates or commissions. Your team controls deployment choices and is responsible for availability, updates, access, backups, and recovery, along with any external services it configures.
What does the standard Leera deployment include?
The documented Compose deployment includes the web app, Rust API, schema migrator, PostgreSQL, MinIO object storage, and Caddy reverse proxy. Redis and a separate managed database account are not prerequisites for that bundled deployment.
What must a Leera backup contain?
Keep the matching database dump, secret key, and environment configuration together. Preserve object storage for uploaded files as well. Copy the backup away from the instance and verify restoration on a separate host.
Does self-hosting keep all AI traffic on our server?
No. AI traffic depends on the provider and client you configure. An external model or connected client may process project context outside the instance. Review the full data path, email services, and integrations before deciding what deployment meets your requirements.
Can the standard self-hosted API run multiple replicas?
The documented self-hosted API uses an in-process realtime hub and should run as one replica. Multiple replicas require a shared event mechanism; adding containers without it can produce missing realtime updates.