Despliega Go en Nodion

Despliega Go paso a paso

1. Escucha en PORT Nodion define PORT para el proceso web; escucha en ese puerto en todas las interfaces. r.Run() de Gin sin dirección ya usa PORT. Con Echo, Fiber o Chi, pasa tú ":" + port. main.go

   package main
   
   import (
   	"log"
   	"net/http"
   	"os"
   )
   
   func main() {
   	port := os.Getenv("PORT")
   	if port == "" {
   		port = "8080"
   	}
   	http.HandleFunc("/", func(w http.ResponseWriter, r *http.Request) {
   		w.Write([]byte("ok"))
   	})
   	log.Fatal(http.ListenAndServe(":"+port, nil))
   }

2. Un binario por cada carpeta cmd/ Sin carpeta cmd/, Nodion compila la raíz del módulo en un único binario. Si hay carpetas cmd/<name> con archivos Go, cada una se convierte en su propio binario y el paquete de la raíz no se compila. El proceso web ejecuta el único binario; si hay varios, el que se llame server, api, web o app, y si no, el primero. Cada uno de los demás binarios se convierte en un tipo de proceso con el mismo nombre.

   cmd/server/main.go
   cmd/worker/main.go
   cmd/migrate/main.go

3. Revisa la configuración de build Los binarios se compilan con CGO_ENABLED=0 y -ldflags "-s -w". Si una dependencia necesita cgo, como mattn/go-sqlite3, define CGO_ENABLED=1 en la pestaña Environment marcando Build. Una variable de Build GOFLAGS_LDFLAGS sustituye los ldflags, así que incluye ahí -s -w si quieres conservarlos.
4. Crea la app En el dashboard, crea una aplicación desde tu repositorio de GitHub, GitLab, Bitbucket o Gitea y elige la rama y la región EU Central. Deja la estrategia de build en Buildpacks; si el repositorio tiene un Dockerfile, el formulario selecciona Dockerfile en su lugar.
5. Vincula PostgreSQL y ejecuta las migraciones En la pestaña Environment, vincula una base de datos de la misma región; DATABASE_URL llega con el siguiente despliegue y los drivers de PostgreSQL como pgx la aceptan tal cual. En tiempo de ejecución tus binarios están en el PATH, así que un binario cmd/migrate puede ejecutarse como paso de release, una vez por build, antes de que arranque la nueva versión. Procfile

   release: migrate

A tener en cuenta

• Workers sin ProcfileUn binario de cmd/worker se convierte en el tipo de proceso worker. En la pestaña Processes, añade un proceso llamado worker sin puerto y deja vacío su comando; ejecutará ese binario. Llama al binario web server, api, web o app para que el proceso web no elija otro.
• Siempre el Go más recienteLa línea go de go.mod y un archivo .go-version no seleccionan una toolchain más antigua: cada build usa la release más reciente de Go que Nodion ha compilado. Ejecuta también tu CI con el Go más reciente.

Lo que Nodion gestiona por ti

• Despliegues sin downtime Haz push a tu rama y Nodion construye una nueva release. El tráfico pasa a las nuevas instancias cuando superan el health check; si una release falla, la que está en marcha sigue activa. En cambio, las apps con un volumen local se reinician porque el disco pertenece a una sola instancia.
• Bases de datos junto a la app PostgreSQL, pgvector, MySQL, Valkey y ClickHouse gestionados en la misma región. Al vincular una base de datos, sus datos de conexión llegan como DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Previews por pull request Activa las previews: cada pull request de tu repositorio tendrá su propia app, con URL y bases de datos nuevas y vacías. Puedes crearla automáticamente o a mano. Se omiten las pull requests de forks y bots.
• Workers, cron jobs y escalado Ejecuta workers como procesos adicionales de la misma app, programa tareas en la pestaña Cron y escala cada proceso hasta 16 instancias.
• Paso de release Con buildpacks, una línea release: del Procfile se ejecuta con cada nueva build. Las apps con Dockerfile, así como los redeploys o rollbacks a una imagen anterior, usan un comando de release definido en la propia app, que además tiene prioridad sobre la línea del Procfile. En los sitios estáticos, el paso de release se ejecuta en una imagen que solo contiene los archivos generados por la build.
• Logs y métricas Logs de build, release y runtime, además de métricas de CPU, memoria, disco y red de cada instancia, en el dashboard.
• Dominios y HTTPS Un nombre de host predeterminado con HTTPS desde el primer despliegue; tus propios dominios reciben certificados automáticamente.

Para seguir leyendo

• Por qué hemos creado buildpacks propios sobre Ubuntu 26.04 Nuestros buildpacks siguen la especificación de Cloud Native Buildpacks, pero el stack, los buildpacks de lenguaje y las versiones de runtime son nuestros. Te contamos por qué.
• Dockerfile vs buildpacks: ¿cuál deberías usar? Los dos convierten tu código en una imagen de contenedor. Lo que cambia es quién escribe los pasos de la build, y eso decide el control, el mantenimiento y las actualizaciones de seguridad.

Go en Nodion: preguntas y respuestas