Cloudron auf einem VPS installieren: Anleitung

Cloudron auf einem VPS installieren: die Kurzfassung

Für die Installation von Cloudron auf einem VPS benötigen Sie einen frischen Ubuntu-Server, mindestens 2 GB RAM und eine Domain, deren DNS-Einträge Sie bearbeiten können. Die Installation selbst besteht aus drei Befehlen und einem Reboot. Fast alle Probleme treten vorher auf (falsches Basis-Image, falscher Virtualisierungstyp) oder danach (DNS, E-Mail, Backups).

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

Cloudron installiert, aktualisiert und sichert selbst gehostete Anwendungen und stellt TLS-Zertifikate (Transport Layer Security) für sie aus. Jede Anwendung läuft in Docker, nginx sitzt vor allen Anwendungen, und jede Anwendung erhält eine eigene Subdomain Ihrer Domain. Deshalb wird die DNS-Konfiguration hier zuerst vorgenommen.

Warum Cloudron beim Basisbetriebssystem wählerisch ist

Das Setup-Skript prüft den Server, bevor es irgendetwas installiert. Wenn eine Prüfung fehlschlägt, müssen Sie einen neuen Server bestellen. Lesen Sie die Anforderungen, bevor Sie ein Image auswählen.

• Nur Ubuntu und nur drei Releases werden unterstützt. Bei allen anderen Systemen wird das Skript mit Cloudron requires Ubuntu 20.04, 22.04, 24.04 beendet. Debian, Rocky und Alpine werden nicht unterstützt. Ubuntu 24.04 benötigt Cloudron 8 oder neuer. Das prüft das Skript für Sie.
• Nur 64-Bit-Systeme mit Intel- oder AMD-Prozessor werden unterstützt: Error: Cloudron only supports amd64/x86_64. Ein ARM-VPS kann Cloudron nicht ausführen.
• Es ist ausschließlich vollständige Hardwarevirtualisierung zulässig. Auf einem containerbasierten VPS wird das Skript mit Error: Cloudron does not support lxc, only runs on bare metal or with full hardware virtualization beendet, weil es den Container mit systemd-detect-virt --container erkennt. KVM ist geeignet. OpenVZ und LXC werden nicht unterstützt.
• Das Root-Dateisystem muss ext4 oder xfs sein. Bei allen anderen Dateisystemen erhalten Sie Error: Cloudron requires '/' to be ext4 or xfs. So schlagen Images mit btrfs und zfs fehl.
• Mindestens 941 MB RAM und 20 GB auf / sind erforderlich. Die Werte werden mit free -m und anhand der Größe des Root-Dateisystems ermittelt.
• Der Server muss wirklich frisch installiert sein. Wenn nginx, docker oder node bereits installiert ist, verweigert das Skript die Installation mit Error: Some packages like nginx/docker/nodejs are already installed..

Diese letzte Prüfung führt häufig zu Diskussionen. Der Grund ist folgender: Cloudron installiert festgelegte Versionen von Docker, nginx, Node.js und MySQL, schreibt die nginx-Konfiguration für jede gehostete Anwendung und verwaltet die iptables-Firewallregeln selbst. Ein Docker, das Sie am Vortag installiert haben, hat möglicherweise die falsche Version. Vorhandene nginx-Sitedateien werden ersetzt. Cloudron verwaltet den gesamten Rechner. Verwenden Sie deshalb einen dedizierten VPS.

Eine weitere Prüfung wird leicht übersehen. Auf einem älteren Prozessor ohne AVX (Advanced Vector Extensions) gibt das Skript CPU has no AVX support. MongoDB will be disabled aus. Jede Anwendung, die MongoDB benötigt, kann dann nicht installiert werden. Prüfen Sie den Prozessor vor der Bestellung mit grep -m1 -o avx /proc/cpuinfo. Auf einem geeigneten Host gibt der Befehl avx aus, auf einem älteren Host dagegen nichts.

Wie viel RAM benötigt Cloudron?

Das Skript verweigert die Ausführung bei weniger als 941 MB mit Error: Cloudron requires atleast 1GB physical memory. Die Dokumentation verlangt 2 GB RAM und 20 GB Speicherplatz. Beide Werte sind das Minimum für die Plattform selbst, nicht für die Plattform einschließlich Ihrer Apps. Noch bevor Sie eine einzige App installieren, laufen auf Cloudron bereits Docker, nginx, der eigene box-Dienst, die Datenbank-Container, die Cloudron den Apps bereitstellt (MySQL, PostgreSQL, MongoDB), Redis und der Mail-Stack. Führen Sie docker ps auf einer neuen Installation aus und zählen Sie die Container.

Die Speicherlimits der Apps kommen zu dieser Basis hinzu. Jedes App-Paket wird mit einem niedrigen Standardlimit ausgeliefert. Sie erhöhen das Limit mit dem Schieberegler in der Ansicht Resources der App. Überschreitet eine App ihr Limit, wird sie neu gestartet und sendet Ihnen eine OOM-Benachrichtigung (out of memory). Wenn ein Server eine App ständig neu startet, liegt daher meist ein Limitproblem und kein Fehler in der App vor.

Das ist die Dimensionierung, die ich bestellen würde. Sie gilt für einen Server, den Sie nicht im nächsten Monat neu aufsetzen müssen. Es handelt sich nicht um gemessene Benchmark-Ergebnisse.

[
  {
    "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
  }
]

Zwei Apps laufen mit 4 GB RAM und 60 GB Speicherplatz komfortabel. Für ungefähr zehn Apps sollten Sie 16 GB RAM und 240 GB Speicherplatz einplanen, weil die Plattformbasis nicht kleiner wird und jede App ein Docker-Image, eine Datenbank und eigene Daten hinzufügt. Der Speicherplatz ist schneller belegt als erwartet: Images, App-Daten und lokale Backups verwenden dasselbe Volume, bis Sie die Backups auf ein anderes System verschieben.

Cloudron stellt jeder App unbegrenzten Swap-Speicher bereit. Das von Ihnen festgelegte Speicherlimit gilt daher nur für den RAM. Bei einem VPS-Image ohne Swap-Datei gibt swapon --show überhaupt keine Ausgabe aus. Speicherdruck führt dann direkt zu OOM-Neustarts statt zu einer langsameren App. Das Hinzufügen von 2 GB Swap ist eine günstige Absicherung, ersetzt jedoch keinen echten Arbeitsspeicher. Der Preisunterschied zwischen den VPS-Tarifen ist gering im Vergleich zu den Stunden, die Sie für die Anpassung der Limits aufwenden würden. Lesen Sie daher was ein VPS tatsächlich kostet und wählen Sie die nächstgrößere Variante.

DNS: Der Wildcard-Eintrag für App-Subdomains

Cloudron stellt das Dashboard unter my.example.com bereit und verwendet für jede App eine eigene Subdomain. DNS ist daher eine Voraussetzung und kein späterer Einrichtungsschritt. Verweisen Sie diese Einträge auf die öffentliche IP-Adresse des Servers, bevor Sie das Dashboard zum ersten Mal öffnen:

• my.example.com als A-Record. Dies ist das Dashboard.
• *.example.com als A-Record. Dieser Eintrag ermöglicht App-Subdomains. Dadurch werden wiki.example.com und git.example.com aufgelöst, sobald Sie diese Apps installieren.
• example.com als A-Record, wenn Sie eine App unter der Hauptdomain bereitstellen möchten.

Ein Wildcard-Eintrag hat eine niedrigere Priorität als ein expliziter Eintrag. Ein vorhandener www.example.com, der auf ein anderes Ziel verweist, funktioniert daher weiterhin.

Bei der Einrichtung wählen Sie, wie Cloudron DNS danach verwaltet:

• Einen API-Provider. Cloudron speichert ein Token für Cloudflare, DigitalOcean, Route53, Hetzner, Porkbun, Linode, deSEC, Gandi, Namecheap und etwa zwanzig weitere Anbieter. Danach legt Cloudron alle Einträge selbst an, einschließlich der Mail-Einträge.
• Wildcard. Sie legen den Eintrag * manuell an. Cloudron schreibt keine DNS-Einträge.
• Manuell. Cloudron zeigt Ihnen jeden Eintrag und wartet, während Sie ihn vor jeder einzelnen App-Installation anlegen.

Ein Wildcard-DNS-Eintrag ist kein Wildcard-Zertifikat. Der standardmäßig verwendete Zertifikatsanbieter ist Let's Encrypt Prod - Wildcard. Dieser weist die Kontrolle über DNS nach und funktioniert daher nur mit einem API-Provider. Bei den Backends Wildcard oder Manuell verwenden Sie stattdessen ein Zertifikat pro App, das über HTTP validiert wird. Dafür muss eingehender Port 80 dauerhaft geöffnet bleiben. Wenn Ihr Registrar oder DNS-Host in der API-Liste enthalten ist, verwenden Sie ihn. Dann müssen Sie sich weder um Mail-Einträge noch um Zertifikate kümmern.

Prüfen Sie die Konfiguration, bevor Sie fortfahren. dig +short my.example.com und dig +short anything.example.com sollten beide die IP-Adresse Ihres Servers ausgeben. Wenn die Wildcard-Abfrage keine Ausgabe liefert, schlagen App-Installationen später fehl, während das Dashboard weiterhin funktioniert.

Wenn sich die Domain hinter Cloudflare befindet, setzen Sie die Einträge auf DNS only. Der Proxy leitet ausschließlich HTTP und HTTPS weiter. Dadurch funktionieren die Mail-Ports nicht, und jede App sieht eine Cloudflare-Adresse statt der Adresse des Besuchers.

Das Setup-Skript ausführen

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

Führen Sie es als root oder über sudo aus, da es andernfalls zunächst This script should be run as root. ausgibt. Die Installation dauert mehrere Minuten und gibt währenddessen keine Meldungen aus, weil die apt-Ausgabe und die Docker-Pulls in eine Protokolldatei geschrieben werden. Überwachen Sie diese Datei in einer zweiten SSH-Sitzung:

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

Am Ende gibt das Skript After reboot, visit one of the following URLs and accept the self-signed certificate to finish setup. und anschließend die Adresse Ihres Servers aus. Danach fragt es The server has to be rebooted to apply all the settings. Reboot now ? [Y/n]. Antworten Sie mit yes. Mit dem Flag --skip-reboot können Sie den Neustart planen. Cloudron kann jedoch erst verwendet werden, wenn der Server wieder gestartet ist.

Erster Start: Domain, DNS-Backend und Administratorkonto

Öffnen Sie https://<server-ip> und akzeptieren Sie die Browserwarnung. Das Zertifikat ist selbstsigniert, weil Cloudron Ihre Domain noch nicht kennt und daher bei keiner Zertifizierungsstelle ein Zertifikat anfordern kann. Klicken Sie in Chrome auf Advanced und anschließend auf Proceed to <ip> (unsafe). Klicken Sie in Firefox auf Advanced und anschließend auf Accept the Risk and Continue.

Auf der ersten Seite werden Sie nach Ihrer Domain gefragt. Geben Sie example.com ein. Anschließend ist das Dashboard unter my.example.com erreichbar. Sie können stattdessen auch eine Subdomain wie cloudron.example.com verwenden. In diesem Fall ist das Dashboard unter my.cloudron.example.com erreichbar. Wählen Sie das DNS-Backend aus, fügen Sie das API-Token ein, falls Sie eines haben, und erstellen Sie das Administratorkonto mit einer E-Mail-Adresse, die Sie regelmäßig lesen. Für die Registrierung bei Let's Encrypt und für alle Plattformwarnungen wird diese Adresse verwendet.

Nach dem Speichern fordert Cloudron Zertifikate an und verschiebt das Dashboard nach https://my.example.com. Die URL mit der IP-Adresse funktioniert danach nicht mehr. Setzen Sie daher ein Lesezeichen für die neue URL.

Zertifikate: Was sie erneuert und wann die Erneuerung ausbleibt

Die Zertifikatserneuerung erfolgt automatisch und richtet sich nach den ACME Renewal Information (ARI), also nach dem Zeitplan, den die Zertifizierungsstelle veröffentlicht. In der Praxis wird das Zertifikat etwa einen Monat vor dem Ablauf erneuert. Bei einer fehlgeschlagenen Erneuerung wird das Administratorkonto per E-Mail benachrichtigt. Nach Ablauf des Zertifikats wird auf das integrierte selbstsignierte Zertifikat zurückgegriffen. Genau das bedeutet die Browserwarnung auf einer Website, die am Vortag noch funktioniert hat.

Dafür sind meist zwei Ursachen verantwortlich. Die HTTP-Validierung benötigt eingehende Verbindungen auf Port 80. Wenn Port 80 geschlossen wird, weil „ohnehin alles HTTPS ist“, schlägt die Erneuerung für jede Anwendung mit einem Wildcard- oder Manual-DNS-Backend fehl. Die DNS-Validierung benötigt ein API-Token mit weiterhin bestehendem Schreibzugriff. Wenn dieses Token ausgetauscht oder sein Berechtigungsumfang eingeschränkt wird, schlägt die Erneuerung unbemerkt fehl, bis die Warnung per E-Mail eintrifft.

Die Domains-Ansicht enthält eine Schaltfläche Renew All, mit der Sie den Versuch sofort erzwingen können. Für Tests steht außerdem ein Let's Encrypt Staging-Provider zur Verfügung. Staging-Zertifikate werden von Browsern absichtlich nicht als vertrauenswürdig eingestuft. Genau das ist der Zweck: Sie können den Vorgang beliebig oft wiederholen, ohne das Rate-Limit der Produktionsumgebung zu verbrauchen.

Sollten Sie den integrierten Mailserver verwenden?

Cloudron enthält einen vollständigen Mail-Stack mit IMAP-Postfächern, Submission, Sieve-Filtern und DKIM-Signierung (DomainKeys Identified Mail). Sie aktivieren ihn im Dashboard pro Domain unter Email. Die Zustellung von E-Mails ist der schwierige Teil, und keine dieser Schwierigkeiten wird von Cloudron verursacht.

• Der ausgehende Port 25 ist bei den meisten VPS-Anbietern zur Spam-Bekämpfung blockiert. Einige Anbieter schalten ihn nach einem Support-Ticket frei. Testen Sie ihn vom Server aus mit nc -zv aspmx.l.google.com 25 (installieren Sie netcat-openbsd, falls der Befehl fehlt). Offene Ports werden mit succeeded gemeldet. Ein blockierter Port bleibt offen, bis eine Zeitüberschreitung eintritt.
• Der PTR-Eintrag (Reverse DNS) wird von Ihrem VPS-Anbieter gesetzt, nicht von Ihrem DNS-Host. Er muss mit dem Mail-Hostname übereinstimmen. E-Mails von einer Adresse mit einem generischen PTR-Eintrag landen in Spam-Ordnern.
• SPF-, DKIM- und DMARC-Einträge werden auf einem DNS-Backend mit API für Sie angelegt. Bei den Backends Wildcard oder Manual fügen Sie sie manuell hinzu. Ein fehlender DKIM-Eintrag bedeutet, dass jede von Ihnen signierte Nachricht nicht verifiziert werden kann.

Für die meisten Benutzer funktioniert folgende Konfiguration: Sie empfangen E-Mails über Cloudron und senden sie über ein Relay wie SendGrid, Postmark, Mailgun oder Amazon SES. Das Relay konfigurieren Sie in der Ansicht Email. Das Relay muss das Senden unter jeder Adresse Ihrer Domain erlauben. Andernfalls werden App-Benachrichtigungen von unterschiedlichen Absendern abgewiesen. Wenn E-Mail der Hauptgrund für die Anschaffung des Servers ist, betreiben Sie einen dedizierten Mailserver wie Mailcow auf einem eigenen System mit eigener IP-Reputation.

Wenn Sie Cloudron Email überhaupt nicht verwenden, blockieren Sie die Ports 25, 465, 587, 993 und 4190 in der Firewall Ihres Anbieters. Führen Sie diese Blockierung dort und nicht auf dem Server durch, weil Cloudron die iptables-Regeln selbst schreibt und deren Verwaltung erwartet. Das ist das Gegenteil eines einfachen VPS, bei dem Sie die ufw-Regeln selbst verwalten.

Konfigurieren Sie das Backup-Ziel, bevor Sie es benötigen

Backups werden standardmäßig im lokalen Dateisystem unter /var/backups gespeichert, auf derselben Festplatte wie alle anderen Daten. Die Dokumentation formuliert es deutlich: „Backups auf derselben physischen Festplatte wie der Plattformserver zu speichern, ist gefährlich.“ Bei einem Festplattenausfall sind Anwendungen und Backups gemeinsam betroffen.

Öffnen Sie Backups und anschließend Backup Sites. Legen Sie das Ziel bereits am ersten Tag auf einen anderen Speicherort. S3-kompatibler Objektspeicher ist die übliche Lösung (Backblaze B2, Wasabi, Cloudflare R2, DigitalOcean Spaces oder ein MinIO-Bucket auf einem zweiten Server). Auch SSHFS-, NFS-, CIFS- und einfache Dateisystemziele werden unterstützt.

Drei Einstellungen bestimmen, ob dieses Backup tatsächlich nützlich ist:

• Format. tgz erstellt pro Anwendung ein komprimiertes Archiv und lädt es bei jedem Lauf vollständig erneut hoch. rsync lädt nur geänderte Dateien hoch. Das ist bei einer großen Nextcloud deutlich günstiger, verursacht aber wesentlich mehr Anfragen an die Storage-API.
• Verschlüsselung. Optionales AES-256 verschlüsselt sowohl Dateiinhalte als auch Dateinamen. Cloudron speichert keine Kopie des Passworts. Wenn Sie es verlieren, können die Backups von niemandem mehr entschlüsselt werden, auch nicht von Ihnen. Speichern Sie es in einem selbst gehosteten Passwortmanager, bevor Sie auf Speichern klicken.
• Aufbewahrung. Die Angabe erfolgt als Anzahl, beispielsweise 7 tägliche und 4 wöchentliche Backups. Eine lange Aufbewahrungsdauer im Objektspeicher verursacht monatliche Kosten. Wählen Sie daher eine Anzahl, deren Kosten Sie dauerhaft tragen können.

Testen Sie anschließend eine Wiederherstellung. Installieren Sie eine kleine Anwendung, stellen Sie sie über das Dashboard wieder her und prüfen Sie, ob sie mit ihren Daten wieder verfügbar ist. Ein Backup, aus dem noch nie eine Wiederherstellung durchgeführt wurde, ist nur eine Vermutung.

Begrenzungen des kostenlosen Tarifs

Stand August 2026 ist der kostenlose Tarif auf zwei installierte Anwendungen begrenzt. Alle übrigen Funktionen sind enthalten: Anwendungsaktualisierungen, Backups pro Anwendung, die Firewall, der Mailserver und Single Sign-on. Bei der dritten Anwendung benötigen Sie eine Lizenz. Die kostenpflichtigen Tarife heben die Begrenzung der Anwendungsanzahl auf. Der höhere Tarif bietet zusätzlich Benutzergruppen und Rollen, einen Verzeichnisserver sowie mehrere Backup-Standorte. Preise können sich ändern. Prüfen Sie daher die Cloudron-Preisseite, statt einen Wert aus einem Tutorial zu übernehmen.

Eine Lizenz gilt für eine Cloudron-Installation. Zwei kleine Server kosten daher doppelt so viel wie ein größerer Server. Diese Preisstruktur führt dazu, dass die meisten Benutzer einen einzelnen größeren VPS einsetzen. Das widerspricht der üblichen Empfehlung, Dienste auf mehrere Rechner zu verteilen. Berücksichtigen Sie das bei der Dimensionierung des Servers. Eine spätere Aufteilung bedeutet sonst doppelte Kosten.

Wenn etwas ausfällt

Beginnen Sie mit der integrierten Prüfung. Sie prüft nacheinander DNS, Zertifikate, Speicherplatz, Arbeitsspeicher und jeden Dienst und zeigt an, welcher Test fehlgeschlagen ist:

sudo cloudron-support --troubleshoot

Verwenden Sie danach die üblichen systemd-Tools für System- und Dienstverwaltung. systemctl status box zeigt den Status des Cloudron-Dienstes selbst an, journalctl -u box -n 100 gibt die aktuellen Logs aus, und journalctl -u docker behandelt die darunterliegende Container-Laufzeitumgebung. Alles, was während der Installation schiefgelaufen ist, steht in /var/log/cloudron-setup.log.

Wenn ein Dashboard nicht geladen wird, liegt die Ursache meist bei DNS oder der Firewall des Providers und nicht bei Cloudron. Führen Sie dig +short my.example.com auf Ihrem Laptop aus und prüfen Sie, ob die Ports 80 und 443 in der Netzwerk-Firewall des Providers geöffnet sind. Diese Firewall ist von den Regeln des Servers getrennt. Wenn Sie von vorn beginnen, verweigert das Skript einen zweiten Lauf mit Error: Cloudron is already installed. To reinstall, start afresh. Ein neu aufgebauter Server ist dann die saubere Lösung.

Wenn Cloudron die falsche Lösung ist

Cloudron passt, wenn Sie Anwendungen und keine Infrastruktur betreiben möchten. Es passt schlecht, wenn Sie eigene Container nach Ihren eigenen Vorgaben betreiben möchten, weil Cloudron nginx, Docker und die Firewall verwaltet und Ihre Änderungen dort überschreibt. Wenn Ihr Plan aus einem Verzeichnis mit Compose-Dateien besteht, bietet Traefik vor Ihren eigenen Docker-Compose-Stacks automatisches TLS und Routing über Subdomains, ohne dass eine zusätzliche Plattform darüberliegt. Wenn Sie sich noch nicht entschieden haben, stellt Cloudron, CasaOS und Coolify im Vergleich die Systeme direkt gegenüber. Die umfassendere Liste der selbst hostbaren Anwendungen ist ein besserer Ausgangspunkt als eine Installationsanleitung.

FAQ

Wie viel RAM benötigt Cloudron auf einem VPS?

Das Setup-Skript verweigert die Ausführung unter 941 MB. In der Dokumentation werden 2 GB vorausgesetzt. Das ist jedoch nur die Untergrenze für die Plattform ohne installierte Apps. Cloudron führt ab dem ersten Boot Docker, nginx, seinen eigenen box-Dienst, Datenbankcontainer und den Mail-Stack aus. Planen Sie 4 GB für zwei Apps und 16 GB für etwa zehn Apps ein. Legen Sie außerdem eine Swap-Datei an. Cloudron gewährt Apps unbegrenzten Swap. Auf einem System ohne Swap führt Speicherdruck sonst zu Neustarts.

Kann ich Cloudron auf Debian oder auf einem Server installieren, auf dem bereits Docker läuft?

Keine der beiden Varianten funktioniert. Das Skript prüft das Release und beendet sich mit Cloudron requires Ubuntu 20.04, 22.04, 24.04. Debian, Rocky und Alpine sind daher ausgeschlossen. Es beendet sich auch, wenn nginx, docker oder node bereits vorhanden ist. Cloudron installiert feste Versionen aller Komponenten und schreibt die nginx-Konfiguration sowie die iptables-Regeln selbst. Verwenden Sie ein frisches Ubuntu-Image auf einem KVM-VPS.

Warum schlagen die App-Subdomains fehl, während das Dashboard funktioniert?

Der Wildcard-DNS-Eintrag fehlt. Das Setup erstellt einen A-Record für my.example.com oder setzt ihn voraus. Daher wird das Dashboard aufgelöst. wiki.example.com liefert dagegen NXDOMAIN, und der Browser meldet, dass die Website nicht gefunden werden kann. Fügen Sie einen A-Record für *.example.com hinzu, der auf die IP-Adresse des Servers zeigt. Prüfen Sie den Eintrag anschließend mit dig +short wiki.example.com, bevor Sie die App installieren.

Muss ich den Mailserver von Cloudron verwenden?

Nein. Sie können den Empfang von E-Mails deaktivieren und den Versand über ein externes Relay wie Postmark, Mailgun oder Amazon SES durchführen. Das ist die sicherere Option, wenn Ihr Provider ausgehenden Port 25 sperrt oder die IP-Adresse keinen guten Ruf für den Mailversand hat. Wenn Sie Cloudron Email vollständig überspringen, schließen Sie die Ports 25, 465, 587, 993 und 4190 in der Provider-Firewall und nicht auf dem Server.

Was passiert, wenn ich im kostenlosen Tarif das Limit von zwei Apps erreiche?

Das Dashboard blockiert die Installation der dritten App und fordert einen Lizenzschlüssel an. Bereits ausgeführte Apps bleiben unverändert. Sie werden weiterhin aktualisiert und gesichert und behalten ihre Zertifikate. Durch Hinzufügen einer Lizenz wird das Limit aufgehoben, ohne dass etwas neu installiert werden muss. Der kostenlose Tarif eignet sich daher gut, um die Plattform zunächst mit einer echten Domain zu testen.