Skip to content

← Back to Fly.io standards

Fly vs AWS

At Brytebridge Fly runs containerized APIs; AWS remains the right place for many databases, queues, identity, and long-lived platform services. This page compares the two for API hosting—not “replace AWS entirely.”

Summary

Section titled “Summary”
Fly (our API default)AWS
RoleDockerized APIs, tunnels, tier orgsBroader cloud primitives and existing platform services
Config surfaceDockerfile, fly.*.toml, GitHub deploy workflowsIAM, VPC, ALB, ECS/EKS/Lambda, S3, RDS, etc.
Logging (APIs)Org-level shipper → Grafana Cloud (no per-app log stack)You design and operate log agents, groups, forwarding
Ops burden (API path)Low—no regional ALB/storage setup for a standard APIHigh—wire LB, networking, compute, often storage yourself

Fly — pros

  • Same Docker model everywhere; gentle guardrails for SDLC
  • Auto-scale and future multi-region from config (see [Fly](/fly/) — starting iad)
  • Org-level logging to Grafana Cloud—apps only need stdout/stderr
  • Cloudflare Tunnel pattern—no public Fly ingress for prod/UAT
  • Separate Fly orgs per tier (staging / UAT / production)
  • Deploy via GitHub Actions + fly.*.toml

Cons

  • Smaller platform—fewer primitives than AWS
  • Not a fit for every workload (we use AWS for those)
  • Standards are Brytebridge-specific (tunnel, no Fly auto-deploy, etc.)

AWS — pros

  • Full cloud catalog (data, messaging, identity, networking)
  • Mature IAM, compliance tooling, and org/account patterns
  • Right home for services we already run on AWS
  • Flexible—any architecture the product needs

Cons (for “just host my API”)

  • Ops burden: load balancers, cross-region routing, compute service choice, often storage and log pipelines
  • Many configuration points before traffic hits your container
  • Easy to over-build or under-standardize without strong conventions

Configuration points

Section titled “Configuration points”

What you typically touch for an API—not every possible service.

Fly (API on Fly)

Section titled “Fly (API on Fly)”
  • Dockerfile — one image for staging / UAT / production
  • fly.staging.toml, fly.uat.toml, fly.main.toml — app name, org, region (iad today), env, health checks, secrets
  • scripts/start-with-tunnel.sh + cloudflared — tunnel token secret; no [http_service] for prod/UAT
  • GitHub workflows — fly-deploy-*.yml; org-scoped FLY_API_TOKEN
  • /health, /metrics — prom-client + nstats (Node)
  • Cloudflare — hostname, access rules, origin http://<app>.internal:8080
  • Logging — nothing extra in the app beyond stdout; org log shipper → Grafana Cloud

AWS (when the API or platform lives on AWS)

Section titled “AWS (when the API or platform lives on AWS)”
  • IAM roles/policies, accounts per environment
  • Network — VPC, subnets, security groups, often ALB (including cross-region if you need it)
  • Compute — ECS, EKS, Lambda, EC2, etc.
  • Secrets — Parameter Store, Secrets Manager
  • Logging — CloudWatch log groups, subscriptions, forwarders to Grafana or other sinks (designed per service)
  • Storage — S3, EBS, etc. when the design requires it
  • CI/CD — pipeline to build image and roll out infrastructure + app

Ops burden — what we skip on Fly

Section titled “Ops burden — what we skip on Fly”

For a standard Brytebridge API on Fly, teams do not manually stand up the AWS-style stack:

  • Load balancers in front of the app (including multi-region ALB/global routing)
  • Block or object storage just to run the API process
  • Per-application log shipping into Grafana (handled at Fly org level)
  • A large networking diagram before the container can receive traffic

Fly + Cloudflare Tunnel + GitHub deploy gives us containers, scale, tunnel ingress, and centralized logs with far fewer moving parts. AWS stays in play where the product needs AWS-native services or existing shared infrastructure.

Section titled “Related”