I didn’t “discover” Fly.io so much as I got tired of duct-taping infrastructure together—again. Every personal project eventually turns into a mini platform: builds, deploys, databases, secrets, scaling, logs, rollbacks. After enough cycles, you stop asking “can I deploy this?” and start asking “why does deploying this feel like a punishment?” That’s the moment Fly.io clicked for me.

The real problem wasn’t hosting—it was friction⌗

Most hosting platforms make one thing easy (usually “getting a server running”) and then quietly add friction everywhere else. For personal projects, that friction compounds:

  • Deployment feels fragile. Small changes trigger big ceremony: build steps, env wiring, migrations, rollbacks.
  • The database becomes a separate world. You end up juggling connection strings, backups, failover, and version mismatches—on top of your app.
  • Scaling is either hand-wavy or expensive. You either guess and over-provision or get surprised when traffic grows.
  • Tooling gets in your way. The CLI should reduce cognitive load, not create a new set of commands you memorize once and regret forever.

Fly.io attacked this as a systems problem. Instead of pretending everything is “just a button,” it gives you primitives that map cleanly to how apps actually run: containers, networks, storage, databases, and a control plane that doesn’t require you to be an infrastructure engineer.

Edge deployment that doesn’t feel like a gimmick⌗

Fly’s core idea is simple: run your workloads closer to users. The practical payoff is lower latency and a deployment model that scales beyond a single region without you building a whole geographic strategy from scratch.

In my case, I was building a small web app with an API and a dashboard. Users weren’t concentrated in one place, and I didn’t want to over-engineer. On Fly, I could ship the same Docker image and rely on Fly’s global infrastructure to handle placement.

Here’s the concrete difference I noticed when comparing approaches:

  • On “traditional” setups, I’d deploy to one region and then spend time convincing myself that performance was “good enough.”
  • On Fly, performance became a default rather than a compromise. If a user is in a different geography, the app doesn’t have to wait for the slowest link in my architecture decisions.

The key is that Fly still uses Docker containers as the deployment unit. That matters because it keeps your workflow consistent: build once, run anywhere within the Fly model, and don’t rewrite how you ship just because the hosting provider is fashionable.

Deployments become boring (in the best way)⌗

Let’s talk about Docker—because for once, Docker isn’t the chore people fear. The workflow is straightforward:

  1. Build a Docker image for your app.
  2. Deploy it to Fly using the CLI.
  3. Configure environment variables, ports, and services.
  4. Let Fly run it where it makes sense.

The best part is the CLI experience. I’m not easily impressed by tools, but Fly’s CLI genuinely reduced my number of “what now?” moments. Commands are predictable. Feedback is helpful. You can tell what’s happening without squinting at logs like you’re decoding a firmware update.

A personal example: I had a small Rails app that I rebuilt and redeployed frequently while iterating. With Fly, the “inner loop” felt tight. I could deploy, check health, inspect logs, and iterate quickly without turning deployment into a recurring afternoon.

And because everything is containerized, you can keep local and remote behavior aligned. Your Dockerfile becomes the contract. That’s how you stop “works on my machine” from turning into “works in production, except when it doesn’t.”

Built-in Postgres, Redis, and LiteFS: less glue code⌗

Databases are where projects go to die—not because databases are hard, but because the integration surface area is huge. You start worrying about provisioning, networking, migrations, backups, and failover, and suddenly your app is no longer the main character.

Fly’s built-in services changed the tone. Instead of assembling a database stack from separate vendors and then babysitting connectivity, I could treat Postgres and Redis as first-class components of the app.

Even more interesting is LiteFS, which gives you SQLite replication via a mechanism designed to keep developer workflows sane. For projects that benefit from SQLite (common for personal tooling, small APIs, and “I want speed without operational drag” apps), LiteFS is a pragmatic bridge: you get the simplicity of SQLite while still aiming for multi-instance resilience.

What I did in practice:

  • Use Postgres for apps where the relational model is the point and concurrency matters.
  • Use SQLite for early-stage or lightweight services where operational simplicity wins.
  • Add LiteFS when I want SQLite’s ergonomics without pretending single-instance is a long-term strategy.

The point isn’t that one database is always best. It’s that Fly gives you options without forcing you to learn and manage an entire ecosystem just to run queries.

Scaling to zero feels possible, not theoretical⌗

One of the most underrated features for personal projects is the ability to scale to zero. When your app isn’t receiving traffic, you shouldn’t have to pay for idle resources—or keep processes running “just because.”

Fly’s Machines API makes scaling explicit and controllable. You can model your service instances instead of treating scaling as an opaque side effect of someone else’s defaults.

In other words: if you want your app to wake up on demand, you’re not stuck with the idea that it must always be on. For my projects, this translated into less worry about “did I just leave something running all weekend?” and more freedom to experiment.

This is also where Fly’s container-based approach shines again. When your workload is a machine definition, scaling becomes a workflow action, not a reconfiguration wizard.

The pricing reality: cheaper than you expect, generous where it matters⌗

Pricing is always a trade-off, but what I appreciated about Fly is that the free tier is usable for real personal projects—not just a demo environment you outgrow in a week.

On the paid side, Fly also felt like it was pricing for developers who don’t want to do cost math every time they deploy. While I won’t pretend every workload maps perfectly, the overall experience for small systems was what I cared about: I could run a meaningful setup without feeling like I was renting a production-grade machine just to host a hobby.

The best comparison isn’t a spreadsheet anyway—it’s your actual monthly behavior. When your stack is frictionless, you deploy more confidently, and the platform stops being a “cost center” you avoid and starts being a tool you rely on.

What switching actually changed in my workflow⌗

After moving personal projects to Fly.io, the biggest change wasn’t performance or cost first—it was confidence.

  • I shipped more often. Deployments were less intimidating.
  • I spent more time on the app. Fewer evenings went into infrastructure cleanup.
  • I stopped re-learning the basics. The same Docker-first model repeated across projects.
  • I had fewer “mystery failures.” Built-in services reduced configuration surface area.
  • Scaling felt like a knob, not a gamble. Machines made it concrete.

If you’re still on Heroku-style patterns (or you’re stuck in the “deployments are a ritual” phase), Fly offers a modern alternative: infrastructure primitives that feel approachable, not overwhelming.

And yes—Fly feels like what Heroku would look like if it were built today with better defaults and cleaner operational semantics. Not because it’s flashy, but because it respects the fact that developers want to build software, not babysit pipelines.

Conclusion: Fly.io is the platform I reach for first now⌗

I switched my personal projects to Fly.io because it solved the problems that always show up: Docker-based deployments, built-in Postgres/Redis, LiteFS for SQLite replication, and a CLI that doesn’t drain my patience. Add edge deployment and Machines-based scaling (including to zero), and you get a platform that fits the way solo developers and small teams actually work.

If you want your projects to feel lighter—technically and emotionally—Fly.io is one of the few choices that makes that promise real.