Cloudron Forum

• Main Page: https://stalw.art/
• Git: https://github.com/stalwartlabs/mail-server
• Licence: AGPL v3 & SELv1 for some features
• Docker: Yes
• Documentation: https://stalw.art/docs/install/docker
• Demo: link

---

• Summary: Stalwart Mail Server is an open-source mail server solution with SMTP, JMAP, IMAP4, and POP3 support and a wide range of modern features. It is written in Rust and aims to be secure, fast, robust and scalable.

---

• Notes: Modern Mail server implementation with security features like Encryption at rest with S/MIME or OpenPGP

---

Key features:

• JMAP, IMAP4, POP3 and ManageSieve server:
  • JMAP server with Sieve Scripts, WebSocket, Blob Management and Quotas extensions.
  • IMAP4rev2 and IMAP4rev1 server with support for numerous extensions.
  • POP3 server with extensions, STLS and SASL support.
  • ManageSieve server for managing Sieve scripts.
• SMTP server:
  • Built-in DMARC, DKIM, SPF and ARC support for message authentication.
  • Strong transport security through DANE, MTA-STS and SMTP TLS reporting.
  • Inbound throttling and filtering with granular configuration rules, sieve scripting, MTA hooks and milter integration.
  • Distributed virtual queues with delayed delivery, priority delivery, quotas, routing rules and throttling support.
  • Envelope rewriting and message modification.
• Built-in Spam and Phishing filter:
  • Comprehensive set of filtering rules on par with popular solutions.
  • LLM-driven spam filtering and message analysis.
  • Statistical spam classifier with automatic training capabilities.
  • DNS Blocklists (DNSBLs) checking of IP addresses, domains, and hashes.
  • Collaborative digest-based spam filtering with Pyzor.
  • Phishing protection against homographic URL attacks, sender spoofing and other techniques.
  • Trusted reply tracking to recognize and prioritize genuine e-mail replies.
  • Sender reputation monitoring by IP address, ASN, domain and email address.
  • Greylisting to temporarily defer unknown senders.
  • Spam traps to set up decoy email addresses that catch and analyze spam.
• Flexible and scalable:
  • Pluggable storage backends with RocksDB, FoundationDB, PostgreSQL, mySQL, SQLite, S3-Compatible, Redis and ElasticSearch support.
  • Clustering support with node autodiscovery and partition-tolerant failure detection.
  • Full-text search available in 17 languages.
  • Sieve scripting language with support for all registered extensions.
  • Email aliases, mailing lists, subaddressing and catch-all addresses support.
  • Automatic account configuration and discovery with autoconfig and autodiscover.
  • Multi-tenancy support with domain and tenant isolation.
  • Disk quotas per user and tenant.
• Secure and robust:
  • Encryption at rest with S/MIME or OpenPGP.
  • Automatic TLS certificate provisioning with ACME using TLS-ALPN-01, DNS-01 or HTTP-01 challenges.
  • Automated blocking of IP addresses that attack, abuse or scan the server for exploits.
  • Rate limiting.
  • Security audited (read the report).
  • Memory safe (thanks to Rust).
• Authentication and Authorization:
  • OpenID Connect authentication.
  • OAuth 2.0 authorization with authorization code and device authorization flows.
  • LDAP, OIDC, SQL or built-in authentication backend support.
  • Two-factor authentication with Time-based One-Time Passwords (2FA-TOTP)
  • Application passwords (App Passwords).
  • Roles and permissions.
  • Access Control Lists (ACLs).
• Observability:
  • Logging and tracing with OpenTelemetry, journald, log files and console support.
  • Metrics with OpenTelemetry and Prometheus integration.
  • Webhooks for event-driven automation.
  • Alerts with email and webhook notifications.
  • Live tracing and metrics.
• Web-based administration:
  • Dashboard with real-time statistics and monitoring.
  • Account, domain, group and mailing list management.
  • SMTP queue management for messages and outbound DMARC and TLS reports.
  • Report visualization interface for received DMARC, TLS-RPT and Failure (ARF) reports.
  • Configuration of every aspect of the mail server.
  • Log viewer with search and filtering capabilities.
  • Self-service portal for password reset and encryption-at-rest key management.

---

• Screenshots:

I got photos and auth working. What still needs to be done:

• Make CLI work to increase storage quota
• Set up OTT to be sent via E-Mail
• Implement option to use multiple s3 backends for redundancy
• Check Accounts app

I have a working package of ente for cloudron.

You can use my docker image with andreasdueren/ente-cloudron --tag 0.4.5

Currently these are the limitations/quirks:

• admins need to manually set up Aliases for the following sub domains: family, albums, cast, auth and accounts
• the actual user IP addresses aren't passed into the log by caddy. Right now the Dockerfile installs the Debian-packaged Caddy that ships with cloudron/base:5.0.0, which is why the optional modules aren’t present. If we want http.handlers.realip, we would need to build Caddy ourselves and bundle that binary instead of apt-getting the stock one.
• I have only tested this package with one s3 zone. Replication should be working but I haven't had time to test it.
• In general this application relies heavily on the CLI for user management. This includes increasing storage quota. It should work, but again haven't had much time to test.

• Main Page: https://reacher.email/
• Git: https://github.com/reacherhq
• Licence: AGPL-3.0
• Dockerfile: Yes
• Demo: link

---

• Summary: Reacher is an open-source email verification API. You can use Reacher to ensure the deliverability of your emails, clean your email lists, and prevent bounces. The API supports both individual email checks and bulk verification processes.

---

• Notes: good companion app to Listmonk

---

• Alternative to / Libhunt link: e.g. https://selfhosted.libhunt.com/umap-alternatives
• Screenshots: images, brand logo

This guide configures Nextcloud Full Text Search (FTS) to use Elasticsearch over the Cloudron-internal app network.

The Elasticsearch REST API is not public. The public app URL exposes only a minimal health endpoint; Nextcloud connects directly to Elasticsearch on internal port 9200.

1. Install Elasticsearch from the community catalog

In Cloudron, open:

App Store → Settings → Community Apps

Add this catalog URL:

https://git.due.ren/andreas/elasticsearch-cloudron/-/raw/main/CloudronVersions.json

Or install through the Cloudron CLI:

cloudron install \
  --versions-url https://git.due.ren/andreas/elasticsearch-cloudron/-/raw/main/CloudronVersions.json \
  --location elasticsearch.example.com

Installing from this catalog makes the app community-tracked, allowing Cloudron to discover later package releases through its normal update mechanism.

Allocate at least 4 GB RAM where possible. The package sizes Elasticsearch's JVM heap from the app memory limit.

2. Obtain the internal Elasticsearch address and credential

Open the Elasticsearch app's Web Terminal and run:

hostname
cat /app/data/credentials.txt

hostname prints the Cloudron app ID. This is the internal hostname that other Cloudron apps can resolve for the lifetime of this installed app.

Use the app-ID hostname, not the container IP. Container IP addresses are not a supported configuration value and can change.

The internal Elasticsearch endpoint is:

http://<APP_ID_HOSTNAME>:9200

For example:

http://210f8b84-f417-4697-80b7-efefd18e7329:9200

The generated password is also available at:

/app/data/secrets/elastic_password

Treat it as a secret. A Cloudron app that has both this password and the internal hostname can query Elasticsearch.

Important: If the Elasticsearch app is removed and installed again, it receives a new app ID. Update the Nextcloud elastic_host configuration after such a migration.

3. Enable the Nextcloud FTS apps

Open the Nextcloud app's Web Terminal and run:

sudo -u www-data php /app/code/occ app:enable fulltextsearch
sudo -u www-data php /app/code/occ app:enable fulltextsearch_elasticsearch
sudo -u www-data php /app/code/occ app:enable files_fulltextsearch

4. Configure Nextcloud

Set the FTS platform and the index name:

sudo -u www-data php /app/code/occ config:app:set \
  fulltextsearch app_navigation --value "1"

sudo -u www-data php /app/code/occ config:app:set \
  fulltextsearch search_platform \
  --value "OCA\\FullTextSearch_Elasticsearch\\Platform\\ElasticSearchPlatform"

sudo -u www-data php /app/code/occ config:app:set \
  fulltextsearch_elasticsearch elastic_index --value "nextcloud"

Set the Elasticsearch connection. The password must be URL-encoded if it contains URL-reserved characters such as @, :, /, ?, #, or %.

sudo -u www-data php /app/code/occ config:app:set \
  fulltextsearch_elasticsearch elastic_host \
  --value "http://elastic:URL_ENCODED_PASSWORD@APP_ID_HOSTNAME:9200"

Replace:

• URL_ENCODED_PASSWORD with the generated Elasticsearch password, URL-encoded where necessary.
• APP_ID_HOSTNAME with the value returned by hostname in the Elasticsearch app.

Example shape:

http://elastic:REDACTED@210f8b84-f417-4697-80b7-efefd18e7329:9200

5. Test and build the index

sudo -u www-data php /app/code/occ fulltextsearch:test
sudo -u www-data php /app/code/occ fulltextsearch:index

The first indexing run can take time, depending on the number and size of files.

Elasticsearch's built-in german analyzer is available. No separate ICU plugin is required for the standard German analyzer.

6. Verify Elasticsearch and the public boundary

Inside the Elasticsearch app:

curl -u elastic:$(cat /app/data/secrets/elastic_password) \
  http://localhost:9200/_cat/indices?v

You should see the nextcloud index after indexing.

From outside the Cloudron, verify that Elasticsearch API routes are not public:

curl -i https://elasticsearch.example.com/_cat/indices

Expected result:

HTTP 404
{"status":"not_found"}

The harmless public health endpoint should remain available:

curl -i https://elasticsearch.example.com/health

Expected result:

HTTP 200
{"status":"green","service":"elasticsearch-cloudron"}

Security and operational notes

• Elasticsearch REST runs on internal port 9200; it is not routed through the public Cloudron reverse proxy.
• The public Cloudron httpPort serves only /health.
• The Elasticsearch transport port 9300 has no external Cloudron port mapping.
• HTTP CORS is disabled by default.
• Elasticsearch data persists in /app/data; routine package updates do not normally require a re-index.
• Do not use container IP addresses in Nextcloud configuration.

I think this is ready for an unstable release: andreasdueren/ente-cloudron:0.5.3

I tested and fixed:

• Upload with the mobile app
• The CLI/increasing storage quota
• httpPorts feature for automatic sub domain setup

@avatar1024 said in Nextcloud Talk high-performance back-end:

I'm just wondering in light of the Jitsi situation (i.e. hard to update), whether it might be worth reviving this thread starting with the package @doodlemania2 made? Or if any other video call app might be simpler to package and maintain on Cloudron (e.g. @Kubernetes made an initial package for MiroTalk but I've got no clue how it compares with Jitsi or NC talk)

For everyone who wants to host it themselves without too much hassle, I have been successfully using this build on a standalone server for some months now: https://github.com/sunweaver/nextcloud-high-performance-backend-setup

• Main Page: https://www.notifuse.com/
• Git: https://github.com/Notifuse/notifuse
• Licence: GNU Affero General Public License v3.0
• Dockerfile: Yes
• Demo: https://demo.notifuse.com/console/signin?email=demo@notifuse.com

---

• Summary: Notifuse is a modern, self-hosted emailing platform that allows you to send newsletters and transactional emails at a fraction of the cost.

---

• Notes: modern go/react implementation of a newsletter software, similar feature set as listmonk but better UI

---

• Alternative to: Mailchimp, Brevo, Mailjet, Listmonk, Mailerlite, Klaviyo...
• Screenshots:

Key Features

Email Marketing

• Visual Email Builder: Drag-and-drop editor with MJML components and real-time preview
• Campaign Management: Create, schedule, and send targeted email campaigns
• A/B Testing: Optimize campaigns with built-in testing for subject lines, content, and send times
• List Management: Advanced subscriber segmentation and list organization
• Contact Profiles: Rich contact management with custom fields and detailed profiles

Developer-Friendly

• Easy Setup: Interactive setup wizard for quick deployment and configuration
• Transactional API: Powerful REST API for automated email delivery
• Webhook Integration: Real-time event notifications and integrations
• Liquid Templating: Dynamic content with variables like {{ contact.first_name }}
• Multi-Provider Support: Connect with Amazon SES, Mailgun, Postmark, Mailjet, SparkPost, and SMTP

Analytics & Insights

• Open & Click Tracking: Detailed engagement metrics and campaign performance
• Real-time Analytics: Monitor delivery rates, opens, clicks, and conversions
• Campaign Reports: Comprehensive reporting and analytics dashboard

Advanced Features

• S3 File Manager: Integrated file management with CDN delivery
• Notification Center: Centralized notification system for your applications
• Responsive Templates: Mobile-optimized email templates
• Custom Fields: Flexible contact data management
• Workspace Management: Multi-tenant support for teams and agencies

️ Architecture

Notifuse follows clean architecture principles with clear separation of concerns:

Backend (Go)

• Domain Layer: Core business logic and entities (internal/domain/)
• Service Layer: Business logic implementation (internal/service/)
• Repository Layer: Data access and storage (internal/repository/)
• HTTP Layer: API handlers and middleware (internal/http/)

Frontend (React)

• Console: Admin interface built with React, Ant Design, and TypeScript (console/)
• Notification Center: Embeddable widget for customer notifications (notification_center/)

Hi all,

The existing Synapse/Element packages on Cloudron work, but they predate Matrix 2.0: no Matrix Authentication Service, which means next-gen auth (Element X), and especially Element Call don't work properly. Instead of patching the old package I've built a new one that packages the full Element Server Suite (ESS Community) stack — the same components as Element's official Helm chart (element-hq/ess-helm), repackaged as a single Cloudron app.

What's included

One app, one container, the whole stack:

Component	Version	What it does
Synapse	1.157.1	Matrix homeserver (MSC4143 RTC transports enabled)
Matrix Authentication Service	1.21.0	Next-gen auth (OIDC-native, Element X compatible)
Element Web	1.12.24	Web client with embedded Element Call
Element Call (standalone SPA)	0.22.0	Guest-accessible call links
LiveKit SFU + lk-jwt	1.13.4 / 0.5.0	WebRTC media backend for calls
Element Admin	0.1.12	Admin UI (users, rooms)
Hookshot	7.4.3	Webhooks/bridges (optional)

Cloudron integration: SSO via the Cloudron OIDC addon → MAS → Synapse. Your Cloudron users log in with their normal accounts, including on Element X mobile. PostgreSQL via the Cloudron addon, well-known files served automatically, all configs regenerated from Cloudron env on every start.

What works today (v0.3.8)

• Login via Cloudron SSO on Element Web and Element X (iOS tested)
• Messaging, media, federation with other Matrix servers
• Element Call between users on your server (desktop confirmed, mobile in testing)
• Element Admin against MAS + Synapse admin APIs

Install

Install as a custom app via the version catalog:

App Store → Settings (gear icon) → Custom App Repository and enter https://git.due.ren/andreas/cloudron-ess/-/raw/main/CloudronVersions.json.

Repo: https://git.due.ren/andreas/cloudron-ess

The app asks for several locations at install time (all prefilled except the primary):

• Primary location = the account/auth domain — set this to e.g. account.example.com (this is where MAS lives; it must be primary because Cloudron's OIDC addon only registers callbacks on the primary domain)
• chat. → Element Web, matrix. → Synapse, mrtc. → RTC backend, admin.matrix. → Admin, call. → standalone Element Call

Current limitations / gotchas (please read before testing)

1. The apex domain alias. Matrix identity lives on your bare domain (@user:example.com), so https://example.com/.well-known/matrix/* must be served correctly. Right now the only way to do this is to add your bare domain as an alias on the ESS app — the app then serves the well-known files itself and redirects everything else to Element Web. That means the apex domain has to be parked on this app, which is far from ideal if you want to run something else there. Cloudron's built-in per-domain well-known support doesn't allow the custom JSON entries Matrix RTC needs (org.matrix.msc4143.rtc_foci), hence the request to the Cloudron team below.
2. Server name is permanent. The Matrix server name is baked in at first start. Changing domains later will brick your identity — the app refuses to start on a mismatch by design.
3. Federated calls require the other homeserver to also advertise an RTC transport (rtc_foci in its well-known). Calls with users on servers that haven't deployed Matrix RTC yet will show "Call is not supported" on their side.
4. Fresh installs only. No migration path yet from the existing Cloudron Synapse package (syn2mas migration is on the roadmap, untested).
5. Element X mobile calls — still shaking out well-known caching issues (log out/in after server updates if calls error out). Actively being worked on.
6. Resource usage: this is ~7 services in one container. Give it 2–4 GB memory.
7. Hookshot ships but is off by default; workers/redis scaling not implemented yet.

Request for the Cloudron team

@girish @nebulon The apex-domain situation (limitation #1) 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.

How you can help

• Install it on a test domain and report: SSO login, Element X login, 1:1 and group calls, federation with matrix.org
• Especially interested in: calls between two different ESS-package servers, iOS vs Android behavior, and apex/alias setups
• Issues → please reply here

Everything is rebuilt from upstream Element artifacts, config generation mirrors the official Helm chart, so upstream version bumps should be routine once this stabilizes. My plan is to eventually either implement the upstream ESS Community migration tool or build a custom script for future migrations from the legacy Cloudron matrix apps.

Thanks for testing!

I've packaged the Nextcloud Talk HPB (nextcloud-spreed-signaling 2.1.1 plus Janus 1.4.1 VideoRoom SFU) for Cloudron and am currently testing it in production with a few Nextcloud instances.

What it does:

• Single instance signaling server plus Janus SFU, NATS built in (loopback mode)
• One install can serve multiple Nextclouds via isolated [backend:<id>] sections
• Selectable TURN modes: Cloudron TURN addon (default), local coturn, external coturn, Cloudflare Realtime TURN, or disabled
• Works with both / and the sunweaver style /standalone-signaling/ URL prefix, so migrating from a VPS setup is straightforward
• Sensible video quality defaults (4 Mbit/s camera, 8 Mbit/s screen share) with a documented knob in config.ini

The recording backend is currently intentionally not included. May add this in the future.

TURN choice: i'm personally running the Cloudflare Realtime TURN mode. Cloudron's platform TURN was a bit unreliable for us, and Cloudflare gives you an anycast TURN edge including TURN over TLS on 443 for restrictive networks. Since Talk only speaks coturn shared secrets and Cloudflare issues short lived credentials, the package ships a small credential minting Worker plus a Talk companion app that handles caching and fallback.

So far my experience with it is slightly better than the sunweaver HPB server. But time and more concurrent users will tell.

Repo: https://git.due.ren/andreas/nextcloud-hpb-cloudron
CloudronVersions.json: https://git.due.ren/andreas/nextcloud-hpb-cloudron/-/raw/main/CloudronVersions.json

Still early. I'd be happy about any feedback, especially from people running other TURN modes or setups with multiple backends.

I did some digging, this is what I think is needed:

The current package uses:

• Synapse v1.144.0 (which is compatible - MAS requires v1.136.0+)
• Cloudron OIDC for SSO (traditional OIDC provider approach)
• PostgreSQL as the database
• Standard Matrix authentication endpoints

What MAS Integration Requires
MAS is fundamentally different from traditional OIDC - it's not just another identity provider, but a complete replacement for Synapse's internal authentication system per MSC3861. It needs:

1. MAS Service Deployment

• MAS needs to run as a separate service (not just a config change)
• It requires its own separate PostgreSQL database
• It needs its own domain/subdomain (e.g., auth.matrix.example.com)
• Docker image: ghcr.io/element-hq/matrix-authentication-service:latest

2. MAS Configuration Requirements

• Encryption secrets and signing keys (RSA minimum)
• Connection to Synapse via shared secret
• Database configuration for its own PostgreSQL database
• HTTP listener configuration
• Email configuration for password recovery
• Policy configuration (WASM file)

3. Synapse Configuration Changes
Replace traditional OIDC with matrix_authentication_service section:

matrix_authentication_service:
  enabled: true
  endpoint: http://mas-internal:8080/
  secret: "SharedSecretWithMAS"

4. Reverse Proxy Changes
These Matrix endpoints must be routed to MAS (not Synapse):

• /_matrix/client/*/login
• /_matrix/client/*/logout
• /_matrix/client/*/refresh

5. User Migration (For Existing Deployments)
MAS includes syn2mas tool to migrate:

• Existing password hashes (bcrypt → argon2id)
• Sessions and devices
• Access tokens
• Upstream IdP mappings

Updated Elastic to v9.1.5
https://git.due.ren/andreas/elasticsearch-cloudron/releases/tag/v9.1.5

I could use some help with this packaging attempt (just ignore the messy code). I can not get encryption working for some reason. This may have something to do with my current matrix installation so I'd be interested in someone else's expertise and experience

Looks like they have expanded the documentation for self-hosting: https://help.ente.io/self-hosting/

One feature I believe would be useful is some sort of locking mechanism. Basically another layer of confirmation between deleting applications. So If I lock an application, no one should be able to delete it via the UI or API, unless the lock is removed.

Updated Ente Package: andreasdueren/ente-cloudron:0.5.7

• Passkeys and Accounts now load properly.
• Share/embed/payments bundles ship with the image, their URLs are rewritten, and Caddy serves them via dedicated hosts and the manifest exposes those hostnames so you can configure them.

This is now called Spacebar https://github.com/spacebarchat

I spun up a test instance and it looks really polished and fast. I'm not a developer but seems to be fairly simple with few dependencies. Written in rust, PostgreSQL support.

Absolute extensive feature list, including encryption at rest, E-Mail delivery debugging, telemetry and much more.

Most if not all things can be configured in the GUI after setup. The biggest Problem at that point really is locking down the server against improper use, which is something cloudron already does pretty well. I'd love to see this in the App Store.

Currently attempting to package this. Frontend and backend are loading but not connecting to each other yet. Will have to investigate when I have a little time.

I packaged it and seems to work without issues: https://git.due.ren/andreas/keila-cloudron Happy about testers for feedback.