Cloudron Forum

@girish Thanks a lot, this is a great great news!

Hi, Since today (April 9, 2026), outbound IPv4 connectivity from app containers is broken. Nothing was changed on our side. Restoring an n8n backup from several days ago did not fix the issue. Symptoms: Workflows using Pipedrive (and Webflow) fail with: "The host is unreachable, perhaps the server is offline" Logs show: connect EHOSTUNREACH 172.67.68.102:443 and connect EHOSTUNREACH 104.18.188.228:443 Error also appears for community nodes fetching: Error while fetching community nodes: connect EHOSTUNREACH 172.67.68.102:443 Diagnosis performed: DNS is working — after fixing the upstream DNS (changed from OVH DNS 213.186.33.99 to 1.1.1.1 on ens3/ens4), nslookup api.pipedrive.com resolves correctly from inside the container. IPv6 works, IPv4 does not — curl https://api.pipedrive.com succeeds via IPv6 but curl -4 https://api.pipedrive.com fails with "No route to host" from inside the container. Host can reach the IPs fine — ping 172.67.68.102 and ping 104.18.188.228 both succeed from the host. Container network looks correct: Default route: default via 172.18.0.1 dev eth0 Container IP: 172.18.18.25/16 iptables / NAT look correct: MASQUERADE rule exists for 172.18.0.0/16 → !br-c372a117c03f cloudron_blocklist ipset is nearly empty (8 entries), does not contain Cloudflare IPs DOCKER-CT, DOCKER-FORWARD, DOCKER-USER chains reviewed — nothing obviously blocking The issue seems to affect all app containers for external IPv4, not just n8n. Question: Did something change on the Cloudron platform side today (routing, iptables rules, network configuration) that could explain why IPv4 forwarding from containers to external IPs stopped working, while IPv6 remains functional? Host info: Cloudron host ID: 9fa34633-859b-460d-a883-d1d3f5030f54-0 Affected app container: 53ed2453-c0d6-49ca-96f9-666104462c2f (n8n) VPS provider: OVH / OpenStack Please let us know what to check next or if a platform-level fix is needed. Thank you.

@nebulon Yeah, I got that wrong. pretty similar names & product.

Bump! Please upvote if you think a configureable timeout for Cloudron SSO would add value to the platform. Currently I am using PIN code verification via Cloudflare Access as a workaround, but ofcourse this only works if the domain is proxied by Cloudflare.

Hello @valexico @Valexico said: Are you speaking of a major release ? No, the next minor release will include this fix. Until then, you can either set the port in pocketbase to 587 if incoming fails is enabled on your Cloudron. (not persistent across restarts) Or you change the mail domain from my to e.g. mail. (persistent across restarts)

I've got a first version of LocalAI for cloudron. I've only tested some basics and you'll need to allow the app to access any GPUS. https://git.cloudron.io/eyecreate/localai https://git.cloudron.io/eyecreate/localai/-/raw/master/CloudronVersions.json?ref_type=heads

Updated the app to version 14.359 version 14.359 is still very fresh. If you use a lot of community modules they will probably break. So only update to version 14.359 if you made sure your community modules are working for the new version. You can now use the CloudronVersions.json to install the FoundryVTT Community App. If you have installed the app in the old style, you won't get automatic updates and need to update the old style way. pull the GitHub repo: git pull git@github.com:BrutalBirdie/cloudron-foundryvtt.git && cd cloudron-foundryvtt cloudron update --app $YOUR_APP_LOCATION --image brutalbirdie/foundryvtt.cloudron.app:2.0.1 The easy way to "migrate" from the old installation style to the new community app style would be: update manually to the latest version create a backup download the backup config uninstall the app install the app from the app store with the CloudronVersions.json restore your backup Now you should get automatic app updates when I release a new version.

Hi Ubuntu 22.04.3 LTS Linux 5.15.0-174-generic

@robi Still shared plugins, but building on your idea... what if EmDash.mycloudron.com could access EmDashPlugin1.mycloudron.com, EmDashPlugin2.mycloudron.com as isolated Workers? If installing a Worker was as easy as perhaps a LAMP app, we might get isolation. Would need some header finagling to satisfy CORS. It might also be interesting to see if Cloudron could expose a "master" app like EmDash on the front-end, and access the plugin endpoints as API-like endpoints on the back-end.