Fly.io alternative for serverless functions without VM management
Fly.io gives you fine-grained control over distributed VM placement—ideal for stateful apps and globally distributed services. Inquir is optimized for event-driven serverless: HTTP functions, cron jobs, webhooks, and background pipelines that scale to zero without machine configuration or region management.
Last updated: 2026-04-20
Answer first
Direct answer
Fly.io alternative for serverless functions without VM management. Inquir functions are invoked on demand with no machine to configure. Write a handler function, declare dependencies in package.json or requirements.txt, and get a gateway endpoint. No Dockerfile, no fly.toml, no region selection required for the common case.
When it fits
- Event-driven HTTP APIs, webhooks, cron jobs, and background pipelines
- Teams that want serverless billing (pay per invocation) rather than per-machine billing
Tradeoffs
- Fly does not have a native Lambda-style function primitive. Every handler needs a Dockerfile, a fly.toml, and a process running inside a machine. Scale-to-zero requires manual stop/start orchestration via the Machines API.
- Without a managed cron trigger, scheduling on Fly means running a dedicated process (a cron container) that watches a schedule—a persistent VM billing even when no jobs are running.
Workload and what breaks
When Fly.io machine management is more than you need
- Deploying a simple HTTP function or cron job requires a Dockerfile and Fly machine configuration
- Fly Machines do not scale to zero by default—idle machines still consume resources
- Background jobs need a separate Fly app acting as a worker, with its own flyctl deploy lifecycle
- Cron requires either an always-on process watching a schedule or Fly`s Machines API with manual orchestration
Fly.io is powerful for distributed stateful applications and globally replicated services. For event-driven workloads—API handlers, cron jobs, webhook processors—the machine model adds configuration overhead that serverless functions eliminate.
Trade-offs
Why serverless functions on Fly.io require extra configuration
Fly does not have a native Lambda-style function primitive. Every handler needs a Dockerfile, a fly.toml, and a process running inside a machine. Scale-to-zero requires manual stop/start orchestration via the Machines API.
Without a managed cron trigger, scheduling on Fly means running a dedicated process (a cron container) that watches a schedule—a persistent VM billing even when no jobs are running.
How Inquir helps
Lambda-style functions without machine management
Inquir functions are invoked on demand with no machine to configure. Write a handler function, declare dependencies in package.json or requirements.txt, and get a gateway endpoint. No Dockerfile, no fly.toml, no region selection required for the common case.
Cron triggers, pipeline steps, and gateway routing are first-class primitives—not workarounds built on top of machine orchestration.
What you get
Inquir vs Fly.io
Deploy model
Inquir: deploy a handler function with a dependency manifest. Fly.io: deploy a Dockerfile with a fly.toml and machine configuration.
Cron
Inquir: first-class cron pipeline triggers with run history. Fly.io: requires a persistent process or manual Machines API orchestration.
Scaling
Inquir: scales to zero between invocations by default. Fly.io: machines require explicit stop configuration for scale-to-zero.
Background jobs
Inquir: pipeline steps triggered from HTTP handlers. Fly.io: requires a separate Fly app acting as a worker.
What to do next
When to use Inquir alongside or instead of Fly.io
Keep Fly.io for stateful distributed apps
WebSocket servers, globally replicated databases, and latency-sensitive stateful services are well-suited for Fly Machines.
Move event-driven functions to Inquir
HTTP API handlers, cron jobs, webhooks, and background pipelines scale better and cost less as serverless functions.
Connect via shared secrets
Store database URLs and API keys as Inquir workspace secrets. Fly apps and Inquir functions can share the same backing services.
Code example
Fly.io scheduled process → Inquir cron pipeline
Fly runs a persistent container watching a cron schedule. Inquir replaces it with a pipeline cron trigger—no always-on process.
export async function handler(event) { // Fired by a cronTrigger node in a scheduled graph pipeline const since = process.env.SYNC_CURSOR ?? new Date(Date.now() - 86_400_000).toISOString(); const records = await source.fetchUpdatedSince(since); await destination.upsertBatch(records); return { synced: records.length }; }
When it fits
Choose Inquir over Fly.io for
When this works
- Event-driven HTTP APIs, webhooks, cron jobs, and background pipelines
- Teams that want serverless billing (pay per invocation) rather than per-machine billing
When to skip it
- Globally distributed stateful apps, WebSocket servers, and latency-critical services that need machine placement control—Fly.io is purpose-built for that
FAQ
FAQ
Can I use Fly.io for my database and Inquir for functions?
Yes—Fly Postgres is a popular choice for managed Postgres. Inquir functions connect via the database URL stored as a workspace secret.
Does Inquir support custom regions?
See the docs for current region availability. For most backend API and cron workloads, a single region close to your database is the right starting point.