Cloudron Forum

@james yes looks like you need to implement a sandbox environment in the package

@msbt this looks like a community package and probably should not be included on the Hermes package. Adds extra complexity, package churn and attack surface.

@humpty mollysocket is needed if you want to use a different push provider like ntfy with Molly (Sognal) on android as opposed to Google Firebase

@msbt I’ll look into it

@MiroTalk said:

which parts are unclear to you and what you would expect to see improved in the explanation of each project

My main confusion is that several projects appear to solve almost the same problem. C2C, P2P and CME all cover one-to-one calls; P2P and SFU offer largely the same meeting experience – and their UI and used terminology are almost identical – at different scales without any end-user distinction; BRO overlaps with SFU’s webinar and broadcasting features.

The overview lists many features and architecture terms, but it does not make the choice simple. People are used to Zoom: they start a meeting and it works, regardless of participant count. I would expect one clear decision guide and clearer terminology on each homepage shipped with the application, explaining who each project is for, its practical limitations, and why I should choose it instead of the overlapping alternatives.

I packaged Bitwarden Lite to compare it to vaultwarden. It seems to work well but personally I won't be using it because too many features are behind the enterprise license. But are there people who would be interested before I discard this completely?

@MiroTalk I love what you're doing but honestly I have the feeling you're cannibalizing your own products too much. It's getting increasingly difficult to explain the difference between these programs. You may want to consider merging some projects or otherwise differentiating them more clearly.

Seems to be a windows issue https://github.com/dani-garcia/vaultwarden/issues/7462. One of my user resolved this by downgrading their extension: https://addons.mozilla.org/en-US/firefox/addon/bitwarden-password-manager/versions/

@gobenizzle Here is my preliminary package: https://git.due.ren/andreas/zeiterfassung-cloudron/-/raw/main/CloudronVersions.json

Let me know how this performs

@LoudLemur Where are you getting this from? I don't see anything on the website, blog, docs or repo.

@firmansi Correct

Biggest Feature would probably be Teams with automatic routing etc.

@nichu42 haha thanks I’m glad it’s of use!

@james @girish Out of curiosity I checked the current n8n package and this appears to be a small package-only change to satisfy @firmansi neeys. No Cloudron platform or custom nginx changes are required.

The implementation could be as simple as:

• Add "multiDomain": true to CloudronManifest.json
• Set N8N_EDITOR_BASE_URL to the primary CLOUDRON_APP_ORIGIN
• Let users select an alias with N8N_WEBHOOK_URL in /app/data/env.sh
• Preserve existing legacy WEBHOOK_URL overrides

One limitation: an alias exposes the whole n8n app, not only webhook paths. It nevertheless provides the requested separate canonical domain for forms, chat, and generated webhook URLs.

I can attach the ready patch here if helpful.

@necrevistonnezr The guide did not directly apply to our package because we never used the abandoned alpine-chrome:124 image. We installed Debian’s Chromium inside the single Cloudron container, so nothing was broken or unavailable.

However, our browser was independently maintained by Debian rather than the exact Chrome build Karakeep tests. I’ve now migrated the package to:

Package 0.1.11:

• Karakeep 0.33.2
• Official Karakeep Chrome 151.0.7922.47
• Chrome image pinned by immutable tag and digest
• Fresh Cloudron installation healthy
• Meilisearch, web, workers, and Chrome all running
• Real crawl of example.com produced:
  • Screenshot: JPEG, 18,511 bytes
  • PDF: 13,850 bytes

@LoudLemur The Problem is that the inbound mail port is blocked by cloudron and can not be reassigned without mayor modifications to cloudron. Currently this is a platform limitation and likely will never be supported because it would require the current deeply integrated mail services to be made more modular. I don't think it's something the Cloudron team is interested in.

Duplicate

The apex-domain limitation for the ESS package could be solved cleanly with a small platform feature: let an app declare custom well-known entries for its parent/apex domain — either in CloudronManifest.json or via an API the app can call — so Cloudron's nginx serves e.g. https://example.com/.well-known/matrix/{server,client} and /.well-known/element/element.json on the app's behalf, without the app claiming the whole apex as an alias.

Cloudron already serves some well-known content per domain, but there's no way to set the arbitrary JSON that Matrix needs today (e.g. the org.matrix.msc4143.rtc_foci transport entry that Element Call requires), and no way for a package to register it automatically. A wellKnown section in the manifest (updated on configure/restart) would benefit any protocol using apex-domain discovery — Matrix, WebFinger/Mastodon delegation, etc. Happy to write up a concrete proposal or beta-test an implementation with this package.

Is this the same as https://docs.cloudron.io/domains#matrix-server-location?

Almost the same, with two differences:

1. That feature only serves a fixed set of locations (matrix/server, matrix/client, host-meta, caldav/carddav). element/element.json isn't in the whitelist, so adding it to the domain config today would still 404. If you're open to adding it there, or better, serving any configured location, that solves it. I actually have a small patch for the generic version ready (branch wellknown-generic-locations on https://git.due.ren/andreas/cloudron-box, incl. regression test) if you want an MR.

2. The entries are static text the admin maintains by hand, while the correct values (e.g. rtc_foci for Element Call, the MAS auth block) come from the app and change with its config. That's the angle of my feature request: letting an app declare/update these entries for its apex domain itself, so they can't go stale. The dashboard feature would stay as the manual override.

So: same mechanism, just asking for it to be un-whitelisted and optionally app-populated.

@Joseph Great, another contender for sso.tax.

Just successfully moved my Matrix instance over to this ESS package.