Decision guide

Percher or Fly.io?

Fly.io is a global infrastructure platform: Firecracker microVMs you can place in 30-plus regions, anycast routing, per-region volumes, and a Machines API that treats every box like a primitive. It rewards power users who want low-level control and global distribution. Both Fly and Percher ship MCP servers today (flyctl bundles an `mcp` subcommand); the design distance is bigger than that one feature, though. Percher is the opposite end of the design space from Fly — one region in Germany, one container per app, no machine APIs to wire up, and MCP as the primary deploy surface (42 tools and a typed `recovery.nextAction` contract). Pick Fly if you need geo-distribution or raw infrastructure primitives; pick Percher if you want zero-config hosting your assistant can drive end-to-end through recovery loops instead of just one-shot deploys.

Who Percher is for

Percher is built for personal apps — projects you build for yourself or your close circle. It is notpositioned as production-grade or enterprise hosting today: there is no uptime SLA, no formal compliance attestation, and a single region in Germany. If you're shipping a monetised SaaS, an app for paying customers, or anything that needs an SLA, Fly.io or a higher-tier provider is the safer choice. Percher may grow into that space; it is not there now.

At a glance

When Percher is the better choice

• You want the assistant doing more than `publish` — full operational tools (logs, env, rollback, doctor, backups, domain add) and a typed `recovery.nextAction` that turns a failed deploy into the next fix automatically.
• Your project is small and single-region, and Fly's pay-as-you-go pricing makes the monthly bill harder to predict than a flat-rate plan.
• You want an opt-in managed PocketBase per app (`[data] mode = "pocketbase"`) for SQLite + auth + file storage instead of standing up Fly Postgres as a separate billed service.
• Your project must stay in the EU for data-residency reasons. Percher is single-region in Germany.
• You want a zero-config deploy that 'just works' for a Node, Bun, Python, or static app without writing a `fly.toml`.

When Percher is the wrong choice (and Fly.io fits better)

• You need real multi-region distribution — the same app running in São Paulo, Tokyo, and Frankfurt with local latency for each. That's Fly's whole pitch and Percher cannot match it.
• You want low-level infrastructure primitives: WireGuard private networking, IPv6 anycast, per-region volumes, the Machines API for dynamic provisioning. Percher abstracts those away.
• Your workload is bursty and benefits from scale-to-zero with fast Firecracker cold starts. Percher containers are long-running by design.
• You need fine-grained control over instance types, regions, and per-region replica counts. Fly exposes those; Percher hides them.
• You're already invested in the Fly ecosystem — Fly Postgres, Tigris object storage, Upstash add-ons — and don't want to migrate them.

Migrating from Fly.io

Fly apps are Docker-first, so the migration is mechanical in the common case: take your existing `Dockerfile`, run `bunx percher init` in the project root (it'll detect the Dockerfile and write `runtime = "docker"` in `percher.toml`), and `bunx percher publish` builds and deploys the same image Fly was building. Env vars don't move automatically — copy them from `fly secrets list` and re-set with `bunx percher env set`. Domains move with a one-time DNS update once the app is live.

What doesn't translate: anything that depends on Fly being globally distributed. If your app uses `fly-replay`, region-aware routing, or per-region volumes, you'll need to decide whether single-region in Germany is acceptable (often: yes, for European audiences) or whether you need to keep Fly. WireGuard-based private networking between Fly services becomes plain HTTPS-over-Percher-proxy on Percher. Fly Postgres has no direct equivalent — point `DATABASE_URL` at any external Postgres (Neon, Supabase, your own) and Percher's outbound proxy handles the connection.

# In your project root (with your existing Dockerfile):
fly secrets list             # copy each secret
bunx percher init            # generates percher.toml (runtime=docker)
bunx percher env set DATABASE_URL=...  # for each Fly secret
bunx percher publish         # build + deploy
bunx percher domains add yourdomain.com

FAQ

Try Percher in under a minute

Free plan, no credit card. Bring any Node, Bun, Python, or Docker app.

Bringing an existing app? See recommended setup or the migration walkthrough above.