I have a new Stalwart installation, running in Docker, and successfully migrated several accounts yesterday. I’m now seeing rate limiting 504 errors, even while using an admin account.
Expected Behavior
Vandelay export transfers account to completion.
Actual Behavior
“warning: server rate-limited (http 504); waiting 12s before retry 5/5 (shared level 5)”
Restarting the Stalwart container briefly fixes the issue, but it quickly returns.
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.
I now have a clear answer. The rate limit is applied to the HTTP/JMAP endpoint per authenticated user, and the “admin” user account itself likely does not have the unlimitedRequests permission unless explicitly granted.
Vandelay authenticates over the regular JMAP/HTTP API, so its requests are subject to the same authenticated-user rate limit as any other client: 1000 requests/minute by default, configured via rateLimitAuthenticated on the HTTP object. A large vandelay export run against a mailbox with many messages/mailboxes can easily exceed that during a single transfer, producing the 504 “server rate-limited” retries you’re seeing.
Only accounts holding the unlimitedRequests permission bypass this limit entirely, and that permission is granted by default only to genuine global “superuser” administrators (a top-level admin account with the Admin role and no tenant association). If your admin account is tenant-scoped, or its role doesn’t explicitly include unlimitedRequests, it will still be capped like any authenticated user, which matches the “restarting briefly fixes it” symptom you describe (the window resets).
Two ways to resolve it:
Confirm the account you’re using for Vandelary actually holds the unlimitedRequests permission (check its assigned Role — you can add unlimitedRequests explicitly to a custom role and assign it).
Alternatively, raise rateLimitAuthenticated on the Http singleton (Settings › Network › HTTP › Security in the WebUI), e.g.:
The admin user being used for the Vandelay export has “Bypass request rate limits” (via System Administrator role), and I’ve already increased the authenticated user rate limit to 30000/minute. Neither seem to have any impact on the admin user.
That is not a rate limit. We answer 429 for those, always with a JSON problem body naming the limit that tripped, and your line shows a bare 504 carrying neither a body nor RateLimit headers. Stalwart does not return 504 anywhere in its HTTP path.
The wording is vandelay’s doing: it treats 429, 502, 503 and 504 alike as retryable and prints all four as “server rate-limited”. A 504 in that position is a gateway timeout from whatever terminates TLS in front of the container, so its proxy read timeout is where I would start.
Your permission change was right, it is just not the thing failing. unlimitedRequests on System Administrator does bypass the limiter, and the raised rateLimitAuthenticated would have taken effect too if a limit had been involved. Client-side fan-out is not it either: maxConcurrentRequests and maxConcurrentUploads both default to 4 and vandelay clamps its worker pools to whatever the session advertises, so it will not exceed what you allow.
What sits in front of the container, and what is its read timeout set to? Given S3-compatible blob storage underneath and a restart buying you a while, a slow upload backing up past the proxy timeout would fit the pattern.