Issue Description
Migrated from v0.15.5 → v0.16.14 in Docker (recovery mode + stalwart-cli apply export.json; apply succeeded, 0 failed — domains, accounts, DKIM, certs all present via CLI). Server is fully functional: JMAP over HTTPS returns 200, IMAP auth works, 12M+ emails indexed in Elasticsearch.
However /admin and /account return 404. This is NOT the usual egress-block cause: the container CAN download the WebUI bundle. From inside the container, curl -sSL https://github.com/stalwartlabs/webui/releases/latest/download/webui.zip returns HTTP 200, 552637 bytes, and objects.githubusercontent.com is reachable. Despite the successful download, the bundle is never unpacked or installed.
Question: What triggers the actual unpack/install of the WebUI Application bundle? Why would the download succeed (200) yet no resource.application-unpacked occur, and why is a manually-staged bundle at the configured unpackDirectory not served?
Expected Behavior
On first start after migration, the server fetches the WebUI bundle from GitHub, unpacks it, and serves the admin console at /admin and the account manager at /account (returning the SPA rather than 404). Per the docs, a successful fetch should emit a resource.application-unpacked event.
Actual Behavior
Both /admin and /account return 404 Not Found. The bundle download itself succeeds (verified: HTTP 200, 552637 bytes from inside the container), but no resource.application-unpacked event appears and no bundle is unpacked (find /tmp inside the container shows no WebUI files). Setting unpackDirectory=/var/lib/stalwart/webui and manually unzipping the valid bundle there (index.html present, owned by uid 2000) is also not served — still 404 after restart. Triggering create Action/UpdateApps via stalwart-cli returns a created Action id but produces no unpack and no change.
Reproduction Steps
- Migrate a v0.15.5 Docker/RocksDB deployment to v0.16.14 via recovery mode + stalwart-cli apply export.json (completes 0 failed).
- Start the server normally with config.json pointing DataStore at /var/lib/stalwart.
- Request /admin or /account over the HTTP listener.
- Observe 404 Not Found, despite the container being able to download webui.zip from GitHub (curl returns 200) and despite no resource.application-unpacked event being logged.
Relevant Log Output
“No resource/application/webui/unpack log lines are emitted at all, even at trace level.”
Stalwart Version
v0.16.x
Installation Method
Docker
Database Backend
RocksDB
Blob Storage
Filesystem
Search Engine
Elasticsearch
Directory Backend
Internal
Additional Context
Ruling out the common causes:
- Egress is NOT blocked: from inside the container, curl of the webui.zip URL returns HTTP 200 (552637 bytes), and both github.com and objects.githubusercontent.com are reachable on 443.
- config.json DataStore path is correct (/var/lib/stalwart, patched from the old /opt/stalwart during migration — verified no /opt/stalwart references remain).
- The Application record looks correct: enabled=true, resourceUrl=https://github.com/stalwartlabs/webui/releases/latest/download/webui.zip, urlPrefix=/admin + /account, autoUpdateFrequency=30d.
Workarounds attempted, none served the UI:
- Set unpackDirectory=/var/lib/stalwart/webui and manually unzipped the downloaded bundle there (correct structure — index.html, assets/, favicon.svg at top level; chowned to uid 2000). Verified present inside the container. Still 404 after restart.
- Triggered
stalwart-cli create Action/UpdateApps— returns a created Action id, HTTP 200, but no unpack occurs and no resource.application-unpacked event is logged. - Multiple full container restarts — no change.
Environment: Docker image stalwartlabs/stalwart:v0.16.14, Ubuntu 24.04 host, RocksDB data store (~59 GB), filesystem blob store on ZFS, Elasticsearch FTS, behind a Caddy reverse proxy. JMAP over HTTPS through Caddy works correctly (returns 200) and IMAP authentication works, so the server itself is healthy — the issue is isolated to the WebUI Application bundle not being unpacked/served.
Container runs as uid 2000; nofile ulimit raised to 1048576.
I have reviewed the documentation and FAQ and confirm that my issue is NOT addressed there.
on
I have searched this support forum (open and closed topics) and confirm this is not a duplicate.
on
I understand that topics in this category are triaged by a bot first but a human reply will follow up. If I’d prefer a human-only reply, I’ll add the no-ai tag to my topic.
on