Despliegue sin interrupciones de Nextjs (servidor local) usando Caddy

Cada vez que me entraban ganas de seguir añadiendo cosas a la página web, hacía un build, y en ese intervalo parece que había gente que se conectaba de vez en cuando.

Por eso empezó a darse el fenómeno de que la puntuación en Search Console iba bajando poco a poco.

Pensé que así no podía seguir y me puse a buscar una forma de hacer despliegues sin interrupciones.

1. 2 carpetas de proyecto + 2 terminales

La solución, sorprendentemente, es sencilla: abrir 2 terminales.

Haces el build en una, mientras en la otra el servidor sigue funcionando.

El problema es que si abres dos terminales dentro de un solo proyecto, se produce un conflicto.

Aunque uno se esté ejecutando bien, en el momento en que haces el build desde la otra terminal, se recrea la carpeta .next, y eso provoca errores internos que al final acaban tirando la web.

Por eso hace falta otra carpeta idéntica al proyecto original.

Como yo también guardaba todas las imágenes en local, modifiqué el proyecto copiado llamado blogCopy para que apuntara a la carpeta original.

Ahora solo quedaba ajustar Caddy.

2. Documentación oficial de Caddy

Ni ChatGPT ni Claude parecían tenerlo muy claro, solo soltaban cosas raras, así que al final entré en la documentación oficial.

El ejemplo que aparecía en la documentación oficial era el siguiente:

example.com {
	reverse_proxy node1:80 node2:80 node3:80 {
		health_uri /healthz
		lb_try_duration 5s
	}
}

Pero esto reparte las peticiones de forma uniforme entre tres nodos, así que necesitaba otro enfoque.

La IA se empeñaba en proponer algo como lo siguiente, pero al meterlo, el reverse proxy dejaba de funcionar.

example.com {
    reverse_proxy localhost:3000 localhost:3001 {
        health_uri /health
        health_interval 5s
        health_timeout 2s
        health_status 200
    }
}

El problema de esto es que no define qué puerto es el principal.

Y como Caddy comprueba los puertos cada 5 segundos, durante los primeros 5 segundos tras iniciarse, no se puede acceder correctamente al puerto adecuado.

Así que decidí gestionarlo manualmente.

example.com {
	reverse_proxy localhost:3000 localhost:3001 {
		lb_policy first
	
   		fail_duration 20s
   		max_fails 2
	}
}

Lo cambié a un método en el que se detecta el fallo de conexión del usuario y entonces se rota el puerto.

De esta manera funciona bien.

3. Conclusión

Ahora ya puedo hacer builds con tranquilidad(?).

A veces, cuando salía un error durante el build, me preocupaba haber dejado el servidor parado demasiado tiempo.

Creo que a partir de ahora eso ya no pasará.

Aprendo cosas todos los días, y aun así siguen apareciendo cosas nuevas que tengo que aprender; es curioso.