v2.0.8 — eliminate first-boot crash-loop on slow hosts
What this fixes
Some operators on slower / entropy-starved VPS hosts saw the container
go into a crash-loop on a fresh deploy:
[init-mailcue] Starting initialisation for domain=...
[init-mailcue] Generating TLS certificates (CA + server)...
s6-rc: fatal: timed out
s6-sudoc: fatal: unable to get exit status from server: Operation timed out
The init oneshot was synchronously generating a 4096-bit CA + a 2048-bit server cert + a 2048-bit DKIM key, plus running alembic migrations, all under a 30-second S6_CMD_WAIT_FOR_SERVICES_MAXTIME. On a constrained host the cert step alone could hit 30s and s6-rc would kill the script before it finished.
Changes
S6_CMD_WAIT_FOR_SERVICES_MAXTIME30 000 ms → 300 000 ms (5 min). Smallest ceiling that's safe on a slow VPS without disabling the timeout entirely.- Persist
/etc/ssl/mailcueas a named volume indocker-compose.deploy.ymlanddocker-compose.production.yml. Previously this directory lived in the container's writable layer, so every image upgrade discarded the certs, re-ran the slow generation path, and rotated the self-signed CA fingerprint that any client had pinned. With the volume, cert generation is a one-time cost.
Hot-patch for existing deployments
If you're hitting the crash-loop and don't want to wait for the new image:
environment:
- S6_CMD_WAIT_FOR_SERVICES_MAXTIME=300000then docker compose up -d. Re-pull 2.0.8 afterwards to pick up the volume change.
Known follow-up (not in this release)
Postfix and Dovecot still read /etc/ssl/mailcue/server.crt regardless of MAILCUE_TLS_CERT_PATH or MAILCUE_ACME_EMAIL — only Nginx picks up the Let's Encrypt / custom cert. Email clients validating SMTP/IMAP TLS will see the self-signed CA until the production-mode init is taught to symlink the trusted cert into server.crt/server.key as well.
Full Changelog: v2.0.7...v2.0.8