Go

Deploys that survive a dropped stream or a control-plane restart

How I moved each Railyard build into an agent-side session that outlives the gRPC stream, so a ping timeout or a control-plane release no longer kills a customer's deploy, and the Go context bug that came with it.

The deploy that hung for an hour

Two bugs in Railyard's Go agent about the end of a process's life: a build timeout that killed one process out of a tree, and a stale Puma pidfile that survived every restart.

Hardening a deploy platform against apps I didn't write

How I harden Railyard against open-source Rails apps: deploy each one unmodified, group the failures into classes, fix the class on its second occurrence, and only call something fixed when a fresh build reproduces it.

Why Railyard is a Rails app and a Go agent joined by one proto file

Railyard splits into a Rails control plane that decides and a Go agent that does the work on each server, joined by a gRPC contract. How the contract is laid out, how build logs stream, and what the split costs.