Hosting Piler for your customers#
This documentation applies to Piler enterprise edition 2.2.5+
Revision #2
Publication date: 2026-OCT-27
How a hosting provider or MSP runs Piler for many customers: one multi-tenant deployment, a tenant per customer, each with its own hostname, users and archive.
Who does what#
| Piler | The hosting partner |
|---|---|
| The software: piler, piler-ui, piler-smtp and the tools, updates and security fixes | Hosting: the servers, storage, network, backups, monitoring |
| Documentation, the example deployments | First-line support to the customers |
| Email support to the partner, business hours, best effort | SLAs, migrations from other archives, onboarding projects |
Piler sells software, not a service: there is no SLA from Piler itself. You set your own prices and terms for your customers.
Licensing: a multi-tenant license is priced per server, regardless of the number of tenants and users. Each worker node and the frontend node has its own license. The more tenants a server holds, the lower your cost per tenant, see sizing and the multi-tenant pricing.
The reference deployment#
A master node with the web UI of every tenant, and worker nodes that receive, archive and index the emails, stored in S3-compatible object storage:
- Architecture and high availability
- The multi-node, multi-tenant example: Docker Compose files for the master and the workers, tested with 2.2.5
- A smaller start: the single-node example with a multi-tenant license, moving to more nodes as the tenants grow
Several master nodes#
Several master nodes (piler-ui) behind a load balancer need leader election. Set on every master:
LEADER_ELECTION_ENABLED=true
They must use the same Redis (they need it for the sessions anyway) and the
same LEADER_REDIS_KEY (default piler:leader). One master, the leader,
runs the background jobs: the billing report, the
quota numbers collected every 15 minutes (from 2.2.5), the quota warning
emails, the Teams retention purge. If it stops, another master takes over
within about 35 seconds (LEADER_LOCK_TTL 30s, LEADER_RETRY_INTERVAL
5s).
Without it, which is the default, every master runs every job: your tenants may get the quota warning email from each master, each master sends the billing report and asks every worker for the quota of every tenant, and the Teams purges run at the same time.
With a single master, leave it off.
Running it#
- Sizing: storage per tenant, tenants per server
- Onboarding a tenant: from DNS to the first archived email
- Offboarding a tenant: handing over the archive, deleting the data
- Backup and restore: the deployment, and a single tenant
- Upgrades: the order of the nodes
- Monitoring: metrics, alerts, Grafana Cloud
- Usage reports for billing: per-tenant numbers, by API and metrics
Releases and security fixes#
The changelog is the single source of what changed in each release, with the upgrade notes. Its feeds tell you about a release without checking the page:
- releases.xml: every release of piler-ee, piler-smtp and the Scanner
- security.xml: only the releases with security fixes
Security fixes are also emailed to the hosting partners, from partners@mailpiler.com.