Choose a serverless computing platform by matching its runtime, execution model, duration limits, concurrency, and operational requirements to your workload. Then estimate usage. Vercel Functions is our serverless compute offering. This guide compares seven platforms for APIs, Python services, and artificial intelligence (AI) workloads by their workload fit and deployment requirements.
A webhook handler and a long-running inference request can differ in duration and resource needs. Use these five criteria to build your shortlist:
Cold-start behavior: How long does a new instance take to serve its first request, and what does keeping instances warm cost?
Execution limits: How long can one invocation run, and is that enough for your background jobs or AI inference requests?
Python support: Which Python versions run at request time, and can you deploy Asynchronous Server Gateway Interface (ASGI) and Web Server Gateway Interface (WSGI) frameworks without adapter code?
Billing model: Does the platform bill gigabyte (GB)-seconds, active central processing unit (CPU) time, or instance time? How does it bill input/output (I/O) waits? Can concurrent requests share instance resources?
Developer experience: How much setup does deployment require? Are scheduling and preview environments built in?
Compare each platform's packaging, invocation model, Python support, and deployment model with what your workload needs. The table shows which workloads each platform supports:
Lambda and Azure bill per GB-second, Cloud Run per vCPU-second, and Vercel splits CPU from memory, which is why the same endpoint costs differently on each.
Copy link to heading1. Vercel Functions
Vercel Functions is Vercel's serverless compute layer. With Fluid compute, Node.js and Python instances can handle several requests at once. Vercel bills Active CPU, Provisioned Memory, and Invocations. A request that computes for 100 ms and waits 400 ms on a database bills 100 ms of CPU. Memory remains billable throughout the request.
It runs Python 3.12 through 3.14, Node.js, Bun, Go, Ruby, and Rust. Capabilities vary by runtime. On Pro and Enterprise, Fluid compute functions have a generally available maximum duration of 800 seconds. Supported Node.js, Bun, and Python versions can run for up to 30 minutes in beta. Durations above 800 seconds require per-function configuration.
Vercel Functions pros:
Active CPU billing: CPU charges pause while code waits on a model or database, so I/O-heavy routes pay mostly for memory.
Scale-to-one: On Pro and Enterprise plans, production deployments keep one instance warm, so low-traffic APIs avoid zero-to-one starts between requests.
Python zero-config: FastAPI, Flask, and Django apps deploy as detected frameworks, with no adapter code to write or maintain.
If your frontend already runs on Vercel, you can deploy the backend through the same Git workflow, with full-stack preview deployments for branches.
Vercel Functions cons:
Hobby cron precision: Hobby cron jobs run once a day with ±59-minute precision, which rules out time-sensitive schedules.
4.5 MB payload cap: Request and response bodies cap at 4.5 MB, which rules out sending large files inline.
Non-commercial Hobby: The free plan covers personal and non-commercial projects only, so revenue-generating apps can't stay on it.
Use object storage for files above the payload limit. Commercial projects and workloads that need minute-level cron schedules require Pro or Enterprise. Include those requirements when deciding whether Vercel fits your application.
Pricing: Hobby is free with 4 hours of Active CPU and 1 million invocations a month. Pro is $20 a month with a $20 usage credit, and Active CPU starts at $0.128 an hour.
Best for: I/O-bound APIs and FastAPI or Django backends that ship through Git with preview deployments.
Copy link to heading2. AWS Lambda
AWS Lambda is Amazon's function-as-a-service runtime. You configure functions to respond to events or HTTP integrations. You can use managed language runtimes or operating-system-only runtimes.
Managed runtimes include Python 3.12 through 3.14, Node.js, Java, .NET, and Ruby. Go and Rust use operating-system-only runtimes. Configure functions on the default compute type with 128 MB to 10,240 MB of memory.
AWS Lambda pros:
Commercial free tier: The permanent monthly allowance covers low-traffic production APIs, including commercial ones, at no charge.
SnapStart for Python: SnapStart captures initialized function state and restores execution environments from that state. Python support begins with version 3.12.
Native AWS triggers: Connect functions to queues, EventBridge rules, and Simple Storage Service (S3) events.
AWS Lambda cons:
Billed waiting time: GB-seconds run for the whole invocation, so an endpoint waiting on an external API or AI model pays the full rate for the wait. Newly launched Lambda Web Functions currently support Node.js and bill active CPU, consumed memory, requests, and transfer.
IAM setup: Needs an Identity and Access Management (IAM) execution role that grants the function access to the AWS resources it uses.
15-minute ceiling: Invocations stop at 900 seconds, so longer work moves to Lambda Managed Instances on Elastic Compute Cloud (EC2) capacity.
Short event handlers barely register these costs, so Lambda's fit depends on how long each invocation waits.
Pricing: Compute is $0.0000166667 per GB-second on x86, with Arm64 about 20% cheaper, plus $0.20 per million requests.
Best for: Event-driven handlers and background tasks that integrate with AWS services.
Copy link to heading3. Google Cloud Run
Google Cloud Run is a fully managed runtime for containers. You can deploy a service from a container image or use Cloud Run functions to deploy supported source code without writing a Dockerfile.
You can package a compatible Python runtime in a container. Cloud Run functions offers managed Python versions. Cloud Run service requests and HTTP-triggered Cloud Run functions can run for up to 60 minutes. Scheduled and task-queue functions have a 30-minute limit. Event-driven functions have a nine-minute limit.
Google Cloud Run pros:
Dual billing modes: Request-based billing charges only while a request is in flight, and instance-based billing lowers the rate for steady traffic.
High concurrency: One instance handles up to 80 concurrent requests by default, so parallel traffic shares capacity instead of adding instances.
Long-running jobs: Cloud Run Jobs run batch work for up to 168 hours, outside the request path entirely.
Services already packaged as containers get the most from these, because the same image runs as a long-lived service or a batch job.
Google Cloud Run cons:
Container packaging: Services ship as container images, which adds a Dockerfile or buildpack step to every project.
Latency spread: A 38-million-invocation benchmark measured the widest latency spread for Cloud Run functions, an 837 ms interquartile range.
Separate scheduler: Cron-style triggers run through Cloud Scheduler, a separate product with its own setup and billing.
Minimum instances remove cold starts at the idle rate, so the cost of warmth shows up on the bill instead of hiding in the meter.
Pricing: Request-based billing in us-central1 is $0.000024 per vCPU-second and $0.0000025 per GiB-second, plus $0.40 per million requests.
Best for: Containerized HTTP services, batch tasks, and applications with existing container images.
Copy link to heading4. Azure Functions (Flex Consumption)
Azure Functions Flex Consumption is Microsoft's recommended serverless hosting plan for Azure Functions. It bills per GB-second of provisioned memory while instances run functions, plus a per-execution fee.
It runs Python 3.12 and later alongside .NET, Java, Node.js, and PowerShell. Instances come in sizes up to 4 GB of memory and scale out to 1,000 instances.
Azure Functions pros:
Long execution: Non-HTTP functions default to a 30-minute timeout with no fixed maximum.
Virtual network integration: Functions reach private backends over a virtual network (VNet).
Always-ready instances: A configured baseline of warm instances removes cold starts, billed at a lower per-GB-second rate.
Private-network and long-running background workloads get the most from Flex, provided the long work runs off an HTTP trigger.
Azure Functions cons:
Python concurrency default: Python instances use an HTTP concurrency setting of one by default. Configure HTTP concurrency to match how your application handles requests.
230-second HTTP limit: HTTP-triggered functions must respond within 230 seconds, so long inference needs an asynchronous pattern.
1-second minimum billing: Every execution bills at least 1,000 ms, so an 80 ms function pays for a full second.
Short Python endpoints under parallel load pay one-second minimums on more instances than the traffic requires.
Pricing: On-demand execution is $0.000026 per GB-second plus $0.40 per million executions, after a monthly free grant.
Best for: Teams on Azure that need VNet integration or long-running background functions.
Copy link to heading5. Modal
Modal is a Python-first serverless container platform. You define functions and their container environments in Python, with optional GPUs.
Function timeouts default to 300 seconds. You can raise the timeout for each function. Apps scale down to zero containers by default when idle.
Modal pros:
24-hour timeout: Training runs and long batch jobs finish inside one function, with no orchestration layer to build.
GPU access: The Starter plan includes 10 concurrent GPU containers, configured in Python alongside dependencies and timeouts.
Container snapshots: Snapshots capture initialized container state. CPU snapshots capture CPU memory. GPU memory snapshots (in alpha) also capture GPU state.
Workloads constrained by dependency size or accelerator access get the most from Modal, while ordinary webhook handlers gain little.
Modal cons:
150-second web limit: HTTP requests past 150 seconds switch to a redirect-and-poll pattern. Clients must follow redirects or submit the job and poll for its result.
Python-first runtime: Modal Functions are implemented in Python.
Billed keep-alive: By default, containers stay alive and billed for 60 seconds after the last input, which adds cost to bursty traffic.
CPU-only APIs with short requests pay these costs without using the GPU and long-timeout capacity that justify them.
Pricing: Starter has no monthly fee and includes $30 of compute a month, with CPU at $0.0000131 per physical core-second.
Best for: ML inference, fine-tuning, and Python data jobs that need GPU access or configurable container environments.
Copy link to heading6. Railway
Railway is a container-based deployment platform that builds and runs services from a repository. You configure the application's environment and process lifecycle per service.
It runs languages that fit in a compatible container. Choose a persistent service or opt into serverless mode, which sleeps an inactive service and resumes it on an incoming request. Sleep detection uses outbound traffic, including telemetry and database connections.
Railway pros:
Auto-detected Python: Railway detects Python projects from files such as
requirements.txtand builds the environment, with no Dockerfile required.Low entry cost: Small APIs fit inside the usage that the Hobby plan's monthly fee already includes.
Persistent and serverless modes: Choose whether each service stays running or sleeps when idle.
The mode switch lets a team trade idle cost for wake-up latency without moving to another deployment platform.
Railway cons:
Cron limits: Cron runs only during the trial on Free, with a cap of 50 jobs on Hobby and 100 on Pro.
Wake-up errors: The first request after idle can return a 502 while a sleeping container starts.
Unpinned Python versions: If you don't pin a Python version, the builder uses its default, which can change between deployments.
Pricing: Hobby is $5 a month including $5 of usage, with CPU at $0.00000772 per vCPU-second and memory at $0.00000386 per GB-second.
Best for: General-purpose APIs that need a container without a Dockerfile.
Copy link to heading7. Netlify Functions
Netlify Functions is the serverless compute layer built into Netlify's frontend hosting. Functions deploy with the site and handle requests or platform events.
It supports JavaScript and TypeScript. Go functions use the deprecated Lambda compatibility mode. Netlify also offers separate Deno-based edge compute for request-time logic.
Netlify Functions pros:
Commercial free tier: The Free plan allows commercial use, so revenue-generating sites can start at no charge.
Frontend integration: Functions deploy with the site, so webhook and form handlers don’t need separate infrastructure.
Background functions: Background functions run for up to 15 minutes, which covers asynchronous tasks without a queue service.
Netlify Functions cons:
No runtime Python: Python runs at build time only, so Python APIs need another platform.
Shared credit pool: Functions draw from the same credits as builds and bandwidth.
CPU cap at the edge: Edge compute stops at 50 ms of CPU per request and uses Deno. Check runtime compatibility when choosing between edge logic and standard functions.
A timeout-sensitive integration needs its longest synchronous request compared against Netlify's current function limits before launch.
Pricing: Function compute costs 10 credits per GB-hour, and paid plans start at $9 a month with 1,000 credits.
Best for: JavaScript or TypeScript request handlers and background tasks on Netlify sites.
Copy link to headingHow do you choose the right serverless computing platform?
Check whether each platform supports your language and longest-running task. Then compare its concurrency, deployment requirements, and billing with what your workload needs.
Use these checks to narrow the shortlist:
Duration ceiling: Long-running work needs extended function duration or a durable workflow engine such as Vercel Workflows, Cloud Run Jobs, or Modal's 24-hour timeouts.
Python runtime: Netlify Functions does not run Python at request time. For the other platforms, check supported versions, framework entrypoints, and packaging requirements.
I/O ratio: Measure how much time the application spends computing and waiting on external services. Use those measurements to estimate charges under the selected platform's billing model.
Measure monthly request volume, active CPU time, total duration, provisioned memory, overlapping requests, region, and transfer volume. Then apply each shortlisted platform's minimum charges, allowances, and plan fees.
Copy link to headingVercel Functions for Python and AI backends
With Vercel Functions, you can deploy Python and AI backends through the same workflow as your frontend. Check its billing model, framework support, and execution limits against your application's requirements.
Copy link to headingFewer cold starts with scale-to-one
Platforms that scale to zero shut down idle instances, so a low-traffic API suffers with a cold start. For Python apps with heavy imports, that first request takes noticeably longer than the rest.
On Pro and Enterprise plans, Vercel keeps one instance warm for each production deployment, so a quiet API keeps answering from a running instance. Bytecode caching on Node.js 20+ and precompiled Python bytecode shorten the cold starts.
Copy link to headingLower cost for I/O-bound APIs with Active CPU billing
GB-second duration billing charges for the full invocation, including time spent waiting on external services. An LLM route that takes 30 seconds in total, with 50 ms of CPU work and the rest spent waiting on a model, incurs duration charges for all 30 seconds. Active CPU billing charges CPU for the 50 ms, while memory remains billable throughout the request.
At 100,000 requests a month with 1 GB of memory, that route comes to about $9.07 on Vercel Pro, covered by the $20 usage credit, and about $43.33 on Lambda x86 after the free tier. Most of the Vercel charge is memory. The example assumes one request per instance and the same CPU time on both platforms, and excludes transfer, model-provider charges, and other services. Concurrent requests sharing a Vercel instance can reduce its memory charges.
Copy link to headingPython deployment without adapter code
Deploying FastAPI or Django on an event-based function platform can require an adapter that translates platform events into ASGI or WSGI requests. The adapter adds a dependency to configure and maintain. Whether you need one, and how much setup it requires, depends on the platform and deployment model.
The Python runtime detects FastAPI, Flask, and Django and routes requests to the ASGI or WSGI app. It reads dependencies from pyproject.toml, with an optional uv.lock to pin dependency versions. Each app deploys as one function, with preview deployments and function logs available in Vercel. Python bundles can reach 500 MB uncompressed, or 5 GB with Large Functions enabled on Fluid compute in public beta, providing room for data and ML libraries.
Copy link to headingLonger execution for inference and batch jobs
Multi-step AI workflows can outlast a function's time limit. Moving one slow route to a separate container platform solves the limit but adds a second deployment pipeline to maintain.
Pro and Enterprise functions run for up to 800 seconds through maxDuration, and a beta extends that to 30 minutes. Vercel Workflows covers longer tasks by pausing and resuming across minutes or months. CPU-bound jobs keep the CPU meter running throughout, so the cost advantage is smallest when computation fills the time.
Start a new project to deploy a serverless function now, or browse templates for production-ready API starters.
Copy link to headingFrequently asked questions about serverless computing platforms
Copy link to headingWhat is the best serverless computing platform for Python in 2026?
Check Python support at request time, framework deployment, concurrent request handling, and execution limits. Vercel Functions supports Python ASGI and WSGI apps and frameworks such as Django and FastAPI.
Copy link to headingCan you use a free serverless plan for commercial projects?
Check commercial-use eligibility before comparing usage allowances. Vercel's Hobby plan is for personal, non-commercial projects. Commercial projects require Pro or Enterprise. The Pro plan has a $20 monthly platform fee with $20 in usage credit.
Copy link to headingWhen is serverless computing the wrong choice?
Always-on stream processors and tasks that exceed function execution limits may need a persistent container service or virtual machine. Vercel Functions supports WebSocket connections with Fluid compute enabled. Each connection is pinned to one instance. Normal function limits and pricing apply, including active-connection usage and data transfer. Follow How to choose between Functions, containers, and Daemons to learn more about picking the right compute.
Copy link to headingWhat is the difference between a serverless platform and a container platform?
Serverless describes how infrastructure is managed and scaled; containers describe how applications are packaged and executed. A serverless service such as Vercel can run containers. Choose an execution model that supports the application's invocation pattern and process lifetime.