How to Install Cloudron on Ubuntu VPS

Cloudron install for VPS: short version

To install Cloudron for VPS, you need fresh Ubuntu server, at least 2 GB RAM, and domain wey you fit edit im DNS records. The install itself na three commands and one reboot. Almost everything wey fit go wrong dey happen before this step (wrong base image, wrong virtualisation type) or after am (DNS, mail, backups).

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

Cloudron dey install, update, back up, and issue TLS (transport layer security) certificates for self-hosted apps. Every app dey run inside Docker, nginx dey in front of all of dem, and every app get im own subdomain for your domain. Na this last detail make the DNS work come first here.

Why Cloudron dey fussy about the base OS

The setup script dey check the server before e install anything. If check fail, e mean say you need order another server. Read the checks before you choose an image.

• Na Ubuntu only, and na just three releases. Anything else go exit with Cloudron requires Ubuntu 20.04, 22.04, 24.04. Debian, Rocky and Alpine no dey supported. Ubuntu 24.04 need Cloudron 8 or newer, and the script go check that for you.
• Na 64-bit Intel or AMD only: Error: Cloudron only supports amd64/x86_64. ARM VPS no fit run am.
• Na full hardware virtualisation only. For container-based VPS, the script go stop with Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization, because e dey detect the container with systemd-detect-virt --container. KVM dey okay. OpenVZ and LXC no dey supported.
• The root filesystem must be ext4 or xfs. For anything else, you go get Error: Cloudron requires '/' to be ext4 or xfs. Na so btrfs and zfs images dey fail.
• RAM must reach at least 941 MB, and / must get 20 GB. The script dey measure this with free -m and the size of the root filesystem.
• The server must genuinely fresh. If nginx, docker or node don already install, the script go refuse with Error: Some packages like nginx/docker/nodejs are already installed.

Na this last check dey make people argue, so make we explain why. Cloudron dey install pinned versions of Docker, nginx, Node.js and MySQL. E dey write the nginx configuration for every app wey e host, and e dey manage the iptables firewall rules by itself. Docker wey you install yesterday fit be the wrong version, and your existing nginx site files go get replaced. Cloudron dey control the whole machine, so give am dedicated VPS.

One more check dey easy to miss. For older CPU wey no get AVX (advanced vector extensions), the script go print CPU has no AVX support. MongoDB will be disabled. Every app wey need MongoDB go then become impossible to install. Check the CPU before you commit with grep -m1 -o avx /proc/cpuinfo. E go print avx for host wey support am, and nothing for old host.

Cloudron need how much RAM?

The script no go run if RAM dey below 941 MB, with Error: Cloudron requires atleast 1GB physical memory, and the documentation dey ask for 2 GB of RAM and 20 GB of disk. Both numbers na the minimum for the platform, no be for the platform plus your apps. Before you install even one app, Cloudron don already dey run Docker, nginx, e own box service, database containers wey e dey provide for apps (MySQL, PostgreSQL, MongoDB), Redis and the mail stack. Run docker ps for fresh install and count dem.

App memory limits dey on top of that base. Every app package dey come with small default limit, and you fit increase am with the slider for the app Resources view. When app pass its limit, e restart and send you OOM (out of memory) notification. So if one app dey restart again and again, na usually limit problem, no be bug.

This na the sizing wey I go recommend. Dem na recommendations for server wey you no go need rebuild next month. Dem no be measured benchmark results.

[
  {
    "label": "2 apps (free tier)",
    "vcpu": 2,
    "ram_gb": 4,
    "disk_gb": 60
  },
  {
    "label": "5 apps",
    "vcpu": 4,
    "ram_gb": 8,
    "disk_gb": 120
  },
  {
    "label": "10 apps",
    "vcpu": 6,
    "ram_gb": 16,
    "disk_gb": 240
  }
]

Two apps go run comfortably with 4 GB of RAM and 60 GB of disk. Around ten apps need 16 GB and 240 GB, because platform base no dey reduce and every app dey add Docker image, database and its own data. Disk dey fill faster than people expect: images, app data and local backups dey share one volume until you move backups comot from the box.

Cloudron dey give every app unlimited swap, so the memory limit wey you set na for RAM only. For VPS image wey no get swap file, swapon --show no go print anything, and memory pressure go turn directly to OOM restarts instead of making the app slow. Adding 2 GB of swap na cheap insurance, but e no replace real memory. The difference between VPS plans small compared with the hours you go spend tuning limits, so see wetin VPS really cost and buy the next size up.

DNS: wildcard record wey dey make app subdomains work

Cloudron dey put dashboard for my.example.com and every app dey get im own subdomain, so DNS na prerequisite, no be step wey you go do later. Point these records to the server public IP address before you open dashboard for the first time:

• my.example.com as A record. Na dashboard be this.
• *.example.com as A record. Na this one dey make app subdomains work, so wiki.example.com and git.example.com go resolve immediately after you install those apps.
• example.com as A record, only if you want app for the bare domain.

Wildcard record get lower precedence than explicit record, so existing www.example.com wey dey point somewhere else go continue to work.

During setup, you go choose how Cloudron go handle DNS from that point:

• API provider. Cloudron go store token for Cloudflare, DigitalOcean, Route53, Hetzner, Porkbun, Linode, deSEC, Gandi, Namecheap and around twenty other providers, then e go write every record by itself, including mail records.
• Wildcard. You go add * record by hand and Cloudron no go write anything.
• Manual. Cloudron go show you each record and wait while you add am, before every single app install.

Wildcard DNS record no be wildcard certificate. Default certificate provider na Let's Encrypt Prod - Wildcard. E dey prove ownership through DNS, so e only works with API provider. For Wildcard or Manual backends, you go use one certificate for each app, validated through HTTP. This means inbound port 80 must remain open forever. If your registrar or DNS host dey on the API list, use am: mail records and certificates both no go remain your responsibility.

Verify am before you continue. dig +short my.example.com and dig +short anything.example.com suppose both print your server IP address. If wildcard query no print anything, apps go fail later while dashboard go work fine.

If domain dey behind Cloudflare, set the records to DNS only. The proxy dey forward HTTP and HTTPS only, so mail ports go break, and every app go see Cloudflare address instead of the visitor own address.

Run the setup script

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

Run am na root account or through sudo, because na the first thing e go print otherwise be This script should be run as root.. The installation fit take several minutes and e no dey print much while e dey work, because apt output and Docker pulls dey go log file. Monitor am from another SSH session:

tail -f /var/log/cloudron-setup.log

For the end, e go print After reboot, visit one of the following URLs and accept the self-signed certificate to finish setup. followed by your server address, then ask The server has to be rebooted to apply all the settings. Reboot now ? [Y/n]. Answer yes. The --skip-reboot flag dey available if you need schedule the restart, but you no fit use Cloudron until the server don come back online.

First boot: domain, DNS backend and admin account

Open https://<server-ip> and accept the browser warning. The certificate na self-signed because Cloudron never know your domain yet, so e no get anything to ask certificate authority for. For Chrome, click Advanced, then Proceed to <ip> (unsafe). For Firefox, click Advanced, then Accept the Risk and Continue.

The first screen go ask for your domain. Enter example.com and the dashboard go settle for my.example.com. You fit use subdomain like cloudron.example.com instead, then the dashboard go dey for my.cloudron.example.com. Choose the DNS backend, paste the API token if you get one, and create the admin account with email address wey you dey really read: Let's Encrypt registration and every platform alert go use am.

When you save am, Cloudron go request certificates and move the dashboard go https://my.example.com. The IP address URL go stop to work at that point, so bookmark the new one.

Certificates: wetin dey renew, and when e go stop

Certificate renewal dey happen automatically and e follow ACME Renewal Information (ARI), wey be the schedule certificate authority publish. For practice, renewal dey happen about one month before expiry. If renewal fail, admin account go receive email. If certificate expire, system go fall back to the built-in self-signed one. Na this fallback dey cause browser warning for site wey work yesterday.

Two causes dey responsible for most cases. HTTP validation need inbound port 80. So, if you close 80 because "everything na HTTPS anyway", renewal go break for every app wey dey use Wildcard or Manual DNS backend. DNS validation need API token wey still get write access. If you rotate the token or reduce the access wey e get, renewal go fail silently until warning email arrive.

The Domains view get Renew All button wey you fit use force the attempt immediately. E also get Let's Encrypt Staging provider for testing. Browsers no trust Staging certificates deliberately. Na the purpose be that: you fit retry as many times as you like without using production rate limit.

You suppose use the built-in mail server?

Cloudron ships complete mail stack with IMAP mailboxes, submission, sieve filters, and DKIM (domainkeys identified mail) signing. You enable am for each domain under Email for the dashboard. The hard part na to make mail deliver, and Cloudron no cause any of the wahala.

• Most VPS providers dey block outbound port 25 to control spam. Some fit unblock am after you open support ticket. Test am from the server with nc -zv aspmx.l.google.com 25 (install netcat-openbsd if the command no dey). Open ports report succeeded, and blocked port go hang until e timeout.
• Your VPS provider dey set the PTR record (reverse DNS), not your DNS host, and e must match the mail hostname. Mail from address wey get generic PTR fit land for spam folder.
• For API DNS backend, the system writes SPF, DKIM, and DMARC records for you. For Wildcard or Manual backend, you must add dem by hand. If DKIM record no dey, nobody fit verify any message wey you sign.

For most people, the setup wey work na to receive mail on Cloudron and send am through relay like SendGrid, Postmark, Mailgun, or Amazon SES. Configure this for the Email view. The relay must allow sending as any address for your domain. If e no allow am, app notifications from different senders go get rejected. If mail na the main reason you dey buy the server, run dedicated mail server like Mailcow for its own box with its own IP reputation.

If you no use Cloudron Email at all, block ports 25, 465, 587, 993, and 4190 for your provider's firewall. Do am there, no be for the server, because Cloudron dey write the iptables rules by itself and expects to own dem. This na opposite of plain VPS, where you manage ufw rules by yourself.

Set up backup target before you need am

Backups dey default go local filesystem for /var/backups, for the same disk wey everything dey use. Documentation talk am direct: "E dangerous make backups dey for the same physical disk with the platform server." One disk failure fit carry apps and backups together.

Open Backups, then Backup Sites, and point am go another place from day one. S3-compatible object storage na the usual answer (Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces, or a MinIO bucket for another server), and SSHFS, NFS, CIFS plus plain filesystem targets dey supported too.

Three settings decide whether that backup get value:

• Format. tgz dey write one compressed archive for each app and re-upload everything every run. rsync dey upload only files wey change, so e cheaper for large Nextcloud, but e go make more requests go storage API.
• Encryption. Optional AES-256 wey cover both file contents and filenames. Cloudron no keep copy of the password, so if you lose am, nobody fit decrypt the backups, including you. Store am for self-hosted password manager before you click save.
• Retention. Dem dey write am as counts like 7 daily and 4 weekly. Long retention for object storage go bill you every month, so choose number wey you ready continue to pay for.

Then test restore. Install small app, restore am from dashboard, and monitor am as e come back with the data. Backup wey nobody don ever restore na just guess.

Wetin the free tier limit

As of August 2026, the free plan no fit pass two installed apps. Everything else dey inside am: app updates, backup for each app, the firewall, the mail server, and single sign-on. Na the third app be the point wey you need licence. The paid plans remove the app limit, and the higher plan add user groups and roles, a directory server, and multiple backup sites. Prices dey change, so check the Cloudron pricing page instead of relying on number for tutorial.

One licence cover one Cloudron install, so two small servers go cost twice wetin one bigger server cost. This pricing make most people use one bigger VPS, even though normal advice be to spread services across different machines. Size the server with this matter for mind, because if you split am later, you go pay twice.

Wen something break

Start with the built-in check. E go check DNS, certificates, disk, memory and each service one after another, then tell you which test fail:

sudo cloudron-support --troubleshoot

After that, use the normal systemd (system and service manager) tools. systemctl status box dey show report about the Cloudron service itself, journalctl -u box -n 100 dey show the recent logs, and journalctl -u docker dey cover the container runtime underneath. Anything wey go wrong during installation dey remain for /var/log/cloudron-setup.log.

If dashboard no gree load, na usually DNS or provider firewall, no be Cloudron. Run dig +short my.example.com from your laptop, and confirm say ports 80 and 443 dey open for provider network firewall. This one separate from the server own rules. If you dey start again, the script go refuse second run with Error: Cloudron is already installed. To reinstall, start afresh. Rebuild the server na the clean answer.

Cloudron no be the right fit

Cloudron dey work well when you want applications, no be infrastructure. E no dey work well when you want run your own containers your own way, because e dey control nginx, Docker and firewall, and e go overwrite anything wey you put there. If your plan na folder of compose files, Traefik in front of your own Docker Compose stacks go give you the same automatic TLS and subdomain routing without any platform on top. If you never choose yet, Cloudron, CasaOS and Coolify compared go show dem side by side, while the wider list of what to self-host na better place to start than install guide.

FAQ

How much RAM Cloudron need for a VPS?

The setup script no dey run below 941 MB, and documentation dey ask for 2 GB. But na the minimum the platform need when no app dey installed. Cloudron dey run Docker, nginx, e own box service, database containers, and mail stack from first boot. Plan 4 GB for two apps and 16 GB for around ten apps. Add a swap file too, because Cloudron dey give apps unlimited swap. If the server no get swap, memory pressure fit cause restarts.

I fit install Cloudron for Debian, or for server wey already dey run Docker?

Neither one go work. The script dey check the release and stop with Cloudron requires Ubuntu 20.04, 22.04, 24.04, so Debian, Rocky, and Alpine no qualify. E also dey stop when nginx, docker, or node already dey present, because e installs pinned versions of all of dem and writes the nginx configuration and iptables rules by itself. Start with fresh Ubuntu image for a KVM VPS.

Why my app subdomains dey fail while the dashboard dey work?

The wildcard DNS record no dey present. Setup creates or requires an A record for my.example.com, so the dashboard resolves. But wiki.example.com returns NXDOMAIN, and browser reports say e no fit find the site. Add an A record for *.example.com wey point to the server IP. Then confirm with dig +short wiki.example.com before you install the app.

I must use Cloudron mail server?

No. You fit disable incoming email and send through external relay like Postmark, Mailgun, or Amazon SES. This one safer when your provider blocks outbound port 25 or the IP address no get mail reputation. If you skip Cloudron Email completely, close ports 25, 465, 587, 993, and 4190 for the provider firewall, instead of closing dem for the server.

Wetin go happen when I reach the two-app limit for the free plan?

The dashboard go block the third install and ask for licence key. Apps wey you already dey run no go change: dem go continue to update, continue to get backed up, and keep their certificates. Adding licence go remove the limit without reinstalling anything. So, the free plan na fair way to test the platform for real domain first.