Desplegar un servicio en Go: el build que no necesita un runtime

Un build de Go produce un único binario enlazado estáticamente, sin nada que resolver en tiempo de ejecución — ninguna versión de intérprete que fijar, ninguna gema ni paquete que descargar en el servidor que está por correr la app. Eso es algo genuinamente distinto de construir comparado con la mayoría de las apps en lenguajes interpretados, y se traduce en menos lugares donde un despliegue pueda salir mal: una vez que el binario compila, corre, punto.

Qué se detecta

Go mismo se detecta a partir de go.mod — incluyendo un módulo que vive en una subcarpeta (server/go.mod junto a un directorio frontend/), encontrado y construido desde el lugar correcto automáticamente.
Un import conocido de driver de base de datos — github.com/jackc/pgx, github.com/lib/pq, github.com/go-sql-driver/mysql, github.com/redis/go-redis — aprovisiona la base de datos correspondiente e inyecta DATABASE_URL o REDIS_URL, sin ningún complemento que agregar a mano antes.
El build corre con Railpack por defecto, o con tu propio Dockerfile si el repo tiene uno.

railyard create my-app https://github.com/me/my-app --port 8080

o la misma URL desde el panel una vez que GitHub está conectado. El único requisito que vale la pena decir claramente: el binario tiene que escuchar en $PORT, y en todas las interfaces, no solo en localhost.

Workers, dado que Go no tiene ninguna convención de framework que detectar

A diferencia de Rails o Django, Go no tiene una librería de colas de jobs dominante que buscar — no hay nada que ofrecer automáticamente como worker. Eso está bien, porque de todos modos es una sola línea:

web:    ./server
worker: ./server -mode=worker

Las dos líneas corren exactamente el mismo binario construido; main() lee un flag o una variable de entorno para decidir qué loop correr en realidad. Un build, varios tipos de proceso, cada uno escalado de forma independiente:

railyard scale my-app worker=2

Para cualquier cosa que corra en un horario en vez de continuamente, Cron corre el binario con un flag distinto a la hora programada y mantiene un historial de ejecuciones — un modelo más limpio que un loop for { time.Sleep(...) } horneado dentro del proceso worker.

Configuración y secretos

Todo lo que se lee con os.Getenv es una variable de entorno simple en Variables, o se define con railyard env:set my-app KEY=VALUE — nunca compilada dentro del binario, así que exactamente el mismo artefacto de build corre sin cambios desde staging hasta producción. Sin recompilar por entorno, que es justamente el punto: una diferencia de configuración entre staging y prod debería ser una variable, nunca un build distinto.

Construir tu propia imagen, cuando lo quieras

railyard deploy my-app --local construye con tu propio Docker y sube una sola imagen directamente, en vez de usar el builder compartido del equipo — útil cuando un build necesita algo específico de tu toolchain local que el camino de build estándar no necesita conocer.

Referencia completa: Documentación de Go, Workers y jobs programados.