Cloudron Forum

@nebulon Shame on me. A clone of FreeScout generates an env file with unique database credentials and uses the clone URL as the domain. No idea what happened yesterday. Maybe I had the same environment open twice or it was just computer voodoo. FreeScout add-ons added their endpoints and serial numbers to the env file, which was copied into the clone. But that's what I expected.

So the current terminal sets the font to monospace which should pick up the monospace font setting from the system. On typical linux systems this would be Noto Sans Mono most likely. But we don't ship any monospace font as such. Can you check which monospace your system settings have?

Hello @andreasdueren There is not cloudron stock app for the MAS service.

Looks like this is working. However, some of my disk read/write nodes were broken after this update. I was able to fix it by updating the paths inside the nodes to explicitly include "/app/data/". Otherwise the error I get is something like "Problem in node ‘Write Files to Disk‘ EROFS: read-only file system, open: xxx". Other than that, it appears the update is working correctly and binary form data is working again! Thanks for your help!

thanks... I back it up 1st then remove and re add it Nozy

I just updated to v1.25.0, set CalAmp Port to 5082 and it works perfectly root@cloudron:~# ss -ln |grep 5082 udp UNCONN 0 0 0.0.0.0:5082 0.0.0.0:* udp UNCONN 0 0 [::]:5082 [::]:* Thanks a lot for your quick help.

@robi Thanks. I'll see what I can find. I was actually surprised to see that it isn't already part of the LAMP App.

@robi Likely in the browser cache when using the web UI. In the App locally on your computer

Always good to check the logs for progress

@girish Unfortunately setting https://my.cloudron.example/openid/jwks_rsaonly isn't working either and testing auth returns: Failed to get your identity Looks like something went wrong. Here are the details. Failed to verify oidc token with fresh keys undefined PKCE is disabled, Email claim is set to email and OIDC Scopes are set to openid,email and profile. I can see the login attempt as authenticated in the logs for some reason though. Edit: https://my.cloudron.example/openid/jwks_rsaonly for my cloudron returns only {"keys":[]}. Was there a regression? I'm running 9.1.3. The regular jwks endpoint is returning proper values..

Fixed - https://git.cloudron.io/platform/box/-/commit/6e0dc24ecae47ba3175ce1574a86c6724fbc98aa . Thanks for debugging @tobiasb and thanks for reporting @luckow

A lot of improvements have happened to CiviCRM since it was first requested. These are summarized here. I hope we can package it for Cloudron: CiviCRM Improvements Since March 2018 (Focus on Standalone for Cloudron Packaging) + Roadmap Hey folks, CiviCRM is now at 6.12 (as of March 2026), and the changes have been transformative — especially for self-hosted use cases like Cloudron. Here's a breakdown of the main improvements: 1. No-Code/Low-Code Revolution: SearchKit + FormBuilder (Powered by APIv4) SearchKit (rolled out ~2020–2021, constantly enhanced): Visual query builder that replaced most legacy searches. Create complex joins, aggregations, charts, calendars, maps, saved searches, dashboards, and Smart Groups — all shareable and embeddable. FormBuilder (Afform): Drag-and-drop custom forms and workflows (events, contributions, petitions, data entry, etc.). Supports conditionals, multi-step forms, drafts ("save and finish later"), and deep SearchKit integration. These tools + mature APIv4 are the biggest game-changer for flexibility without PHP hacking. 2. CiviCRM Standalone – The Big Win for Self-Hosting & Cloudron Introduced as an extension (early 2020s), then moved to core and stabilized/promoted with CiviCRM 6.0 (March 2025). Runs completely without Drupal, WordPress, Joomla, or any CMS — just CiviCRM + a web server + database. Cloudron-friendly features: Official tarballs, Composer support, and Docker images published with every release (civicrm/civicrm on Docker Hub). Built-in user management, email login, 2FA, and dedicated extensions (Auto Logout for Standalone, Standalone Switch User, etc.). Simpler stack, fewer dependencies, easier updates, and cleaner resource usage. This is the single biggest reason to be excited: packaging Standalone is far more straightforward and maintainable than the old CMS-integrated versions. 3. Modern Theming & UX: RiverLea Theme Framework New theming system launched ~2024 and made default/popular in 6.x. Uses CSS variables (separates structure from styling), resulting in much lighter/faster themes (~15–30 kb vs. megabytes). Major UX/accessibility gains: Dark mode, better contrast, keyboard navigation, accordions, error messaging, and responsive design. Makes branding and future core UI changes far less painful. 4. Technical Infrastructure, Performance & Stability Smarty5 migration completed in 6.12 (2026): Dropped old Smarty2 for better security, performance, and modern PHP compatibility. Entity Construction Kit (ECK) (stable ~2025): Create custom entities via UI — they automatically get SearchKit/FormBuilder support. Ongoing performance tweaks, better multilingual support, improved logging, imports, and admin screens rebuilt with the new tools. Regular monthly releases + Extended Security Releases (ESR) option for stability-focused users. 5. Core Feature & Extensibility Enhancements Better handling across Contributions, Events, Cases, Mailings, and CiviMobile (native app). Stronger integrations (e.g., Mailchimp Sync) and a thriving extension ecosystem. Accessibility upgrades throughout and general polish that makes the whole system feel more modern and reliable. Promising Features on the Horizon / Roadmap (2025–2026+) RiverLea polish: In-app customizer, better frontend/public theming, and full accessibility compliance (community interest high, though some core funding paused). Deeper SearchKit/FormBuilder integration into more core admin screens (AdminUI/SearchUI work ongoing). Continued ECK evolution for even richer custom data models. Enhanced reporting (Pivot Reports), financial tools, and automation features. Focus on Standalone improvements, headless/API-first use cases, and overall stability (community sprints and CiviConf driving this). Overall verdict: CiviCRM has gone from a capable but somewhat rigid tool to a highly flexible, modern, self-hostable platform. Standalone + RiverLea + SearchKit/FormBuilder make it especially attractive for Cloudron packaging right now. Tips on must-have core extensions would be awesome too! Links for reference: Release announcements → https://civicrm.org/blog/tags/release Standalone install docs → https://docs.civicrm.org/installation/en/latest/standalone/ Docker repo → https://github.com/civicrm/civicrm-docker Looking forward to your thoughts!

Great, let me know if anything else is off

What Cloudron fights you on for Plane: the single-container model. It is probably better to just use Plane's Docker Compose and run it on its own little VPS. Plane is not a monolithic app with a database bolted on. It is a distributed system with nine services, a message broker, and an object store. Cramming all of that into one container with supervisord is not how any of those components were designed to run. It works (Outline, Cal.com, Seafile, and Zoneminder have all been packaged this way), but the result is fragile in ways that a Docker Compose deployment is not. If the Celery worker crashes and supervisord restarts it, that is fine. If LavinMQ crashes and takes in-flight messages with it while the API is still accepting requests, you get silent failures that are hard to diagnose. The failure modes multiply with the number of co-located services.