Need help: After migration to v0.16.0 login to web GUI not possible

[Mic2025]

Hello,

I'm running Stalwart Mail in Docker and today I migrated from version 0.15.5 to 0.16.0. I used the instructions in the release notes:

https://github.com/stalwartlabs/stalwart/blob/main/UPGRADING/v0_16.md

Everything seems to have worked fine. My email program can access the mail server. My problem is that I can no longer log into the web GUI with any username/password.

I open http://192.168.1.90:8080/login, but neither my old password (from version 0.15.5) nor the new password I received from the web GUI during the initial setup of the new server (before importing "export.json") works.

How can I regain access to the web GUI?

Thank you so much for your help.

Regards,
Mic.

[mdecimus]

The behaviour you described is the result of two changes in v0.16 worth knowing about.

1. The WebUI is bound to the configured hostname over HTTPS. Loading http://192.168.1.90:8080/login after the migration will appear to load the sign-in page, but the OAuth flow underneath only completes when the browser reaches Stalwart over the same hostname that's stored in defaultHostname (the value used in Step 1 of the wizard, also editable from the WebUI under Settings > Network > Services or with stalwart-cli). Try https://<your-configured-hostname>/admin instead, accepting any self-signed certificate warning if a real certificate is not in place yet.

2. Recovery mode is the right path for re-entering the WebUI when normal sign-in is not yet possible. Restart the container with STALWART_RECOVERY_MODE=1 and STALWART_RECOVERY_ADMIN=admin:<some-password> set in the environment, reach http://192.168.1.90:8080/admin, and sign in with the recovery admin credentials to reset the user's password or fix the configuration that is preventing the normal sign-in.

Updated documentation:

• Post-migration sign-in expectations and the reverse-proxy section: https://github.com/stalwartlabs/stalwart/blob/main/UPGRADING/v0_16.md#log-in-to-the-admin-panel
• Recovery mode: https://stalw.art/docs/configuration/recovery-mode

If the recovery container also returns 404 at /admin, that's a separate symptom (the WebUI bundle was not downloaded from GitHub on first start) and is described here: https://github.com/stalwartlabs/stalwart/blob/main/UPGRADING/v0_16.md#admin-or-account-returns-404-not-found

Let us know if any of these resolve the issue, or if a different symptom appears after trying recovery mode.

[MartinPesek]

From the linked documentation:

The published URLs are independent of how the request reached Stalwart. Whether the proxy talks to Stalwart on the HTTP listener (port 8080), on the HTTPS listener (port 443), with or without Proxy Protocol, the discovery documents contain https://[:STALWART_HTTPS_PORT]/... in every case. The proxy is free to use whichever upstream pattern fits the deployment best; it does not need to forward X-Forwarded-Proto or X-Forwarded-Host for OAuth and JMAP discovery to work correctly.

This is not true for me at all, when I call https://mail.domain.tld/jmap/session I get:

{
    "capabilities": {
// removed for brevity
        },
// removed for brevity
        "urn:ietf:params:jmap:sieve": {
            "implementation": "Stalwart v1.0.0"
        },
        "urn:ietf:params:jmap:blob": {},
        "urn:ietf:params:jmap:quota": {},
        "urn:ietf:params:jmap:websocket": {
            "url": "ws://mail.domain.tld:80/jmap/ws",
            "supportsPush": true
        }
    },
    "accounts": {},
    "primaryAccounts": {},
    "username": "",
    "apiUrl": "http://mail.domain.tld:80/jmap/",
    "downloadUrl": "http://mail.domain.tld:80/jmap/download/{accountId}/{blobId}/{name}?accept={type}",
    "uploadUrl": "http://mail.domain.tld:80/jmap/upload/{accountId}/",
    "eventSourceUrl": "http://mail.domain.tld:80/jmap/eventsource/?types={types}&closeafter={closeafter}&ping={ping}",
    "state": "0"
}

I changed http listener from port 8080 to 80 to try to trick it to respond something more useful. But I get non-https URLs and this is also tripping the signing in flow.

The only way for me to sign in is to have direct mapping to Stalwart's 443 (I opened 8443 to public and firewalled it for my IP). If I call that then I have this response from the URL above:

{
    "capabilities": {
// removed for brevity
        },
// removed for brevity
        "urn:ietf:params:jmap:sieve": {
            "implementation": "Stalwart v1.0.0"
        },
        "urn:ietf:params:jmap:blob": {},
        "urn:ietf:params:jmap:quota": {},
        "urn:ietf:params:jmap:websocket": {
            "url": "wss://mail.domain.tld/jmap/ws",
            "supportsPush": true
        }
    },
    "accounts": {},
    "primaryAccounts": {},
    "username": "",
    "apiUrl": "https://mail.domain.tld/jmap/",
    "downloadUrl": "https://mail.domain.tld/jmap/download/{accountId}/{blobId}/{name}?accept={type}",
    "uploadUrl": "https://mail.domain.tld/jmap/upload/{accountId}/",
    "eventSourceUrl": "https://mail.domain.tld/jmap/eventsource/?types={types}&closeafter={closeafter}&ping={ping}",
    "state": "0"
}

Which finally fixes the URLs but the flow is now start at :8443, get redirected to reverse proxy :443 and then end up at :8443.

As as side note I do have an issue that Stalwart is not seeing proper real IP from reverse proxy on the http/https endpoints (it works ok for SMTP/IMAPS/...). It's also the only container in my deployment that has this issue and I am out of ideas why is that. But from the linked documentation it seems like this shouldn't affect this.

[mdecimus]

Yes, the fix will be part of 0.16.1. Currently it appends the local port and you should configure your proxy to use https in the meantime.

[Mic2025]

Hello,

Thank you for your feedback. I also suspected that the Stalwart web GUI was now linked to the mail domain. You absolutely must remove this connection. The Stalwart web GUI must not be accessible from the internet via my domain URL. That would be a security risk.

I transferred the configuration from 0.15.5 to 0.16.0 using the Python script and the Stalwart CLI tool. Now I have three passwords: the password that was created when I first started and set up Stalwart, before I imported the export from 0.15.5 using the Stalwart CLI tool, and then the password from my old 0.15.5 configuration. I don't know if this one was imported.

As a test, I configured my local DNS (AdGuard Home) so that my domain URL opens the Stalwart web GUI. But none of my passwords work there either.

With this DNS trick, I can't open the admin web GUI. However, I can then open it via my local stalwart IP address, and the login works with the temporary admin username and password from the environment variable. But in the web GUI, I don't see a menu item where I can change the password for user "admin". There simply isn't a menu item for user accounts. There seems to be a bug.

However, if I manually type this address into the browser's address bar, I see a menu called "Accounts":

http://192.168.1.90:8080/admin/Management/x:Account/User

This menu basically only displays my configured email addresses (mailboxes). I can click "Create User" in the upper right corner. Afterward, I fill out a form with user information, but I can't always save the user.

After several attempts, I was able to create a new admin user, but even with that, I still can't log in using the normal login dialog. It simply doesn't work.

What's causing this, and how can I fix it? Or is the current version 0.16.0 really not too buggy to use?

Thanks!

Regards,
Mic.

[Mic2025]

@Mic2025 0.16.1 has been available on docker hub for 9 hours ;)

But when I try to pull it I do not get an update.

  stalwart-mail:
    image: stalwartlabs/stalwart:latest

... does not offer an update.

  stalwart-mail:
    image: stalwartlabs/stalwart:v0.16.1

... does also not offer an update.

[quagsirus]

@Mic2025 perhaps you already have it? the digest is 7f182c91aac6732db68ea6179c6a4b7af056704a349c60f333c8854d3c869f31

# I am downloading the image for the first time
$ docker image pull stalwartlabs/stalwart:v0.16.1
v0.16.1: Pulling from stalwartlabs/stalwart
ff62e60165ea: Pull complete 
0e42af447286: Pull complete 
b34f475cbeef: Pull complete 
4c644327aff6: Pull complete 
2c1ce468d9f3: Pull complete 
Digest: sha256:7f182c91aac6732db68ea6179c6a4b7af056704a349c60f333c8854d3c869f31
Status: Downloaded newer image for stalwartlabs/stalwart:v0.16.1
docker.io/stalwartlabs/stalwart:v0.16.1

# My computer can't find the image
$ docker image pull stalwartlabs/stalwart:v0.16.2
Error response from daemon: manifest for stalwartlabs/stalwart:v0.16.2 not found: manifest unknown: manifest unknown

# I already have the image downloaded
$ docker image pull stalwartlabs/stalwart:v0.16.1
v0.16.1: Pulling from stalwartlabs/stalwart
Digest: sha256:7f182c91aac6732db68ea6179c6a4b7af056704a349c60f333c8854d3c869f31
Status: Image is up to date for stalwartlabs/stalwart:v0.16.1
docker.io/stalwartlabs/stalwart:v0.16.1

I included what you would see if the version hadn't been released - with the made up version 0.16.2

[Mic2025]

Oh you are right. Sorry.

docker exec -it stalwart-mail stalwart --version
0.16.1

But the problem still exists. I cannot login to the admin web GUI by using:

http://192.168.1.90:8080/admin

[quagsirus]

@Mic2025 Unfortunately despite Stalwart running a HTTP server on port 8080 by default, it's impossible to login over HTTP unless in recovery mode, since the login flow requires the redirect url to be HTTPS :(

stalwart-1  | 2026-04-25T18:10:54Z ERROR Authentication error (auth.error) listenerId = "https", localPort = 443, remoteIp = 172.30.0.1, remotePort = 57541, details = "Redirect URI must be HTTPS."

Here's the best I got working:

Public JMAP, private /admin

If you want to expose JMAP, etc publicly, but NOT the admin dashboard, follow this:

Note

If you want the public services exposed at a custom port, then configure the STALWART_HTTPS_PORT environment variable appropriately, and change either the port exposed in your compose file, or on the https listener at /admin/Settings/x:NetworkListener

1.

Add anAccess-Control-Allow-Origin header for CORS here, with the value set to the hostname or IP you'll use to access the admin dashboard: /admin/Settings/x:Http

2.

Create a separate HTTP listener with Implicit TLS for your admin dashboard at /admin/Settings/x:NetworkListener, bound to a different interface or port:

3.

After that, add a new rule in the "Allowed endpoints" section /admin/Settings/x:Http/HttpSecurity

IF:
listener == "https" && contains(["admin", "account"], split(path, "/")[1])
THEN:
404

4.

After restarting Stalwart, you should be able to access the admin dashboard at https://10.0.0.2:8443/admin, and not from https://<defaultHostname>:443/admin

No public HTTP/HTTPS server

"Default Hostname" is used for the OIDC configuration, which is where you get sent after typing an email address on the page without a password box, and there is no way to override it for OIDC only :/

1.

That's okay though, we can set it to a private IP at /admin/Settings/x:SystemSettings/NetworkSettings:

2.

...and then override to the correct public-facing hostname for mail transfers over here: /admin/Settings/x:SystemSettings/NetworkServices:

3. (optional)

If you'd like to change the port then configure STALWART_HTTPS_PORT and change your compose file to expose the Stalwart HTTPS server on the same port:

services:
  stalwart:
    image: stalwartlabs/stalwart:v0.16-alpine
    restart: unless-stopped
    environment:
      TZ: Europe/London
      STALWART_HTTPS_PORT: 8443
    volumes:
      - ./data:/var/lib/stalwart
      - ./etc:/etc/stalwart
    ports:
      #- "25:25"
      #- "465:465"
      #- "993:993"
      - "8443:443"

4.

You need to restart Stalwart after changing any of these settings!

5.

I would hypothetically use my firewall to block access to the HTTPS server outside of my trusted network.

After all that, I'm able to login to the web UI with recovery mode disabled at: https://10.0.0.2:8443/admin (after acknowledging a self-signed certificate warning in my browser)

Hope this helps!!

[Mic2025]

Thank you for your effort. This all sounds quite complicated. I had hoped that Stalwart would remove this HTTPS binding with version 0.16.1. But they didn't. That's a real shame. It seems the Stalwart developers want our mail servers to be vulnerable to attack from the internet.

The self-signed certificates are a tricky issue. Somehow, Stalwart seems to use them for client access to the mail server, which then causes error messages.

I've given up now and linked the Stalwart web GUI to my domain.

• www.mydomain.de --> Opens my website
• www.mydomain.de/admin --> Opens the Stalwart web GUI.

I might take another look at your workaround later.

[mdecimus]

Just released:

Stalwart Server v0.16.1

Added

• OIDC: Extract username from JWT token.
• system('node_hostname') and system('node_role') expression variables to retrieve the local node hostname and cluster role respectively.

Fixed

• JMAP:
  • Invalid receivedAt headers after importing (Invalid receivedAt returned by Email/get after Email/import #2939).
  • Sorting order issues when emails lack receivedAt headers.
• IMAP: Fix BINARY fetch responses (Roundcube displays garbled text for windows-1251 emails with Stalwart #2940).
• WebDAV: Fix ACL validation for target folders.
• ACME: Allow requesting apex domain certificates.
• Hostname issues:
  • Accept RFC 6761 reserved TLDs during bootstrap.
  • Allow hostnames without TLDs in remote server settings.
• Reverse proxy issues.
• OSS builds.
• DNS Updater:
  • RFC2136: TSIG secret not base64 decoded.
  • Google DNS: Chunk TXT records when they exceed 255 characters.
  • Cloudflare:
    • Fix CAA record updates.
    • Check zone subdomains when finding zones

Stalwart WebUI v1.0.1

Added

• OIDC:
  • Logout users from IdP when logging out of the app.
  • Include openid scope in OIDC authentication requests.

Fixed

• Mobile display issues.
• Editing a secret clears its masked value.
• Array label properties crashes app.

Stalwart CLI v1.0.1

Fixed

• Allow JSON schema to be uncompressed.