IS FLY.IO SAFE? SECURITY ANALYSIS | VIBEEVAL

Firecracker Isolation

Fly.io runs each Machine inside a Firecracker microVM — the same hypervisor AWS Lambda uses. That gives you hardware-level isolation between tenants, which is a stronger boundary than the shared-kernel model that container platforms rely on. The platform handles VM provisioning, anycast routing, and TLS termination at the global edge, so the per-region Machine you boot is reachable on a global IP within seconds.

The trade-off Fly makes in exchange for that flexibility: it gives you primitives, not opinions. Most platforms hide their networking. Fly puts a 6PN private IPv6 mesh, an internal DNS namespace, WireGuard, and explicit services config in your hands. That’s powerful when you know what you’re doing and a footgun when you don’t. Most of the audit findings we have on Fly deployments are in the gap between “I expected this to be private” and “but the services.ports block exposed it on 0.0.0.0.”

Security Considerations

Private Networking

Fly’s 6PN private network gives every app in your org a .internal DNS name reachable only from inside the org’s WireGuard mesh. Use it for service-to-service traffic. The mistake we keep finding:

# fly.toml — wrong, exposes the internal API on the public internet
[[services]]
  internal_port = 8080
  protocol = "tcp"
  [[services.ports]]
    port = 80
    handlers = ["http"]

If the service is internal-only, drop the [[services]] block entirely. The Machine is still reachable on <app>.internal over 6PN; nothing should be reachable from the public anycast IP.

# right — internal-only service, no public ports
[experimental]
  auto_rollback = true
# no [[services]] block at all

Volume Encryption

Volumes are not encrypted at rest by default. For anything storing PII, secrets, or regulated data, create the volume with --encrypted:

fly volumes create data --size 10 --region iad --encrypted

There is no in-place encryption migration. If you forgot to encrypt at create time, you have to snapshot, create a new encrypted volume, and copy the data over. Plan accordingly before going to production.

Secrets Management

fly secrets set stores secrets encrypted in the platform and injects them as env vars at boot. Secrets are versioned, and changing one triggers a redeploy. The pattern that bites teams: setting a secret in one app and assuming it’s available across the org. Each app has its own secret namespace.

fly secrets set DATABASE_URL="postgres://..." --app api
fly secrets set DATABASE_URL="postgres://..." --app worker  # separate set
fly secrets list --app api

Avoid baking secrets into the Docker image — flyctl rebuilds on fly deploy and the build cache can leak layer contents. Always inject via secrets, never via ARG or ENV in the Dockerfile.

SSH and WireGuard Access

fly ssh console is convenient and dangerous. Anyone with org membership can pop a shell in any Machine. Restrict org membership to the people who actually need to debug production. WireGuard credentials issued via fly wireguard create give an entire VPN tunnel into the private network — they should be revoked when contractors leave, and never committed.

Application Security

Fly secures the platform; authn, authz, input validation, and the same pile of OWASP-Top-10 fundamentals are yours. The flat private network means a compromise on one Machine can reach every other Machine in the org over 6PN. Defense in depth applies: don’t assume your internal API is safe because it’s “only on the private network.”

Common Mistakes We See in Audits

• [[services]] block left on internal services, exposing them via the public anycast IP.
• Volumes created without --encrypted storing customer PII or backups.
• Secrets baked into Docker images via ARG instead of injected at runtime.
• WireGuard tunnels issued to contractors and never revoked.
• fly ssh console enabled for the whole org instead of restricted to ops.
• Postgres apps deployed via fly pg create left with the default flyio superuser and no rotation.
• auto_stop_machines turned off on staging, running an old vulnerable image for months.

Comparison vs Railway and Render

The three are often considered together. The differences that matter for security:

• Isolation: Fly uses Firecracker microVMs (hardware isolation). Railway and Render use containers (shared kernel). For multi-tenant or regulated workloads, Fly’s boundary is stronger.
• Networking: Fly gives you raw networking primitives via 6PN and WireGuard. Railway and Render hide most of it behind a “private services” toggle. Fly is more powerful and easier to misconfigure.
• Defaults: Render has the safest defaults (private services are private; HTTPS on; managed Postgres encrypted at rest). Fly has the most flexibility. Railway sits in between.
• Compliance: All three are SOC 2 Type II. Fly publishes the most detailed architecture documentation; Render has the cleanest “just works” story.

Enterprise Considerations

• SSO: SAML SSO is on the Launch plan and above. Smaller plans rely on personal GitHub accounts.
• Audit Logs: Org-level audit log is available; ship to your SIEM via the API.
• Compliance: SOC 2 Type II; HIPAA available with a BAA on higher tiers. Confirm scope with their team if regulated.
• Secret rotation: No built-in scheduled rotation. Build it into your CI or use an external secret manager.
• Network egress: Fly does not provide an egress allowlist. If you need outbound IP allowlisting (a common B2B requirement), you’ll need a separate proxy.

Security Assessment

Strengths

• • Hardware-level VM isolation (Firecracker)
• • Automatic HTTPS with managed certificates
• • Private 6PN networking between apps
• • Encrypted secrets management with versioning
• • Global anycast for DDoS resilience
• • SOC 2 Type II compliance
• • Per-region Machine placement for data residency

Concerns

• • Application security is developer responsibility
• • Database access needs proper configuration
• • Volume encryption is opt-in
• • [[services]] block easily exposes internal services
• • Flat 6PN network means lateral movement after compromise
• • SSH console access defaults to all org members
• • No egress IP allowlisting

The Verdict

Fly.io is a safe deployment platform with excellent infrastructure security. Firecracker VM isolation provides stronger boundaries than container platforms — meaningful for multi-tenant or regulated workloads. The flexibility costs you in defaults: enable volume encryption, drop [[services]] on internal apps, restrict SSH access, and treat the 6PN network as untrusted. Application-level security is, as always, yours.

Related Resources

How to Secure Fly.io

Step-by-step guide covering 6PN configuration, volume encryption, secrets versioning, and the SSH/WireGuard hardening checklist.

Fly.io Security Checklist

Interactive checklist for launch-blockers and the quarterly review.

Is Railway Safe?

Side-by-side analysis of the two most popular Heroku-replacement platforms.

Scan Your Fly.io App

Let VibeEval scan your Fly.io deployment for security vulnerabilities — including the exposed-internal-service, missing-auth, and unencrypted-volume patterns that account for most incidents on the platform.