majiayu000 PaaS Compute Hosting Selection
Use this skill to pick the right managed compute platform for an application, agent, or bot when you don't want to operate Kubernetes, EC2 fleets, or your own infrastructure.
This is a selection skill, not an implementation guide. If you already know the platform and need help building on it, hand off to the platform's docs or to software-backend / agent-stack skills.
When To Use This Skill
- Picking where to deploy a Next.js / FastAPI / Node / Python app
- Choosing the compute substrate for an agent (Shape A triggered, Shape B bot, Shape C loop)
- Deciding between Vercel-style serverless, Fly.io-style always-on containers, and Cloudflare-style edge workers
- Evaluating "deploy-and-forget" platforms vs setting up your own infra
- Picking a host for a side-project, prototype, or production product without a platform team
When NOT To Use This Skill
| Need | Use Instead |
|---|---|
| Managed data/auth platforms (Supabase, Convex, Firebase) | ../software-baas-platforms/SKILL.md |
| Kubernetes, Terraform, GitOps, self-managed clusters | ../ops-devops-platform/SKILL.md |
| Cost optimization across existing infra | ../ops-cost-optimization/SKILL.md |
| Backend implementation defaults (REST, auth, queues, observability) | ../software-backend/SKILL.md |
| Always-on bot serving stack (FastAPI + Redis) | ../ai-bot-builder/references/production-deployment.md |
| Voice bot deployment (SIP, media, recording) | ../ai-voice-bots/references/production-deployment.md |
| Agent trigger integration | ../ai-coding-agents-tasks/references/webhook-and-queue-triggers.md |
| LLM inference cost and provider routing | ../ai-llm-inference/SKILL.md |
Quick Reference
| Question | Read | Outcome |
|---|---|---|
| Which PaaS fits this workload? | references/platform-comparison.md |
Strengths, weaknesses, pricing model, lock-in profile for 8 platforms |
| Where should I host an agent / bot / loop? | references/agent-hosting-matrix.md |
Per-shape (A/B/C) reference architectures with concrete platform stacks |
| Which facts must be rechecked? | data/sources.json |
Primary docs for volatile limits, pricing, and beta platform features |
Workflow
- Classify the workload by statefulness: stateless request, stateful session, always-on worker, durable workflow, or media/voice.
- Bound execution shape: max request duration, concurrency, WebSocket/SSE needs, queue semantics, cron cadence, and restart tolerance.
- Choose the placement driver: near users, near data, compliance boundary, cost floor, or team familiarity.
- Read
references/platform-comparison.mdfor 1-2 eligible platforms; reject ineligible options with a concrete reason. - For agents and bots, confirm the selection in
references/agent-hosting-matrix.md. - Before giving current limits, queues, regions, free-tier, or pricing claims, verify against
data/sources.jsonand primary docs. - Hand off implementation details to the chosen platform docs plus
software-backend,software-baas-platforms, or agent runtime skills.
Fact-Checking
Treat PaaS limits, pricing, regions, managed database maturity, and beta/preview features as volatile. Verify before relying on:
- Vercel function duration (GA vs "extended max duration" beta), Queues beta status, Workflow, AI Gateway, Sandbox, Agent, and plan-level billing.
- Cloudflare Workers CPU time, subrequest caps (raised Feb 2026 — verify current free vs. paid default and configurable ceiling), wall-clock duration, Queue consumer retries, Durable Objects, Workflows, Vectorize, and AI Gateway.
- Deno Deploy vs Deploy Classic migration state (Classic and subhosting v1 are scheduled to shut down; treat the date as imminent and re-verify against the migration guide, not this document), supported regions, queue support, and framework/runtime compatibility.
- Fly.io Managed Postgres vs legacy Fly Postgres, Machines autostart/autostop behavior, regions, and support boundaries.
- Railway, Render, Northflank, and Koyeb plan limits, free-tier behavior, sleep/scale-to-zero semantics, and production support.
- Amazon Bedrock AgentCore Runtime duration, Memory/Gateway/Identity semantics, Registry preview state, pricing dimensions, and region/service availability.
Three-Question Selection
Answer these three before reading deeper:
Is the workload stateless per request, stateful per session, or always-running?
- Stateless → Vercel, Cloudflare Workers, Netlify, Deno Deploy
- Stateful (sessions, WebSocket, long-held) → Fly.io, Railway, Render
- Always-running (loops, daemons, cron-driven) → Fly.io Machines, Railway Workers, Render Background Workers, Inngest
What's the max single-request duration?
- <30s CPU / short wall time → any platform
- 30s–300s CPU → Cloudflare Workers Paid if configured, Vercel Fluid, Fly.io, Railway, Render
- 300s–800s wall time → Vercel Pro/Enterprise Fluid Compute (800s is GA), Fly.io, Railway, Render
- 800s–1800s → Vercel Pro/Enterprise "extended max duration" (30 min, beta as of mid-2026, select Node/Python runtimes only, incompatible with Secure Compute/Static IPs) or a container platform
- 1800s+ or multi-hour → Fly.io Machines, container workers, Vercel Workflows (no fixed duration ceiling), or durable orchestration; not a single request-scoped function
- Multi-step durable → wrap in Inngest / Trigger.dev / Temporal / Vercel Workflows regardless of host
Does it need to be near users (edge) or near data (region)?
- Edge / low-latency first byte → Cloudflare Workers, Vercel Edge, Deno Deploy
- Region / co-located with database → Fly.io (multi-region capable), Railway, Render
Default Picks
| Workload | Default | Why |
|---|---|---|
| Next.js product site / web app | Vercel | First-party support; AI SDK and AI Gateway baked in |
| Always-on Python/Node bot | Fly.io | Long-held connections, WebSocket, persistent state, no cold-start surprises |
| Triggered agent (webhook → run) | Vercel + Inngest or Cloudflare Workers + Queues | Idempotency + durable steps native to both |
| Autonomous loop (Shape C) | Inngest on Vercel or Fly.io Machines | Durable iteration + budget caps |
| Voice bot control plane | Fly.io (paired with LiveKit Cloud for media) | Persistent agent worker per call |
| Multi-tenant SaaS backend | Fly.io or Railway | Stateful, scales horizontally, owns Postgres |
| Edge AI (low-latency LLM proxy) | Cloudflare Workers + AI Gateway | Low-latency global request handling; verify CPU and subrequest limits |
| AWS enterprise agent | AgentCore Runtime + Memory + Gateway | Long sessions, framework choice, managed identity/tooling; verify pricing and regional support |
| Background workers and cron | Render Background Workers, Railway Workers, Fly.io Machines | Cheap, simple, always-on |
Graduating From PaaS To Raw Cloud
PaaS is the right default until one of these becomes true; treat each as a concrete trigger, not a vague "we're big now" feeling:
| Signal | Why PaaS stops fitting |
|---|---|
| Sustained monthly PaaS spend materially exceeds one platform-team engineer's fully-loaded cost | The math flips toward owning the infra; verify current spend against current salary bands rather than assuming a fixed dollar threshold |
| Compliance mandates a named cloud, region, or physical control (data residency, FedRAMP, sector-specific hosting rules) | No PaaS vendor can contractually satisfy a requirement it wasn't built for |
| Workload needs GPUs, custom kernels, specialized network hardware, or sub-millisecond determinism | PaaS compute is general-purpose; specialized silicon or latency floors need raw cloud or bare metal |
| Multi-region active-active with strong consistency guarantees | Most PaaS databases and compute are single-region-primary or eventually consistent by default |
| Platform-specific limits (duration, subrequests, memory, egress) are hit routinely, not as an edge case | Repeated limit-hugging is a sign the workload has outgrown the platform's target shape, not a config problem |
Migrate incrementally: keep the stateless front end on PaaS, move only the constrained workload (the GPU job, the compliance-scoped service) to raw cloud, and re-evaluate the rest only if the same pressure recurs elsewhere.
Deploy-and-Forget Scope
| Removed by the platform | Still your responsibility |
|---|---|
| OS patching and kernel updates | Application correctness |
| Load balancer config | Schema migrations |
| TLS certificate management | Secret rotation |
| Autoscaling rules (sensible defaults) | Cost monitoring |
| Log aggregation | Provider failover (LLM / external APIs) |
| Health-check wiring | Domain-specific compliance (recording, audit logs) |
| Zero-downtime deploys | Backups and disaster recovery |
| Build pipeline (Dockerfile or buildpacks) | Billing alerts at the platform level |
ASCII Flow
workload + scale + statefulness
│
▼
┌──────────────────────────────────┐
│ Three-Question Selection │
│ (stateful? duration? edge?) │
└────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────┐
│ references/platform-comparison │
│ → pick 1–2 finalists │
└────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────┐
│ references/agent-hosting-matrix │
│ → confirm against shape A/B/C │
└────────────┬─────────────────────┘
│
▼
┌──────────────────────────────────┐
│ Implementation handoff │
│ → platform docs │
│ → software-backend defaults │
│ → agent-runtime guides │
└──────────────────────────────────┘
Lock-in Discipline
| Rule | Why |
|---|---|
| Use Dockerfile-based deploys | Buildpacks and platform-specific config tie you to the host |
| Keep data in external services (Supabase, Neon, Upstash, Cloudflare D1) | Data portability is the hardest part of a platform migration |
| Use portable secret stores (Doppler, Infisical, AWS Secrets Manager) | Platform-native env vars do not survive a migration |
| Avoid host-proprietary primitives unless they are load-bearing | Vercel Edge Config, Cloudflare Durable Objects — choose deliberately |
Pin runtime versions in package.json / Dockerfile |
A platform's default Node/Python upgrade can break silently |
Cost Discipline
Default cost shape per platform:
| Platform | Free tier | Hobby paid tier | Production scaling |
|---|---|---|---|
| Vercel | Free for non-commercial / prototype use | Pro is the usual production baseline | Function duration, bandwidth, seats, storage, AI products |
| Fly.io | Trial / usage credit varies | Pay-as-you-go | Machine size/count, bandwidth, volumes, Managed Postgres |
| Railway | Free/trial credits vary | Hobby for personal, Pro for teams | Resource usage, replicas, storage, egress |
| Render | Free web services may sleep | Paid instances for always-on | Instance count, databases, workers, bandwidth |
| Cloudflare Workers | Free request tier | Workers Paid for production limits | Requests, CPU, duration, storage products |
| Deno Deploy | Verify current plan | Usage-based / platform-specific | Region, build, and runtime limits |
| Northflank | Trial / free credits vary | Team/container plans | Container hours, add-ons, environments |
| Koyeb | Free instance is preview/hobby only | Instance-hour pricing | Instance type/count, bandwidth, regions |
Always set spend alerts at the billing platform level. The single most common surprise in PaaS bills is autoscale-driven egress on a misconfigured background job.
Common Anti-Patterns
- Treating Vercel functions as always-on workers (they're stateless; use Fly.io or Render)
- Putting Postgres on the same Fly.io machine as the app (split for durability)
- Hosting voice agents on Vercel (no SIP/media; use LiveKit Cloud + Fly.io)
- Running a 6-hour autonomous loop in a single function (use durable orchestrator)
- Using a platform's in-cluster database without a migration plan
- Forgetting that "free tier" CPU is throttled — production workloads need the paid plan
- Deploying a multi-tenant bot to edge functions without per-tenant rate limits
- Holding a WebSocket on a Vercel function (it terminates; use Fly.io / Cloudflare Durable Objects)
- Treating Cloudflare's default 30s CPU limit as a wall-clock request limit; HTTP Workers can run longer while connected, but CPU, queue, cron, and Durable Object alarm limits still matter
- Using Vercel Queues as a mature queue without checking beta status, poison-message handling, and dead-letter requirements
- Assuming Deno Deploy Classic behavior still applies; Classic and subhosting v1 are on a hard shutdown date in July 2026 (imminent — treat any project still on Classic as an urgent migration, not a someday task), projects do not migrate automatically, and the new Deploy has different regions, APIs, and queue support
- Confusing legacy Fly Postgres guidance with Fly Managed Postgres; evaluate support, backups, HA, regions, and missing managed features explicitly
- Treating Koyeb's free instance as production-ready; it is explicitly scoped to testing/hobby use (single region, no worker services, no volumes, no custom scaling, scales to zero on idle) — not a beta feature, just a non-production tier
- Ignoring egress and subrequest fan-out costs: a background job that fans out to many external calls or streams large payloads through a serverless function is the most common runaway PaaS bill, independent of which platform is chosen
- Picking a platform by brand familiarity instead of the three-question selection; "we already use Vercel" is not a reason to force a stateful WebSocket workload onto stateless functions
Navigation
references/platform-comparison.md— Vercel, Fly.io, Railway, Render, Cloudflare Workers + Durable Objects, Deno Deploy, Northflank, Koyebreferences/agent-hosting-matrix.md— Shape A/B/C → recommended PaaS and AWS stacks with reference architecturesreferences/aws-bedrock-agentcore.md— AWS-native agent runtime, memory, gateway, identity, observability, evaluation, policy, and registry choicesdata/sources.json— primary documentation sources for volatile platform facts../software-baas-platforms/SKILL.md— managed data/auth platforms (sibling skill)../ops-devops-platform/SKILL.md— for K8s/self-managed substrate decisions../ai-coding-agents-tasks/SKILL.md— agent task and trigger model../ai-agents/references/24-7-operating-model.md— SLOs and on-call once deployed../ai-agents/references/autonomous-loop-patterns.md— Shape C loop drivers../ai-bot-builder/references/production-deployment.md— bot serving stack patterns../ai-voice-bots/references/production-deployment.md— voice deployment (LiveKit-paired)
Related Skills
../software-baas-platforms/SKILL.md— data layer../software-backend/SKILL.md— backend defaults../ops-devops-platform/SKILL.md— when PaaS isn't enough../ops-cost-optimization/SKILL.md— cost governance../ai-llm-inference/SKILL.md— LLM provider routing../software-workflow-automation/SKILL.md— Inngest/Temporal durable substrate
Learnings Loop
Before applying this skill on a non-trivial task, read learnings.consolidated.md in this directory (and learnings.md if present).
After applying it, if you encountered a pattern worth remembering, a mistake worth preventing, or a domain fact that surprised you, append one dated bullet to learnings.md via agents-skills-feedback-loop/scripts/append_learning.py. Do not modify SKILL.md itself.