Cloudron Forum

@necrevistonnezr I wonder why they went with Apache in the first place, if they didn't want that sort of thing to happen.

Here is our AIo repo:

https://forgejo.wanderingmonster.dev/WanderingMonster/AIo

We spent a lot of time on considering how to document our projects taking into account AI.

It is easiest to try with a greenfield (new) coding project, but the AIo spec also shows how to introduce it to a brownfield (pre-existing) project, too.

We hope you like the cool artwork and might like to try using some of the procedures there. We have been working on this for half a year or so.

I think AI for documentation is a strong way forward and I hope Cloudron experiments with it. A clear template works wonders for having the AI conform to a standard style of presentation. The burden falls on creating/finding an exemplary model which the AI can follow, and then providing a couple of iterations to tweak it with some human feedback.

Readability was mentioned by @girish. We naturally assume human readability is meant here, and that is important. In the future, increasingly larger amounts of code will be created, debugged, documented and maintained by AI. (We think of this as being AI-Forward.) The distinction between documentation and code is becoming blurred, as AI coders are using the documentation as instructions. We should consider AI agents as part of the readership and perhaps consider them as 1st Class Citizens (!), when we create documentation.

We have been investigating this area and to keep discussion going, here are 6 suggestions for making documentation better suited for AI.

(SPOILER ALERT - Shield your eyes, this is AI generated!)

Six things that make docs genuinely useful to AI

• One document, one job. Tutorial, how-to, reference, or explanation — never mixed. A page that switches modes halfway retrieves badly and gets summarised wrong.

• Put the metadata at the top. Title, purpose, audience, status, and last-updated date in a header block. This is what lets a tool decide whether the page is relevant before reading it.

• Say the context out loud. Prerequisites, assumptions, and where this sits relative to everything else. A model has no hallway to ask in — anything "everyone knows" is invisible to it.

• Write in self-contained chunks. Descriptive headings, one idea per section, no "as mentioned above". Retrieval hands over fragments, not whole documents, so each fragment has to stand alone.

• Be exact and executable. Real file paths, real commands, real values — no placeholders, no "adjust as needed". Anything ambiguous gets guessed, and a confident wrong guess costs more than a gap.

• Don't restate what the source already says. Directory trees, function signatures, and config keys are read directly and go stale fast. Document the why — intent, constraints, dead ends — which is the part nothing else records.

The last one is usually the least intuitive to a room and the highest-leverage: most teams' docs are ~40% restated structure that the tool would rather read from the source anyway.

@p44 said:

. I hope it can be documented more thoroughly

What do you think about ai being used to create documentation?

@marcusquinn said:

We're pretty-much now in the age of: "I'll have my AI speak to your AI, and TLDR me the results."

Wild times.

It is like Hollywood: "I'll have my people talk to your people and we can figure out a time to have lunch."

@necrevistonnezr has a valid point, too. What else can we do, though? "Understand it better?" This problem meant people were not receiving emails. Not sending a bug report, particularly when the ai had found a fix, didn't seem public spirited. It also is a bit like self-censorship.

On the other hand, Cloudron has a policy about no AI generated text in the forum. This is just one case where there is an AI bug report. @girish kindly found the time to investigate it. In the future, there may be many AI bug reports and human intervention might not be able to handle them all.

There are arguments for and against both sides. It does seem rude though to paste a load of AI and expect a human to look at it. I know what you mean.

---

Category: Support / Mail

---

@staff could you please take a look at this as mail is not working?

Cloudron 9.0.0, mail image cloudron/mail:4.3.5.

After a reboot of a reasonably busy server, inbound mail was dead for nearly three hours. The dashboard showed the mail service healthy for all of it. There are four separate issues tangled together here, and the last two are what turned a bad morning into a long one.

1. A slow Solr start takes Haraka and Spamd down with it

services.js starts things in this order:

async function start() {
    await dovecot.start(); // start this before solr in case the fts has to be re-indexed
    await fts.start();
    await haraka.start();
    await spamd.start();
    ...
}

On our boot, Solr exceeded the readiness timeout:

08:55:47  Error: Could not verify fts readiness: Timed out waiting for solr/tika readiness
            at Object.start (/app/code/fts.js:286:27)
            at async Object.start (/app/code/services.js:32:5)
08:57:26  solr core "dovecot" comes up normally (14,093 docs)

Solr was fine, just about a hundred seconds slower than the check allowed, because the whole box was contending after a reboot. But the throw propagated out of start(), so haraka.start() and spamd.start() never ran:

dovecot        RUNNING
haraka         STOPPED   Not started
spamd          STOPPED   Not started
mail-service   RUNNING
solr           RUNNING
tika           RUNNING

Full-text search is a search index. It seems wrong for it to be a hard prerequisite of SMTP. Could fts.start() be made non-fatal, logging and continuing with a background retry, or simply moved after haraka.start()? Either would have turned a three-hour mail outage into a temporarily degraded search box.

2. The healthcheck reports green while all mail is being rejected

Throughout the outage, and afterwards in the broken state described below:

{"status":true,"haraka":{"status":true},"dovecot":{"status":true},"spamd":{"status":true},
 "redis":{"status":true},"solr":{"status":true},"tika":{"status":true}}

This is because getHealth() is process liveness only:

const out = safe.child_process.execSync(`supervisorctl status ${program} | grep RUNNING`, ...);
health[program].status = out && out.includes('RUNNING');

A running Haraka that rejects every recipient is reported exactly like a working one. Would it be reasonable for the healthcheck to assert that /run/haraka/config/host_list is non-empty whenever at least one domain has inbound set? That single check would have caught both this and issue 3.

3. Starting Haraka by hand skips config generation, and makes things worse

Seeing haraka STOPPED, the obvious operator move is:

docker exec mail supervisorctl start haraka spamd

Both come up RUNNING, the healthcheck goes green, and SMTP answers on 25 and 587. It looks fixed. It is not. haraka.start() is not just supervisorctl start haraka:

async function start() {
    const [syncConfigError] = await safe(syncConfig());
    if (syncConfigError) throw new Error(...);
    safe.child_process.execSync('supervisorctl start haraka', ...);
}

syncConfig() is what writes /run/haraka/config/host_list and populates the DKIM runtime directory. Starting the daemon directly skips it, so Haraka runs with an empty host list and no DKIM keys. The result:

RCPT TO:<valid-mailbox@example.com>     550 I cannot deliver mail for <valid-mailbox@example.com>
RCPT TO:<nosuchuser@example.com>        550 No such address

Note the asymmetry, which is what misled us for a while: the invalid address gets the correct "No such address" from the cloudron plugin, proving the plugin is loaded and knows the domain. The valid address falls through to Haraka's core rejection in connection.js, because the cloudron plugin calls plain next() for a good mailbox and relies on rcpt_to.in_host_list to accept it, and host_list is empty.

This state is worse than the service simply being down. With Haraka stopped, port 25 refuses connections and sending servers queue and retry for days, so nothing is lost. With Haraka running against an empty host list, every sender gets a permanent 550 and gives up. Mail is destroyed rather than delayed.

Two suggestions:

• Have Haraka refuse to serve, or exit, when host_list is empty while inbound domains are configured. Failing closed at connect level is far safer than 550-ing real mail.
• Consider a comment or a guard around the supervisorctl entries, since supervisorctl start haraka is the natural thing for an operator to type and it is silently wrong.

4. POST /mail/<domain>/inbound returns 202 without applying anything

Having worked out that the runtime config needed regenerating, the natural way to trigger it looks like a no-op write of a domain's existing inbound setting. It answers a confident 202 and does nothing relevant:

async function setDomainInbound(domain, enabled, auditSource) {
    const result = await database.query('UPDATE mail SET inbound = ? WHERE domain = ?', );
    if (result.affectedRows === 0) throw new MailError(...);
    await boxEventlog.add(...);
}

There is no call to restartHarakaService(). It is defined at domains.js:11 but called only from lines 92, 128 and 143, and the route returns 202 unconditionally. host_list stayed empty and Haraka's uptime never reset. Would it be worth having domain setters that change delivery-relevant state trigger a reconfigure, or at least not report success when nothing was applied?

The recovery, for anyone who lands here

The underlying config is untouched in the database; only Haraka's runtime copy is missing. A no-op write of the existing max email size triggers haraka.reconfigure(), which regenerates host_list and the DKIM keys and restarts Haraka, without touching Dovecot and without re-running the fts check. It also returns 503 with a real error if the reconfigure fails, rather than an unconditional success:

GET  /max_email_size?access_token=$CLOUDRON_MAIL_TOKEN     -> {"size":25000000}
POST /max_email_size?access_token=$CLOUDRON_MAIL_TOKEN
Body: {"size": 25000000}                                    (write back the same value)

Verify all three of these, because the first two can look right while mail is still broken:

cat /run/haraka/config/host_list      # your inbound domains
ls  /run/haraka/config/dkim           # one directory per domain
supervisorctl status haraka           # uptime MUST reset to seconds

A Haraka uptime that has not reset means the reconfigure did not run, whatever the HTTP code said. Then test a real recipient over SMTP. A valid mailbox must return 250 where it previously returned 550 I cannot deliver mail for, while a genuinely unknown address should still return 550 No such address.

One last note for anyone probing SMTP by hand: Haraka applies a greeting delay to unknown clients, so a short-timeout probe reports failure against a perfectly healthy server. Allow at least 20 seconds before concluding the port is dead.

@andreasdueren said:

I have successfully used NC Talk with the HPB and 30+ users

Hey, well done on that! It must have been a great call. Thanks for letting us know.

Lets see how long it takes to top this! I think you will have the record for quite a while.

Do you have any tips for managing such a large teleconference?

TL;DR: Unseen Servant publishes one folder of plain text to Gemini, Gopher, Spartan, Nex and Finger at once, and mirrors the same pages to the web. No build step, and nothing executed, ever. Human architected, AI coded. Packaged for Cloudron; unofficial and community-maintained; built and tested on Cloudron 9.x.

What it does

• Six surfaces, one content tree: Gemini on 1965 with Titan uploads on the same listener, the web mirror, and, each off until you switch it on, Gopher, Spartan, Nex and Finger.
• Rendering happens when a file changes, not per request. Save a page and it is live everywhere a couple of seconds later, with no second copy to keep in step. The rendered HTML tree is a self-contained static site you can copy anywhere.
• The cleartext protocols cannot leak gated content: anything behind a certificate zone is excluded from the Gopher, Spartan, Nex and Finger trees when they are built, because those protocols cannot authenticate a reader at all.
• Identity that survives the platform: the certificate is minted once per hostname and never silently replaced, through updates, backups, restores and domain moves, so readers who pinned it stay undisturbed.
• Agents are first class: an automated publisher presents a client certificate rather than a password or API key, every read-only command emits JSON, and /llms.txt with Markdown siblings serves machine readers.
• What it refuses, permanently: CGI, scripting, proxying, plugin APIs, an admin panel, and visitor address logging by default. Content is data, never code.
• The design started by reading the field: Agate's certificate lifecycle, Molly Brown's certificate zones, GmCapsule's Titan handling, gmid's testing discipline and the gopher servers' menu conventions, each credited in the repository with what was declined and why.

Links

• Project site: https://unseenservant.dev/
• Source and issues: https://forgejo.unseenservant.dev/unseen-servant/unseen-servant
• 🪞 GitHub mirror: https://github.com/OrcVole/unseen-servant

The site is the demonstration: the page you land on is served by the software, from one folder, on every protocol it supports, and its front page opens with the facts (version, licence, packages, networks, lineage) before it asks you to read a word of prose. Swap https:// for gemini:// on the same address and you are reading the same file.

How to install

Click the Add custom app dropdown (top right in the App Store) and choose Community app, then paste the CloudronVersions.json URL into the box that pops up. Apps installed this way receive automatic updates.

https://raw.githubusercontent.com/OrcVole/unseen-servant/main/CloudronVersions.json

Or with the CLI:

cloudron install \
  --versions-url https://raw.githubusercontent.com/OrcVole/unseen-servant/main/CloudronVersions.json \
  --location capsule.example.com

Minimums: 256 MiB RAM, localstorage only. No database, no extra subdomain. Cloudron 9.1 or newer.

First run: there is no login, which is the point: no admin panel means no credential to leak and no login page to probe. The app writes a starter capsule and serves it immediately; you edit the content folder through the dashboard's File Manager. The Gemini port is fixed at 1965 because every client assumes it; the other four protocols are optional ports in the app's settings, served above 1024 because their canonical ports are privileged.

For users

The small internet is genuinely nice to write for, and the usual barrier is that publishing there means picking one protocol and one server, then maintaining a second copy for people who only have a browser. Here one folder of plain text is the whole workflow: gemtext in, every surface out, within seconds of saving.

Good fit if you keep a gemlog, or want one, and would rather not run five daemons. Not a fit if you need a general-purpose web server: this one refuses dynamic anything, permanently and by design, and its own site will tell you which of Agate, gmid, Molly Brown or GmCapsule to run instead.

Cloudron specifics worth having: backups include the server identity, so a restore brings back the same certificate your readers pinned; all state is one directory under /app/data.

On authorship

Human architected, AI coded

What is offered instead of trust: every design decision recorded in writing before the code, the research published, a wire-level test suite, eight fuzzed parsers, and a conformance run against the live deployment. It is a first release and not independently audited; Agate and gmid have years of production hardening this does not, and the project's own comparison page says so.

🧰 For packagers: what we learned

What helped: the app is a single static binary with no database and no supervisor, so the whole package is a Dockerfile, a start.sh and the manifest; localstorage covered every persistence need.

What was tricky: four real ones. The conventional ports for Gopher, Finger and Spartan (70, 79, 300) are privileged and tcpPorts refuses them, so the package publishes 1024, 7979 and 3300 instead. Port 3000 is also refused as reserved, which is not in the manifest documentation and only surfaces as a 400 at install time. tcpPorts entries marked readOnly cannot be moved, which means two installs of this app cannot coexist on one box, correct here but worth knowing. And the health check has to stay green when an admin disables the Gemini port, or the app hangs in "Starting…" because of a protocol-side setting.

Still rough: the first install from a versions URL onto a fresh subdomain is the path with the least mileage on it, and confirmations from anyone who tries it are welcome.

️ For the Cloudron team

Maintenance burden: light. The package carries no patches, the binary has no runtime dependencies, and the scope is deliberately fixed: new protocols are a versioned decision, not organic growth.

Why it suits the App Store: the niche, the package is small: 256 MiB and a few megabytes on disk.

Friction worth knowing: the community-install validator requires iconUrl, mediaLinks and packagerUrl, none of which are in the manifest's own documented field list, and each is discovered as a separate 400 during install. iconUrl additionally forces minBoxVersion to 9.1.0 or newer, a compatibility floor imposed by a metadata field rather than by anything the app does. A single validation pass listing all missing fields at once would have saved several round trips.

Unlocks

A gemlog on your Cloudron that someone in Lagrange, someone in a gopher client from the nineties, and someone who only clicked a link in an email all read from the same files, with no second server and no publishing step.

Synergies

Unseen Servant + Forgejo or Gitea: keep the content in a git repository, pull it into the content folder, and the same tree is a website, a capsule and a gopherhole with no build between them.

Unseen Servant + Miniflux or FreshRSS: it writes Atom, so your own gemlog is subscribable in the reader you already run.

Unseen Servant + Surfer: if you already publish static HTML with Surfer, this adds the small-network surfaces from the same source files rather than replacing anything.

Feedback, bug reports, and "works on our install" confirmations all welcome.

@nostrdev said:

Your wish has been granted: https://ca.cloudron.io/app/wazuh

Well done on packaging this!

We did an automated look at whether Wazuh would be a suitable candidate for a cloudron package and the result was a resounding, "No!"

In case you are interested, according to our ai:

Our ai thought the resource floor for Wazuh exceeds and would dwarf the rest of a Cloudron's combined apps. It also thought it would be difficult to find a place for the agents to connect. Cloudron backups assume gigabytes not terrabytes. Upstream ships its own deployment tooling. Wazuh is a fork of a fork (it forks opensearch which is a fork of elastic search.)

Thank you and well done!

Adobe Fonts → Google Fonts ?

Adobe Fonts → Bunny Fonts!

https://fonts.bunny.net/

@fbartels said:

xyOps

Thank you, @fbartels!

It looks beautiful. That front end! https://xyops.io/

Semaphore UI is a web interface for Ansible. Playbooks, inventories, repositories, environments and schedules get a browser front end, so routine automation can be run and reviewed by people who are
not sitting at a terminal, and by people you would rather did not have your SSH keys.

It is not Semaphore CI. The name is shared with an unrelated continuous-integration product.

Headline features

• Ansible is in the image, not a prerequisite. The Ansible community bundle 9.2.0
  (ansible-core 2.16.3) and git ship inside, so a fresh install can clone a playbook repository
  and run it with nothing else installed anywhere.
• Cloudron single sign-on through the application's own OIDC support, not proxyAuth. That
  matters here: Semaphore has a full REST API and webhook triggers, and fencing the whole app behind
  a proxy would have broken both.
• Every install generates its own encryption keyring at first run. Upstream's default is either
  no key at all, which stores your SSH keys base64-encoded and calls it done, or the literal key
  published in their compose file. Neither ships here.
• Schedules, webhook integrations and a REST API, so playbooks can run on a cron, be triggered by
  another service, or be driven from your own tooling.
• Task concurrency capped at 10. Upstream defaults to 9999; since every task forks its own
  Ansible process, that default makes any memory limit theoretical.
• PostgreSQL through the platform addon. No bundled database to back up separately.

Links

Package repository: https://github.com/OrcVole/semaphore-cloudron

Versions feed: https://raw.githubusercontent.com/OrcVole/semaphore-cloudron/main/CloudronVersions.json

Upstream project: https://semaphoreui.com — source at https://github.com/semaphoreui/semaphore

How to install

The easiest route, and the one that gets you automatic updates: in the App Store, open the Add
custom app dropdown at the top right, choose Community app, and paste the versions URL above
into the box that appears.

https://raw.githubusercontent.com/OrcVole/semaphore-cloudron/main/CloudronVersions.json

️ Requirements and first run

Minimums: 1 GiB memory, addons localstorage, postgresql, oidc. No extra subdomain.

First run: an administrator is created for you. Open a Terminal for the app and run
cat /app/data/.initial-admin to get the password, sign in as admin, change it, then promote your
own account from Team → Users.

That last step is not optional bookkeeping. Accounts arriving through Cloudron single sign-on are external users and are never administrators, and upstream does not let non-administrators create
projects, so without promoting yourself, signing in with SSO leaves you looking at an empty app.

One more thing worth knowing: Semaphore's "disable password login" setting only hides the password
form. The login endpoint keeps accepting credentials. Treat the admin password as live.

Back up /app/data/keys. It holds the key that decrypts every credential the app stores. It is
inside Cloudron's normal backups, so the only way to lose it is to restore selectively, but if it does go, the app keeps running and looks healthy while every stored credential is permanently
unreadable. semaphore vaults check --config /run/semaphore/config.json tells you the truth; every
key should say active.

For users

Why try it: you have playbooks, and the people who need to run them keep asking you to run them.

What you get: a browser front end for playbooks, inventories and credentials; scheduled runs and webhook triggers; per-project members and permissions, so someone can run the deploy without holding the keys it uses.

Cloudron wins: single sign-on, TLS, backups and updates all handled by the platform, and the encryption key is generated per install rather than shared with everyone who downloaded the same compose file.

🧰 For packagers: what we learned

What helped the platform's postgresql and oidc addons covered the whole dependency list; nothing needed bundling. Existing community packages were the reference for the versions feed shape.

What was tricky:

• The runtime user's home is read-only, and Ansible wants $HOME/.ansible/tmp. It needs HOME, and
  separately ANSIBLE_REMOTE_TEMP — the second is the one that breaks module transfer, and a
  playbook using only debug will happily pass without revealing it.
• Semaphore runs tasks with a sanitised environment, forwarding only variables it is told to. So
  exporting from the start script does not reach Ansible; the configuration has to live somewhere the
  package owns, which is /etc/ansible/ansible.cfg.
• A platform restore returns /app/data owned by a different uid. Git then refuses every stored
  repository as "dubious ownership" and every task fails at the clone — while row counts, checksums,
  health and login all look perfect. The start script takes ownership of the whole volume.
• The PostgreSQL port belongs inside the host value as host:port; there is no separate port
  setting, and sslmode=disable is needed because the addon serves no TLS.

Still rough We would welcome a second pair of eyes on a cold install from the feed onto a fresh subdomain, and on behaviour with a large existing playbook repository.

️ For the Cloudron team

Maintenance burden: low. The package is a build of one Go binary plus Ansible from the distribution, with no patched application code, upstream releases drop straight in with a version bump. Upstream ships often, roughly fortnightly with point releases between.

Why it suits the App Store: Ansible is the obvious automation tool for exactly the audience that runs a Cloudron, and until now running it meant a terminal and a laptop that happened to be on. It uses the platform's own identity rather than reimplementing users, and it has no bundled datastore.

For Semaphore's developers

Thank you! The configuration surface is clean, the OIDC support is in the community build, and the keyring with vaults check and vaults rekey is a good piece of design that made the custody decision easy.

Two things we would raise: password_login_disable is not enforced at the login endpoint, only in the interface; and web/src/assets/logo.svg is a leftover from the Vue
scaffold rather than your mark, which is a small trap for anyone packaging you.

Unlocks

Server maintenance that someone other than you can run. Patch windows as a scheduled task rather than an evening. Credentials that live in one encrypted store instead of on four laptops.

Synergies

Semaphore + Gitea or Forgejo: keep playbook repositories on the same box that runs them; Semaphore clones over the internal network and never needs an outside git host.

Semaphore + Uptime Kuma: point a Kuma alert at a Semaphore webhook integration so a failed check triggers the remediation playbook instead of a notification you read in the morning.

Semaphore + n8n: n8n handles the branching and the approvals, Semaphore does the part that needs Ansible, called through its REST API.

Semaphore + Grafana: dashboards for the fleet, and the tool that changes the fleet, on the same
login.

Semaphore + ntfy: task results pushed to your phone, which is the difference between a scheduled
playbook you trust and one you check.

@andreasdueren The dev closed a feature request with a note explaining why:

https://github.com/baptisteArno/typebot.io/issues/734#event-29694236908

The maintainer has said they are no longer planning new features, product improvements or large internal projects. This will help keep the focus on bugs, security and compatiblity.

The ask, in one line

Add a manifest field to set an app container's /dev/shm size, in the same shape as the existing
memoryLimit.

What we hit

Our community package for vLLM updated from upstream 0.26.0
to 0.27.1. The new version runs its inference engine in a separate process and brokers work between
the two over a POSIX shared-memory ring buffer. It refuses to start if /dev/shm is too small:

RuntimeError: Insufficient space in /dev/shm: 160 MiB required, 62 MiB free.
Increase /dev/shm (e.g. --shm-size or --ipc=host).

A Cloudron app container gets a fixed 64 MiB, confirmed on two independent installs on two
different Cloudron servers (9.x and 8.3.x):

$ df -h /dev/shm
shm              64M   76K   64M   1% /dev/shm

We could find no way to change it: no manifest field, no CLI flag, and nothing in the app
configuration UI.

Why we think it is worth a platform change rather than a per-app workaround

The 64 MiB default is Docker's, and it predates the current generation of workloads. Anything using
PyTorch or Python multiprocessing shared memory, headless Chrome or Chromium (a very common
packaging target), or a database tuned with large shared buffers, runs into the same ceiling. In
every case the symptom is a confusing message from a library several layers down rather than
"your platform gives you 64 MiB", so the diagnosis is expensive each time. It cost us about
twenty minutes on a package we already understood well.

It is also the kind of limit that only bites on update. Our 0.26.0 install is healthy today. Had
we published 0.27.1 without catching this, every install would have updated into a container that
cannot boot at all — and because the app never becomes healthy, the failure presents as an install
problem rather than a resource one.

What we did instead, in case it is useful to others

vLLM can run its engine in-process, which never allocates the ring buffer. On a single-model,
single-replica CPU server that costs nothing, so our start.sh now measures the free space in
/dev/shm at boot and sets VLLM_ENABLE_V1_MULTIPROCESSING=0 when it is under 200 MiB, logging the
reason. It is written as a detection rather than a constant so the package returns to upstream's
default automatically if the platform limit ever rises.

That works, and we are shipping it. But it is a workaround chosen because the platform value is
fixed, and the next package to hit this may not have an equivalent escape hatch.

Suggested shape

{
  "memoryLimit": 10737418240,
  "shmSize": 268435456
}

Defaulting to today's 64 MiB, capped at some fraction of memoryLimit so it cannot be used to
evade memory accounting, and ignored by older boxes so manifests stay backward compatible.

Happy to test a build.

@BrutalBirdie said:

Here you go: https://ca.cloudron.io/app/tachyon

Hey, BrutalBirdie, that is great and thank you very much! I think many here might like to know how it goes if you already have SnappyMail up and running on Cloudron and want to switch over to your Tachyon. Is easy to do? How is the new GUI for Tachyon by the way?

Could Cloudron allow apps to request privileged tcpPorts (<1024), or document the restriction?

This is absent from the manifest docs. Does an exception mechanism exist?

Is displacing the built-in mail stack ever supported?

These enquiries relate to the recent thread discussing SnappyMail not receiving many updates anymore, and looking around for alternative mail servers to package for Cloudron, e.g. Stalwart:

https://stalw.art/mail-server/