The docker container keerps running but stalwart just stops working, you can’t reach the web page anymore and/or send any mails. there aren’t any errors and restarting the container does not output any logs nor starts the service
Stalwart Version
v0.16.x
Installation Method
Docker
Database Backend
MySQL
Blob Storage
MySQL
Search Engine
MySQL
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.
Here are the most likely causes and how to diagnose them for your MySQL-backed Docker setup:
Most likely causes
1. Stalwart has stopped but the container is still running
The Docker container process is just the wrapper – the stalwart binary itself may have exited silently inside it. Check with:
docker logs stalwart 2>&1 | tail -100
Since all logs go to stdout/stderr in Docker (there is no separate log file), this is the primary place to look. If the logs are empty after restart, the binary may be failing immediately on startup before it can write anything.
2. MySQL connectivity loss
Because all three stores (data, blob, search) and the directory are all MySQL, a lost or refused database connection will effectively halt the server. Common triggers:
The MySQL container restarted and Stalwart’s connection pool has stale connections
MySQL’s wait_timeout / interactive_timeout dropped idle connections that Stalwart was holding
The MySQL container ran out of connections (default pool: min 5, max 10 per store – with 3 stores that’s up to 30 connections)
Check your MySQL logs for “too many connections” or “connection refused” errors.
3. WebUI bundle not downloaded / GitHub unreachable
If the container can’t reach github.com on TCP 443, the WebUI bundle is never fetched and every /admin request returns 404. This wouldn’t prevent mail delivery, but it would look like “the web page is gone.”
Steps to try
Check container logs:docker logs stalwart 2>&1 – look for any panic, error, or MySQL-related messages.
Check if the process is actually alive inside the container:docker exec stalwart ps aux – see if stalwart is listed.
Check MySQL connectivity from within the container: docker exec stalwart mysql -h <host> -u stalwart -p.
Ensure --restart unless-stopped is set on the Stalwart container so it automatically recovers.
If the binary is exiting, run it directly to see the error: docker exec -it stalwart /usr/local/bin/stalwart --config /etc/stalwart/config.json.
The MySQL timeout field (default 15s) and pool settings (poolMinConnections, poolMaxConnections) can be tuned in the WebUI under Settings > Storage > Data Store if connection exhaustion or timeouts are the cause.
No logs at all on restart usually means either there’s no console tracer configured (so nothing is being emitted) or the process is wedged before it gets to serving, often on a stalled database connection rather than actually crashing. MySQL as the blob store is also an unusual and stress-prone choice worth flagging.
To dig in, can you share: your exact 0.16.x version; the tracer config (server.tracer.*) and confirmation that stdout tracing at info is on; docker logs output and the container STATUS; whether ss -ltnp shows the ports still bound when it’s “stopped”; and the MySQL server status / connection limit at the time. That’ll tell us whether it’s hung or genuinely exiting.
I am not the original poster. But, I am facing the similar problem. My set up: latest docker with stalwart, initially tried with v0.16.19, then upgraded to v0.16.20, all stores and setting are defaults with rocksDB. Its for internal homelab email testing and no external service. Sufficient hardware with 4 cpu, 16GB RAM and good ssd drive. DNS management is set to auto and handled by stalwart without any issues. Log is set to both file and console at trace level. Container starts fine, downloads the webui and all other necessary csv files. I was able to set them all up without any issues, sending and receiving email was working without any problems, connecting to bulwark mail was also working.
Fast forward to about 18 hours after installation, opening the webui results in no loading. Checking the docker and file logs shows nothing but regular info messages. No errors shows up. Trying to access via bulwark ui results in “unable to reach your server”.
docker ps shows stalwart container running healthy, spits out console logs as regularly as if its working.
I tested it three days, three times on two different hardware and all three times it resulted in the same problem.
@sats, a container that stays healthy with logs still flowing while nothing is reachable fits an auto-ban better than a crash. A blocked IP gets dropped at accept time, before any protocol handling, so the server carries on logging as normal, and the image’s healthcheck falls back to plain HTTP on 127.0.0.1:8080, which a ban on your client address would never touch.
Ban events log at info level, so grep the log for the security. prefix: security.ip-blocked, security.scan-ban, security.loiter-ban, security.authentication-ban. The default rates are per-day counters (30 scan, 150 loiter, 100 auth), and when the matching *BanPeriod is unset the ban never expires on its own, which would explain why recreating the container does not clear it. Does one of those lines name your client or your LAN range?
From inside the container the source address is loopback, so you are not locked out there: docker exec stalwart curl -k https://127.0.0.1:443/healthz/live will tell you whether 443 is really serving, and the API is reachable the same way to list and delete BlockedIp entries. Rate and period keys are on the Security object. You are on a different setup from the report that opened this topic, so if your log shows no ban, this probably wants a thread of its own.