What are your thoughts on removing the app proxy limit as a vehicle to help market/promote Cloudron and get people into the ecosystem?

@markpousee have you already set the proxy server as a Trusted IP on cloudron - https://docs.cloudron.io/networking/#trusted-ips ? Though, I cannot think of why nginx is automatically restarting . TBH, I have never seen nginx crash. This makes me wonder if something in your setup (compose?) is monitoring nginx responses (some healtcheck?) and restarting nginx automatically ? If you have a test Cloudflare, you can quickly put Cloudflare in front of Cloudron and check if that works. After all, your proxy is same as Cloudflare functionally.

That makes sense.

@marcusquinn ooops, well caught, sorry

@micmc Node apps run fine too, you just need to set the right ENV vars and adjust the startup script as well as the apache config to correctly route to the node app on port 3000 or whatever the code expects.

Oh, I just rebooted it again, and it seems to be all services / apps are running. Thanks

@humptydumpty yes, this is already fixed in 9.0. In addition, the update information is available as part of each app object as well (in the REST response).

Not a bad concept. Doesn't need dedicated hardware, might be able to run on the build/demo server or other sponsoring org. Integrate with CCAI upgraded to a distributed DB or some master/share topology to keep a running list of all custom packages successfully installed and make them available to everyone else.

To me it would be a selfhosted solution / load balancing peace of mind thing. That said I haven't really seen the server struggle to do anything for my less than 10 connections simultaneously. I'm not sure what the capacity for a single server would be, if I avoid apps that are CPU heavy, just use nextcloud for file sharing.

Setup Overview In this setup, I will be using Nginx Proxy Manager, but these instructions will also apply to other reverse proxy setups. The goal is to proxy Cloudron traffic via Anubis without disrupting the existing Cloudron installation. To achieve this, I’ll be utilizing a second VPS to deploy Anubis and to proxy traffic. This arrangement allows to proxying of selected apps through Anubis instead of the entire server. Note: This setup will not work for apps on Cloudron that require additional ports to be forwarded, beyond just port 443. VPS Configuration VPS 1: This VPS runs Cloudron with the apps you want to proxy. VPS 2: This VPS runs Ubuntu Server and hosts three Docker containers: Nginx Proxy Manager: This acts as the reverse proxy for traffic going to Anubis. Anubis: This container forwards valid requests to the Cloudron server on VPS 1. Redis: Anubis stores completed challenge data in memory by default, which is lost on restart. The Redis container provides persistent storage for this data, ensuring that Anubis retains challenge information between restarts. The following steps assume that Docker is installed and the user is familiar with deploying a Docker Compose file. VPS 2 Docker Compose See below for docker compose for above mentioned container stack. I've made comments below where modification's required. For additional information on Anubis Variables, visit this link. services: ngixn-proxy-manager: image: jc21/nginx-proxy-manager:latest container_name: npm restart: unless-stopped ports: - "127:.0.0.1:80:80" - "443:443" - "127:.0.0.1:81:81" volumes: - /home/appdata/npm/data:/data #Change this path for npm data as required - /home/appdata/npm/letsencrypt:/etc/letsencrypt #Change this path for npm certs as required networks: - anubis-cloudron anubis-cloudron-redis: image: redis:8-alpine container_name: anubis-cloudron-redis restart: always volumes: - redis_data:/data networks: - anubis-cloudron anubis-cloudron: image: ghcr.io/techarohq/anubis:latest container_name: anubis-cloudron ports: - "127.0.0.1:10000:10000" #This port can be utilised with a prometheus container for Anubis metrics - "127.0.0.1:8300:8300" #The network port that Anubis listens on. pull_policy: always restart: always depends_on: - anubis-cloudron-redis environment: BIND: ":8300" #The network port that Anubis listens on. DIFFICULTY: "4" #The difficulty of the challenge METRICS_BIND: ":10000" # Prometheus Metrics Port SERVE_ROBOTS_TXT: "true" #If set true, Anubis will serve a default robots.txt file that disallows all known AI scrapers. POLICY_FNAME: "/data/cfg/botPolicy.yaml" # Config file Internal location. This can be left as it is. TARGET: "https://<CLOUDRON-VPS-IP-ADDRESS>" #Change this to the IP address of Cloudron Server. TARGET_INSECURE_SKIP_VERIFY: "true" #Skip TLS certificate validation for targets that listen over https. This is required. REDIRECT_DOMAINS: "app1.example.cloud, app2.example.cloud" #These should match the current cloudron app sub domains. This can be expanded as required. COOKIE_DYNAMIC_DOMAIN: "true" #If set to true, automatically set cookie domain fields based on the hostname of the request. COOKIE_EXPIRATION_TIME: "168h" #The amount of time the authorization cookie is valid for. COOKIE_SECURE: "true" ED25519_PRIVATE_KEY_HEX: "4e7d024d97030b8e80f89de052494b31ff799d0ee83c238c6f22d01979ba8b54" #This is a sample key. Generate a new key by running 'openssl rand -hex 32' and paste it here OG_PASSTHROUGH: "false" #If set to true, Anubis will enable Open Graph tag passthrough. volumes: - "/home/appdata/anubis/cloudron.yaml:/data/cfg/botPolicy.yaml:ro" # Config file location. Change this to the location of file below in section below. This is to be manually created. networks: - anubis-cloudron volumes: redis_data: networks: anubis-cloudron: driver: bridge Anubis - Config file Below's the configuration file which I'm utilising for Cloudron. This setup allows both Mastodon and Pixelfed to be behind Anubis. Modify the configuration file as required depending on your Cloudron services and change mapping of config file path on docker compose file based on where this file is saved. - import: (data)/bots/ai-robots-txt.yaml - import: (data)/bots/cloudflare-workers.yaml - import: (data)/bots/headless-browsers.yaml - import: (data)/bots/us-ai-scraper.yaml - import: (data)/crawlers/googlebot.yaml - import: (data)/crawlers/bingbot.yaml - import: (data)/crawlers/duckduckbot.yaml - import: (data)/crawlers/qwantbot.yaml - import: (data)/crawlers/internet-archive.yaml - import: (data)/crawlers/kagibot.yaml - import: (data)/crawlers/marginalia.yaml - import: (data)/crawlers/mojeekbot.yaml - import: (data)/clients/git.yaml - import: (data)/common/keep-internet-working.yaml - name: allow-uptime-kuma user_agent_regex: Uptime-Kuma.* action: ALLOW - name: allow-api path_regex: ^/api/ action: ALLOW - name: allow-assets action: ALLOW path_regex: \.(eot|ttf|woff|woff2|css|js|jpg|jpeg|png|mp4|webp|svg)$ - name: allow-website-logos action: ALLOW path_regex: ^/hareen/website-logos/.*$ - name: allow-well-known path_regex: ^/.well-known/.*$ action: ALLOW - name: allow-mastodon-actors-objects path_regex: ^/users/[^/]+(/.*)?$ action: ALLOW - name: allow-shared-inbox path_regex: ^/inbox$ action: ALLOW - name: allow-pixelfed-actors-objects path_regex: ^/@[^/]+(/.*)?$ action: ALLOW - name: allow-user-inbox path_regex: ^/@[^/]+/inbox$ action: ALLOW - name: allow-nodeinfo-webfinger path_regex: ^/\\.well-known/(host-meta|webfinger|nodeinfo.*)$ action: ALLOW - name: generic-browser user_agent_regex: >- Mozilla|Opera action: CHALLENGE dnsbl: false thresholds: - name: minimal-suspicion expression: weight <= 0 action: ALLOW - name: mild-suspicion expression: all: - weight > 0 - weight < 10 action: CHALLENGE challenge: algorithm: metarefresh difficulty: 1 report_as: 1 - name: moderate-suspicion expression: all: - weight >= 10 - weight < 20 action: CHALLENGE challenge: algorithm: fast difficulty: 2 report_as: 2 - name: extreme-suspicion expression: weight >= 20 action: CHALLENGE challenge: algorithm: fast difficulty: 4 store: backend: valkey parameters: url: "redis://anubis-cloudron-redis:6379/0" Note: Redis is mapped in the configuration file and therefore creation of a config file is required prior to deploying the docker compose file above (Refer to 'store:' in above config). Once the above setup is deployed, visit the Nginx Proxy Manager interface on Port 81, setup an account by following the on screen instructions. DNS Provider Configuration Visit the DNS provider, and change the ipv4 and ipv6 addresses of app1.example.cloud and app2.example.cloud, which points at VPS1 (Cloudron server) which were setup previously with Cloudron, to point at VPS2 (Anubis server) ipv4/ipv6 address instead. Note: This change will disrupt these services till the next few steps are followed. Nginx Proxy Mananger Configuration First setup a SSL cerificate for *.example.cloud by visiting the SSL Certificate Tab → Let's Encrypt Certificate. DNS challange option can be utilised here for automated validation without needing to open port 80. Instructions will be shown when the slider's enabled. [image: 1754732701185-screenshot-2025-08-09-at-7.44.43-pm.png] Add a Proxy Host for app1.example.cloud. Set the scheme as http and point at the Anubis container (anubis-cloudron:8300 if above docker compose file was followed). [image: 1754728691428-screenshot-2025-08-09-at-6.03.56-pm.png] Next click SSL and select the certificate created in the previous step. Then enable Force SSL and HTTP/2 Support. Both HSTS options can also be enabled here based on the application being proxied. [image: 1754728728106-screenshot-2025-08-09-at-6.09.29-pm.png] Allow inbound traffic on port 443 on VPS 2, and ensure that UFW or any other firewall in use also allows traffic on this port. Once this is configured, app1.example.cloud (hosted on Cloudron) will be accessible with Anubis protection in place. To add additional Cloudron subdomains, repeat the same steps. Don't forget to update the Docker Compose file to include the new subdomains in the REDIRECT_DOMAINS environment variable within the Anubis container configuration. Optional Steps A Prometheus docker container can be deployed which can be used with Anubis Metrics Port (10000 in above docker compose) to monitor the Anubis instance with Grafana to output data similar to this. [image: 1754728764582-screenshot-2025-08-09-at-6.31.40-pm.png]

@hpalmier [image: 1754604757035-4847a2f1-9c49-484f-9e53-b1bb3a705c0b-image.png]

I'm confused too by the problem description, is it possible to develop a bit on what problems you are trying to solve exactly and why you would need redirects?

I moved from Cloudflare to Infomaniak (registrar) + Bunny NET (DNS). DNSSEC works well.

I have a custom bash script which copies /home/yellowtent/appsdata/* into an external disk every week or so. Just to add another layer of backup on top of Cloudron backups. So far, I haven't needed to use it, but you never know . edit: also copies /home/yellowtent/boxdata

I would strongly recommend Univention as the authentication back end. I used that in the past (pre cloudron) for LDAP auth for everything. I migrated all my apps / data to Cloudron/OpenID/Oauth and am now re-deploying Univention for desktop auth. Desktop users of my company will only need two passwords (cloudron/univention) but with Cloudron SSO, and they can stay (essentially) perm logged in with cookies, it's not a big deal. Only artists/engineers etc doing heavy desktop work will need Univention logins. One other option I'm exploring is having Linux auth to keycloak... https://github.com/kha7iq/kc-ssh-pam

Got it. Thank you so much for the update. Sorry about my mis-perception/understanding of the tone. Thank you all for the great support you provide us all!

Hello @elorden and welcome to the Cloudron forum. I will answer your questions: @elorden said in Pre Sales Questions: I read in an old post (from 2020) that the same application can only be installed 5 times within the same Cloudron. Is this still the case, or has this limitation been removed? No, this is no longer the case. If you wish to install e.g. 100x LAMP apps, you can do that. You can even test this on the Cloudron Demo Server https://my.demo.cloudron.io/ I just installed 8x LAMP apps: [image: 1753812342377-2d0af459-de6c-45ca-a39b-b98ad55df82f-image.png] @elorden said in Pre Sales Questions: In my case, I want to install 20 instances of the same app for 20 clients. I want to see if I can do this with one Cloudron license. Or, on the contrary, will I need four licenses? And is it allowed to market this according to Cloudron's TOCs? Yes you can do so and yes you can market/sell these with no issues. Be aware, since each app may come with its own license and conditions, please respect them as well. What you do with your Cloudron Server is fully up to you. Cloudron does not impose restrictions in this regard. If you'd like to read our terms, thery are linked here: https://www.cloudron.io/legal/terms.html @elorden said in Pre Sales Questions: Is it possible to create databases (e.g., Postgree) in Cloudron? There are applications, such as MetaBase, that need to connect to an external database. And, from what I can see, I'm afraid that would be something to configure outside of Cloudron. Currently, there is no APP just providing a database like PostgreSQL or MySQL etc. In your question, would this MetaBase be hosted outside the Cloudron server or on the same Cloudron server? But, creating a simple app that just provides a singular postgresql, mysql or mongodb would be a fast workaround to have Cloudron still provide and manage these Databases. @elorden said in Pre Sales Questions: Is it possible to add other open source applications? Yes, many people here even publish and maintain their own apps. For example, @BrutalBirdie with his custom FoundryVTT requested from this topic https://forum.cloudron.io/topic/8296/foundry-virtual-tabletop @elorden said in Pre Sales Questions: I'm not a developer, but if it's not too complicated, I'd like to try to help package them so that we can all have them. Because although the Cloudron catalog is very good, I see that new interesting applications are appearing every day that are offered on other platforms (e.g., Coolify) and are not available on Cloudron. Packaging a Cloudron App comes with some caveats. There is a big doc section about this topic here: https://docs.cloudron.io/packaging/tutorial/ When packaging you will always have to have the Cloudron App filesystem in mind. If there are any questions left, or I created new ones, please ask away.

@james said in sshfs backup duplicates network traffic?: So, sshfs tries to issue a remote copy command but falls back to sshfs based copy if it fails for some reason. What is your provider for sshfs? Most people here use Hetzner Storage Boxes. I'm my own provider I'm just using a standard SSH install on proxmox, and the files are stored on a ZFS cluster. I don't know of anything that would stop the copy command from working; what can I do to check / troubleshoot this?

Hello @xarp In Cloudron 9 the mail notification settings look like this (note: this is a preview and still is subjected to change until released) [image: 1753685397426-6e282456-54d4-4030-8435-580d21522def-image-resized.png] I will create a feature request topic quoting your message to track that e-mail notifications should also be included there. EDIT: Done, see: https://forum.cloudron.io/post/110773 If anything is missing in this feature request, please extend it to your liking @xarp