Recently updated to version 1.0.0 via Stalwart-Migrate. However I cannot access the WebUI after finished migrating.
stalwart | 2026-10-27T09:28:48Z ERROR Resource error (resource.error) reason = Resource error (resource.error) { causedBy = "crates/common/src/manager/application.rs:655", url = "https://github.com/stalwartlabs/webui/releases/latest/download/webui.zip", details = "Application bundle does not contain a manifest" }, url = "https://github.com/stalwartlabs/webui/releases/latest/download/webui.zip", details = "Failed to unpack application for prefixes: account, admin, no bundle is available to serve"
I restarted the Stalwart container and it still can’t download the WebUI bundle with the same error.
Expected Behavior
Able to access the Stalwart WebUI.
Actual Behavior
Can’t access the WebUI with error 404:
{"type":"about:blank","status":404,"title":"Not Found","detail":"The requested resource does not exist on this server."}
Reproduction Steps
Update to version 1.0.0 via Stalwart-Migrate.
Restart the containers after the migration.
The log should show the Resource error above. Restarting the container does not fix the issue.
Stalwart Version
v1.x
Installation Method
Docker
Database Backend
PostgreSQL
Blob Storage
S3-compatible
Search Engine
Internal
Directory Backend
OIDC
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.
The cause is the resourceUrl your Application is using. It points at .../releases/latest/download/webui.zip, but the v1.0 default is https://github.com/stalwartlabs/webui/releases/download/v2/webui.zip. The migration most likely carried over an old URL.
The latest release of the webui repo is not a v1.0-compatible bundle. It has no stalwart-app.json manifest at the root of the zip, which every bundle must have. The server rejects the bundle, so no bundle is served and /admin and /account return 404.
Fix
Open the Application object for the WebUI and change resourceUrl to https://github.com/stalwartlabs/webui/releases/download/v2/webui.zip. It is under Settings › Applications in the WebUI or the Application object in stalwart-cli.
Restart the server, or run the UpdateApps action, so it downloads the bundle again.
Alternatively, download the v2 webui.zip yourself, copy it into the container and set resourceUrl to a file:// URL such as file:///var/lib/stalwart/webui.zip.
Also set unpackDirectory to a persistent path. Otherwise the unpacked files can be deleted from /tmp later.
Didn’t work so well. Stalwart Recovery Mode will still download the already-set resourceUrl.
The way I solved it is via the Stalwart CLI:
stalwart-cli query Application # to get <YOUR_APPLICATION_ID>
stalwart-cli update Application <YOUR_APPLICATION_ID> --field key resourceUrl https://github.com/stalwartlabs/webui/releases/download/v2/webui.zip
stalwart-cli create Action/UpdateApps # to redownload the bundle, or restart the Docker container.
We hit the same 404 on /admin and /account after stalwart-migrate, but in our case the resourceUrl was already
correct, so I think there is a second cause besides an old URL.
Setup: 0.16.27 to 1.0.0, stalwart-migrate 1.0.0 with defaults, PostgreSQL data store, the S3 blob store reused (the
recommended answer).
Steps:
Fresh 0.16.27 with default settings; open /admin once (the default WebUI v1.0.11 bundle is cached).
prepare with defaults, then run --final.
Start 1.0.0 on the new data store.
Result: the Application’s resourceUrl is rewritten to .../releases/download/v2/webui.zip as expected, yet /admin and
/account answer 404 and the log says “Application bundle does not contain a manifest”. 1.0 serves the cached bundle
stored under the application id in the shared blob store, and that is still the 1.x bundle written by 0.16; the URL
is not compared. Action/UpdateApps fixes it at once. The same happens in reverse after stalwart-migrate rollback.
Suggestion: drop the cached application blobs in run --final and in rollback, or check the cached bundle against
the URL or its manifest version before serving it.
This topic was marked as solved, but I think this should be a patch to either stalwart or the migration tool? Holding off on migrating until we get an answer on this as I had already noticed the drift in the WebUI package on my 0.16 install. @stalwart
For me when I had that issue the problem was that I had two stalwart users stalwart-mail from the early days and stalwart. I thought at some point during the process I’d want to be closer to the default and decided to go with the stalwart user from the install script. I removed the directories created by my first import experiment with the stalwart-mail user. But I did not know there was a dir created in /tmp/ too. This /tmp/ dir was tried to be reused but was owned by stalwart-mail instead of stalwart and therefore stalwart could not extract the web interface. After changing that dir to be owned by stalwart:stalwart everything worked as intended…
A short summary for anyone landing here, since this thread now has three different causes for the same symptom
(/admin and /account answer 404, log says “Application bundle does not contain a manifest”):
Old resourceUrl (first post): the Application still points at .../releases/latest/download/webui.zip.
Check: stalwart-cli query Application. Fix: set it to .../releases/download/v2/webui.zip, then Action/UpdateApps or a restart.
Stale cached bundle in a shared blob store (our case, post #4): the URL is already the v2 one, but 1.0 serves the
0.16 bundle cached under the application id. Check: the URL is correct and Action/UpdateApps alone fixes it.
Leftover unpack directory owned by another user (post #6): a directory in /tmp from an earlier run, owned by an old
service user, so the bundle cannot be unpacked. Check: ownership of the unpack directory. Fix: chown it to the
user Stalwart runs as, or set unpackDirectory to a persistent path you own.
From our side: we rehearsed the move on a test host (0.16.27 to 1.0.0, Docker, PostgreSQL, S3 blob store reused) and
we hit case 2 after run --final, and the same in reverse after rollback. Looking at the 1.0.0 source
(crates/common/src/manager/application.rs), the cached bundle is read by application id only; the URL is not
compared, and a failed manifest check does not trigger a new download. As far as I can see, stalwart-migrate 1.0.1
to 1.0.3 do not change this.
So for case 2 the workaround is easy, but anyone who reuses the blob store and has opened the 0.16 admin UI will
likely hit it, and the 404 on the admin UI right after a migration looks scary. Two small changes would avoid it:
drop the cached application blobs in run --final and rollback, or re-download when the cached bundle fails the
manifest check.
@stalwart could you say whether one of these is planned? Then we know whether to keep UpdateApps in our runbook.
Thanks!
One more data point, with stalwart-migrate 1.0.3 and server 1.0.1 (RocksDB data store, file system blob store reused). We hit both case 1 and case 2 from the summary above.
The Application’s resourceUrl was …/webui/releases/latest/download/webui.zip on 0.16.27. It was not rewritten by migrate 1.0.3 and still read latest on 1.0.1. (latest now points at a 2.x bundle with stalwart-app.json, so the URL itself happened to be fine.)
1.0.1 still served the 1.x bundle that 0.16 had cached in the shared blob store under the application id, and logged “Application bundle does not contain a manifest”. A restart didn’t help. Action/UpdateApps fixed it immediately, and the next start was clean.
So the cached-bundle problem is still there in 1.0.1 / migrate 1.0.3. Dropping the cached application blobs in run --final (and in rollback), as suggested in #4, would avoid it.
I do have the same problem but cannot use any of the proposed things to rectify that.
I use stalwart 0.16.27, ran the stalwart-migrate (with the known verify error for the vcards) and then installed stalwart v1.01 with the installer.sh. I run a three node cluster.
One of the systems came up correct, one not at all and the third in a limbo. After restarting the first it stopped as well.
If you hit the same case (resourceUrl already points at v2, and only UpdateApps fixes it), please add your setup there so the team sees how common it is.
unfortunately not. In non recovery mode the access is not possible at. In recovery mode the same. I’m stuck here at the moment.
The system is not starting completely in either mode. Sometimes I get to the point that at least a response is coming but unforthnately it is “ssl_certificate_response_too_long”.