<?xml version="1.0" encoding="UTF-8"?><rss xmlns:dc="http://purl.org/dc/elements/1.1/" xmlns:content="http://purl.org/rss/1.0/modules/content/" xmlns:atom="http://www.w3.org/2005/Atom" version="2.0"><channel><title><![CDATA[Define custom well-known entries via CloudronManifest.json]]></title><description><![CDATA[<p dir="auto">The apex-domain limitation for the <a href="https://forum.cloudron.io/topic/15728/testers-wanted-element-server-suite-ess-community-for-cloudron">ESS package</a> could be solved cleanly with a small platform feature: let an app declare custom <code>well-known</code> 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. <a href="https://example.com/.well-known/matrix/%7Bserver,client%7D" target="_blank" rel="noopener noreferrer nofollow ugc">https://example.com/.well-known/matrix/{server,client}</a> and /.well-known/element/element.json on the app's behalf, without the app claiming the whole apex as an alias.</p>
<p dir="auto">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.</p>
<blockquote>
<p dir="auto">Is this the same as <a href="https://docs.cloudron.io/domains#matrix-server-location" target="_blank" rel="noopener noreferrer nofollow ugc">https://docs.cloudron.io/domains#matrix-server-location</a>?</p>
</blockquote>
<p dir="auto">Almost the same, with two differences:</p>
<ol>
<li>
<p dir="auto">That feature only serves a fixed set of locations (<code>matrix/server</code>, <code>matrix/client</code>, <code>host-meta</code>, <code>caldav</code>/<code>carddav</code>). <code>element/element.json</code> 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 <code>wellknown-generic-locations</code> on <a href="https://git.due.ren/andreas/cloudron-box" target="_blank" rel="noopener noreferrer nofollow ugc">https://git.due.ren/andreas/cloudron-box</a>, incl. regression test) if you want an MR.</p>
</li>
<li>
<p dir="auto">The entries are static text the admin maintains by hand, while the correct values (e.g. <code>rtc_foci</code> 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.</p>
</li>
</ol>
<p dir="auto">So: same mechanism, just asking for it to be un-whitelisted and optionally app-populated.</p>
]]></description><link>https://forum.cloudron.io/topic/15818/define-custom-well-known-entries-via-cloudronmanifest.json</link><generator>RSS for Node</generator><lastBuildDate>Mon, 24 Aug 2026 03:44:04 GMT</lastBuildDate><atom:link href="https://forum.cloudron.io/topic/15818.rss" rel="self" type="application/rss+xml"/><pubDate>Mon, 10 Aug 2026 20:41:50 GMT</pubDate><ttl>60</ttl></channel></rss>