Un singolo server può ospitare tutti i siti web e le app web che RAM e disco consentono. La regola che stabilisce se una nuova pubblicazione viene messa accanto a una già esistente oppure la sostituisce è la stessa in ogni flusso: dipende dall’identificatore che le assegni.
La regola
L’identificatore è ciò che collega una pubblicazione a uno slot specifico sul server:
- Sito statico → l’identificatore è il dominio che hai inserito durante la pubblicazione.
- App web → l’identificatore è il nome dell’app nella sezione Avanzate (per impostazione predefinita usa il nome della tua cartella, per esempio
my-api). - Database → l’identificatore è il nome del DB + il motore (ogni motore — Postgres / MySQL / MariaDB — viene eseguito nel proprio container).
| Cosa fai | Cosa succede | |
|---|---|---|
| Pubblichi un sito statico con un nuovo dominio | Nuova cartella /var/www/<new-domain>/, nuovo blocco [[caddyfile | Caddyfile]], convive con tutto il resto. |
| Pubblichi un sito statico con un dominio esistente | La directory /var/www/<domain>/ esistente viene svuotata e sostituita con i tuoi nuovi file. Faro ti chiede prima l’approvazione. | |
| Pubblichi un’app web con un nuovo nome app | Nuova cartella /opt/<new-app>/, nuova unità <new-app>.service, nuovo blocco reverse proxy Caddy per il suo dominio. | |
| Pubblichi un’app web con un nome app esistente | La cartella /opt/<app>/ esistente viene svuotata e sostituita. Il servizio viene riavviato con il nuovo codice. |
Siti statici — identificati dal dominio
Ogni pubblicazione di un sito statico risiede in /var/www/<domain>/ e riceve il proprio blocco :
mysite.example.com { root * /var/www/mysite.example.com; file_server }
api-docs.example.com { root * /var/www/api-docs.example.com; file_server }Due domini diversi = due cartelle diverse, due blocchi Caddyfile, entrambi serviti in parallelo. gestisce i certificati HTTPS di ciascuno in modo indipendente.
Se ripubblichi sullo stesso dominio, Faro ti avvisa in chat del passaggio di sostituzione imminente:
*"Attenzione:/var/www/mysite.example.com/contiene già una pubblicazione precedente. Contenuto attuale:index.html, about.html, assets/. Tutto ciò che si trova lì verrà sostituito con i tuoi N file caricati. Se hai una cartella di runtime (uploads/, data/, ecc.) che vuoi conservare, annulla ora, aggiungi al suo interno un file vuoto.helm-keepdalla scheda File e riesegui la pubblicazione."*
Il marker .helm-keep è la via d’uscita: vedi [Conservare una cartella tra una ripubblicazione e l’altra](#preserve-a-folder-across-redeploys) più sotto.
App web — identificate dal nome app
Ogni pubblicazione di un’app web risiede in /opt/<appName>/ e viene eseguita come unità separata:
/opt/my-api/ → my-api.service (Node, port 3000)
/opt/scraper/ → scraper.service (Python, port 5000)
/opt/notifier/ → notifier.service (Go, port 8080)Tre nomi app diversi = tre servizi indipendenti. Ognuno ha la propria porta interna, il proprio utente e i propri log. instrada ciascun dominio verso il servizio corrispondente tramite reverse proxy. Costo in risorse: ridotto (Node e Python usano circa 50–200 MB di RSS, a seconda dell’app).
Se ripubblichi con lo stesso nome app, la cartella /opt/<app>/ esistente viene sostituita e il servizio riparte con il nuovo codice. Vale la stessa via d’uscita con .helm-keep.
Lo slot “senza dominio” è unico
Se pubblichi un sito statico o un’app web senza dominio, finisce in uno slot speciale “default”:
- Statico:
/var/www/default/ - App web: valgono le stesse regole di
/opt/<appName>/(devi comunque scegliere un nome app)
Per i siti statici, esiste un solo slot default. Una seconda pubblicazione statica senza dominio sostituisce la prima, perché l’identificatore dello slot è la stringa letterale default. Se vuoi due siti statici raggiungibili solo via IP, devi assegnare almeno a uno dei due un vero (sotto)dominio.
Per le app web, l’identificatore basato sul nome app continua a distinguerle: app web raggiungibili solo via IP possono convivere senza problemi, purché abbiano nomi app diversi, perché la porta sottostante è interna ed è Caddy a mappare :80 verso una di esse. (In pratica, una sola app web senza dominio alla volta può essere il target “default” di Caddy sulla porta 80. Faro lo capisce e te lo dice.)
Conservare una cartella tra una ripubblicazione e l’altra
Quando ripubblichi sullo stesso identificatore, il comportamento predefinito è svuotare e sostituire. Per conservare una sottodirectory specifica (caso tipico: dati caricati dagli utenti in uploads/, cache di runtime in data/), prima della prossima ripubblicazione inserisci al suo interno un file vuoto chiamato **.helm-keep**:
- Apri il pannello del servizio del sito → scheda File.
- Entra nella sottodirectory che vuoi conservare (per esempio
uploads/). - Fai clic su + Nuovo file nella barra degli strumenti, digita
.helm-keep, premi Invio. - Ripubblica come al solito: Faro rileva il marker, mette da parte quella sottodirectory prima di svuotare tutto e poi la ripristina dopo l’arrivo dei nuovi file.
Se preferisci farlo fuori dal pannello, funzionano anche questi metodi: trascina un .helm-keep vuoto dal computer nella sottocartella, caricalo via SFTP (FileZilla, Cyberduck), entra via SSH ed esegui sudo touch /var/www/<domain>/<subdir>/.helm-keep, oppure chiedilo semplicemente a Faro in chat (*"crea un .helm-keep vuoto in /var/www/mysite.example.com/uploads/"*).
Faro te lo segnala in chat prima del passaggio distruttivo, elencando le cartelle conservate così puoi confermare:
*"Conservo queste cartelle perché contengono un marker.helm-keep:uploads/, data/. Tutto il resto verrà sostituito con i tuoi N file caricati."*
Se il nuovo caricamento contiene anche una directory uploads/, vince la versione conservata sul server: Faro ti avvisa dopo che la uploads/ del tuo caricamento è stata scartata. Se invece vuoi forzare l’uso della versione caricata, rimuovi il marker .helm-keep e ripubblica.
Limiti di risorse
Non c’è un limite rigido al numero di siti che puoi eseguire: dipende da RAM e disco. Regole pratiche indicative su un server piccolo (2 GB di RAM):
- I siti statici sono quasi gratuiti: file su disco + un blocco Caddy. Puoi eseguirne tranquillamente più di 50. Il vincolo è il disco, e in genere ciascuno è minuscolo (≤ 100 MB).
- Le app web native consumano circa 50–200 MB di RSS ciascuna, a seconda del linguaggio e di ciò che fanno. Un server da 2 GB ne esegue comodamente 5–8 insieme a Caddy + un database.
- Le app web in container aggiungono circa 30–100 MB per container oltre al costo del runtime: fissano le versioni del runtime, ma consumano più RAM. Vedi [Nativo vs container](#) per il compromesso.
- I database sono i più pesanti: Postgres o MySQL a riposo usano circa 100–300 MB; sotto carico, il buffer pool può crescere fino a un limite configurabile.
La scheda Stato nel pannello di ogni servizio mostra memoria + CPU attuali; il pannello Server mostrerà (in una release futura) il riepilogo totale di tutto ciò che gira sulla macchina.