Deploying a Rails API on Fly.io: Architecture, Pitfalls, and Lessons Learned

Although my default deployment platform for Rails APIs is Render, I’ve recently been exploring other platforms — specifically Fly.io, Railway, and Cloudflare — to better understand their trade-offs in real-world Rails deployments.

This article documents my experience deploying a Rails API on Fly.io, including what worked well, what broke, and why I ultimately kept Render as my primary platform for this project.

Architecture overview

flyio-rails-api-deployment

At a high level, the setup looks like this:

• Rails API runs inside a Docker container
• Deployed as Fly Machines (lightweight VMs)
• Managed Fly Postgres cluster
• Secrets injected via Fly (RAILS_MASTER_KEY, DATABASE_URL)
• Traffic routed through Fly’s global proxy
• Rails server must bind to 0.0.0.0:3000

This architecture is clean and powerful — but it assumes you are comfortable with Docker and infrastructure-level concerns.

What worked well

• Fast global deployment with minimal latency
• Clear separation of app and database
• Strong Docker-based workflow (great for infra learning)
• Rails app deployed successfully and served requests
• API reachable publicly via Fly domain

The API itself ran correctly, and the deployment flow made sense once everything was aligned.

Pitfalls I encountered

This is where Fly.io differs sharply from Render-style PaaS platforms.

1. Docker dependency management Missing system packages (yarn, node, libyaml, etc.) caused repeated build failures. This is expected in Docker—but easy to underestimate if you come from Render.
2. Rails must listen on 0.0.0.0 Binding to localhost works locally but breaks on Fly. A small detail with big consequences.

About Cloudflare and Railway

• Railway is Rails-friendly but increasingly restrictive on its free tier.
• Cloudflare does not support Rails apps directly (Workers are not suitable for Rails), so it’s not a viable option for this use case.
• Fly.io sits somewhere between PaaS and infrastructure — it gives power, but expects responsibility.

Final decision

Although the API is live on both Render and Fly.io, I chose to continue with Render for this project because:

• It aligns better with my current delivery needs
• Fewer moving parts for a production Rails API

That said, Fly.io is a solid platform — especially if you want deeper control and are comfortable with Docker and infrastructure concepts.

Closing thoughts

This wasn’t a failed experiment — it was a valuable one.

Understanding Fly.io has made me a better Rails engineer, especially around:

• Docker
• Environment parity
• Deployment observability
• Database lifecycle management

I’ll continue exploring Fly.io and similar platforms — but with clearer expectations.

Source code: https://github.com/HossainAraf/medic-bd