We have a Go-based AI agent platform that generates, compiles, and deploys agent binaries. The current architecture on Fly.io uses two distinct capabilities:
- Ephemeral builder —
DispatchBuildspins up a Fly Machine via the Machines API (api.machines.dev), it builds the Go binary, then the machine self-destructs - Persistent deploy — The compiled binary runs as a long-lived Fly app with
auto_stop_machines/auto_start_machines
This document evaluates Railway, Koyeb, and Northflank as alternative deployment targets.
Ephemeral builder: No direct equivalent. Railway doesn't expose a raw "spin up a machine, run a command, tear it down" API like Fly Machines. Their build system is tightly coupled — you push code/Dockerfile and Railway builds + deploys it as one unit. Workarounds:
- Use a cron job service configured to run once (hacky)
- Build locally/in CI and push a pre-built Docker image
- Use their GraphQL API to trigger a deployment from a Dockerfile that does the build internally
Persistent deploy: Yes. Railway deploys long-running services well, supports custom Dockerfiles, and has ephemeral environments for PR previews. You'd likely push a Docker image containing the compiled agent binary.
Verdict: Feasible but you lose the ephemeral builder pattern. You'd need to build in CI or inside the Docker image itself at deploy time. No equivalent to POST /v1/apps/{app}/machines for fire-and-forget compute.
References:
Ephemeral builder: Partial. Koyeb has Sandboxes — ephemeral compute environments — but they're oriented toward code execution sandboxing, not arbitrary Docker builds. They also have Workers for background jobs but those are persistent, not run-to-completion.
Persistent deploy: Yes. Koyeb supports deploying pre-built Docker images from any registry, with scale-to-zero. Their API is REST-based and straightforward.
Verdict: No ephemeral builder. You'd need to build externally (CI/local) and push a Docker image. The deploy-from-registry API is clean though.
References:
Ephemeral builder: Yes — closest to Fly Machines. Northflank has a first-class Jobs API that supports one-off, run-to-completion tasks triggered via API/webhook. Jobs can build from a Dockerfile, use ephemeral storage, and are torn down after completion. Their API lets you programmatically create jobs with custom environment variables, resources, and deployment config — very similar to the Fly DispatchBuild pattern.
Persistent deploy: Yes. Full service deployment with preview environments from PRs, managed containers, etc.
Verdict: Best fit. Northflank's Jobs + Services model maps almost 1:1 to the Fly Machines (ephemeral builder) + Fly Apps (persistent deploy) pattern. The API is comprehensive enough to replicate DispatchBuild without major architectural changes.
References:
| Capability | Fly | Railway | Koyeb | Northflank |
|---|---|---|---|---|
| Ephemeral builder (fire-and-forget) | Machines API | No | No | Jobs API |
| Deploy from Docker image | Yes | Yes | Yes | Yes |
| Scale-to-zero | Yes | No (always running) | Yes | Yes |
| API-triggered builds | Yes | GraphQL | REST | REST |
| Closest to current arch | Current | Medium effort | Medium effort | Low effort |
If adding a second deployment platform, Northflank would require the least refactoring — its Jobs API is conceptually equivalent to Fly Machines for the builder step. Railway and Koyeb would require moving the build step to CI or into the Dockerfile itself.