Cloudron Forum

I have finished packaging it.

https://git.cloudron.io/synchrone/mastodon-app

The app needs a minimum of 640 MB of RAM to start up and stabilize. After it, the memory consumption seems to go down a bit, but cloudron will still require that much for it.

It is available for testing under <your-cloudron>/#/appstore/org.joinmastodon.cloudronapp?version=2.6.1

Okay, 4 years later, we now have a fairly good prosody 0.12 release (March-June 2022).

Components like Multi-User Chat, and Proxy65 for file uploads require their own TLS certificates, which is now sort of possible via Secondary Domains aka "httpPorts" introduced in December 2021.

The only thing missing is accessing those TLS certs via tls add-on. It should work if you just upload your certs to /app/data/certs as well though.

@jdaviescoates: converse.js gets served on the frontend, yes. There is also a fully featured Prosody.im installation, so it's a fully-featured xmpp/jabber server, and you can use any compatible client app with it.

Now that cloudron has custom secondary domains feature, some apps that require their own TLS on subdomains (like XMPP servers) are made possible.

Here is a patch that expands TLS addon to support this:
https://git.cloudron.io/synchrone/box/-/commit/575247af0610dd6cc76142fe697e5415b256427b

This will help the following prospective apps to provide a sufficient level of XMPP support, as verifying TLS on their TCP ports under subdomain names is mandatory nowadays:

https://forum.cloudron.io/topic/7755/openfire-xmpp-server
https://forum.cloudron.io/topic/2486/ejabberd-robust-scalable-and-extensible-realtime-server-using-xmpp-mqtt-and-sip/12
https://forum.cloudron.io/topic/4188/snikket-server-your-own-messaging-server-in-a-box/9
https://forum.cloudron.io/topic/1234/prosody-kaiwa/5

Ok, certificates are in place (thanks @girish) so now jabber-app is in a useable state with server-to-server communication, AND mutli-user chatrooms support.

One problem is that when we limit MUC room creation to local users only (so random people off the internet won't be able to create public rooms on your conference.example.com) - prosody expects your local JIDs to be user@example.com, not user@chat.example.com.

I have side-stepped this by defaulting jabber-app's conference subdomain to conference.chat.example.com, and not conference.example.com. So it's possible misconfiguration by the end user will result in the MUC component not being functional.

Another problem is, I would like to be able to use cloudron's apex domain as my JID host (syn@example.com, not syn@chat.example.com)

That requires 2 things:

• DNS management to add SRV records (we can probably have the users manually do that with a generated instruction)
• Access to the TLS certificate for apex domain
  • alternatively, TLS-proxied ports 5223/5270, although I'm not certain what is the state of Direct TLS adoption among clients/server implementations these days

then a small patch for prosofy.cfg.lua should enable those upper-level VirtualHosts, and it's done.

When running a normal ./cloudron-setup in a restricted network environment or during a docker hub outage:

2026-06-21T09:58:41 ==> installer: downloading new addon images
2026-06-21T09:58:41 ==> installer:      Pulling docker images: registry.docker.com/cloudron/graphite:3.5.3@sha256:44ddbfd8c30d3eaa4fa6db207f4e18a4f1749ce6ed82d44e9e9a233a96febced registry.docker.com/cloudron/mail:3.18.2@sha256:130d518db6d56aa536f19a4901d7bc265666927165205aed302e6450c51791c7 registry.docker.com/cloudron/mongodb:6.3.0@sha256:8757111970a99fb9a9880f02a2a77fe9cb7368745fcff555bf528471ecb50ec3 registry.docker.com/cloudron/mysql:3.6.0@sha256:12fd9d8d92a41b78ca422ef05d7dade75eba4f8647b0fabaa873ba6efb607783 registry.docker.com/cloudron/postgresql:6.4.0@sha256:759c5c68e8f3a91592911177dcd2e9e39de48528b7b1bab659bae2f5ebd2d207 registry.docker.com/cloudron/redis:3.8.0@sha256:54a12252edbc326fd4d10e8c00836cc68776f3463f22366279f7cd8d4dafd20f registry.docker.com/cloudron/sftp:3.10.0@sha256:c3a65928ef5cf7ba0750e93d9c605fb39e7fec02de7db05cffe80927b39943de registry.docker.com/cloudron/turn:1.8.2@sha256:9f3609969a5757837505c584c98246a3035a84a273b9be491665ac026423fd5f
Error response from daemon: Get "https://registry.ipv4.docker.com/v2/": net/http: TLS handshake timeout

I configured the mirror via /etc/docker/daemon.json with e.g {"registry-mirrors": ["https://mirror.gcr.io"]}

But currently cloudron uses registry.docker.com as an explicit registry host, so it bypasses the Docker Hub mirror registry config.

Patching src/infra_version.js to replace registry.docker.com with docker.io enables the proxying.

The ipv6 workaround implemented in or after https://forum.cloudron.io/topic/7420/ipv6-only-cloudron would also need to be patched, but otherwise this seems a net win?

@girish sure. This has waited for years. Can wait another couple months

Also can you please rename this topic into "Prosody + Converse.js" ? Kaiwa is long since unmaintained and even forks have also dried up.

@murgero movim looks interesting, I can totally see it as another app on cloudron. XMPP allows for 3rd party web clients over BOSH/websockets. I would set up CORS on prosody for this, if not already supported.

@girish I consider this app ready for Beta submission to cloudron app store.

I wanted to keep using the account that has the app dev badge
Also may have lost access to the old one over the years.

https://docs.cloud.google.com/artifact-registry/docs/pull-cached-dockerhub-images

@jdaviescoates as I posted on 18 Jul 2018, 20:23:

I have packaged this as https://git.cloudron.io/synchrone/jabber-app

@murgero the blockers for my dream-world Jabber app on Cloudron are not related to configuring prosody. It's done already and I for one am using the current jabber-app daily.

The remaining issues are related to lack of interfaces to editing DNS (SRV, TXT) records from inside cloudron apps. That is going to affect any XMPP implementation.

I appreciate your feedback, but please look into the actual limitations instead of jumping to between shiny end-user brandings.

@girish in my provisional implementation I am using the key from httpPort for a predictable certificate/key locations.

given:

"httpPorts": {
    "CONFERENCE_DOMAIN": {
      "title": "Conference Service Domain",
      "description": "XEP-0045 domain",
      "containerPort": 5280,
      "defaultValue": "conference.chat"
    }
  },

the expected paths by convention are:

ssl = {
        certificate = "/etc/certs/secondary/CONFERENCE_DOMAIN.cert";
        key = "/etc/certs/secondary/CONFERENCE_DOMAIN.key";
    }

but I do not insist on this method. I would be perfectly fine with listing that directory to find out which domains exist, as well as environment variable based paths per a predictable httpPorts key.

So each feature is in it's own subdomain, is it?

not necessarily. E.g file uploads and proxy65 turned out to not need their own TLS certificates.

However, XMPP components that participate in federation MUST authenticate themselves for server-to-server communication via TLS. In my current configuration there is a Multi-User chat component that acts as it's own entity under "conference.chat.example.com" and must present a CA-trusted TLS certificate for that domain. Same goes for pubsub service.

This is necessary because other XMPP servers will expect to talk to "conference.chat.example.com" on port 5269 or 5222 with STARTTLS.

I do not expect many more components to be there. In total under 5 in the scope of this app. There may be a different XMPP Transports app that will have it's own configuration, but right now I'm focused on getting the core functionality.

As to why Jitsi is working ... I would need to check that code, but perhaps they do not do server-to-server xmpp ? Everything would happily work within the boundaries of the single prosody server, but outside world XMPP federation wouldn't work.