Cloudron Forum

Hello,

Thank you for packaging n8n. I've been playing a bit with it and tried to send an email. I'd liked it to be able to send emails like any other application.

This took a bit of fiddling, so I thought to write it up. Also, since it is not obvious how to do it, I would like this to be added to the n8n cloudron documentation so that the next user does not have to do the same research as I had to do.

---

When setting up the email credentials, an expression is required for each of the fields:

• User: {{$env["CLOUDRON_MAIL_SMTP_USERNAME"]}}
• Password: {{$env["CLOUDRON_MAIL_SMTP_PASSWORD"]}}
• Host: {{$env["CLOUDRON_MAIL_SMTP_SERVER"]}}
• Port: {{$env["CLOUDRON_MAIL_SMTP_PORT"]}}
• SSL/TLS: disabled

To set an expression, click the gear icon next to the field, and click Add expression.

Then, in the expression field, paste the expression as listed before. The warning in red can be ignored, this will work fine when executing it.

Then, in a Send Email node, set the From Email field to the following expression: My App <{{$env["CLOUDRON_MAIL_FROM"]}}>.

This will send an email with the name My App, and the address that is set in the cloudron settings.

Then, if you have set up the To and Subject, when you execute the node, you should get an email.

Hi,

I just came across these two posts:

• https://github.com/AgainstTheWest/NginxDay
• https://www.nginx.com/blog/addressing-security-weaknesses-nginx-ldap-reference-implementation/

Apparently, there is a flaw in the nginx-ldap-auth module.

I know that Cloudron uses nginx a lot, and LDAP as well, so I wanted to make you aware of this.

I lack the knowledge to determine whether Cloudron is vulnerable.

Could you please investigate and remediate if necessary?

Thanks!

Hi,

I just moved to a new machine. As usual, the restoration process went fairly smoothly.

There is one issue remaining though, impacting two apps.

Both were configured to use an external media mount (the kind that is included in backup), which was a secondary disk. That disk is unavailable on the new machine.

For these two apps, the restoration failed, because it this disk could not be found. I tried to set the apps storage to use the default storage, but I couldn't because they are in error state.

What do I need to do to fix this issue and get the apps up-and-running again with their data?

Output of cloudron-support --troubleshoot

Vendor: QEMU Product: Standard PC (Q35 + ICH9, 2009)
Linux: 6.8.0-107-generic
Ubuntu: noble 24.04
Execution environment: kvm
Processor: Intel(R) Core(TM) i7-7700 CPU @ 3.60GHz
BIOS pc-q35-10.2  CPU @ 2.0GHz x 4
RAM: 12177808KB
Disk: /dev/sda2        45G
[OK]    node version is correct
[OK]    IPv6 is enabled and public IPv6 address is working
[OK]    docker is running
[OK]    docker version is correct
[OK]    MySQL is running
[OK]    netplan is good
[OK]    DNS is resolving via systemd-resolved
[OK]    unbound is running
[OK]    nginx is running
[OK]    dashboard cert is valid
[OK]    dashboard is reachable via loopback
[OK]    No pending database migrations
[OK]    Service 'mysql' is running and healthy
[OK]    Service 'postgresql' is running and healthy
[OK]    Service 'mongodb' is running and healthy
[OK]    Service 'mail' is running and healthy
[OK]    Service 'graphite' is running and healthy
[OK]    Service 'sftp' is running and healthy
[OK]    box v9.1.5 is running
[OK]    Dashboard is reachable via domain name
[WARN]  Domain <redacted> expiry check skipped because whois does not have this information

Excerpt from the app log:

2026-04-02T22:00:31.732Z tasks: updating task 20419 with: {"percent":65,"message":"Downloading 15488M@6MBps"}
2026-04-02T22:00:38.028Z tasks: updating task 20419 with: {"percent":65,"message":"Still downloading backup (3721s, 15488M)"}
2026-04-02T22:00:41.737Z tasks: updating task 20419 with: {"percent":65,"message":"Downloading 15552M@6MBps"}
2026-04-02T22:00:50.832Z backupformat/tgz: tarExtract: extracted 217597 entries
2026-04-02T22:00:50.833Z backupformat/tgz: tarExtract: pipeline finished: {"startTime":1775163517410,"duration":3733423,"transferred":16364142900}
2026-04-02T22:00:50.833Z backuptask: downloadApp: time: 3751.965
2026-04-02T22:00:50.833Z tasks: updating task 20419 with: {"percent":70,"message":"Restoring addons"}
2026-04-02T22:00:51.395Z services: restoreAddons: restoring ["postgresql","ldap","sendmail","oidc","redis","localstorage","scheduler","turn"]
2026-04-02T22:00:51.396Z services: Restore postgresql
2026-04-02T22:02:41.597Z services: Setting up LDAP
2026-04-02T22:02:41.726Z services: Setting up SendMail
2026-04-02T22:02:41.727Z services: Setting sendmail addon config to [{"name":"CLOUDRON_MAIL_SMTP_SERVER","value":"mail"},{"name":"CLOUDRON_MAIL_SMTP_PORT","value":"2525"},{"name":"CLOUDRON_MAIL_SMTPS_PORT","value":"2465"},{"name":"CLOUDRON_MAIL_STARTTLS_PORT","value":"2587"},{"name":"CLOUDRON_MAIL_SMTP_USERNAME","value":"nextcloud.app@<redacted>"},{"name":"CLOUDRON_MAIL_SMTP_PASSWORD","value":"<redacted>"},{"name":"CLOUDRON_MAIL_FROM","value":"nextcloud.app@<redacted>"},{"name":"CLOUDRON_MAIL_DOMAIN","value":"<redacted>"}]
2026-04-02T22:02:41.761Z services: Setting up OIDC
2026-04-02T22:02:41.787Z services: Restoring redis
2026-04-02T22:02:41Z [POST] /restore
2026-04-02T22:02:41Z restoring
2026-04-02T22:02:42Z 13:M 02 Apr 2026 22:02:42.062 * BGSAVE done, 0 keys saved, 0 keys skipped, 88 bytes written.
2026-04-02T22:02:42Z 13:M 02 Apr 2026 22:02:42.062 * Saving the final RDB snapshot before exiting.
2026-04-02T22:02:42Z 13:M 02 Apr 2026 22:02:42.062 * User requested shutdown...
2026-04-02T22:02:42Z 13:M 02 Apr 2026 22:02:42.208 # Redis is now ready to exit, bye bye...
2026-04-02T22:02:42Z 13:M 02 Apr 2026 22:02:42.208 * DB saved on disk
2026-04-02T22:02:42Z 13:M 02 Apr 2026 22:02:42.208 * Removing the pid file.
2026-04-02T22:02:42Z 13:signal-handler (1775167362) Received SIGTERM scheduling shutdown...
2026-04-02T22:02:42Z 2026-04-02 22:02:42,019 INFO waiting for redis to stop
2026-04-02T22:02:42Z 2026-04-02 22:02:42,210 INFO stopped: redis (exit status 0)
2026-04-02T22:02:42Z 2026-04-02 22:02:42,997 INFO spawned: 'redis' with pid 46
2026-04-02T22:02:43Z 46:C 02 Apr 2026 22:02:43.017 # WARNING Memory overcommit must be enabled! Without it, a background save or replication may fail under low memory condition. Being disabled, it can also cause failures without low memory condition, see https://github.com/jemalloc/jemalloc/issues/1328. To fix this issue add 'vm.overcommit_memory = 1' to /etc/sysctl.conf and then reboot or run the command 'sysctl vm.overcommit_memory=1' for this to take effect.
2026-04-02T22:02:43Z 46:C 02 Apr 2026 22:02:43.017 * Configuration loaded
2026-04-02T22:02:43Z 46:C 02 Apr 2026 22:02:43.017 * Redis version=8.4.0, bits=64, commit=00000000, modified=1, pid=46, just started
2026-04-02T22:02:43Z 46:C 02 Apr 2026 22:02:43.017 * oO0OoO0OoO0Oo Redis is starting oO0OoO0OoO0Oo
2026-04-02T22:02:43Z 46:M 02 Apr 2026 22:02:43.018 # Failed to write PID file: Permission denied
2026-04-02T22:02:43Z 46:M 02 Apr 2026 22:02:43.018 * Increased maximum number of open files to 10032 (it was originally set to 1024).
2026-04-02T22:02:43Z 46:M 02 Apr 2026 22:02:43.018 * Running mode=standalone, port=6379.
2026-04-02T22:02:43Z 46:M 02 Apr 2026 22:02:43.018 * monotonic clock: POSIX clock_gettime
2026-04-02T22:02:43Z 46:M 02 Apr 2026 22:02:43.019 * Loading RDB produced by version 8.4.0
2026-04-02T22:02:43Z 46:M 02 Apr 2026 22:02:43.019 * RDB age 14982 seconds
2026-04-02T22:02:43Z 46:M 02 Apr 2026 22:02:43.019 * RDB memory usage when created 37.47 Mb
2026-04-02T22:02:43Z 46:M 02 Apr 2026 22:02:43.019 * Server initialized
2026-04-02T22:02:43Z 46:M 02 Apr 2026 22:02:43.171 * DB loaded from disk: 0.153 seconds
2026-04-02T22:02:43Z 46:M 02 Apr 2026 22:02:43.171 * Done loading RDB, keys loaded: 29201, keys expired: 53.
2026-04-02T22:02:43Z 46:M 02 Apr 2026 22:02:43.171 * Ready to accept connections tcp
2026-04-02T22:02:44.212Z tasks: updating task 20419 with: {"percent":80,"message":"Creating container"}
2026-04-02T22:02:44.241Z apptask: createContainer: creating container
2026-04-02T22:02:44.246Z shell: mounts: mountpoint -q -- /mnt/volumes/d8d52065be8d499f85c1e566498693bb
2026-04-02T22:02:44.260Z shell: mounts: mountpoint -q -- /mnt/volumes/d8d52065be8d499f85c1e566498693bb errored BoxError: mountpoint exited with code 32 signal null
2026-04-02T22:02:44.261Z shell: mounts: systemd-escape -p --suffix=mount /mnt/volumes/d8d52065be8d499f85c1e566498693bb
2026-04-02T22:02:44.273Z shell: mounts: journalctl -u mnt-volumes-d8d52065be8d499f85c1e566498693bb.mount\n -n 10 --no-pager -o json
2026-04-02T22:02:44.286Z apptask: run: app error for state pending_restore: BoxError: Storage volume "External Data" is not active. Could not determine mount failure reason. 
2026-04-02T22:02:44.325Z tasks: setCompleted - 20419: {"result":null,"error":{"message":"Storage volume \"External Data\" is not active. Could not determine mount failure reason. ","reason":"Bad State"},"percent":100}
2026-04-02T22:02:44.325Z tasks: updating task 20419 with: {"completed":true,"result":null,"error":{"message":"Storage volume \"External Data\" is not active. Could not determine mount failure reason. ","reason":"Bad State"},"percent":100}
2026-04-02T22:02:44.342Z Exiting with code 0
2026-04-02T22:02:44.342Z taskworker: Task took 4088.725 seconds
2026-04-02T22:02:44Z 2026-04-02 22:02:44,173 INFO success: redis entered RUNNING state, process has stayed up for > than 1 seconds (startsecs)
2026-04-04T10:05:01Z [GET] /healthcheck
BoxError: Storage volume "External Data" is not active. Could not determine mount failure reason. 
pipeFileToRequest: piped /home/yellowtent/appsdata/b62559e1-63a2-443c-8afc-cf91c3f4faab/dump.rdb, waiting for response
pipeFileToRequest: piped /home/yellowtent/appsdata/b62559e1-63a2-443c-8afc-cf91c3f4faab/postgresqldump, waiting for response
pipeFileToRequest: piping /home/yellowtent/appsdata/b62559e1-63a2-443c-8afc-cf91c3f4faab/dump.rdb
pipeFileToRequest: piping /home/yellowtent/appsdata/b62559e1-63a2-443c-8afc-cf91c3f4faab/postgresqldump
pipeFileToRequest: response status code 200
pipeFileToRequest: response status code 200
pipeFileToRequest: success
pipeFileToRequest: success
}
}

@jdaviescoates said in Invidious: an alternative front-end to YouTube:

@loudlemur said in Invidious: an alternative front-end to YouTube:

The maintainer ceased developing it

I'd like this too, but that's a bit of a red flag.

Generally Cloudron only likes to include actively maintained apps, for good reason really.

It might be that the original creator stopped developing it, but a quick look at the repository shows active development. So it seems that it is actively maintained.

Sure, I just did.

Hi,

I have another question regardiing this. The following is the output of docker system df.

$ docker system df
TYPE                TOTAL               ACTIVE              SIZE                RECLAIMABLE
Images              34                  16                  9.857GB             6.508GB (66%)
Containers          21                  18                  0B                  0B
Local Volumes       160                 36                  5.274GB             3.964GB (75%)
Build Cache         0                   0                   0B                  0B

As you can see, docker claims that a lot of storage is reclaimable.

Is it safe to run docker volume prune and docker image prune?

I've wished for OAuth support for quite a few times already to support SSO to non-Cloudron apps. So in that case, Cloudron would serve as the identity provider for a third-party app. Kind of like Login with Cloudron.

That would require that one can register third party apps with their client id, client secret and callback URL though.

I have a little bit of experience with Keycloak. I know that U=using Keycloak would (also) support this use case, provided a Cloudron user has access to the Keycload administration interface.

That worked, this is solved now. Thank you.

I have tried this a few months ago as well.

The next blocker is that the setup code does some domain IP validation, and refuses to continue of there are no IPv4 addresses available. I worked around it in the setup code of the box project on my machine, but that is of course highly discouraged . Sadly, I lost that code (it wasn't too bad). I'm not entirely sure whether it works with a private IPv4. I haven't tested that. I don't think so though.

Once the box supports primary IPv6, then the rest will more or less work. Because it support IPv6 mostly fine after setup. Thinks like the web front-end, and mail all work with IPv6.

Individual apps may or may not work if they do something other than standard HTTP(S). The OpenVPN app for example does not work correctly yet. At least it does not route IPv6 through the tunnel, possibly because the Docker containers are all IPv4-only.

@thetomester13 Thanks I'm glad I've been of help!

@girish Sorry for reopening this after quite a while.

If have the exact same problem when I am not using the docker client, but the RedHat-built containers projects (podman / skopeo / buildah / etc).

The solution is the exact same patch, but then with container instead of docker. I tried to create a pull request for it, but apparently I have no right to fork the box code and make one.

Either way, on my server, the code looks like this now:

in nginxcoonfig.ejs:

    location @proxy-auth-login {
        if ($http_user_agent ~* "docker") {
            return 401;
        }
        if ($http_user_agent ~* "container") {
            return 401;
        }
        return 302 /login?redirect=$request_uri;
    }

in proxyauth.js

function isBrowser(req) {
    const userAgent = req.get('user-agent');
    if (!userAgent) return false;

    // https://github.com/docker/engine/blob/master/dockerversion/useragent.go#L18
    return !userAgent.toLowerCase().includes('docker') && !userAgent.toLowerCase().includes('container');
}

Would it be possible to patch this too with the next box release?

On the Cloudron blog, when the dark mode is enabled, the links are barely readable.

I suggest using a lighter colour for the links in that case.

@girish I have tested this (just the HTTPS applications though, but that's the majority), and that works fine.

Not sure about the non-HTTPS applications though, like VPN, AdGuard and so on.

Also, if this gets more development, I'd be quite happy to help test it.

Hi, I have encountered this bug once more, with the following user agents:

• Podman: libpod/<version>
• Skopeo: skopeo/<version>

@girish Would it be possible to add those as well? That would be much appreciated.

In src/proxyAuth.js

// someday this can be more sophisticated and check for a real browser
function isBrowser(req) {
    const userAgent = req.get('user-agent');
    if (!userAgent) return false;

    // https://github.com/docker/engine/blob/master/dockerversion/useragent.go#L18
    return !userAgent.toLowerCase().includes('docker') && !userAgent.toLowerCase().includes('container') && !userAgent.toLowerCase().includes('libpod') && !userAgent.toLowerCase().includes('skopeo');
}

In src/nginxconfig.ejs

    location @proxy-auth-login {
        if ($http_user_agent ~* "docker") {
            return 401;
        }
        if ($http_user_agent ~* "container") {
            return 401;
        }
        if ($http_user_agent ~* "libpod") {
            return 401;
        }
        if ($http_user_agent ~* "skopeo") {
            return 401;
        }

        return 302 /login?redirect=$request_uri;
    }

@joseph It took a while, and one of the two is now restored.

I have an issue still with Immich though: it seems that the container version that was specified in the backup cannot be found:

No such image: cloudron/app.immich.cloudronapp:202603270614470000

Apr 08 00:11:43 apptask: createContainer: creating container
Apr 08 00:11:43 apptask: run: app error for state pending_import: BoxError: (HTTP code 404) no such container - No such image: cloudron/app.immich.cloudronapp:202603270614470000
Apr 08 00:11:43 tasks: setCompleted - 20478: {"result":null,"error":{"message":"(HTTP code 404) no such container - No such image: cloudron/app.immich.cloudronapp:202603270614470000 ","reason":"Docker Error"},"percent":100}
Apr 08 00:11:43 tasks: updating task 20478 with: {"completed":true,"result":null,"error":{"message":"(HTTP code 404) no such container - No such image: cloudron/app.immich.cloudronapp:202603270614470000 ","reason":"Docker Error"},"percent":100}

So now I'm stuck again.

Since I've run a PowerDNS Authoritative DNS for quite a while now, I've been interested in this feature as well. Cloudron not supporting this is the only thing that has prevented me to move my cloudron-managed domains away from cloud providers.

I've made several private integrations with the API in the past, but Javascript has held me back from trying my hand at this for Cloudron. Now, with the help of an LLM, I probably have a working implementation. At least it looks good from the API calls perspective.

So I have two questions for staff:

1. How can I test it (preferably on a fresh VM, so as to not put my production Cloudron in jeopardy)? I could not really find build/test/deploy instructions in the box repo.

2. Would you be interested in this implementation if it is tested and works? If you are, I fully intend to give you this code under the terms of your license as show in the box repo. It's in a private repo for now since I seem to have lost the account I once had on git.cloudron.io.

Thank you in advance!

@girish, I noticed when using OIDC that on the authorize page there is no possibility to switch the user account. In other words: once logged in with a specific user, one is always logged in with that user, unless one manually figures out the logout endpoint for OIDC.

Would it be possible to add a logout or switch user button the the OIDC authorization page?

There has been a long discussion about Keycloak in the Keycloak & Cloudron topic.

From a quick scan, it seems that at least someone got it working: https://forum.cloudron.io/post/44783.

@girish Minor thing, but the links to the "Full Changelog" entries for the last releases seem to go to random Github user profiles.