So I have tons of services running on my network and I'm using the Nginx Proxy Manager (NPM).
It work's fine but I noticed the apps in Cloudron reporting the NPM IP Address instead of the true IP Address.
In this case, it's the Mastodon app. 
I've tried adding this:
I've also tried adding the TRUSTED_PROXY_IP Address in the env.production file:
But this resulted in displaying the Cloudron internal IP Address instead.
@girish said in Cloudron and Apps Behind a Proxy:
X-Forwarded-For
I got it setup like this but doesn't seem to work. Does anyone have better luck?
@BrutalBirdie actually I didn’t get emails on backup failure, app update or reboot required. How do I enable those?
Are we supposed to receive email notifications about the Cloudron notifications? If not, how do we set that up?
@nebulon i've identified the issue and it was my S3 configuration.
The endpoint and hostname should never have the bucket name.
S3_ENDPOINT=https://s3.us-west-001.example.com
S3_HOSTNAME=s3.us-west-001.example.com
@shanelord01 I've got mine working. It's only advisable to have it running from with in the same server otherwise you'll have to expose it to the internet.
I'm hosting my ES in docker but its similar.
Here's what I've done:
ES_ENABLED=true
ES_HOST=[ES IP Address]
ES_PORT=9920
@doodlemania2 somewhat related, does the apps in cloudron report client ip as your nginx proxy manager's ip or their true ip?
@girish great that works! remember to rebuild the feeds and redeploy elasticsearch if that's in use.
So I've accidentally setup Mastodon with Cloudron LDAP enabled. How do I turn it off so that I will not encounter issues with Users signing up directly to Mastodon?
Can I simply remove the LDAP config in the env.production file?
@gh0stface so this is what I've setup;
## S3 Storage
PF_ENABLE_CLOUD=true
FILESYSTEM_DRIVER=local
FILESYSTEM_CLOUD=s3
PF_LOCAL_AVATAR_TO_CLOUD=true
MEDIA_DELETE_LOCAL_AFTER_CLOUD=true
AWS_ACCESS_KEY_ID=xxx
AWS_SECRET_ACCESS_KEY=xxx
AWS_DEFAULT_REGION=xxx
AWS_BUCKET=mediapixelfedsg
AWS_URL=https://media.pixelfed.sg
AWS_ENDPOINT=https://xxx.backblazeb2.com
#AWS_USE_PATH_STYLE_ENDPOINT=false
and it works.
Another weird thing about the app is that if you upload from web, it's serving the image from the Server even though both locations has it.
if you upload from the app, it'll serve from s3.
then when you run php artisan cache:clear it'll get fixed.
Wonder if it'll auto switch to s3 without touching.
Since it's storing images on both locations, will it like auto delete from server?
I also recommend that the cleanup.sh to add the tootctl media remove --prune-profiles
Mastodon has released 4.1.0 and it has a whole slew of fixes and features!
https://github.com/mastodon/mastodon/releases/tag/v4.1.0
Not rushing anyone but… 
@doodlemania2 what’s your current setup? If you don’t mind providing.
I’m wondering how’s everyone’s Mastodon server. How many users can a Mastodon running with Cloudron can take.
I currently have 30 users, about 12 active. The app is eating about 2.5gigs of ram.
I’ve been crawling through the web and I can’t seem to find any guides on migrating a Mastodon instance into Cloudron. Is it possible?
While we are at it, is it also possible to migrate the instance out of Cloudron?
I’m surprised this isn’t on Cloudron yet.
So running the cleanup.sh works for most parts.
Only the Orphaned Media portion fails. Running the command manually doesn't help too.
I've got my media hosted in BackBlaze B2, no issues loading images, etc.
Obviously the api key has read/write permissions. Something else I've missed?
@doodlemania2 what’s your setup now?
here's mine:
#!/bin/bash
# Setup scaling related environment variables here - https://docs.joinmastodon.org/admin/scaling/
# Puma
export WEB_CONCURRENCY=3 # number of worker processes
export MAX_THREADS=10 # the number of threads per process
# Streaming API
export STREAMING_CLUSTER_NUM=3 # number of worker processes
export DB_POOL=15
# Sidekiq
export SIDEKIQ_THREADS=75
export DB_POOL=75 # must be at least the same as the number of threads
export MALLOC_ARENA_MAX=2
@girish why is this package downgrading Mastodon from 4.0.2 to 4.0?
I have an NPM that helps to manage traffic to my NAS, Cloudron and other services.
It appears that Cloudron is reporting the client IP Address as my NPM address.
For my NAS, I’ll just need to indicate my Trusted Proxy IP Address and it’ll start reporting the true client IP Address.
Where can I do the same for Cloudron? TIA!
@girish found the culprit, NPM was not forwarding the web socket properly. Fixed that and the terminal works now.
@girish I have similar issues, I’m using the nginx proxy manager. Everything works but the app terminal. Already tried your config for ngix but didn’t work.
I've tried installing Cloudron multiple times but keep getting stuck at the same spot. Unbound service was not able to successfully start.
Followed the guide here didnt help, https://docs.cloudron.io/troubleshooting/
I'm on Ubuntu 20.04, trying to install Cloudron 7.3.4 using ./cloudron-setup, Ubuntu is a VM on my Windows 10 host using Hyper-V.
× unbound.service - Unbound DNS server
Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
Active: failed (Result: exit-code) since Thu 2022-12-22 04:44:11 UTC; 5min ago
Docs: man:unbound(8)
Main PID: 7130 (code=exited, status=1/FAILURE)
CPU: 10ms
Dec 22 04:44:10 sgpvm01 systemd[1]: unbound.service: Failed with result 'exit-code'.
Dec 22 04:44:10 sgpvm01 systemd[1]: Failed to start Unbound DNS server.
Dec 22 04:44:11 sgpvm01 systemd[1]: unbound.service: Scheduled restart job, restart counter is at 5.
Dec 22 04:44:11 sgpvm01 systemd[1]: Stopped Unbound DNS server.
Dec 22 04:44:11 sgpvm01 systemd[1]: unbound.service: Start request repeated too quickly.
Dec 22 04:44:11 sgpvm01 systemd[1]: unbound.service: Failed with result 'exit-code'.
Dec 22 04:44:11 sgpvm01 systemd[1]: Failed to start Unbound DNS server.
Install logs
Setting up unbound (1.13.1-1ubuntu5.3) ...
Created symlink /etc/systemd/system/multi-user.target.wants/unbound.service → /lib/systemd/system/unbound.service.
Created symlink /etc/systemd/system/unbound.service.wants/unbound-resolvconf.service → /lib/systemd/system/unbound-resolvconf.service.
Could not execute systemctl: at /usr/bin/deb-systemd-invoke line 142.
Job for unbound.service failed because the control process exited with error code.
See "systemctl status unbound.service" and "journalctl -xeu unbound.service" for details.
invoke-rc.d: initscript unbound, action "start" failed.
● unbound.service - Unbound DNS server
Loaded: loaded (/lib/systemd/system/unbound.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Thu 2022-12-22 04:43:46 UTC; 4ms ago
Docs: man:unbound(8)
Process: 4603 ExecStartPre=/usr/lib/unbound/package-helper chroot_setup (code=exited, status=0/SUCCESS)
Process: 4606 ExecStartPre=/usr/lib/unbound/package-helper root_trust_anchor_update (code=exited, status=0/SUCCESS)
Process: 4609 ExecStart=/usr/sbin/unbound -d -p $DAEMON_OPTS (code=exited, status=1/FAILURE)
Process: 4610 ExecStopPost=/usr/lib/unbound/package-helper chroot_teardown (code=exited, status=0/SUCCESS)
Main PID: 4609 (code=exited, status=1/FAILURE)
CPU: 9ms
Dec 22 04:43:46 sgpvm01 systemd[1]: unbound.service: Failed with result 'exit-code'.
Dec 22 04:43:46 sgpvm01 systemd[1]: Failed to start Unbound DNS server.
# we need unbound to work as this is required for installer.sh to do any DNS requests
echo -e "server:\n\tinterface: 127.0.0.1\n" > /etc/unbound/unbound.conf.d/cloudron-network.conf
systemctl restart unbound
Job for unbound.service failed because the control process exited with error code.
See "systemctl status unbound.service" and "journalctl -xeu unbound.service" for details.