Cloudron Forum

Here's my guide on how to run your local Cloudron from home or office through a public reverse proxy server on a VPS in the 'Cloud' through Tailscale. No port forwarding or network acrobatics are required!

Prerequisites

• VPS
  • You don't need much for this: 1 CPU, 1GB RAM and minimal disk space
  • Pay attention to the IP allocation and bandwidth allowed!
• Locally hosted Cloudron VM (fresh install)
• A domain name to use with the install
• At least 100mbps uplink to the Internet

Simple overview

Set up and configure the VPS Proxy Server

Procure and configure the VPS in the 'Cloud'. I use Vultr.com and you can get a $100 credit for two weeks to test things out (affiliate link) or DigitalOcean.com for $200 for 60 days (affiliate link).

I use Debian 12, but you can choose Ubuntu or something similar. Not tried it with RedH*t or Arch.

Ideally, you should get a VPS with direct access to the internet and an IPv4 address. Watch out as some providers try to save costs, and IPv6 and network shenanigans are out of the scope of this tutorial.

Install Docker: (ref. https://docs.docker.com/engine/install/debian/#install-using-the-convenience-script)

curl -fsSL https://get.docker.com -o get-docker.sh | sudo sh get-docker.sh

You may need to install docker-compose separately:

sudo apt install docker-compose

Pull Nginx Reverse Proxy (or your preferred reverse proxy with Let's Encrypt SSL). I use Docker Compose to keep things neat. You can find out more here: https://nginxproxymanager.com/setup/#running-the-app.

Configure your firewall - I use the one at the provider - to only allow ports 80 and 443 to the public. Wall-off SSH (22) and the Nginx Proxy Manager's admin port (81) by only allowing access from your home/office IP(s) and or Tailscale network.

Install Tailscale and set it to accept routes (this is key):

curl -fsSL https://tailscale.com/install.sh | sh

Get Tailscale online and accept routes (important!):

sudo tailscale up --accept-routes

Make sure you have restarted and tested. You can see your node in the Tailscale control panel, and the routes have been enabled.

Ready? Let's go local.

Prepare the server for Cloudron

Install a fresh VM (ideally) with Ubuntu 22.04 (boo!).

Set your VM's IP to be fixed via DHCP or manually, as we don't want it to change again.

Install your favourite tools, such as mc and qemu-guest-agent (if you're using Qemu/Proxmox), git, and curl.

Ensure you install Tailscale on the server and run it with the option to expose its route using the local IP:

sudo tailscale up --advertise-routes=192.168.X.X/32

Log in to the Tailscale control panel and enable the route!

Log on to your VPS and ping the VM's local IP to ensure our proxy can access the server.

ping 192.168.X.X

All good? If not, return a few steps and make sure your routes are exposed and accepted.

On your DNS for the domain you want to use, create two A Records, one for the root domain and one wildcard, both pointing to the VPS IP address.

On the VPS, login to Nginx Proxy Manager (http://<IP of VPS>:81) and create a wildcard SSL certificate for the domain (*.example.com).

Create a new reverse proxy entry using both the root and wild card, pointing at https://<local IP of your VM>:443.

Install and configure Cloudron

Head over to the local VM and install Cloudron (finally).

wget https://cloudron.io/cloudron-setup && chmod +x ./cloudron-setup && sudo ./cloudron-setup

Once installed, reboot and log on to the configuration wizard (https://<local IP>/).

Now come the critical bits, which took me some trial and error. Be sure to snapshot the VM before you continue to avoid reinstalling everything in case you make a mistake!

• Domain: your root domain (e.g. example.com)
• DNS Provider: whatever you are using or set it to manual and tweak it later
• Zone Name: leave it as it is (should show your root domain)
• Certificate Provider: set this to 'Self-signed/Custom' and upload the certs provided by the Nginx Proxy Manager from earlier. They'll download in a ZIP archive. You will need:
  • fullchain1.pem and privkey.pem respectively
  • ref. https://docs.cloudron.io/certificates/#custom-certificates
• IP Configuration: select 'Static IP Address'
• IP Address: enter the public IPv4 address of your VPS (not the local one of the VM)

If you are sure you have taken a backup/snapshot of your VM at this point, be braver and hit the 'Next' button.

It will take a while to check itself and present you with the Cloudron account set-up screen. If not, watch for errors in the log file (the path is shown on the screen).

If all goes well, browse my.<your domain>.<tld> and log in. If not, restore to the snapshot and try again. Feel free to post your comments and questions below, and I'll do my best to help.

Finalise the set-up

Once logged on, head to settings and set up the backups. I use a local Samba share from my NAS and rsync (no encryption as the volume is already encrypted). This should make for fast, local backups. I just entered my local NAS IP address (e.g. 192.168.x.x) and login details. Remember that while Cloudron is served from behind the proxy on the VPS, the actual Cloudron server is on your local network and you can point it to local services

You can also set up other volumes on your NAS for photos or other stuff.

Check the email set up for our primary domain is working and it is probably showing some red marks if you chose manual DNS set up. In this case, head to your DNS and create the missing records shown in the error messages.

The reverse DNS entry (PTR record) will fail unless you change it on your VPS provider's DNS (where available). While you can host multiple Cloudrons behind the same Nginx Proxy Manager and IP, if you care about performance and email deliverability, I recommend a separate VPS and IPv4 for each or ignore the error and use an external bulk SMTP service like SMTP2GO or Mailgun.

Fin

Ensure everything you need is green, and double-check the error logs for messages. Once you are happy, install an app and enjoy your new Cloudron

Up next

The next part of this guide will focus on using Tailscale to access the Cloudron service locally without going out of the network and back in again. One of the strengths of Tailscale (and similar services) is that it can connect services directly for lower latency and increased performance.

Let me know what else you would like to see. I post this primarily as a note to myself and share it hoping you found it helpful.

Please note

Let me know your questions or comments on how I accomplished this, and note that I am not affiliated with any of the service providers, Cloudron, or companies mentioned unless stated otherwise.

The help I provide on this forum is free and constitutes my opinion, not that of my employer. Professional services are available via the link in my signature - I cannot provide any paid support in this forum. No warranties are provided or implied.

Document version control

• 2024-04-27 - v.1.0 - Initial version

Posting this here while it applies to everything on your Cloudron, not just Nextcloud.

I love Nextcloud and struggled to find a solution that keeps my data at rest and secure specifically for the app. The easy option is to just encrypt the whole installation medium of your Cloudron, not just Nextcloud.

On bare metal or virtual machines in your home server, this is easy as pie while you install a fresh machine. In the cloud that can often prove a challenge.

I found a super easy way I wanted to share with you using Hetzners Install Image tool:

1. Create a fresh cloud server
2. Reboot it into the rescue system (be sure to note or reset a root password)
3. Follow the official guide and pick a suitably secure password for the encryption (I would suggest avoiding special characters!)

https://community.hetzner.com/tutorials/install-ubuntu-2004-with-full-disk-encryption

4. When you log in, you login into a temporary SSH session to allow you to decrypt the medium. That can be done via your terminal app of choice and the Hetzner KVM virtual console. Enter cryptroot-unlock and your password.

You will need to do this every time your box restarts! If it automatically reboots after updates or due to an error, you should set up a remote alert (e.g. uptime monitor, etc).

5. Once you unlocked the drive, your box will automatically carry on and close your SSH session. So remember to not be surprised to have to log in again

I hope you found this nugget of info useful and I'd love to hear how you roll your own Cloudron.

PS You will not need to install any encryption-related apps in Nextcloud. Your data is already safe at rest now.

@girish et al what happened to the Wireguard app? :pleadingface:

Re. https://forum.cloudron.io/topic/9180/what-s-coming-in-7-5/2?_=1694469098213

@necrevistonnezr

1. Install Cypht app (d'uh)

2. Open the Filemanager for the app and navigate to cypht / hm3.ini

3. On line 55 change the value to auth_type = IMAP

4. In the 'IMAP Authentication' section (from line 77 onwards), amend the IMAP server settings to suit your server. I have used the Cloudron one - simples.

; IMAP Authentication
; -------------------
; If auth_type is set to IMAP, configure the IMAP server to authenticate against
; with the following settings, otherwise these are ignored.
;
; This is just a label used in the UI. It can be set to anything
imap_auth_name=Cloudron

; The hostname or IP address of the IMAP server to authenticate to
imap_auth_server=mysupercoolcloudron.server

; The port the IMAP server is listening on.
imap_auth_port=993

; Enable TLS/SSL connections. Leave blank or set to false to disable. Set to
; true to enable TLS connections. If you want to use IMAP STARTTLS, do NOT
; enable this. This is only for TLS enabled sockets (typically on port 993).
imap_auth_tls=true

5. On line 157 change the value to user_config_type=file

This way no db is needed and settings are kept in files.

6. Make sure that the location for where cypht will place the files exists. For example, on line 165, change the value to user_settings_dir=/app/data/hm3/users

Line 173 attachment_dir=/app/data/hm3/attachments

Line 181 app_data_dir=/app/data/hm3/app_data

7. Save the file and close the Filemanager

8. Open the Terminal for the app and change to the cypht directory: cd ../data/cypht/

9. Run the following command to update the config for cypht: sudo php ./scripts/config_gen.php

10. Get out of the Terminal and restart the app

11. Login using an appropriate account that authenticates against the IMAP server you added to the config.

Enjoy and let me know how you get on

Restoring a server with lots of data can be a pain even with a big fibre connection. As a user, I'd like to be able to select which apps to restore and the order in which to restore them in so that I can prioritise.

For example, I have three Nextcloud apps with over 100GB each and would prefer to focus on one to make sure the service is restored and the server doesn't crap out under the load.

I may have some smaller apps that perform vital services, like VPN or DNS that I would have preferred to go first too.

Anyway, just my 2p. Thanks for reading

Got it working using IMAP auth, logging in using an email account (my Cloudron one) and storing the session.

Hi folks, I am playing with Nextcloud some more and wanted to move an app to an encrypted volume without the root volume being encrypted. Please see my other post on how to encrypt the entire Cloudron. I'm sharing this with you in case you find it useful and look forward to your comments.

*** This guide comes without warranties and is not supported by Cloudron - Caveat emptor! ***

Step 1: Install cryFS

See https://www.cryfs.org/tutorial for more details on this awesome Open Source project. I have chosen it because of how easy and lightweight it is. Let me know which other ways you have tried or can recommend.

sudo apt update && sudo apt install cryfs

Step 2: Create a folder and mount it

In this example, I am creating the place where the data is actually stored in /root/baseDir and mount it to /mnt/nextcloud

You can choose what ever suits your needs and if the baseDir folder is not already in existence it will prompt you to have it created.

sudo cryfs /root/baseDir /mnt/nextcloud -o allow_other

Step 3: Create a sub-folder to store your data in

The reason for this is because we cannot set permissions the way we need to on the mount's root folder.

sudo mkdir /mnt/nextcloud/data && sudo chown -R yellowtent:yellowtent /mnt/nextcloud/data

Step 4: Add the volume to Cloudron

https://your.cloudron.cloud/#/volumes

Then add your volume using the 'Filesystem' mount type and full path to /mnt/nextcloud/data

Step 5: Move your Nextcloud app's data directory

Go to Settings, then Storage for your app and select the volume we created from the dropdown. Hit move and get yourself a cup of tea

Notes:

• Content will be included in your backups
• You will manually need to mount this volume using the same command as in Step 2 when you restart your Cloudron!
• This will not protect you from anyone who has root access to your server or to your Nextcloud app. It just encrypts data at rest.
• Make sure to stop the Nextcloud app before you reboot and disable automatic reboots

Let me know what you think about this approach and how you keep your Nextcloud secure

Hi all, just moving back to Cloudron after a few months on Nextcloud AIO for reasons I leave to your imagination

I saw a few posts online about this topic and thought I'd share how I do it in case it is helpful. I'd love to hear your thoughts and how you do it, so leave me a comment below this post.

Step 1 - Prepare

• Backups
  Have a backup of your existing install!

• DNS
  Ensure your domain's DNS record(s) are set to a low TTL (time to live) because you may need to back out of the migration quickly. If it is set to something like 1 hour or longer, that's how long it would take to restore the previous status. Ignore this at your peril

• Comms
  Arrange for a day and time with your users to migrate, as you must not have people log in and change stuff

Step 2 - Getting ready
Put the site in maintenance mode and take another backup. I also like to have a VM snapshot of the whole shebang to make backing out of the migration a click away. You can never have too many backups

Check that everything from step 1 is done, especially the user comms thing. You don't want a VIP calling you on Sunday morning to say they desperately need something.

Install the Nextcloud 'user migration' app and start exporting each user. I also like to use the 'impersonate' app to help speed things up for this. Depending on the amount of users and the size of their profiles, prepare to make a lot of cups of tea.

This process will take a long time, so plan for this. If you use a VM/VPS, increase the resources for the duration to speed things up.

While things are being exported, go and make a list of apps in use and their settings. This is a manual and tedious process, and I find screenshots helpful. You could do a db dump of the relevant tables and rows, but the manual route is safest, IMO.

The time-consuming stuff is user migrations and their data, not the apps.

Step 3 - Moving-in

Setting up users
On the new server, it helps to mirror the users and groups before you proceed with the app and data migration. This is a manual process. After the migration, I told the users they would need to reset their passwords.

Copy-n-Tea
Once you have a copy of everything downloaded locally from the old server and a complete record of users, groups, apps and their settings, go to your Cloudron and spin up an app. Downloading TBs of data may take a while... grab another tea (with a biscuit).

Hostname and DNS
If you like, turn off the old server and use the same hostname for the Cloudron Nextcloud. You could do this with a different name, but I assume you are doing a complete migration where everything stays the same.

The first time
Assign the user groups to the Nextcloud app and log in with your Cloudron account first, then log out as the new admin the app created and assign your Cloudron user admin rights. Log out and back in as yourself, then remove the autogenerated admin or disable it.

Step 4 - Apps
Install the apps you need and apply their configs before you migrate the users. Ensure you install the 'impersonate' and 'user migration' apps!

Step 5 - Users and data
One by one, use the 'user migration' app to upload and restore the user profiles.

Log in after each restore to check if it matches the old server (handy if it is still running, and you can log in). You may need to manually re-import contacts and calendars.

This process takes the longest, depending on the number of users and the size of their profiles. Make sure you have (a) tea (b) food and (c) a fast connection to the new server.

Step 6 - Checks and go live
Double-check that everything is working, especially email notifications and email app provisioning if used.

Check the error log and the security guide, and run a proper test to see if you get green everywhere.

Perhaps you like to pick a random user, create a file, and share it with an external test account.

Perhaps you don't and will get lots of angry users on Monday morning

Step 7 - Turn off your phone and go on holiday
This step is optional but make sure you take a break after the initial hyper care period is over and the dust has settled

You deserve a pad on the back, a pay rise and the admiration of your favourite person(s). Don't be disappointed if you don't get any of this because you chose to work in IT and it is a thankless world

But cheer up; you are in safe company in the Cloudron community and an open ear to hear how things went for you. Let me know in the comments below.

Hi @johannesjom,

I'll try answering your questions although please note this is not official support

1. Yes, commonly they are moved to the Spam box

2. While I don't know the time frame I understand that the system needs 50 good and bad messages to start training first. I'd leave spam in the folder for at least 14 days, depending on how much junk you get.

3. It's per account as I understand it

4. See answer to (3), yes as far as I know

Further reading and reference:
https://docs.cloudron.io/email/#marking-spam

Hope this helps.

Best,
Axel

Do not adjust your web browser. What follows is a retelling of an event that may or may not have taken place. This story is shared as a warning to others and for the general entertainment of anyone finding themselves with nothing better to do than to read random forum posts on a %current_day%. Enjoy.

It was raining cats and dogs (not literally) on a Sunday afternoon when I tried to run a backup on my Cloudron. My seat was warm and comfortable from having spent way too much time in it since I wrestled myself out of bed this morning. It provided soothing relief for what was to come.

At first, I suspected nothing wrong. Everything was as it seemed and no error messages lurking behind a page refresh to cause my stomach to feel upset.

It was backup restoration testing time and after readying myself with a fresh cup of PG Tips tea and a German cookie left over from the care parcel my mum sent for Christmas.

And then, my plans for a relaxing afternoon split between feeding the brood, killing NPCS in C&C Generals Zero Hour and waiting for backups to download went to hell!

The manually triggered backup was completed and I sunk into my chair in the same way a bowling ball does in a bean bag, not suspecting to be thrown down the aisle, meeting nine pins of doom head-on.

When I tried to restore my backup set, I was met with an error message I couldn't fathom. So I tried again. And again. But to no avail, the tar ball that supposedly rested safely in its volume was absent!

No backup was able to be restored. Frustrated, I topped up my tea and rummaged for more rapidly depleting supplies of Oma's finest Christmas cookies in an attempt to get to the bottom of this.

I remembered yesterday, my server ran out of disk space because I foolishly threw a ton of data at a volume that turned out to be way too small (imagine The IT Crowd episode where Jen is trying to cram her foot into a shoe that was way too small).

I tried removing files, emails anything that brought the space back to 47% available space, surely enough to run backups.

My remote drive didn't mount, so I switched to another using SSHFS rather than CIFS. Now nothing backs up anymore, my Nextcloud app lies broken - its logs claiming not to know who or what it was. The backups were completed without error pretending everything was OK when the reality was nothing close.

I was stumped. What should I do now? Only a few hours left in the day and dinner time was approaching fast.

I did what every sysadmin desperate enough would do: recover to a new instance with the last known backup set that was 'good'.

Good meaning the horrors and mistakes from the last 48 hours would be wiped out and soon to become nothing but a bad dream.

A dream too horrible to reimagine. I don't dare tell my children of the feeling of doom and dread, the shock that makes you stare into the middle distance for 9,000 yards, of a weekend not well spent.

But all this is behind me now and the children never need to know. My Cloudron runs happily on its new instance and the backups are purring.

As I slump back onto my sofa and my back meeting the comforting embrace of its pillows, I wonder what the next backup test restore day will bring and fall asleep.

I notion but never liked the fact I rely on a third party service for some personal data.

+1 for Outline

Just answering my own question: Following some more digging we can just use vector.im or matrix.org. In fact browsing to my Element web app on mobile suggests I configure the native mobile app using vector.im.

However, when I do, I get errors suggesting something ain't right. I set the well known and even opened 8448 in my fw. Any help @girish or @nebulon can give to help a poor, tired sysadmin out? please

oh, yeah ... and Happy New Year!

Hi folks,

If you are like me looking to enable public free/busy information for your calendars in SOGo, simply add this line to your config and restart your app:

SOGoEnablePublicAccess = "YES";

Step-by-step

1. Open the File Manager for your SOGo app
2. Edit the sogo.conf file
3. Add SOGoEnablePublicAccess = "YES"; to a free line (I added mine to line 28)
4. Save the file
5. Get outta there
6. Head back to the SOGo app settings in Cloudron (phew)
7. Go to Repair
8. Hit Restart
9. Wait for it all to come back online
10. Login and check out the new settings ;D

Merry Christmas 3:=)

@JOduMonT thanks, that's really helpful

To add the key to the config.js, I added this code below the admin keys part (it can go anywhere though):

supportMailboxPublicKey: [
        "~~~YourPublicKeyHere~~~",
    ],

The snippet in context looks like:

adminKeys: [
     //"[cryptpad-user1@my.awesome.website/YZgXQxKR0Rcb6r6CmxHPdAGLVludrAF2lEnkbx1vVOo=]",
 ],

 supportMailboxPublicKey: [
     "~~~YourPublicKeyHere~~~",
 ],

 /* =====================
  *        STORAGE
  * ===================== */

And then just restart the app

Hey @jordanurbs, you are not the only one It should be much better documented.

Anyhow, here it goes:

To connect Zapier to a self-hosted Cal.com instance, follow these steps:

TL;DR

• Invite Link == Whatever sequence of random numbers and letters you want (aka API Key!)
• Note that the invite link / API key
• Create an app for the connection in Zapier's dev account

Log in to your self-hosted Cal.com instance as an admin.

1. Navigate to the settings/admin/apps section of your instance
2. Enable the Zapier app in your Cal.com instance and set the necessary app keys
3. Generate an API key specifically for Zapier integration (https://<yourinstance>/apps/zapier/setup)
4. In Zapier, create a new Zap and select Cal.com as your Trigger app
5. When prompted, enter your unique API key generated from your self-hosted Cal.com instance
6. Test the trigger to ensure the connection is working correctly

https://github.com/calcom/cal.com/blob/main/packages/app-store/zapier/README.md
https://developer.zapier.com

As a home server user the drawbacks using email with your set up are PTR records and occasionally going offline (thanks domestic broadband or unreliable 4G).

I use a third party MX provider who queues my mail to mitigate against lost messages during periods of bad connectivity, etc. I also use an external SMTP provider, which can be set on a per domain basis.

Setting an external MX record for a domain means a constant error and the occasional overwriting of DNS records.

Having to set an external SMTP server for each domain can also be a pain, especially when you have heaps.

Please, can we have a configuration option for Cloudron to recognise and avoid overwriting external MX records as well as a way to globally set an external SMTP gateway?

I have now tried it and got it working well (so far). You can find out how I did it in my latest guide.

Hi gang. Hope your New Year is going well

Quick question to ask your advice on the following situation:

My Cloudron has grown in size somewhat, especially since I moved mailboxes from O365 and Google onto it, which now means backups take for.ev.er.

Hence, I want to split mail from the apps and dedicate a fresh VM to email, so it can blossom without restrictions.

What's the best way to do this?

Right now, I am thinking:

1. Take a backup (good idea in any case)
2. Set up a second VM and give its own hostname under my main domain (e.g. email.bebraver.cloud)
3. Install Cloudron on it and connect it to my main apps server via LDAP
4. Change the email domain to be email.bebraver.cloud (rather than mail.)
5. Manually export mailboxes from the apps box to the mailbox (yes, pun intended)
6. Remove the mailboxes from the app server (and free up some more space)
7. I think there should be a seventh step because I like that number and it's a good place to have a nice cup of tea / pint of bitter

@necrevistonnezr true! Using a VPS with a fixed IP as your exit node is the way around it. You do not need to worry about your home IP, as Tailscale connects you up regardless

I hope I understood what you meant and answered your question. If not, please let me know.

@JOduMonT said in How to install Cloudron/Nextcloud with LUKS full disk encryption on Hetzner cloud server:

Maybe I miss read, but, do we have the same understanding that LUKS and full-disk encryption is only useful when the system is not running; aka the drive is not mounted ?

Yep, this is covering only against scenarios where actors might gain access to the drive or volume your data resides on when the machine is offline.

Think of security as layers of an onion and this is just one layer for one(ish) attack vector.

As part of my information security policy, I need to protect data at rest (e.g. hard drives of servers, laptops, phones and backup media) and prevent unauthorised access when machines are running. So full disk encryption satisfies that requirement nicely and being able to do it from afar on a virtualised or bare-metal system like at Hetzner makes it pretty convenient too.

My concern with home/office is theft and with hosters or data centres in general, that drives may end up being replaced or recycled. Hetzer and hosters like them will have easy physical access, so LUKS protects against someone going to the machine, turning it off and passing the drive on to someone else for whatever reason.

Happy to expand and try to answer any questions, with the caveat that I am not offering professional advice nor does it come with any guarantees