Documentación / Conceptos fundamentales / Apps y servicios

Apps y servicios

Una aplicación es la configuración que usted gestiona; los contenedores que ejecuta son los servicios. Esta página explica su relación, los ajustes de una aplicación y lo que sh0 hace por defecto.

Aplicaciones y servicios

Aplicación: la configuración persistente. Su origen, ajustes, variables de entorno, dominios y límites de recursos sobreviven a cada despliegue.
Servicio: un contenedor creado por un despliegue, llamado sh0-<prefijo-id-stack>-<app>-<prefijo-id-despliegue>. Cada despliegue crea uno nuevo; el contenedor anterior solo se detiene y elimina cuando el nuevo está sano y enrutado.

Estado de una aplicación

Una aplicación muestra uno de estos estados:

Estado	Significado
inactive	Creada, nunca desplegada.
building	Un despliegue está construyendo la imagen o iniciando el contenedor.
running	El contenedor superó su comprobación de salud y recibe tráfico.
stopped	Detenida por un usuario (`sh0 stop` o el panel).
failed	El último despliegue falló. Un contenedor de un despliegue anterior que seguía en marcha continúa sirviendo.

Crear una aplicación

En un stack, Agregar app abre la página Desplegar con el stack preseleccionado. Una aplicación puede venir de una imagen Docker, un repositorio Git, un archivo subido, un Dockerfile, un archivo Docker Compose, una plantilla de framework o el catálogo de plantillas. Desde una terminal, sh0 push sube el directorio actual y lo despliega.

Ajustes de una aplicación

La pestaña Configuración de la aplicación contiene estos campos, que se guardan con Guardar cambios:

Campo	Descripción
Nombre de la aplicación	Identificador de la aplicación; también su nombre de host dentro del stack (`<nombre>` y `<nombre>.internal`).
URL del repositorio, Rama	Para aplicaciones Git: el repositorio y la rama que se despliega.
Ruta de build, Dockerfile	Subdirectorio que se construye y Dockerfile que se usa. Sin Dockerfile, sh0 detecta la tecnología y genera uno.
Puerto	Puerto en el que escucha la aplicación dentro del contenedor; el tráfico público se dirige a él.
Réplicas, Orden de arranque, Proyecto	Número de contenedores, posición al desplegar el stack completo y stack al que pertenece la aplicación.

No hay campos de comando de build ni de arranque: decide el Dockerfile. Los argumentos de build son variables de entorno marcadas como «build», consulte Variables de entorno.

Límites de recursos

Cada contenedor de aplicación tiene un límite de CPU y de memoria, en cualquier instalación, con o sin licencia:

Campo	Por defecto	Valores admitidos
CPU	La mitad de los núcleos del host, al menos 0,5	`cpu_limit` en milinúcleos (1000 = un núcleo), de 100 al número de núcleos del host
Memoria	512 MB	`memory_limit` en MB, de 64 a la memoria del host

Cámbielos en la pestaña Escalado de la aplicación, en Límites de recursos, y luego Guardar configuración. En la API, ambos valores son enteros y 0 restablece el valor por defecto. Una cadena como "512m" se rechaza con 422.

Terminal

$ curl -s -X PUT https://panel.example.com/api/v1/apps/e17d4314-ff61-485a-a509-58b3974c1eee/resources \
    -H "Authorization: Bearer $SH0_TOKEN" -H "Content-Type: application/json" \
    -d '{"cpu_limit":500,"memory_limit":256}'
{"data":{"app_id":"e17d4314-ff61-485a-a509-58b3974c1eee","autoscale_cpu_threshold":80,"autoscale_enabled":false,"autoscale_memory_threshold":80,"cooldown_seconds":300,"cpu_limit":500,"created_at":"2026-10-02 02:52:11","current_replicas":1,"id":"64433fb7-a676-4257-8c78-474d2fb961fd","last_scale_at":null,"lb_policy":"round_robin","max_replicas":1,"memory_limit":256,"min_replicas":1,"updated_at":"2026-10-02 03:04:09"}}

Los nuevos límites se aplican en el siguiente despliegue; hasta entonces el contenedor en ejecución conserva los anteriores. Observado en una aplicación de prueba: antes del nuevo despliegue el contenedor seguía con 512 MB y 2 núcleos (host de 4 núcleos), después con 256 MB y 0,5 núcleos:

Terminal

$ docker inspect <container> --format '{{.HostConfig.Memory}} {{.HostConfig.NanoCpus}}'
536870912 2000000000
$ sh0 deploy my-api
[*] Deploying my-api...
  Deployment ID: 9b98d35b-0751-490e-88e8-f089fb0a6007
  Status:        queued
$ docker inspect <new-container> --format '{{.HostConfig.Memory}} {{.HostConfig.NanoCpus}}'
268435456 500000000

Warning

Un contenedor que supera su límite de memoria es eliminado por el kernel (OOMKilled). Si ocurre durante un despliegue, este falla de inmediato en lugar de esperar el tiempo límite de la comprobación de salud. Suba el límite o reduzca el consumo de la aplicación.

Política de reinicio

Cada contenedor de aplicación funciona con la política de Docker unless-stopped: Docker lo reinicia tras un fallo o un reinicio del host, salvo que usted lo haya detenido. La política no es configurable.

Comprobación de salud al desplegar

Antes de enviar tráfico a un contenedor nuevo, sh0 espera a que esté sano, hasta 300 segundos. La comprobación se elige automáticamente y no tiene ajustes:

Si la imagen define un HEALTHCHECK de Docker, sh0 lo usa.
Si no, para una aplicación web, debe tener éxito una conexión TCP al puerto de la aplicación. No hay comprobación de una ruta HTTP.
Un worker (sin puerto) está sano cuando lleva 15 segundos en marcha sin reiniciarse.

Note

Un bucle de fallos o una terminación por falta de memoria hace fallar el despliegue de inmediato. Cuando un despliegue falla, el contenedor anterior no se detiene y sigue sirviendo el tráfico.

Stacks

Dominios y SSL