Varios sitios en el mismo servidor

Cada sitio o app en un servidor gestionado por Server Manager vive en su propia carpeta, identificada por su dominio (o por el nombre de la app). Los identificadores distintos conviven; si reutilizas el mismo identificador, se reemplaza lo que ya hay.

Última actualización 23 may 2026

Un solo servidor puede alojar tantos sitios web y apps web como le permitan la RAM y el disco. La regla para saber si un nuevo despliegue vive junto a uno existente o lo reemplaza es la misma en todos los flujos: depende del identificador que le des.

La regla

El identificador es lo que vincula un despliegue a un hueco concreto del servidor:

Sitio estático → el identificador es el dominio que escribiste durante el despliegue.
App web → el identificador es el nombre de la app en la sección Avanzado (por defecto, el nombre de tu carpeta, por ejemplo my-api).
Base de datos → el identificador es el nombre de la BD + el motor (cada motor — Postgres / MySQL / MariaDB — se ejecuta en su propio contenedor).

Qué haces	Qué ocurre
Despliegas un sitio estático con un dominio nuevo	Se crea una nueva carpeta `/var/www/<new-domain>/`, un nuevo bloque de [[caddyfile	Caddyfile]], y convive con todo lo demás.
Despliegas un sitio estático con un dominio existente	El directorio existente `/var/www/<domain>/` se borra y se reemplaza con tus archivos nuevos. Faro te pide confirmación primero.
Despliegas una app web con un nombre de app nuevo	Se crea una nueva carpeta `/opt/<new-app>/`, una nueva unidad `<new-app>.service` y un nuevo bloque de proxy inverso de Caddy para su dominio.
Despliegas una app web con un nombre de app existente	La carpeta existente `/opt/<app>/` se borra y se reemplaza. El servicio se reinicia con el código nuevo.

Sitios estáticos: identificados por dominio

Cada despliegue de sitio estático vive en /var/www/<domain>/ y tiene su propio bloque de :

mysite.example.com { root * /var/www/mysite.example.com; file_server }
api-docs.example.com { root * /var/www/api-docs.example.com; file_server }

Dos dominios distintos = dos carpetas distintas, dos bloques de Caddyfile, ambos sirviendo en paralelo. gestiona los certificados HTTPS de cada uno de forma independiente.

Si vuelves a desplegar en el mismo dominio, Faro te explica en el chat el paso de reemplazo antes de hacerlo:

*"Aviso: /var/www/mysite.example.com/ ya contiene un despliegue anterior. Contenido actual: index.html, about.html, assets/. Todo lo que hay ahí se reemplazará por tus N archivos subidos. Si tienes un directorio en tiempo de ejecución (uploads/, data/, etc.) que quieres conservar, cancela ahora, añade dentro un archivo vacío llamado .helm-keep desde la pestaña Archivos y vuelve a ejecutar el despliegue."*

El marcador .helm-keep es la vía de escape; consulta [Conservar una carpeta entre redespliegues](#preserve-a-folder-across-redeploys) más abajo.

Dos sitios estáticos en el mismo servidor, cada uno en su propia carpeta /var/www/, con sus propios bloques de Caddyfile

Apps web: identificadas por nombre de app

Cada despliegue de app web vive en /opt/<appName>/ y se ejecuta como su propia unidad :

/opt/my-api/      → my-api.service      (Node, port 3000)
/opt/scraper/     → scraper.service     (Python, port 5000)
/opt/notifier/    → notifier.service    (Go, port 8080)

Tres nombres de app distintos = tres servicios independientes. Cada uno tiene su propio puerto interno, su propio usuario y sus propios logs. hace de proxy inverso desde un dominio hacia cada uno. Coste de recursos: pequeño (Node y Python usan unos ~50–200 MB de RSS, según la app).

Si vuelves a desplegar con el mismo nombre de app, la carpeta existente /opt/<app>/ se reemplaza y el servicio se reinicia con el código nuevo. Se aplica la misma vía de escape con .helm-keep.

Tres apps web en el mismo servidor, cada una en su propia carpeta /opt/ con su propia unidad systemd

El hueco "sin dominio" es único

Si despliegas un sitio estático o una app web sin dominio, va a un hueco especial "predeterminado":

Estático: /var/www/default/
App web: se aplican las mismas reglas de /opt/<appName>/ (sigues eligiendo un nombre de app)

En los sitios estáticos, solo hay un hueco predeterminado. Un segundo despliegue estático sin dominio reemplaza al primero, porque el identificador del hueco es la cadena literal default. Si quieres tener dos sitios estáticos accesibles solo por IP, tienes que dar a al menos uno de ellos un (sub)dominio real.

En las apps web, el identificador del nombre de app sigue diferenciándolas: las apps web sin dominio pueden convivir sin problema siempre que tengan nombres de app distintos, porque el puerto subyacente es interno y Caddy es quien asigna :80 a una de ellas. (En la práctica, solo una app web sin dominio puede ser el destino "predeterminado" de Caddy en el puerto 80 a la vez. Faro lo resuelve y te lo explica.)

Conservar una carpeta entre redespliegues

Cuando vuelves a desplegar sobre el mismo identificador, lo predeterminado es borrar y reemplazar. Para conservar un subdirectorio concreto (caso típico: datos subidos por usuarios en uploads/, cachés en tiempo de ejecución en data/), coloca dentro un archivo vacío llamado **.helm-keep** antes del siguiente redespliegue:

Abre el panel de servicio del sitio → pestaña Archivos.
Entra en el subdirectorio que quieres conservar (por ejemplo, uploads/).
Haz clic en + Archivo nuevo en la barra de herramientas, escribe .helm-keep y pulsa Intro.
Vuelve a desplegar como siempre: Faro detecta el marcador y guarda aparte ese subdirectorio antes de borrar, luego lo restaura cuando los archivos nuevos ya están en su sitio.

Si prefieres hacerlo fuera del panel, cualquiera de estas opciones también sirve: arrastrar y soltar un .helm-keep vacío desde tu ordenador al subdirectorio, subirlo por SFTP (FileZilla, Cyberduck), entrar por SSH y ejecutar sudo touch /var/www/<domain>/<subdir>/.helm-keep, o simplemente pedírselo a Faro en el chat (*"create an empty .helm-keep in /var/www/mysite.example.com/uploads/"*).

Faro te lo cuenta en el chat antes del paso destructivo, enumerando los directorios conservados para que puedas confirmarlo:

*"Se conservarán estos directorios porque tienen un marcador .helm-keep dentro: uploads/, data/. Todo lo demás se reemplazará por tus N archivos subidos."*

Si la nueva subida también contenía un directorio uploads/, gana la versión conservada del servidor: Faro te avisa después de que el uploads/ de tu subida se descartó. Si quieres que gane la versión de la subida, elimina el marcador .helm-keep y vuelve a desplegar.

Un sitio estático con marcadores .helm-keep dentro de uploads/ y data/, conservados entre redespliegues

Límites de recursos

No hay un límite rígido de cuántos sitios puedes ejecutar: depende de la RAM y del disco. Reglas orientativas para un servidor pequeño (2 GB de RAM):

Los sitios estáticos cuestan casi nada: archivos en disco + un bloque de Caddy. Puedes ejecutar fácilmente más de 50. La limitación es el disco, y normalmente cada uno ocupa muy poco (≤ 100 MB).
Las apps web nativas cuestan unos ~50–200 MB de RSS cada una, según el lenguaje y lo que hagan. Un servidor de 2 GB ejecuta cómodamente 5–8 junto a Caddy + una base de datos.
Las apps web en contenedor añaden unos ~30–100 MB por contenedor además del coste del runtime: fijan versiones del runtime, pero consumen más RAM. Consulta [Nativo vs. contenedor](#) para ver la comparación.
Las bases de datos son lo más pesado: Postgres o MySQL en reposo usan unos ~100–300 MB; bajo carga, el buffer pool puede crecer hasta un límite configurable.

La pestaña Estado de cada panel de servicio muestra la memoria y la CPU actuales; el panel del servidor mostrará (en una versión futura) el total acumulado de todo lo que se ejecuta en la máquina.