Server Manager/ Help
Open Server Manager →

Nativo vs. contenedor — ¿cuál debería elegir?

Nativo ejecuta tu aplicación web directamente en el host con systemd: rápido, poca RAM, entorno de ejecución compartido. Contenedor la ejecuta dentro de Docker: una versión propia del entorno por app, ~30–100 MB de RAM extra.

Solo es relevante si vas a desplegar una aplicación web (Node, Python, Go). Los sitios estáticos y WordPress no muestran esta opción.

Cuando despliegas una aplicación web, la sección Avanzado de la ventana de despliegue incluye un selector: Desplegar como proceso nativo o Contenedor. Ambas opciones publican tu app detrás de con HTTPS de ; la diferencia está en cómo se ejecuta tu código por debajo.

Qué estás eligiendo

El selector "Desplegar como" dentro de la sección Avanzado de la ventana de despliegue
El selector "Desplegar como" dentro de la sección Avanzado de la ventana de despliegue
  • Proceso nativoServer Manager instala el entorno de ejecución una vez en el host (Node 22 LTS, Python 3 + venv, o Go) y luego ejecuta tu app directamente con como un servicio propio.
  • ContenedorServer Manager crea una imagen de Docker para tu app con la versión del entorno de ejecución que elijas y luego la ejecuta como un contenedor delante del Caddy del host.

En ambos casos: mismo dominio, mismo HTTPS, mismo botón para traer la última versión desde git, mismo acceso a tu código desde la pestaña Archivos.

Cómo funciona Nativo

Tu app vive en /opt/<appName>/ y se ejecuta como una unidad de llamada <appName>.service. El entorno de ejecución (Node, Python, Go) se instala una sola vez a nivel del sistema operativo y se comparte entre todas las aplicaciones web nativas del servidor.

Despliegue nativo: tres apps con systemd, todas compartiendo una instalación de Node y una de Python en el host
Despliegue nativo: tres apps con systemd, todas compartiendo una instalación de Node y una de Python en el host
  • Archivos en /opt/<appName>/
  • Servicio gestionado por systemd: sudo systemctl status <appName> funciona como esperas
  • Registros capturados por journald y mostrados en la pestaña Registros
  • Entorno de ejecución una instalación de Node 22, una de Python 3 y una de Go en el host: todas las apps nativas las comparten

Cómo funciona Contenedor

Tu app se ejecuta dentro de su propio contenedor de Docker. El archivo compose vive en /opt/<appName>/docker-compose.yml, y delante del contenedor está Caddy en el host, que actúa como proxy inverso entre tu dominio y el puerto interno del contenedor.

Despliegue en contenedor: tres apps, cada una en su propio contenedor de Docker con su propia versión fija del entorno de ejecución
Despliegue en contenedor: tres apps, cada una en su propio contenedor de Docker con su propia versión fija del entorno de ejecución
  • Archivos en /opt/<appName>/: tu código fuente, más un Dockerfile y un docker-compose.yml que generamos
  • Servicio gestionado por Docker: sudo docker compose -f /opt/<appName>/docker-compose.yml ps muestra el estado
  • Registros capturados por Docker y mostrados en la pestaña Registros
  • Entorno de ejecución cada app fija su propia versión: Node 18, Node 22, Python 3.11 y Python 3.13 pueden convivir sin problema

¿Cuál debería elegir?

La mayoría de las apps deberían empezar con Nativo. Elige Contenedor solo si tienes un motivo concreto.

Si…Elige
Tienes una sola app en el servidor y no te importa fijar versionesNativo
Quieres el menor consumo extra de RAM (importa en servidores de 1 GB / 2 GB)Nativo
Quieres despliegues más rápidos (sin crear imagen)Nativo
Tienes dos apps con versiones distintas del entorno de ejecución (por ejemplo, Node 18 + Node 22)Contenedor al menos para la que sea diferente
Quieres aislamiento estricto entre apps (por ejemplo, una usa código de terceros en el que no confías del todo)Contenedor
Tu app trae una dependencia compleja que no es el entorno de ejecución (una versión concreta del cliente de Postgres, una compilación de ImageMagick, etc.)Contenedor (todo va incluido en la imagen)
Tienes pensado mover esta app a otro host más adelanteContenedor (la imagen es portable; los despliegues nativos dependen del entorno de ejecución del host)

La comparación en números (aproximados):

  • Nativo: ~50–200 MB RSS por app (solo la app + intérprete). Primer despliegue: 10–30 s.
  • Contenedor: ~50–200 MB RSS para la app + ~30–100 MB de sobrecarga de Docker por contenedor. Primer despliegue: 1–3 min (creación de la imagen).

En un servidor de 2 GB que está casi siempre inactivo, puedes ejecutar 5–8 aplicaciones web nativas + Caddy + una base de datos pequeña. Con contenedores, eso baja a ~4–6.

Cambiar más adelante

El modo es propio de la app: no hay un selector en el panel del servicio para cambiar una app nativa a contenedor ni al revés.

Para cambiarlo, vuelve a desplegar la app desde el modal y elige la otra opción:

  1. Abre AccionesDesplegar desde mi ordenador (o Desplegar una aplicación web desde un repositorio git)
  2. Suelta tu código o pega la URL del repositorio
  3. Despliega Avanzado → cambia el selector Desplegar como
  4. Haz clic en Desplegar: la app existente se sustituye por el nuevo modo

El código permanece en disco (las reglas .helm-keep de Varios sitios en el mismo servidor se aplican igual a los redespliegues en contenedor). Tu dominio sigue apuntando al mismo sitio. La interrupción dura lo que tarde un redespliegue normal: normalmente menos de un minuto.