Documentación / Conceptos fundamentales / Apps y servicios

Apps y servicios

Las apps son las unidades desplegables dentro de un stack. Cada app se ejecuta como uno o más servicios (contenedores). Entender esta relación es clave para gestionar tus despliegues de forma efectiva.

Apps vs. servicios

En sh0, la distinción entre una app y un servicio es importante:

App

Una app es una configuración -- define qué desplegar, desde qué fuente (Git, imagen, plantilla), con qué ajustes (variables de entorno, dominios, límites de recursos). Una app es una entidad persistente que sobrevive a los despliegues.

Servicio

Un servicio es una instancia en ejecución -- el contenedor Docker real creado desde un despliegue. Los servicios son efímeros. Cada despliegue crea un nuevo servicio y (después de que las verificaciones de salud pasen) elimina el antiguo.

Piensa en una app como el plano y un servicio como el edificio en ejecución. Cuando redespliegas una app, sh0 crea un nuevo servicio desde el plano actualizado, verifica que funcione y luego elimina el servicio antiguo.

Diagram showing an App box containing configuration (Git URL, env vars, domain), with arrows pointing to Service v1 (old, being removed) and Service v2 (new, running)

Apps persist across deployments; services are recreated each time

Ciclo de vida de la app

Una app pasa por varios estados durante su ciclo de vida, desde la creación hasta el despliegue activo:

Estados del ciclo de vida

Estado	Insignia	Descripción
Creada	Gray	La app está configurada pero nunca ha sido desplegada.
Construyendo	Blue	El código fuente se está clonando y la imagen del contenedor se está construyendo.
Desplegando	Yellow	El contenedor se está iniciando y las verificaciones de salud se están ejecutando.
En ejecución	Green	La app está activa y sirviendo tráfico. Las verificaciones de salud están pasando.
Detenida	Gray	La app fue detenida manualmente. El contenedor no está en ejecución.
Fallida	Red	El build o despliegue falló. La versión anterior continúa ejecutándose si está disponible.

App list showing apps in different states: 'frontend' with a green Running badge, 'worker' with a yellow Deploying badge, and 'migration-job' with a gray Stopped badge

Apps display their current lifecycle state

Despliegues sin tiempo de inactividad

Cuando una app está en estado En ejecución y activas un nuevo despliegue, sh0 usa una estrategia blue-green. El servicio antiguo continúa manejando tráfico mientras el nuevo se construye e inicia. El tráfico solo cambia después de que el nuevo servicio pase su verificación de salud. Si el nuevo servicio falla, el antiguo permanece activo.

Crear una app

Las apps se crean dentro de un stack. Navega a un stack y haz clic en Add App. Puedes crear apps desde tres fuentes:

Repositorio Git -- Proporciona una URL, y sh0 clona, detecta el stack, construye y despliega automáticamente.
Imagen Docker -- Descargar y ejecutar una imagen existente de Docker Hub, GitHub Container Registry o cualquier registro privado.
Plantilla -- Elige entre más de 170 plantillas preconfiguradas para aplicaciones populares.

Add App dialog showing three source options as cards: Git Repository with a branch icon, Docker Image with a container icon, and Template with a grid icon

Choose your app source

Configuración de la app

Cada app tiene un panel de configuración completo organizado en varias categorías.

Configuración general

Nombre -- El identificador de la app dentro del stack. También se usa como nombre del contenedor Docker y hostname interno.
Puerto -- El puerto en el que tu aplicación escucha dentro del contenedor. sh0 enruta el tráfico externo a este puerto.
Fuente -- La URL de Git, imagen Docker o configuración de plantilla.
Rama -- Para apps basadas en Git, la rama a rastrear y desde la cual desplegar.
Autodespliegue -- Cuando está habilitado, los pushes a la rama rastreada activan despliegues automáticos.

Configuración de build

Comando de build -- Sobreescribir el comando de build predeterminado (ej., npm run build).
Comando de inicio -- Sobreescribir el comando de inicio predeterminado (ej., node server.js).
Ruta del Dockerfile -- Usar un Dockerfile personalizado en lugar del autogenerado por sh0.
Argumentos de build -- Pasar variables de tiempo de build al proceso de build de Docker.

App settings page showing the Build Settings section with fields for Build Command, Start Command, Dockerfile Path, and Build Arguments

Customizing build and start commands

Límites de recursos

Puedes establecer límites de CPU y memoria en cada app para prevenir que una sola aplicación consuma todos los recursos del servidor:

Configuración	Por defecto	Descripción
Límite de CPU	Sin límite	Máximo de núcleos CPU que el contenedor puede usar (ej., 0.5, 1, 2)
Límite de memoria	Sin límite	RAM máxima (ej., 256m, 512m, 1g). El contenedor se elimina si se excede.
Reserva de memoria	Sin límite	Límite suave. Docker intenta mantener el contenedor cerca de este valor.

Setting Limits via API

curl -X PUT http://localhost:9000/api/apps/APP_ID \
  -H "Authorization: Bearer YOUR_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"cpu_limit": 1.0, "memory_limit": "512m"}'

Sin memoria

Cuando un contenedor excede su límite de memoria, Docker lo elimina inmediatamente (OOMKilled). Si tu app alcanza el límite frecuentemente, aumenta la asignación o investiga fugas de memoria. Consulta la sección de monitoreo para gráficos de uso de memoria.

Políticas de reinicio

Las políticas de reinicio determinan qué sucede cuando un contenedor se detiene o falla:

Política	Comportamiento
`always`	Siempre reiniciar el contenedor, sin importar el código de salida. Por defecto para apps.
`on-failure`	Solo reiniciar si el contenedor sale con un código de salida distinto de cero.
`unless-stopped`	Reiniciar a menos que sea detenido explícitamente por el usuario.
`no`	Nunca reiniciar. Útil para tareas de una sola vez como migraciones.

Tip

Para servicios de larga duración (servidores web, APIs), usa always. Para trabajos de una sola vez (migraciones de base de datos, scripts de seed), usa no para que el contenedor se detenga después de completar la tarea.

Verificaciones de salud

Las verificaciones de salud confirman que tu app funciona correctamente después del despliegue. sh0 soporta dos tipos:

Verificación de salud HTTP -- sh0 envía una solicitud HTTP GET a una ruta especificada (por defecto: /) y espera una respuesta 2xx.
Verificación de salud TCP -- sh0 verifica que el contenedor esté escuchando en el puerto configurado. Se usa para servicios no HTTP.

Health Check Configuration

{"health_check": {"type": "http", "path": "/health", "interval": 10, "timeout": 5, "retries": 3, "start_period": 30}}

App health check settings showing type selector (HTTP/TCP), path field, interval, timeout, retries, and start period fields with sensible defaults

Configuring health checks for your app

Note

Durante el despliegue, sh0 espera a que la verificación de salud pase antes de enrutar tráfico al nuevo contenedor. Si la verificación falla después de los reintentos configurados, el despliegue se marca como fallido y la versión anterior continúa sirviendo tráfico.

Stacks

Domains & SSL