Cloudron Forum

@girish @nebulon Server crashed again last night. But this time the pattern is different — no containers in restart loop, no runner issues. The cron cleanup job is working. All containers were stable (Up 11 hours) before the crash. The Docker journal shows the DNS resolver dying on its own: 23:38 - External DNS timeouts begin (185.12.64.2) 23:57 - Internal Docker DNS fails (172.18.0.1:53 i/o timeout) 23:59 - [resolver] connect failed: dial tcp 172.18.0.1:53: i/o timeout 00:xx - Server becomes unresponsive There's also a container (different ID each time) producing "ignoring event" / "cleaning up dead shim" messages every minute — not sure if related. This happens roughly at the same time every night (~23:00-00:00 UTC). All previous fixes applied (no restart loops, domain renewed, hardware clean). I'm running out of ideas on my end. Would it be possible to get SSH-level support to debug this? I can provide access anytime. This is really urgent as it's been impacting my mail service daily for weeks now. Thank you.

Had this same issue today, same storage provider (Backblaze B2). Multiple of the files in the snapshot folder had backups as old as a month and a half when my retention policy is set to one week. Also had timestamped folders that were over a month old that weren't being cleaned up.

Send email to support@

I just learned about https://github.com/grishy/any-sync-bundle/ it is a repackaged server to make self hosting the sync server easier. This example lists the environment variables that it needs to have set for external redis and mongodb: https://github.com/grishy/any-sync-bundle/blob/main/compose.external.yml

Bumping this thread in case someone got an idea.

Perfect, thanks a lot!

I see, I guess since I only use 24h format, the 160px was always wide enough. Fixed for next release with https://git.cloudron.io/platform/box/-/commit/a5da68a7f9fa0ef616299b36a13faba0fea2ca8a

If your workflow takes more then 5 minutes to complete, you should increase the timeout time.

Hello @potemkin_ai You can already configure each domain to not use wildcard. This is also documented here: https://docs.cloudron.io/domains#certificates go into your dashboard click Domains click the Edit button next to a domain click Advanced settings… Under Certificate provider select Let's Encrypt Prod or did I misunderstand what you are looking for? If this is indeed what you need, can we improve something to make this information more accessible?

@james Thank you @james! I was under the (wrong) impression that it was already installed (due to it being listed in /app/code/node_modules, thank you so much for clarifying. Having chromium (for eg. playwright) would probably be a good thing. I can imagine several use cases where a headless web browser could be useful.

To narrow down the issue a bit, can you create a mailbox on Server A which uses a local account to authenticate and then setup Outlook for that mailbox? If this suffers the same issue, then it is not related to the LDAP binding between those two Cloudrons.

@djxx said: Restarting the app doesn't fix it anymore, so now when it crashes I change the SFU TCP/UDP port range to something else and it works when the app restarts. This issue can occur if another application is already using ports within the 40000–40100 range. To resolve it, you can either change the port range (for example, starting from 25000) [image: 1774513002629-port-conflicts-resized.png] or enable WebRTC server mode in the env (edit it via Cloudron file manager), which requires fewer ports, as described above. SFU_SERVER=true Then restart the instance. Edit: The second option requires implementation on the Cloudron side, as described here: https://forum.cloudron.io/post/117374

@LoudLemur said: @IniBudi I am not sure, but according to Grok: "you've got a classic volumetric DDoS (the kind that floods bandwidth with junk traffic like UDP floods or SYN floods) that chewed through 1TB and knocked your server offline. Cloudflare free + Hetzner/Netcup anti-DDoS is a solid starter setup, but it's getting bypassed or overwhelmed because:Most attacks hit your VPS's real IP directly (bypassing Cloudflare unless everything is perfectly proxied). Hetzner's protection (Arbor/Juniper-based) is automated but often slow to kick in or just null-routes your IP (blackholes the whole server to protect their network). Netcup's 2 Tbps filter is better but still leaks big attacks or causes brief downtime. Cloudflare free is unmetered and excellent for web traffic routed through it (absorbs massive attacks at the edge), but it only helps if traffic never reaches your VPS. The 1TB bandwidth bill/spike proves the attack was hitting your origin directly.Immediate Effective Fixes (Do These Right Now — Mostly Free)Force everything through Cloudflare In Cloudflare DNS, make ALL records Proxied (orange cloud icon). No A/AAAA records pointing directly to your VPS IP. This routes attacks to Cloudflare's global network first. Lock your VPS firewall to Cloudflare IPs only (this is the #1 game-changer) Block everything except Cloudflare's published IP ranges. This stops 99% of direct IP attacks. Hetzner: Use their Cloud Firewall (or iptables). Netcup: Same with ufw/iptables. Cloudflare publishes the list here: cloudflare.com/ips (update it automatically via their API — there's a simple cron script for this). Result: Attack traffic dies at Cloudflare; your VPS barely sees clean traffic. Activate Cloudflare's emergency mode Turn on "I'm Under Attack" mode (Security → Overview). Enable Bot Fight Mode + managed WAF rules + rate limiting (free tier has these). Set Security Level to "High" or "I'm Under Attack". This challenges suspicious traffic with JS/captchas before it even reaches your server. Extra quick wins Use Cloudflare Tunnel (cloudflared) if possible — runs on your VPS and proxies traffic without exposing any ports publicly. Zero public IP exposure. On the server: iptables rate limiting + fail2ban for extra layers. Contact your VPS support immediately — they can sometimes manually tune mitigation. These steps alone usually stop the bandwidth massacre because Cloudflare absorbs the junk at their edge (they've mitigated 11+ Tbps attacks).The Strongest Solutions (Ranked by Effectiveness vs Cost)Here's what actually survives big attacks in 2026:Best affordable strong solution: Switch VPS to OVHcloud + keep Cloudflare free/Pro OVH has the strongest built-in, always-on DDoS protection in the budget VPS world (unlimited, multi-Tbps scrubbing centers, rarely null-routes, works great for L3/L4 volumetric). Users consistently report it handles attacks that destroy Hetzner/Netcup. Pair it with Cloudflare for L7 (web) protection and you're basically bulletproof for most attacks. Migration is straightforward (snapshot your server, spin up OVH VPS, point DNS). This is the combo I recommend for 90% of people in your spot. Specialized DDoS-protected hosting DDoS-Guard (or similar like PATH.net / Evolution Host): Purpose-built for heavy volumetric attacks. Offers protected VPS or proxy services with fixed pricing and excellent filtering. Great if you want to stay cheap but stronger than Hetzner/Netcup. BuyVM: Super cheap add-on protection (handles 700M+ pps). Upgrade Cloudflare only (if you love your current VPS) Go Pro ($20/mo) for advanced WAF, better rate limiting, and more rules. Still use the firewall lockdown above. For non-HTTP/UDP (games, APIs, etc.), you'll eventually need Cloudflare Spectrum (paid) or a dedicated L4 protector. Enterprise-level (if budget allows and attacks are constant) Cloudflare Magic Transit (BGP routing) + your VPS, or Akamai/Imperva. These are what big sites use — full network scrubbing. Quick Reality CheckIf your server is a website/API (HTTP/HTTPS), the Cloudflare + firewall lockdown + OVH combo will solve 95% of cases for very low cost. If it's a game server, UDP-heavy service, or Minecraft/etc., prioritize a host with native L4 protection (OVH or specialized like TCPShield) — Cloudflare free alone won't proxy those ports easily.The core principle for any strong solution: You need high-capacity upstream scrubbing so the 1TB flood never reaches your VPS bandwidth/CPU.Do the immediate firewall + proxy steps first — that often fixes it instantly without spending anything. If you tell me exactly what your server runs (website? game? API? ports?), attack type (from CF analytics), or your budget, I can give exact config commands/scripts or migration steps. " I already created inbound traffic firewall only accept Cloudflare IPs. Unfortunately, my server is still down. I don't know why the attacker is targeting my website, the content only talks about Digital Marketing, SEO, etc. Hmm, I am still searching alternative solution because I just use Cloudflare Free and cheap VPS. Thank you for sharing @loudlemur

I just want to say that this community fed, driven, produced work is wonderful. AND, I will always keep paying for my Cloudron! The people and the(ir) tech behind Cloudron has made this wonder possible. Thank you.