Ein einzelner Server kann so viele Websites und Web-Apps hosten, wie RAM und Speicherplatz hergeben. Die Regel, ob ein neues Deployment neben einem bestehenden läuft oder es ersetzt, ist in jedem Ablauf gleich: Entscheidend ist die Kennung, die du vergibst.
Die Regel
Die Kennung verbindet ein Deployment fest mit einem Platz auf dem Server:
- Statische Website → Die Kennung ist die Domain, die du beim Deployment eingegeben hast.
- Web-App → Die Kennung ist der App-Name im Bereich „Erweitert“ (standardmäßig dein Ordnername, z. B.
my-api). - Datenbank → Die Kennung ist der DB-Name + die Engine (jede Engine — Postgres / MySQL / MariaDB — läuft in einem eigenen Container).
| Was du tust | Was passiert | |
|---|---|---|
| Eine statische Website mit einer neuen Domain deployen | Neuer Ordner /var/www/<new-domain>/, neuer [[caddyfile | Caddyfile]]-Block, läuft neben allem anderen. |
| Eine statische Website mit einer bestehenden Domain deployen | Das vorhandene Verzeichnis /var/www/<domain>/ wird geleert und durch deine neuen Dateien ersetzt. Faro fragt vorher nach deiner Zustimmung. | |
| Eine Web-App mit einem neuen App-Namen deployen | Neuer Ordner /opt/<new-app>/, neue -Unit <new-app>.service, neuer Caddy-Reverse-Proxy-Block für ihre Domain. | |
| Eine Web-App mit einem bestehenden App-Namen deployen | Das vorhandene /opt/<app>/ wird geleert und ersetzt. Der Dienst wird mit dem neuen Code neu gestartet. |
Statische Websites — nach Domain zugeordnet
Jedes Deployment einer statischen Website liegt unter /var/www/<domain>/ und bekommt einen eigenen -Block:
mysite.example.com { root * /var/www/mysite.example.com; file_server }
api-docs.example.com { root * /var/www/api-docs.example.com; file_server }Zwei unterschiedliche Domains = zwei unterschiedliche Ordner, zwei Caddyfile-Blöcke, beide laufen parallel. verwaltet die HTTPS-Zertifikate für jede Domain unabhängig.
Wenn du erneut auf dieselbe Domain deployst, beschreibt Faro im Chat den bevorstehenden Ersetzungsschritt:
*„Hinweis:/var/www/mysite.example.com/enthält bereits ein früheres Deployment. Aktueller Inhalt:index.html, about.html, assets/. Alles darin wird durch deine N hochgeladenen Dateien ersetzt. Wenn du ein Laufzeitverzeichnis (uploads/, data/ usw.) behalten möchtest, brich jetzt ab, füge darin über den Tab „Dateien“ eine leere.helm-keep-Datei hinzu und starte das Deployment erneut.“*
Die .helm-keep-Markierung ist der Ausweg — siehe [Ordner über erneute Deployments hinweg behalten](#preserve-a-folder-across-redeploys) weiter unten.
Web-Apps — nach App-Namen zugeordnet
Jedes Web-App-Deployment liegt unter /opt/<appName>/ und läuft als eigene -Unit:
/opt/my-api/ → my-api.service (Node, port 3000)
/opt/scraper/ → scraper.service (Python, port 5000)
/opt/notifier/ → notifier.service (Go, port 8080)Drei unterschiedliche App-Namen = drei unabhängige Dienste. Jeder hat seinen eigenen internen Port, seinen eigenen Benutzer und eigene Logs. leitet per Reverse Proxy jeweils eine Domain an einen Dienst weiter. Ressourcenbedarf: gering (Node und Python liegen je nach App bei etwa 50–200 MB RSS).
Wenn du mit demselben App-Namen erneut deployst, wird das vorhandene /opt/<app>/ ersetzt und der Dienst mit dem neuen Code neu gestartet. Derselbe .helm-keep-Ausweg gilt auch hier.
Der Platz „ohne Domain“ ist einmalig
Wenn du eine statische Website oder Web-App ohne Domain deployst, landet sie an einem speziellen „Standard“-Platz:
- Statisch:
/var/www/default/ - Web-App: Es gelten dieselben Regeln für
/opt/<appName>/(du wählst weiterhin einen App-Namen)
Für statische Websites gibt es nur einen Standardplatz. Ein zweites statisches Deployment ohne Domain ersetzt das erste, weil die Kennung dieses Platzes wörtlich default lautet. Wenn du zwei statische Websites nur über die IP betreiben möchtest, musst du mindestens einer davon eine echte (Sub-)Domain geben.
Bei Web-Apps unterscheidet weiterhin der App-Name — Web-Apps nur über IP können problemlos nebeneinander bestehen, solange sie unterschiedliche App-Namen haben, weil der zugrunde liegende Port intern ist und Caddy :80 einer davon zuordnet. (In der Praxis kann immer nur eine Web-App ohne Domain gleichzeitig das „Standard“-Caddy-Ziel auf Port 80 sein. Faro erkennt das und sagt dir Bescheid.)
Ordner über erneute Deployments hinweg behalten
Wenn du erneut auf dieselbe Kennung deployst, ist die Standardeinstellung: löschen und ersetzen. Um ein bestimmtes Unterverzeichnis zu behalten (typischer Fall: von Benutzern hochgeladene Daten in uploads/, Laufzeit-Caches in data/), lege vor dem nächsten Deployment darin eine leere Datei namens **.helm-keep** ab:
- Öffne das Service-Panel der Website → Tab Dateien.
- Gehe in das Unterverzeichnis, das du behalten möchtest (z. B.
uploads/). - Klicke in der Werkzeugleiste auf + Neue Datei, gib
.helm-keepein und drücke Enter. - Deploye wie gewohnt erneut — Faro erkennt die Markierung, sichert dieses Unterverzeichnis vor dem Löschen zwischen und stellt es wieder her, nachdem die neuen Dateien angekommen sind.
Wenn du es lieber außerhalb des Panels erledigst, funktioniert auch Folgendes: Ziehe eine leere .helm-keep per Drag-and-drop von deinem Computer in den Unterordner, lade sie per SFTP hoch (FileZilla, Cyberduck), melde dich per SSH an und führe sudo touch /var/www/<domain>/<subdir>/.helm-keep aus, oder bitte Faro einfach im Chat darum (*„erstelle eine leere .helm-keep in /var/www/mysite.example.com/uploads/“*).
Faro beschreibt das vor dem destruktiven Schritt im Chat und listet die beibehaltenen Verzeichnisse auf, damit du bestätigen kannst:
*„Diese Verzeichnisse bleiben erhalten, weil sie eine.helm-keep-Markierung enthalten:uploads/, data/. Alles andere wird durch deine N hochgeladenen Dateien ersetzt.“*
Wenn der neue Upload ebenfalls ein Verzeichnis uploads/ enthielt, gewinnt die erhaltene serverseitige Version — Faro teilt dir danach mit, dass das uploads/ aus deinem Upload verworfen wurde. Wenn stattdessen die Version aus dem Upload gewinnen soll, entferne die .helm-keep-Markierung und deploye erneut.
Ressourcenlimits
Es gibt keine feste Obergrenze dafür, wie viele Websites du betreiben kannst — entscheidend sind RAM und Speicherplatz. Grobe Faustregeln für einen kleinen Server (2 GB RAM):
- Statische Websites sind fast kostenlos — Dateien auf der Festplatte + ein Caddy-Block. Du kannst problemlos 50+ davon betreiben. Die Grenze ist der Speicherplatz, und jede einzelne ist normalerweise klein (≤ 100 MB).
- Native Web-Apps benötigen je nach Sprache und Aufgabe etwa 50–200 MB RSS pro App. Ein Server mit 2 GB betreibt bequem 5–8 davon neben Caddy + einer Datenbank.
- Container-Web-Apps benötigen zusätzlich zum Laufzeitbedarf etwa 30–100 MB pro Container — sie fixieren Runtime-Versionen, verbrauchen aber mehr RAM. Siehe [Nativ vs. Container](#) für die Abwägung.
- Datenbanken sind am schwersten — Postgres oder MySQL belegen im Leerlauf etwa 100–300 MB; unter Last kann der Buffer Pool bis zu einem konfigurierbaren Limit wachsen.
Der Status-Tab in jedem Service-Panel zeigt den aktuellen Speicher- und CPU-Verbrauch; das Server-Panel wird (in einer zukünftigen Version) die Gesamtsumme über alles auf dem Server anzeigen.