Railway alternative for serverless functions and background jobs
Railway is excellent for always-on services—persistent processes, databases, and long-running workers. Inquir is optimized for event-driven workloads: HTTP functions that scale to zero, cron jobs with run history, and background pipelines that run outside HTTP timeout windows—without a Dockerfile or persistent process to manage.
Last updated: 2026-04-20
Answer first
Direct answer
Railway alternative for serverless functions and background jobs. Inquir functions are invoked on demand—HTTP requests, cron triggers, webhook events, or pipeline steps. No persistent process means no idle billing and no process management.
When it fits
- HTTP APIs, webhooks, and cron jobs that benefit from scale-to-zero billing
- Background job patterns where a persistent worker process is more than needed
Tradeoffs
- Railway does not have a native serverless/Lambda function primitive. Deploying a function-style handler on Railway means wrapping it in a web server (Express, Fastify) and running it as an always-on service—which defeats the scale-to-zero billing advantage.
- Background jobs on Railway require a second service acting as a worker, a queue (Redis, Postgres), and coordination between the web service and the worker—separate deploys, separate logs, separate scaling.
Workload and what breaks
When always-on Railway services are more than you need
- A simple cron job or webhook handler does not need a persistent process running 24/7
- Railway bills for idle time on always-on services—serverless scales to zero between requests
- Cron jobs on Railway require a Dockerfile and a persistent process watching a schedule
- Background workers need a separate Railway service with its own deploy lifecycle
Railway excels at hosting persistent services. For event-driven patterns—HTTP endpoints that get traffic in bursts, cron jobs that run once per hour, webhooks that fire irregularly—a persistent process is more infrastructure than the workload needs.
Trade-offs
Why serverless functions on Railway require workarounds
Railway does not have a native serverless/Lambda function primitive. Deploying a function-style handler on Railway means wrapping it in a web server (Express, Fastify) and running it as an always-on service—which defeats the scale-to-zero billing advantage.
Background jobs on Railway require a second service acting as a worker, a queue (Redis, Postgres), and coordination between the web service and the worker—separate deploys, separate logs, separate scaling.
How Inquir helps
Event-driven functions without persistent processes
Inquir functions are invoked on demand—HTTP requests, cron triggers, webhook events, or pipeline steps. No persistent process means no idle billing and no process management.
Cron jobs are first-class triggers with validated expressions and run history. Background jobs are pipeline steps triggered from HTTP handlers—no separate worker service, no queue to provision.
What you get
Inquir vs Railway
Billing model
Inquir: per-invocation (scales to zero). Railway: per service-hour (always-on).
Cron jobs
Inquir: first-class cron triggers with history and retries. Railway: requires a persistent process watching a schedule inside a service.
Background jobs
Inquir: pipeline steps triggered from HTTP handlers, runs outside request window. Railway: requires a separate worker service + queue.
Deploy model
Inquir: deploy a handler function with package.json/requirements.txt/go.mod. Railway: deploy a Dockerfile or a buildpack-detected service.
What to do next
When to use Inquir alongside or instead of Railway
Keep Railway for persistent services
Databases, message queues, and stateful services that need to stay running are a good fit for Railway.
Move event-driven workloads to Inquir
HTTP API endpoints, cron jobs, webhook processors, and background pipelines are better as serverless functions that scale to zero.
Share secrets across platforms
Use Inquir workspace secrets for function credentials. Railway environment variables for service config. Keep them separate and well-named.
Code example
Railway worker → Inquir background pipeline
A Railway worker service polls a queue. The Inquir equivalent: an HTTP handler returns 202 and triggers a pipeline step—no worker service to deploy or scale.
export async function handler(event) { const { jobType, payload } = JSON.parse(event.body || '{}'); if (!jobType) return { statusCode: 400, body: JSON.stringify({ error: 'jobType required' }) }; // Trigger pipeline step — replaces adding to Railway worker queue const { instanceId: jobId } = await global.durable.startNew(jobType, undefined, payload); return { statusCode: 202, body: JSON.stringify({ jobId }) }; }
When it fits
Choose Inquir over Railway for
When this works
- HTTP APIs, webhooks, and cron jobs that benefit from scale-to-zero billing
- Background job patterns where a persistent worker process is more than needed
When to skip it
- Persistent services (web apps, databases, long-running workers)—Railway is the right fit for those
FAQ
FAQ
Can I use Railway for databases and Inquir for functions?
Yes—this is a common pattern. Railway hosts your Postgres or Redis; Inquir functions connect via the database URL stored as a workspace secret.
Does Inquir have a free tier?
See the pricing page for current plans. Serverless billing means low-traffic workloads pay very little compared to an always-on Railway service.