Fly
Fly.io is essentially Docker for running applications—you ship a container image, Fly runs it close to users, and you manage it with config files and deploy commands.
At Brytebridge we use Fly for APIs. That is the role today: backend services in containers, not a general home for every workload.
Why Fly vs AWS?
We are choosing Fly for APIs because it gives us gentle guardrails—a smaller, opinionated surface than a full cloud account—so teams can ship without navigating every AWS knob.
Those guardrails help us comply with SDLC standards: separate orgs per tier, branch-named deploy config, production through GitHub Actions, and patterns that line up with Zero Trust—not a free-form production console for day-to-day dev work.
AWS remains the right place for many other resources; Fly is where we run containerized APIs with standards baked in.
Three Fly organizations
Section titled “Three Fly organizations”We run three separate Fly organizations:
| Organization | Apps |
|---|---|
| Production | All production APIs and services |
| UAT | All UAT workloads |
| Staging | All staging workloads |
This is intentional Zero Trust design: segment by environment so each person and token gets the least permissions needed for their layer. Developers work in staging (and UAT where policy allows)—not with blanket access to production—so we avoid inadvertent cross-environment mistakes and security issues.
More standards (branch-named fly.*.toml, tunnels, CI/CD) will build on this layout as we document them.