The best serverless function platforms in 2026

"Serverless function" has drifted into meaning almost anything — a Lambda, a Worker, an edge middleware file, a container that scales to zero. The common thread is narrower than the marketing: you hand a platform a piece of code, it runs that code on demand in response to an event or HTTP request, and you don't manage the machine underneath. Everything else — how it's isolated, how fast it starts, what it costs, whether it can run a nightly job — is where the platforms actually diverge, and where a roundup that just lists eight names and a checkmark table stops being useful.

This one goes deeper on that divergence. I build PandaStack, whose serverless functions are one of the seven platforms covered below — I'll flag my bias where it's relevant and try to describe the others the way I'd want a competitor to describe mine: qualitatively, fairly, and without inventing numbers I haven't measured myself. For every platform except PandaStack, treat the specifics here as a starting point and verify current limits, regions, and pricing against that vendor's own docs before you commit — this space moves fast and free tiers get renegotiated constantly.

What a serverless function platform actually is

Strip away the branding and there are three moving parts: a deploy step that takes your code and produces something runnable, a trigger (HTTP request, queue message, cron schedule, storage event), and an execution environment that starts on demand, runs your handler, and goes away. What differs between vendors is almost entirely in that last part — what "starts on demand" costs you in latency, and what "goes away" means for isolation between one invocation and the next, especially if you're running code you don't fully trust (user scripts, AI-agent-generated code, third-party plugins).

What to actually evaluate

Six things determine whether a platform fits, in roughly the order they bite you.

Cold start and isolation model

These two are really one axis. A V8 isolate starts in single-digit milliseconds because it shares a process and an OS kernel with every other tenant's isolate — extraordinary for stateless HTTP handlers, harder to justify if you need a real filesystem, arbitrary native dependencies, or a hard security boundary. A container gives you a fuller environment but usually a slower cold start and a shared-kernel isolation model — one kernel vulnerability away from cross-tenant exposure. A microVM (Firecracker and similar) gives each execution its own kernel with a hardware-enforced boundary, historically at the cost of a slower boot — which is exactly the problem snapshot-restore techniques exist to solve. Know which axis you're actually optimizing for before you pick a vendor by cold-start number alone.

Language and runtime support

V8-isolate platforms are strongest on JavaScript/TypeScript and WASM; anything that needs a native binary, a C extension, or a runtime the isolate doesn't ship is a fight. Container- and VM-based platforms tend to run whatever you can put in a container or a VM image, at the cost of you owning more of the build.

Execution duration limits

Every platform below caps how long a single invocation can run, and the cap tells you what class of workload it's built for. Sub-minute limits mean request/response and light background work. Multi-minute to unbounded limits mean batch jobs, video/ML processing, or anything that legitimately takes a while. Get this wrong and you'll be stitching together a queue-and-checkpoint pattern to work around a limit that a different platform simply doesn't have.

Pricing model

Roughly three shapes: pay per invocation plus GB-seconds of memory×duration (the classic Lambda-style model), pay per request with duration priced separately or not at all (common on edge/isolate platforms), and pay for compute time regardless of framing (containers and VMs, sometimes billed to the second, sometimes with a minimum). None is inherently cheaper — it depends on whether your workload is bursty-and-short or steady-and-long. Model your actual invocation pattern against each pricing shape rather than trusting a headline "free tier" number.

Cron and scheduling support

Not every function platform treats scheduled execution as first-class. Some require you to wire up a separate scheduler service and point it at an HTTP-invoke endpoint; others have cron as a native resource type with its own run history. If you have nightly jobs, usage rollups, or report generation, check whether scheduling is a platform primitive or a bolt-on you're expected to build.

Observability

Logs, per-invocation metrics, and run history are what turn "the function is slow" into an actual root cause. Check specifically whether you get per-run logs (not just aggregated metrics), whether cold starts are visible as a distinct metric, and whether a failed scheduled run is easy to find without grepping a shared log stream.

The platforms

Seven platforms, roughly in the order most teams encounter them.

AWS Lambda

The default. Lambda's underlying execution has run on Firecracker microVMs since 2018 — one of the reasons it can offer a real security boundary between tenants while still being a mature, broadly-adopted platform. Strengths: the deepest event-source integration in the industry (S3, DynamoDB Streams, SQS, EventBridge, API Gateway, and dozens more), the widest language support of any FaaS platform via custom runtimes, and an ecosystem of tooling (SAM, Serverless Framework, CDK) that's had a decade to mature. Tradeoffs: cold starts on less-common runtimes and larger deployment packages can be noticeable, the pricing model has enough dimensions (requests, duration, memory, provisioned concurrency, data transfer) that a bill surprise is a rite of passage, and the IAM/VPC configuration surface is real work if you haven't done it before. Scheduling is native via EventBridge Scheduler rules. If your workload is already deep in AWS, Lambda is usually the path of least resistance rather than a decision you need to relitigate.

Cloudflare Workers

Runs your code in V8 isolates distributed across Cloudflare's edge network rather than in per-tenant containers or VMs — the isolate model is what makes its cold starts consistently fast, since there's no OS or container boot in the critical path, only a JS context. Strengths: genuinely global by default, very fast for stateless request/response work, and a pricing model built around request counts that's easy to reason about. Tradeoffs: the V8 isolate sandbox means no arbitrary native binaries and a constrained standard library compared to Node — porting an existing Node service usually means adaptation, not a lift-and-shift. CPU time per request is metered and capped, which is the right constraint for edge middleware and the wrong one for anything compute-heavy. Cron Triggers cover scheduling natively. Pick Workers when your function is genuinely request-shaped and you want it close to users everywhere; look elsewhere for long-running or native-dependency-heavy work.

Vercel Functions

Two flavors worth distinguishing: Edge Functions run on a V8-isolate runtime similar in spirit to Workers, while standard Serverless Functions run on managed container/VM infrastructure with broader Node.js and Python support. Strengths: the deploy experience is excellent if your frontend is already on Vercel — functions are just files in your repo, versioned and previewed alongside the app, with per-deploy preview URLs that make testing changes painless. Tradeoffs: functions are tightly coupled to the Vercel deploy model, so using them independently of a Vercel-hosted frontend is unusual, and the two runtime flavors have meaningfully different capabilities and limits that are easy to conflate when reading the docs quickly. Scheduling exists via Cron Jobs as a platform feature. Best fit is a team already building on Vercel who wants backend logic co-located with the frontend rather than a standalone function platform.

Google Cloud Functions / Cloud Run functions

Google has been consolidating its function offering into Cloud Run functions, which runs on the same gVisor-sandboxed container infrastructure as Cloud Run generally — a user-space kernel emulation layer that intercepts syscalls rather than a hardware VM boundary, a different isolation tradeoff than Lambda's or Fly's microVMs. Strengths: solid language support (Node, Python, Go, Java, .NET, Ruby, PHP), tight integration with the rest of GCP (Pub/Sub, Firestore, Eventarc), and the Cloud Run lineage means you can graduate a function into a full container service without switching platforms if it outgrows the FaaS model. Tradeoffs: the product has been renamed and re-platformed enough times in recent years that docs and blog posts disagree on which product to use for a new project — read the current landing page carefully rather than an older tutorial. Cloud Scheduler handles cron, as a separate but well-integrated service. A reasonable default if you're already on GCP and want an event-driven function that can grow into a longer-running service later.

Modal

Python-first, and built specifically for compute-heavy and GPU workloads rather than lightweight request handlers — you define infrastructure in Python decorators, and Modal provisions containers (with GPU access when requested) around your function. Strengths: genuinely good developer experience for ML/data workloads specifically — GPU access, large dependency images, and long-running jobs are first-class in a way general-purpose FaaS platforms don't attempt. Tradeoffs: it's a Python-centric platform, so it's not the tool for a polyglot function fleet, and it's priced and positioned for compute-intensive work rather than as a cheap way to run a small HTTP handler. Scheduling is supported natively via a `@modal.schedule` style periodic decorator. Strong pick specifically for ML inference, batch data jobs, or anything GPU-bound; not really competing in the same lane as Lambda or Workers for general request handling.

Fly.io

Fly Machines run on Firecracker microVMs, similar in isolation model to Lambda under the hood and to PandaStack below — but Fly's product surface is oriented around always-on or scale-to-zero application instances more than a request-triggered function abstraction, and functions-specific tooling (scheduled invocation, per-run metrics) is thinner than on purpose-built FaaS platforms. Strengths: real VM isolation, fast Machine start times, and the flexibility to run genuinely anything since a Machine is close to a general-purpose VM rather than a constrained function runtime. Tradeoffs: you're closer to managing infrastructure than on a pure FaaS platform — there's no built-in event-source integration comparable to Lambda's, and scheduling typically means running your own cron process inside a Machine or wiring an external scheduler. Best fit if you want microVM isolation with full control over the runtime and don't mind assembling the trigger/schedule layer yourself.

PandaStack

This is mine, so read it as the disclosed-bias entry. PandaStack's serverless functions upload a code bundle to storage, then run each invocation inside a fresh Firecracker microVM sandbox — the same snapshot-restore boot path the rest of the platform uses for sandboxes, so a function execution gets a real per-invocation kernel boundary rather than a shared container or isolate. Concretely: `POST /v1/functions` creates a function, `POST /v1/functions/{id}/deploy` uploads the code bundle, `POST /v1/functions/{id}/invoke` and the HTTP-invoke path trigger a run, and `GET /v1/functions/{id}/metrics` / `.../runs` give per-invocation history. Cron schedules are a first-class resource (`POST /v1/schedules`, backed by `robfig/cron`), not a bolt-on — you get scheduled runs with their own run history and a manual-trigger endpoint for testing a schedule without waiting for it to fire.

Where that's genuinely useful: you need real isolation between invocations — untrusted code, per-tenant execution, or a security requirement you have to defend in a review — and you'd rather have that boundary by construction than by configuration. The rest of the platform's numbers apply here too: a sandbox create via snapshot-restore lands around 179ms p50 / 203ms p99, with the restore step itself around 49ms of that, and only the very first boot of a given template pays a roughly 3-second cold-boot cost before a snapshot exists to restore from.

Where it's honestly not the best fit: if you want the deepest event-source ecosystem, Lambda has a decade's head start. If your workload is genuinely edge-shaped stateless JS, a V8-isolate platform will out-cold-start a microVM on raw milliseconds for that specific case. If you're doing GPU-bound ML work, Modal is built for exactly that in a way a general-purpose function platform isn't trying to be. PandaStack's case is the isolation boundary and the fact that functions, cron, sandboxes, apps, and managed Postgres share one platform and one billing relationship — not being uniformly faster or cheaper than every specialist on every axis.

# create a function, deploy a code bundle, and put it on a cron schedule
pandastack functions create my-report-job --runtime python3.12

# zip your handler + deps, then deploy the bundle
zip -r bundle.zip handler.py requirements.txt
pandastack functions deploy my-report-job --bundle bundle.zip

# invoke it once to sanity-check before scheduling
pandastack functions invoke my-report-job

# run it nightly at 02:00 UTC — cron is a first-class resource, not a bolt-on
pandastack schedules create \
  --function my-report-job \
  --cron "0 2 * * *" \
  --name nightly-report

# tail recent runs (each one executed in its own Firecracker microVM)
pandastack functions runs my-report-job --follow

Side-by-side

A quick-reference summary. Verify current specifics — limits, regions, pricing — against each vendor's own docs before deciding; this list is qualitative on purpose.

• AWS Lambda — isolation: Firecracker microVM per execution environment; best for: teams already on AWS who want the deepest event-source integration and widest language support.
• Cloudflare Workers — isolation: V8 isolate, shared process; best for: stateless, latency-sensitive request/response logic served close to users globally.
• Vercel Functions — isolation: V8 isolate (Edge) or managed container/VM (standard); best for: backend logic co-located with a Vercel-hosted frontend.
• Google Cloud Functions / Cloud Run functions — isolation: gVisor-sandboxed container; best for: GCP-native event-driven functions that may grow into a full Cloud Run service.
• Modal — isolation: managed container, optional GPU; best for: Python ML/data workloads and GPU-bound batch jobs.
• Fly.io — isolation: Firecracker microVM (Fly Machines); best for: teams wanting VM-level control and isolation who are comfortable assembling their own trigger/schedule layer.
• PandaStack — isolation: Firecracker microVM per invocation via snapshot-restore; best for: workloads that need a real per-execution security boundary plus native cron, alongside sandboxes, apps, and managed Postgres on one platform.

How to choose

Start from the isolation requirement, not the pricing page. If you're running code you don't fully control — user-submitted scripts, AI-agent-generated code, third-party plugins — the shared-kernel platforms (isolates and standard containers) put more weight on the platform's own patch cadence than a hardware-backed VM boundary does; decide how much that matters for your threat model before anything else.

From there, match the workload shape to the platform's actual strength: genuinely stateless and latency-critical points at an edge-isolate platform; deep integration with an existing cloud's other services points at that cloud's native function product; GPU or heavy ML batch work points at a workload-specific platform like Modal rather than a general-purpose one; and a need for real per-invocation isolation plus native cron, sitting next to sandboxes or a hosted app on the same platform, is the case PandaStack is built for.

Then run the same checklist you'd run for any infra decision: deploy your actual handler, not a hello-world — dependency size and native extensions are where surprises live. Trigger a scheduled run and confirm you can find its logs without archaeology. Price your real invocation pattern, not the free-tier headline. And check what happens on a cold path after genuine idle time, since that's the number that shows up in production and never in a demo.