En cursoFallido#5Load product images through the new loader7c41e09ahora31 sLa versión #4 siguió sirviendo
En producción#4Tune image loading on the case studies page9b3e0d6hace 1 d24 s
Correcto#3Add the contact form's spam check2f7a8c122 de octubre24 s
Correcto#2Bump Next.js to 15.2 and fix the sitemap route5e9d0b315 de octubre24 s
Correcto#1Rework the homepage hero sectiona1c4f928 de octubre24 s
#5 arranca junto a #4#5 arranca junto a #4Noust le pide la página de inicio cada 2 s
#5 da un error 500 durante 30 s#5 da un error 500 durante 30 sLa comprobación falla y no se le envía ninguna visita
#4 sigue en producción#4 sigue en producciónTodas las peticiones las atendió #4
Tres datos medidos
52 s
de apt install a la primera aplicación con HTTPS, en nuestra prueba
instalar el paquete 22,1 s
preparar el servidor 19,4 s
la primera aplicación con su certificado 10,4 s
Noust 3.3.1, anterior a la 4.0, en un contenedor con Debian 13, dentro de un portátil de 14 núcleos, el 20 de octubre de 2026. El paquete ya estaba descargado y el certificado lo emitió Pebble, el servidor de pruebas de Let’s Encrypt: en un servidor de verdad tarda más.
aplicaciones probadas que se instalan con un comando
Los días 28 y 29 de octubre de 2026 arrancamos cada receta en un servidor limpio, con el código en desarrollo posterior a la 4.0.0, y cada una pasó su comprobación. La prueba entera de una receta, con la descarga de sus imágenes, tarda 54 s de mediana.
versiones de Linux en las que se prueba el instalador
Con paquetes: Debian 12 y 13; Ubuntu 22.04, 24.04 y 26.04; Fedora 43; openSUSE Leap 16.0 y Tumbleweed. Con pip: Rocky Linux, AlmaLinux, RHEL, CentOS Stream y Oracle Linux, en sus versiones 9 y 10.
De un repositorio a HTTPS, una base de datos para la aplicación, una versión rota que nunca recibe tráfico y todos tus servidores en una consola. Grabado tal cual en la consola, sin sonido.
Qué se ve en el vídeo
En la central, Marta empieza una aplicación nueva en fra-1 y escribe el repositorio kelmoor-labs/tidewick-site. Noust reconoce una web en Next.js; ella escribe tidewick.io y la consola comprueba que apunta al servidor.
La despliega y la sigue en directo: descarga, instalación, compilación, arranque y una comprobación de que responde. tidewick.io ya funciona, con HTTPS.
Le crea una base de datos PostgreSQL. Noust la vincula como DATABASE_URL.
Busca la tienda en el buscador. Iker sube un cambio a shop.brumaria.es: la versión nueva no responde a la comprobación de arranque, así que la aplicación vuelve a la versión #21 y la tienda sigue funcionando.
Desde el selector de servidor, toda la flota: fra-1, ams-3 y lon-2 responden, lo que requiere atención en cada uno, y su CPU, memoria y disco lado a lado.
Cada despliegue se comprueba, y si falla sigue el anterior
Cada despliegue se construye junto al que está en producción y solo lo sustituye si pasa la comprobación. Vale para las aplicaciones de Node.js, Next.js, Python y Vite creadas desde la 4.0; las demás, más abajo.
Una animación de dos despliegues seguidos de wrenfield.io. Las visitas siguen llegando por nginx al que está en producción, el #3. El #4 se compila a su lado, en su propio puerto, y Noust le pide la página de inicio cada 2 segundos; responde 200 tres veces, así que nginx manda las visitas nuevas a #4, y #3 termina las peticiones que tenía y se detiene. Después el #5 se compila junto a #4 y se comprueba igual; responde 500 tres veces, así que queda como fallido y se detiene. No le llegó ninguna visita, y #4 siguió sirviendo sin reiniciarse.
1Se construye junto al que está en producción2Se comprueba en su propio puerto3Si la pasa, recibe el tráfico4Si no la pasa, #4 sigue sirviendo
Visitantes
nginxwrenfield.io
#3:3001En producciónTerminandoDetenido
Add the contact form's spam check
#5:3001FallidoCompilandoComprobando
No le llegó ninguna visitaLoad product images through the new loader
#4:3000En producciónCompilandoComprobando
Sin reiniciarseTune image loading on the case studies page
Comprobacióncada 2 s
500200500200500200
GET /GET /GET /500200500200500200
1
1. Se construye junto al que está en producción
El despliegue nuevo tiene su propio directorio y lo compila noust-build, una cuenta sin privilegios. Mientras tanto, el que está en producción sigue sirviendo.
2
2. Se comprueba en su propio puerto
Noust le pide la página de inicio cada 2 s durante 30 s como máximo, y se da por buena cualquier respuesta HTTP con código inferior a 500. La ruta, las respuestas y el tiempo se pueden cambiar.
3
3. Si la pasa, recibe el tráfico
nginx manda las peticiones nuevas al despliegue nuevo, y el anterior termina las que tenía en curso; después se detiene.
4
4. Si no la pasa, #4 sigue sirviendo
#5 se detiene y #4 no se ha reiniciado. El despliegue guarda la salida de la comprobación y el journal.
Lo que deja un despliegue fallido
La salida de la comprobación, tal como la escribe Noust, y las últimas líneas del journal de la aplicación, como las enseña la página del despliegue #5.
The application did not answer the health check.
Health check attempts 1-15 failed: HTTP 500 is not an expected status
Last lines of the journal of wrenfield-io.service:
Oct 29 10:16:02 fra-1 wrenfield-io[52114]: Error: Cannot find module './lib/image-loader'
Oct 29 10:16:02 fra-1 wrenfield-io[52114]: Require stack: .next/server/app/page.js
Las demás aplicaciones también se comprueban
Una web estática cambia un enlace y una aplicación PHP recarga PHP-FPM, sin reiniciar nada. Las demás aplicaciones que guardan sus despliegues anteriores, y los stacks de Compose, se reinician y se comprueban; si fallan, vuelve el despliegue anterior. Las desplegadas con Noust 1.x, que no los guardan, se comprueban y solo avisan si fallan.
Volver a #3 es apuntar current otra vez a su directorio: unos segundos, sin compilar nada.
El directorio de wrenfield.io en el servidor: tres despliegues, #4, #3 y #2, y current, un enlace que apunta al que está en producción, #4. noust releases rollback wrenfield.io mueve current a #3, y #3 queda en producción: no se compila nada. Junto a ellos, shared/.env, un solo fichero con permisos 0600 para todos los despliegues, y repo/, la caché de git.
$noust releases rollback wrenfield.io
Rolled back to release 20261022-141133-2f7a8c1 of wrenfield.io
/var/www/apps/wrenfield-io/
releases/
20261028-031502-9b3e0d6/#4
20261022-141133-2f7a8c1/#3
20261015-094410-5e9d0b3/#2
currenten producción
shared/.env# permisos 0600, compartido entre todos los despliegues
repo/
Noust devuelve el código, nunca la base de datos
Si un despliegue migró la base de datos, Noust pide confirmación antes de volver a uno anterior, porque el esquema se queda como lo dejó la migración: el código vuelve, la base de datos no.
Pon un límite al disco, la memoria, los errores o el tiempo de respuesta. Si un servidor lo supera y sigue por encima, Noust te avisa por Slack, por correo o por otros 11 canales, y otra vez cuando se resuelve.
Leer la guía
Disco de ams-3Última hora
NormalActiva
disk-almost-full: más del 85 % durante 10 min
100 %85 %50 %0 %
10 minSaltó al 91 %Resuelta al 63 %
10:0010:1510:3010:4511:00
#opsen Slack
NNoust App
disk-almost-full está activa en ams-3Disco al 91 % durante 10 min; el límite es el 85 %.10:40
MMarta ha reconocido la alertaLos recordatorios se paran mientras la atiende.10:43
La limpieza de ams-3 liberó 11,4 GBLa lanzó Marta: borró 4 versiones antiguas y 6 volcados de bases de datos.10:47
disk-almost-full resuelta en ams-3Disco al 63 %, otra vez por debajo del límite.10:49
Let’s Encrypt para cada dominio, renovado cuando le quedan 30 días. Si a uno le quedan menos de 14, te llega una alerta.
Leer la guía
Certificados en fra-1
Hoy 26 oct27 oct28 oct29 oct
avisorenueva0143090 días
wrenfield.ioVálidoRenovandoRenovadoCaduca el 26 nov, en 31 díasCaduca el 26 nov, en 30 díasCaduca el 25 ene 2027, en 90 díasCaduca el 25 ene 2027, en 89 díasCaduca el 25 ene 2027, en 88 días
api.kestrelworks.ioVálidoCaduca el 23 dic, en 58 díasCaduca el 23 dic, en 57 díasCaduca el 23 dic, en 56 díasCaduca el 23 dic, en 55 días
blog.nortewave.comNo se renovóCaduca el 11 nov, en 16 días; el nombre apunta a otro servidorCaduca el 11 nov, en 15 días; el nombre apunta a otro servidorCaduca el 11 nov, en 14 días; el nombre apunta a otro servidorCaduca el 11 nov, en 13 días; el nombre apunta a otro servidor
Enviado a #ops en Slack: el certificado de blog.nortewave.com caduca en 13 días y no se pudo renovar.
Con tu proveedor de DNS conectado, añadir un nombre crea su registro. Noust lo comprueba en resolutores públicos, configura el servidor web y añade el nombre al certificado sin reiniciar la aplicación.
Leer la guía
www.tidewick.ioAlias de tidewick.io en fra-1
Registro DNSEn esperaCreándolo en CloudflareA 203.0.113.10, creado en Cloudflare
Apunta aquíEn esperaPreguntando a 1.1.1.1 y 8.8.8.81.1.1.1 y 8.8.8.8 responden 203.0.113.10
La aplicación, su .env y sus bases de datos, cifradas y enviadas a S3, R2, Backblaze o SFTP. Guarda las siete últimas y cada 30 días prueba a restaurar una.
Leer la guía
wrenfield.io en fra-1
Cada noche a las 03:00
La copia de esta noche
versión #4
.env
wrenfield_prod, 2,1 GB
Próxima a las 03:0003:00:02 Copiando la base de datos wrenfield_prod03:00:29 Enviando a vault-r2Enviada a las 03:00:41, 2,3 GB
Conserva el PostgreSQL 16 del servidor y pon el 17 a su lado: la imagen oficial, fijada a su versión exacta, escuchando solo en 127.0.0.1.
Leer la guía
Versiones que Noust puede ejecutar junto a las del servidor
PostgreSQL
12131415161718
MySQL
5.78.08.49.7
MariaDB
10.610.1111.411.8
Redis
7.27.48.08.4
Valkey
7.289
KeyDB
6.3
ClickHouse
25.826.326.8
MongoDB
6.07.08.0
PostgreSQL también con pgvector y PostGIS. Imágenes oficiales; consultamos el registro de cada motor el 6 de octubre de 2026.
Motores en fra-1
PostgreSQL 16.4En ejecuciónDe los paquetes del servidor, puerto 5432
MySQL 8.0.39En ejecuciónDe los paquetes del servidor, puerto 3306
Redis 7.2En ejecuciónDe los paquetes del servidor, puerto 6379
PostgreSQL 17postgresql@pg17, de la imagen oficial fijada a su versión exacta, en 127.0.0.1:5433 con 512 MBDescargando la imagenArrancandoEn ejecución
17
206 aplicaciones que se instalan con un comando
Nextcloud, Immich, Grafana, Vaultwarden y 202 más. Cada receta fija la versión exacta de sus imágenes. 199 se arrancaron en un servidor limpio el 28 y el 29 de octubre de 2026 y pasaron su comprobación; otras 7 esperan todavía esa prueba.
Una central, que es un Noust más, gestiona los demás servidores por túneles SSH que abre ella, sin shell. Cada servidor decide hasta dónde llega.
La central nunca tiene shell
Su clave solo permite reenviar un puerto. Cualquier otra orden acaba en /usr/bin/false, que no hace nada, y lo imponen tanto sshd como la propia clave.
Cada servidor fija hasta dónde llega la central
Leer, desplegar o administrar: lo eliges en el servidor con noust fleet authorize y es el servidor quien lo hace cumplir.
Si cambia la clave SSH de un servidor, el túnel se cierra
La central guarda la clave de cada servidor al añadirlo. Si cambia, cierra el túnel y explica el motivo en vez de fiarse de la nueva.
Una animación de la flota de ejemplo. fra-1, la central, abre un túnel SSH con cada uno de ams-3, lon-2 y mad-1; ams-3 la deja administrar, y lon-2 y mad-1 solo desplegar. La central manda una actualización a los tres. palenbrook.io en ams-3 y quillfield.io en mad-1 pasan la comprobación y entran en producción; en lon-2, la versión #14 de staging.wrenfield.io no la pasa y sigue sirviendo la #13. El certificado renovado de quillfield.io en mad-1, una copia enviada desde lon-2 y una alerta del disco al 91 % en ams-3 llegan a la consola de fra-1. Después mad-1 deja de responder y su túnel se cierra; la central lo vuelve a abrir y mad-1 responde.
fra-1Central, Fráncfort
Todos respondieronAbriendo los túneles1 no responde
fra-13 túneles abiertos
fra-1Actualizando 3 servidores2 de 3 servidores actualizados
Dos personas para todo lo que sea root, y un registro que nadie retoca sin que se note
Los roles deciden quién puede hacer qué. Con las aprobaciones activadas, lo que equivale a root espera a que lo apruebe otra persona. Cada cambio entra en un registro de auditoría encadenado línea a línea que se copia fuera del servidor.
Una animación de una aprobación y del registro de auditoría de fra-1. Marta, administradora, pide un terminal de root en fra-1, y la petición espera a una segunda persona. Sara, de seguridad, la aprueba y el terminal se abre. Cada paso queda escrito en el registro de auditoría de fra-1, cada línea encadenada a la anterior por su HMAC, y cada línea se copia al SIEM, fuera del servidor, en cuanto se escribe. Después, en ese terminal de root, Marta reescribe con sed la línea 62 del registro para que diga sara en vez de ella. Sara lanza noust audit verify: comprueba la cadena desde arriba, da por buenas las líneas anteriores y se para en la 62, que se cambió después de escribirse. La copia de la línea 62 en el SIEM, fuera del servidor, sigue diciendo marta.
M
MartaAdministrador
S
SaraResponsable de seguridad
noust audit verify
fra-1Fráncfort
Aprobaciones
Nada pendiente
Terminal de root en fra-1
La pide MartaAprobada por SaraEspera a otra persona
Un terminal de root, una unidad o un fichero de nginx escritos a mano, un hook de despliegue o un rol nuevo esperan a que los apruebe alguien de seguridad, que nunca puede ser quien los pidió.
Quien tiene root en el servidor tiene la clave y podría rehacer una cadena coherente. La copia que Noust envía por syslog o a tu SIEM en cuanto se escribe cada línea queda fuera de su alcance y sigue diciendo lo que pasó.
Las aplicaciones nuevas nunca se compilan como root
La instalación y la compilación se ejecutan como noust-build, dentro de un entorno aislado de systemd. Si Noust no puede comprobar que el aislamiento funciona, la compilación se para en vez de pasar a root. Compilar una aplicación como root es una decisión que queda registrada y, con las aprobaciones activadas, pide una segunda persona.
noust-buildCompilación de wrenfield.io #5
Llega a
releases/#5
su caché de compilación
las variables de su .env
No ve
/root
/etc/noust
otras aplicaciones
la base de datos de Noust
Llega a: releases/#5, su caché de compilación, las variables de su .env. No ve: /root, /etc/noust, otras aplicaciones, la base de datos de Noust.
Un solo ajuste aplica las medidas de la categoría media que una herramienta como Noust puede hacer cumplir, y un informe da al auditor las evidencias. Noust no es un sistema certificado.
Cada versión lleva una etiqueta de git firmada, y el instalador publica su SHA256SUMS, también firmado. Los paquetes de Python de cualquier commit se reconstruyen idénticos, byte a byte. Verificar una versión
Avisar de una vulnerabilidad en privado
Abre un aviso privado en GitHub o escribe a support@noust.dev con «[noust security]» en el asunto. Confirmamos que lo hemos recibido en 3 días laborables y acordamos la gravedad en 10. Abrir un aviso privado
Todo lo que hace la consola se puede automatizar
La consola usa la misma API JSON que tus scripts, y cada página enseña la orden equivalente.
# compila #5 junto a #4, lo comprueba y cambianoust update wrenfield.io# cada despliegue en el disco, con el que sirve marcadonoust releases list wrenfield.io# apunta current al despliegue anterior, en segundosnoust releases rollback wrenfield.io# el journal de la aplicación, con las credenciales ocultasnoust logs wrenfield.io --follow# una receta, con la misma comprobación que cualquier aplicaciónnoust recipe install immich -d photos.kelmoor.dev
Una orden por acción, con los nombres que usa la consola.Todas las órdenes
# Pone una actualización en cola y responde 202 con el trabajo, que puedes seguir.curl -X POST https://fra-1.kelmoor.dev/api/jobs/update \
-H "Authorization: Bearer $NOUST_TOKEN" \
-H "Content-Type: application/json" \
-d '{"domain": "wrenfield.io"}'# Cada ruta que usa la consola, en un solo esquema.curl -H "Authorization: Bearer $NOUST_TOKEN" \
https://fra-1.kelmoor.dev/api/openapi.json
Cada token tiene su alcance y su dueño. El esquema OpenAPI está en /api/openapi.json.La API
# noust.yaml, en la raíz del repositoriohooks:pre_deploy:
- run: ./node_modules/.bin/prisma migrate deploy
timeout: 600
# para volver atrás desde aquí, Noust pide confirmaciónmigrates: true
post_deploy:
- run: ./scripts/purge-cache.sh
También puedes dejarlo en el repositorio, en noust.yaml. Si el fichero trae una clave que Noust no conoce, el despliegue falla y dice cuál.Los hooks
import os
from noust_sdk import Client
client = Client("https://fra-1.kelmoor.dev", token=os.environ["NOUST_TOKEN"])
for app in client.applications.list_apps()["apps"]:
print(app["domain"], app["status"])
# espera a que termine la comprobación; si falla, lanza JobFailed
queued = client.applications.create_app({
"domain": "shop.brumaria.es",
"source": "https://github.com/kelmoor/brumaria-shop.git",
})
job = client.wait_for_job(queued)
Leímos la documentación, los precios y el código de cada plataforma el 29 de octubre de 2026, y las respuestas de Noust salen de su documentación de la 4.1. Si algo ha cambiado, avísanos en una incidencia.
Gratis y libre, con todas las funciones
Todo lo que hace Noust está en la versión gratuita, con el inicio de sesión único y la auditoría.
Community
0 €
Licencia AGPL-3.0
Todas las funciones: flota, inicio de sesión único, SCIM, roles, auditoría y perfil del ENS
Tantos servidores y aplicaciones como quieras
Paquetes firmados y actualizaciones con apt, dnf o zypper
Respuestas cortas. Cada una enlaza a la explicación completa.
¿Puedo usarlo en un servidor que ya tiene mis aplicaciones?
Sí, sin reconstruirlas. Con noust app discover ves los sitios de nginx y Apache que no escribió Noust, y adoptar uno lo pone en la consola con su estado, sus registros y sus reinicios. Un stack de Compose se adopta tal como está funcionando, con noust app adopt. Un sitio adoptado todavía no tiene despliegues, así que no hay a qué volver hasta que lo despliegues desde su código.
El servicio sí: instala paquetes y escribe la configuración de nginx, systemd y los certificados. En las aplicaciones nuevas, las compilaciones, las instalaciones y los hooks de despliegue se ejecutan con noust-build, una cuenta sin privilegios, en un entorno aislado de systemd, y cada aplicación con una cuenta propia.
Para tus propias aplicaciones, no: Noust ejecuta directamente Node.js, Python, PHP, Go y webs estáticas, como servicios de systemd detrás de nginx o Apache. Docker hace falta para los stacks de Compose, las aplicaciones en contenedor y la mayoría de las recetas.
Para empezar, 1 GB de memoria, 1 procesador y 10 GB libres; con 2 GB y 2 procesadores va holgado, y por debajo de 512 MB de memoria o 3 GB de disco el instalador se detiene. Instala nginx, certbot, git y Node.js. En reposo, Noust ocupa unos 290 MB de memoria: la consola y el monitor, medidos en Ubuntu 24.04.
¿Qué pasa con mis aplicaciones si dejo de usar Noust?
Siguen funcionando. Cada una es una unidad de systemd, un sitio de nginx o Apache, un directorio y un fichero .env, y con systemctl, journalctl y git basta para llevarlas sin Noust.
No envía datos tuyos ni de tus servidores: no hay telemetría. Lo único que hace por su cuenta es preguntar si hay una versión nueva. Al otro lado solo se ve la dirección IP del servidor. Con noust config set updates.check false lo desactivas.
Sí, con noust console expose, que le pone un nombre, un certificado y nginx por delante. El comando se niega a publicarla mientras alguna cuenta pueda entrar sin segundo factor.
