Issue Description
When trying to use my own web app i get a “resource not foound on this server 404 error.
Expected Behavior
I should get into this web app https://github.com/PimWilTaart125/stalwart-lobby/archive/refs/tags/V2.zip
Actual Behavior
i’m getting a 404 error
Reproduction Steps
Install the webapp
Update the applications
Fail dramatticallyui
Stalwart Version
v0.16.x
Installation Method
Docker
Database Backend
RocksDB
Blob Storage
RocksDB
Search Engine
Internal
Directory Backend
Internal
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
Based on the docs, a 404 for a custom Application like this is almost always one of these causes:
-
resourceUrl download failed and nothing is cached yet. The very first time an Application is unpacked, the bundle is fetched from resourceUrl. If that fetch fails (bad URL, unreachable host, firewall blocking outbound HTTPS), there’s no previously installed bundle to fall back on, and requests to the mount path return 404 Not Found until the next successful refresh. Check that the resourceUrl you set points directly at the zip asset (e.g. the GitHub release zip URL) and that the Stalwart host has outbound HTTPS access to github.com.
-
No index.html at the archive root. The bundle must contain an index.html at the root of the zip; if your stalwart-lobby archive nests its files in a subfolder instead, the unpack will not find it correctly and serving will fail/404.
-
urlPrefix mismatch. Make sure you’re actually browsing to the exact path you configured in urlPrefix (e.g. /lobby), not a different one, and that it doesn’t collide with another Application or a reserved API/.well-known path (collisions are rejected at config time, but a typo in the prefix will simply 404).
To confirm which of these is happening, trigger a manual refresh (UpdateApps action via WebUI, stalwart-cli create action/update-apps, or x:Action/set with {"@type":"UpdateApps"}) and check the server logs for the download/unpack result for that Application — a failed download or bad archive is logged there.
This is an automated reply from the Stalwart Help Bot. Other community members may follow up if this answer is incomplete or wrong.
2026-10-01T20:23:57Z INFO Application resource updated (resource.application-updated) url = “https://github.com/stalwartlabs/webui/releases/latest/download/webu
i.zip”, details = “Stalwart Web Interface”
2026-10-01T20:24:10Z INFO Application resource updated (resource.application-updated) url = “https://github.com/PimWilTaart125/stalwart-lobby/archive/refs/tags/
V2.zip”, details = “lobby”
The 404 comes from how the zip is laid out. An application bundle has to have index.html at the root of the archive (Overview | Stalwart). GitHub’s “Source code” downloads like archive/refs/tags/V2.zip put everything inside a top-level <repo>-<tag>/ folder, so Stalwart downloads and caches it fine but finds no index.html to serve. If the repository holds sources that still need building, that archive has no built app in it either.
Build the app, zip the contents of the build output folder (not the folder itself), attach that zip to the V2 release as an asset and point resourceUrl at .../releases/download/V2/<file>.zip. If it still returns 404 after that, post the urlPrefix you set and the exact URL you’re opening.