--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.
```
---
### Author:  [@CuneytKorkmaz](https://support.stalw.art/u/CuneytKorkmaz)
#### Post date: [October 27, 2026, 8:43pm UTC](https://support.stalw.art/t/stalwart-1-0-0-cant-get-to-the-webui-resource-error-application-bundle-does-not-contain-a-manifest/2052/4 "2026-10-27T20:43:14Z")
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:
1. Fresh 0.16.27 with default settings; open /admin once (the default WebUI v1.0.11 bundle is cached).
2. `prepare` with defaults, then `run --final`.
3. 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.
---
### Author:  [@Zeus](https://support.stalw.art/u/Zeus)
#### Post date: [October 27, 2026, 11:03pm UTC](https://support.stalw.art/t/stalwart-1-0-0-cant-get-to-the-webui-resource-error-application-bundle-does-not-contain-a-manifest/2052/5 "2026-10-27T23:03:37Z")
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
---
### Author:  [@enaut](https://support.stalw.art/u/enaut)
#### Post date: [October 28, 2026, 8:13pm UTC](https://support.stalw.art/t/stalwart-1-0-0-cant-get-to-the-webui-resource-error-application-bundle-does-not-contain-a-manifest/2052/6 "2026-10-28T20:13:44Z")
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…
---
### Author:  [@CuneytKorkmaz](https://support.stalw.art/u/CuneytKorkmaz)
#### Post date: [October 28, 2026, 10:10pm UTC](https://support.stalw.art/t/stalwart-1-0-0-cant-get-to-the-webui-resource-error-application-bundle-does-not-contain-a-manifest/2052/7 "2026-10-28T22:10:47Z")
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”):
1. 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.
2. 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.
3. 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!
---
### Author:  [@sphen13](https://support.stalw.art/u/sphen13)
#### Post date: [October 29, 2026, 12:49pm UTC](https://support.stalw.art/t/stalwart-1-0-0-cant-get-to-the-webui-resource-error-application-bundle-does-not-contain-a-manifest/2052/8 "2026-10-29T12:49:33Z")
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.
---
### Author:  [@mathias.gaertner](https://support.stalw.art/u/mathias.gaertner)
#### Post date: [October 30, 2026, 4:29am UTC](https://support.stalw.art/t/stalwart-1-0-0-cant-get-to-the-webui-resource-error-application-bundle-does-not-contain-a-manifest/2052/9 "2026-10-30T04:29:50Z")
Hello,
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.
I see the error message
2026-10-30T04:11:58Z **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](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](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”
When I try to use stalwart-cli I get the error message:
stalwart-cli query Application --user XXXXX --password XXXXX --url [https://mail.XXXXX:8080](https://mail.XXXXX:8080)
warning: failed to refresh schema (error sending request for url ([https://mail.XXXXX:8080/api/schema](https://mail.XXXXX:8080/api/schema))); using cached copy
error: error sending request for url ([https://mail.XXXXXX:8080/jmap/session](https://mail.XXXXXX:8080/jmap/session))
The error messages do not surprise me since the port 8080 is not open (anymore) on the mail-system.
I verified that I can download the webui zip file from that server:
wget [https://github.com/stalwartlabs/webui/releases/download/v2/webui.zip](https://github.com/stalwartlabs/webui/releases/download/v2/webui.zip)
Auflösen des Hostnamens [github.com](http://github.com) ([github.com](http://github.com))… 4.237.22.38
Verbindungsaufbau zu [github.com](http://github.com) ([github.com](http://github.com))|4.237.22.38|:443 … verbunden.
HTTP-Anforderung gesendet, auf Antwort wird gewartet … 302 Found
ls -l web\*
-rw-r–r–. 1 root root 555723 30. Okt 00:45 **webui.zip**
Trying to start recovery mode does not change anything, same error messages.
---
### Author:  [@enaut](https://support.stalw.art/u/enaut)
#### Post date: [October 30, 2026, 5:32am UTC](https://support.stalw.art/t/stalwart-1-0-0-cant-get-to-the-webui-resource-error-application-bundle-does-not-contain-a-manifest/2052/10 "2026-10-30T05:32:30Z")
In recoverymode the ports 8080 should be open again…
When not in recovery mode you need to use the port that the stalwart web if/ jmap was using before instead of 8080.
---
### Author:  [@CuneytKorkmaz](https://support.stalw.art/u/CuneytKorkmaz)
#### Post date: [October 30, 2026, 9:25am UTC](https://support.stalw.art/t/stalwart-1-0-0-cant-get-to-the-webui-resource-error-application-bundle-does-not-contain-a-manifest/2052/11 "2026-10-30T09:25:05Z")
For the cached-bundle cause (post 4, confirmed by post 8 on 1.0.1), I opened a separate issue. We reproduced it again on the latest releases (Stalwart 1.0.1, stalwart-migrate 1.0.3) on a fresh install, including the rollback direction: [Stalwart-migrate: /admin and /account 404 after migration with a reused blob store (stale cached WebUI bundle), still in 1.0.1](https://support.stalw.art/t/2128)
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.
---
### Author:  [@mathias.gaertner](https://support.stalw.art/u/mathias.gaertner)
#### Post date: [October 30, 2026, 10:07am UTC](https://support.stalw.art/t/stalwart-1-0-0-cant-get-to-the-webui-resource-error-application-bundle-does-not-contain-a-manifest/2052/12 "2026-10-30T10:07:14Z")
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”.
---
### Author:  [@Disrupt](https://support.stalw.art/u/Disrupt)
#### Post date: [October 30, 2026, 11:48am UTC](https://support.stalw.art/t/stalwart-1-0-0-cant-get-to-the-webui-resource-error-application-bundle-does-not-contain-a-manifest/2052/13 "2026-10-30T11:48:13Z")
> [@mathias.gaertner](#):
>
> ssl\_certificate\_response\_too\_long
You’re trying to go to port 8080 with HTTPS, it needs to be HTTP.
---
### Author:  [@mathias.gaertner](https://support.stalw.art/u/mathias.gaertner)
#### Post date: [October 30, 2026, 7:44pm UTC](https://support.stalw.art/t/stalwart-1-0-0-cant-get-to-the-webui-resource-error-application-bundle-does-not-contain-a-manifest/2052/14 "2026-10-30T19:44:02Z")
Mate, don’t insult me by assuming I do not know about networks and protocols. Of course I tried http as well.