Linux Cloud Boxes en Dockup: 7 opciones de distribución

Los Linux cloud boxes proporcionan un entorno de sistema operativo que configuras mediante SSH. Son útiles para experimentos, software heredado, servicios de sistema personalizados, build hosts y cargas de trabajo cuyo ciclo de vida no está vinculado de forma natural a un repositorio de Git o a una imagen de contenedor.

Dockup admite siete opciones de imagen: Ubuntu 22.04, Ubuntu 24.04, Debian 12, Alpine 3.20, Fedora 40, AlmaLinux 9 y Rocky Linux 9.

¿Cuándo es mejor una Linux box que un servicio de contenedores?

Elige una box cuando la carga de trabajo necesite controlar el sistema operativo, en lugar de limitarse a ejecutar un proceso de aplicación.

Algunos ejemplos adecuados son:

• Instalar varios system daemons.
• Probar paquetes del sistema operativo de forma interactiva.
• Ejecutar una aplicación heredada con configuración manual.
• Mantener un host de build o automatización.
• Reproducir el entorno Linux de un cliente.
• Ejecutar herramientas de larga duración que no estén organizadas como un despliegue desde Git.
• Crear un workspace SSH temporal y aislado.

Prefiere un servicio de Dockup cuando la carga de trabajo sea una aplicación reproducible con repositorio, build, comando de inicio, health endpoint y necesidades de escalado horizontal.

Requisito	Linux box	Servicio de contenedores
Personalización del sistema operativo con privilegios de root	Encaja muy bien	Incluye los cambios en el Dockerfile
Administración mediante SSH	Nativa	El shell interactivo es PRO
Auto-deploy mediante Git push	Configuración manual	Integrado
Blue-green health gate	Diseño manual	Integrado
Imagen reproducible	Requiere runbook/script	Dockerfile/Nixpacks
Autoscaling	No es el modelo de la box	Opción de Kubernetes
Pruebas rápidas de distribuciones	Encaja muy bien	Puede bastar con la base image

Una box sustituye automatización de despliegues por flexibilidad del sistema operativo.

¿Qué siete distribuciones de Linux están disponibles?

Consulta la lista de imágenes actual:

dockup box images --json

Imagen	Ecosistema de paquetes	Motivo habitual para elegirla
ubuntu-22.04	APT	Compatibilidad a largo plazo
ubuntu-24.04	APT	Base Ubuntu LTS más reciente
debian-12	APT	Servidor general conservador
alpine-3.20	apk	Entorno pequeño basado en musl
fedora-40	DNF	Herramientas de Linux más recientes
almalinux-9	DNF	Compatibilidad con Enterprise Linux
rockylinux-9	DNF	Compatibilidad con Enterprise Linux

Adapta la distribución al entorno compatible que indique el proveedor del software. Alpine usa musl en lugar de glibc, lo que puede afectar a los binarios nativos precompilados. Las variantes de Enterprise Linux son útiles cuando el software espera ese ecosistema de paquetes.

Registra el slug exacto de la imagen. “Ubuntu” no es suficiente porque las versiones de los paquetes y los periodos de soporte difieren entre 22.04 y 24.04.

¿Cómo se crea una Linux cloud box?

Provisiona la imagen con un nombre, memoria y CPU:

dockup box create \
  --project production \
  --image ubuntu-24.04 \
  --name build-host \
  --memory 2048 \
  --cpu 1 \
  --json

Este ejemplo solicita 2.048 MB de RAM y 1 vCPU. Empieza con requisitos medidos y ajusta los recursos según el comportamiento observado de la carga de trabajo. El uso de CPU, RAM y disco se descuenta del saldo del plan con medición por minuto.

El plan Free cuesta 0 $ al mes e incluye un crédito inicial de 10 $, un workspace, tres bases de datos y tres despliegues. Los planes de pago permiten recursos ilimitados por cantidad, aunque el consumo de compute sigue descontándose del saldo incluido. El plan Pro recomendado cuesta 20 $ al mes e incluye 20 $ de crédito de uso.

La box creada se convierte en un recurso del proyecto con un target estable como production/build-host. Mantén ese target en el runbook.

¿Cómo se obtienen y protegen las credenciales SSH?

Solicita los datos de conexión:

dockup box ssh production/build-host --json

La respuesta incluye el host, el puerto, el usuario y la contraseña. Trata la contraseña como información confidencial. Guárdala en un gestor de contraseñas aprobado, no la muestres en la respuesta de un agente y rótala o sustitúyela según la política de la organización.

Antes de conectarte:

1. Verifica el proyecto y el slug de la box.
2. Confirma que el operador tiene autorización.
3. Registra el propósito de la sesión.
4. Evita copiar secretos de producción en una box desechable.
5. Mantén el historial de comandos y los logs libres de credenciales.
6. Cierra las vías de acceso y las sesiones que no utilices.

El acceso SSH proporciona un amplio nivel de control dentro de la box. Un coding agent con la credencial podría instalar paquetes, modificar servicios, exponer puertos o eliminar archivos. Usa el acceso de agentes únicamente para tareas revisadas y acotadas, y conserva un registro de auditoría fuera del shell.

El artículo AI agent production guardrails explica el modelo de autonomía.

¿Cómo debe iniciarse una carga de trabajo SSH en una Linux box?

Después de obtener el acceso SSH, configura el inicio de procesos con las herramientas del sistema operativo compatibles con la distribución. Ubuntu, Debian, Fedora, AlmaLinux y Rocky Linux suelen usar systemd; Alpine utiliza sus propias convenciones de gestión de servicios.

La definición de inicio debe indicar el ejecutable, el directorio de trabajo, el usuario de ejecución, el entorno necesario, la política de reinicio y el destino de los logs. Mantén las credenciales fuera del unit file o del startup script y usa rutas absolutas para que el comportamiento no dependa de un shell interactivo.

Comprueba lo siguiente:

• La carga de trabajo se inicia después de un reinicio sin que un operador tenga que iniciar sesión.
• El entorno necesario está disponible sin depender de exports exclusivos del shell.
• Los logs tienen una ubicación conocida.
• El proceso se ejecuta con el usuario previsto.
• Los fallos son observables.
• Las actualizaciones no sustituyen dependencias silenciosamente.

Para un único proceso web con estos requisitos, un servicio de contenedores basado en Git puede ofrecer ya un ciclo de vida mejor.

¿Cómo se debe operar y reconstruir una Linux box?

Trata cada comando manual como una posible configuración divergente. Captura la configuración en un script o en un proceso de gestión de la configuración:

#!/usr/bin/env bash
set -euo pipefail

apt-get update
apt-get install -y git ca-certificates
mkdir -p /opt/app

Este ejemplo genérico no es un comando de Dockup; muestra cómo hacer repetible la configuración de una box. Fija o documenta las versiones de los paquetes cuando la carga de trabajo necesite estabilidad.

El runbook de una box debe incluir:

• Slug de la imagen.
• CPU y memoria solicitadas.
• Paquetes y repositorios instalados.
• Cuentas de usuario y política de SSH.
• Ubicaciones del sistema de archivos.
• Servicio de inicio, ejecutable y directorio de trabajo.
• Servicios expuestos y su autenticación.
• Método de backup de datos.
• Procedimiento de parches y reinicio.
• Pasos de reconstrucción.
• Criterios de migración o retirada.

No des por hecho que el sistema de archivos de una box tiene el mismo flujo de snapshots que el volumen de un servicio de Dockup, salvo que dicho flujo esté configurado y admitido explícitamente para ese recurso. Diseña los backups para los datos y el software que realmente se ejecutan allí.

¿Cuándo debe trasladarse la carga de trabajo a un contenedor?

Pasa a un servicio de contenedores cuando:

• La configuración se haya convertido en un script estable.
• Un único proceso de aplicación sea el objetivo principal.
• Los cambios de código deban desplegarse desde Git.
• Se necesiten releases sin downtime con health gates.
• El rollback deba seleccionar un ID de despliegue anterior.
• Se necesiten varias réplicas idénticas.
• La box presente divergencias entre operadores.
• El acceso SSH se utilice únicamente para volver a desplegar manualmente.

Convierte la configuración en un Dockerfile, define el puerto de la aplicación y la ruta de health, y despliega primero un servicio de preview o uno que no sea de producción. Compara el comportamiento antes de apagar la box.

La guía Nixpacks vs Dockerfile ayuda a elegir el nuevo método de build. Kubernetes vs Docker explica las opciones de ubicación en el runtime.

Checklist para elegir una Linux box

Una decisión fiable sobre Linux cloud boxes responde a estas preguntas:

1. ¿Cuál de los siete slugs de imagen coincide con el soporte del proveedor?
2. ¿Por qué no puede utilizar la carga de trabajo un servicio normal?
3. ¿Cómo se protegen las credenciales SSH?
4. ¿Cómo se reproduce la configuración?
5. ¿Dónde se encuentran los logs y los datos persistentes?
6. ¿Cómo se prueban los parches?
7. ¿Qué proceso debe iniciarse automáticamente?
8. ¿Qué evento desencadena la contenerización o la retirada?

Consulta la referencia de la CLI de Dockup para ver los comandos actuales de las boxes y la lista de imágenes. Para trabajos exclusivos de Windows, compara Windows VM con RDP.

Control de la confianza en paquetes y repositorios

Una box puede instalar cualquier paquete que solicite el operador, por lo que las fuentes de paquetes forman parte del perímetro de seguridad. Usa los repositorios firmados de la distribución, documenta los repositorios de terceros y evita canalizar scripts de red no revisados directamente a un shell de root.

Registra la lista de paquetes después de la configuración y compárala durante el mantenimiento. Cuando un agente proponga instalar una herramienta, exige la fuente del paquete, la versión, el propósito y el plan de desinstalación.

Mide si la box sigue estando justificada

Revisa cada mes la frecuencia de las sesiones SSH, los pasos de despliegue manual, el requisito de uptime, el uso de recursos y los incidentes de divergencia. Una box que recibe releases de la aplicación de forma habitual mediante SSH indica que necesita un flujo de trabajo de servicio reproducible.

Revisa el consumo de CPU, RAM y disco de la box en app.dockup.ai, junto con el runbook. Las Linux cloud boxes son valiosas cuando el control del sistema operativo es el requisito; resultan costosas desde el punto de vista operativo cuando solo ocultan un despliegue de aplicación no documentado.

Retira las boxes temporales de forma deliberada

Una box de pruebas debe tener un responsable y una fecha de caducidad desde el momento de su creación. Antes de retirarla, exporta únicamente los datos persistentes aprobados, elimina las credenciales copiadas, conserva cualquier script de configuración reutilizable y confirma que ningún DNS, tarea programada o runbook del equipo siga dependiendo del host.

Así evitarás que un experimento breve se convierta en un servidor permanente sin parches.

Mantén un responsable del acceso de emergencia

Designa a la persona o al equipo responsable cuando el operador SSH habitual no esté disponible. El responsable de respaldo debe saber dónde se almacenan las credenciales y cómo verificar el target exacto sin compartir contraseñas.

Conserva la justificación

Documenta por qué las Linux cloud boxes siguen siendo necesarias.

Empieza con un despliegue verificable

Crea una box pequeña que no sea de producción, automatiza toda su configuración desde una imagen limpia y decide por adelantado qué evidencias justificarían trasladar la carga de trabajo a un contenedor.

Empieza gratis en app.dockup.ai. El plan Free cuesta 0 $ al mes, incluye un crédito inicial de 10 $ y admite un workspace, tres bases de datos y tres despliegues.

Preguntas frecuentes

¿Qué distribuciones de Linux pueden usar las boxes de Dockup?

Dockup admite ubuntu-22.04, ubuntu-24.04, debian-12, alpine-3.20, fedora-40, almalinux-9 y rockylinux-9.

¿Cómo obtengo las credenciales SSH de una Linux box?

Ejecuta dockup box ssh con el target exacto del proyecto y la box, junto con --json, y almacena de forma segura los datos de conexión devueltos.

¿Cómo debe iniciarse el software después de configurar SSH?

Configura el inicio con el service manager compatible de la distribución seleccionada y documenta el ejecutable, el directorio de trabajo, el usuario de ejecución, el entorno, la política de reinicio y los logs.

¿Cuándo es mejor un servicio de contenedores que una Linux box?

Usa un servicio de contenedores cuando la carga de trabajo sea una aplicación reproducible que se beneficie del despliegue desde Git, health gates, rollback y autoscaling.

¿Cómo se cobran los recursos de una Linux box?

El consumo de CPU, RAM y disco se mide por minuto y se descuenta del saldo del plan, por lo que debes supervisar el uso real y evitar asignaciones sobredimensionadas.