Ejecutar Docker en un VPS económico

Por qué Docker en un VPS pequeño, para empezar

El argumento a favor de Docker no tiene nada que ver con el tamaño de la máquina. Los despliegues reproducibles significan que la imagen que probaste es, byte a byte, la que corre en producción; el rollback es simplemente arrancar la tag anterior; y el contenedor que funciona en tu portátil funciona de forma idéntica en producción.

En un VPS pequeño estas propiedades importan más, no menos. Cuando los recursos escasean no puedes permitirte un misterio — depurar al estilo 'en mi máquina funciona' quema exactamente el tiempo y la memoria que no tienes. Una imagen, en todas partes, acaba con esa clase de problemas.

La memoria es el presupuesto

En un VPS económico, la RAM es el recurso que se agota primero, y Docker dejará alegremente que un contenedor mate de hambre al resto si no le dices lo contrario. Pon un límite de memoria explícito a cada contenedor, para que una fuga se convierta en un servicio reiniciado en lugar de un servidor congelado.

Añade un archivo de swap modesto como red de seguridad — no para vivir de él, sino para sobrevivir a picos breves sin que el kernel mate procesos al azar. Y prefiere imágenes slim o alpine: una base más pequeña significa menos memoria, descargas más rápidas y una superficie de ataque menor.

• Establecer límites --memory por contenedor
• Usar imágenes base ligeras
• Un proceso por contenedor

Compose para todo el stack

Un solo docker-compose.yml que describa tu aplicación y su reverse proxy convierte todo el stack en un único archivo que puedes leer, versionar y reproducir. Levantar el servidor desde cero pasa a ser un solo comando, en lugar de un ritual recordado a medias.

Mantén el archivo aburrido y explícito: tags de imagen fijadas, políticas de reinicio, límites de memoria. Todo lo que ejecuta el servidor debe verse en ese archivo — si no está en Compose, no existe.

services:
  app:
    image: ghcr.io/you/app:latest
    restart: unless-stopped
    mem_limit: 512m

Mantén la base de datos fuera del contenedor

Ejecutar PostgreSQL o MySQL en Docker sobre una máquina diminuta es donde los montajes económicos van a morir. Las bases de datos quieren memoria estable, almacenamiento cuidado y copias de seguridad de verdad — justo lo que un VPS pequeño con contenedores peleándose por la RAM no puede prometer. Un OOM kill en mitad de una escritura y estarás restaurando a base de esperanza.

Usa en su lugar una base de datos gestionada y deja que el VPS haga lo que se le da bien: ejecutar tu aplicación sin estado. El estado pertenece a otro sitio — en Anested Cloud, PostgreSQL, MySQL y MongoDB gestionados empiezan gratis, y tus contenedores solo reciben una cadena de conexión.

Actualizaciones sin drama de caídas

La rutina de actualización es corta: descargar la nueva imagen, reiniciar el servicio y dejar que un health check confirme que el nuevo contenedor realmente responde antes de seguir. Si no responde, reiniciar la tag anterior es tu rollback — segundos, no una tarde entera.

Antes de cambios grandes — nuevas versiones mayores, reescrituras del archivo Compose — haz primero un snapshot del VPS. Es el seguro más barato que existe: si la actualización sale mal, restauras la máquina entera al instante justo anterior a tocarla.