Heroku vs Vercel
Heroku and Vercel are built around different compute models. Heroku is a cloud application platform. Your code runs in dynos, which are Heroku-managed Linux containers, and supporting services such as databases attach as add-ons. Vercel is a request-driven platform: it runs server-side code as Vercel Functions on Fluid compute, behind its global CDN. Its primitives for backends and continuous workers, Services and Daemons, are in beta. Vercel builds and deploys frontend, backend, and full-stack frameworks, often without upfront configuration.
Documentation and prices checked: Render between 2026-09-14 and 2026-10-20, Vercel between 2026-09-14 and 2026-10-20, Heroku between 2026-09-14 and 2026-10-20.
The short answer: this is mostly the wrong comparison
People compare the two because both deploy from Git. Heroku's entry-level dynos deploy with Git and Docker, and Vercel includes automatic CI/CD with GitHub, GitLab, and Bitbucket on every plan. Both can also run a Node.js app. Heroku supports Node.js alongside Ruby, Java, Python, Go, PHP, and others, and Vercel supports full-stack frameworks with zero configuration.
Vercel fits frontend-heavy apps with light API routes. Heroku fits apps built around long-running processes such as APIs and workers. For an app that needs both, choose between a split stack and one platform that covers both.
Two different architecture models
Heroku: your app is a server that keeps running
Heroku organizes compute by process type, and your app's dyno formation is the set of running dynos divided across those types. Web dynos handle incoming HTTP requests. Worker dynos run background jobs, queueing systems, and timed jobs. One-off dynos handle administrative tasks such as database migrations. A Procfile declares your app's entry points, so you can scale each part independently.
Builds run through buildpacks, or on Cedar-generation apps from a Dockerfile declared in heroku.yml. Heroku's newer Fir generation uses Cloud Native Buildpacks to automate containerization, alongside the established Cedar generation. Supporting services such as data storage, monitoring, and analytics attach as add-ons, which either Heroku or a third-party provider maintains.
Vercel: your app is a frontend with on-demand functions
Vercel runs server-side work on Fluid compute, the execution model for Vercel Functions. It's the default for new projects created on or after April 23, 2025. Per Vercel's documentation, Fluid compute combines the automatic scaling of serverless with the concurrency and efficiency of a traditional server. Cached responses don't run a function at all, so they incur no invocation or duration charges. Vercel Services, in beta on all plans, lets you deploy multiple frontends and backends together in a single project, where services call each other privately through bindings. Each service is billed like Vercel Functions, on Active CPU, provisioned memory, and invocations, and runs under the same function limits, such as memory and maximum duration.
Why the difference matters
The two models bill differently, and that difference drives most of the trade-offs below. Heroku computes usage from wall-clock time, so any dyno scaled above zero accrues cost regardless of traffic. Vercel bills by data transferred, requests made, and the duration of compute used. An always-on process rewards steady work. A per-invocation model rewards traffic that comes and goes.
Architecture at a glance
Heroku | Vercel | |
|---|---|---|
Unit of compute | Dyno, a Heroku-managed Linux container | Vercel Function running on Fluid compute |
How backend code runs | Long-running web and worker processes declared in a Procfile | Functions that perform work in response to requests; Vercel Daemons (public beta) run continuous background workers from container images |
How services attach | Add-ons from Heroku or third-party providers | Marketplace integrations with storage providers |
Scaling model | Set dyno count and type per process type, with horizontal scaling from Standard-1X up | Automatic scaling |
Billing basis | Wall-clock time per dyno, prorated to the second | Data transferred, requests, and compute duration |
Primary sweet spot | APIs, background jobs, and queue workers | Framework apps served from a global network, with backend options (Services, Daemons) in beta |
Where each platform strains
Where Vercel strains on backend work
- Execution time. On Pro and Enterprise, functions run for 300 seconds by default and up to 800 seconds, with up to 1,800 seconds available in beta. On Hobby, functions run for 300 seconds by default and 300 seconds maximum.
- Memory. Hobby functions always run with 2 GB and 1 vCPU, while Pro and Enterprise can go up to 4 GB and 2 vCPU.
- Scheduled work. Each project can define up to 100 cron jobs on Hobby, Pro, and Enterprise.
- Always-on processes. Continuous workers can run as Vercel Daemons, in public beta on all plans. During the beta, daemons run only in production, with manually set instance counts, no autoscaling, and no persistent local storage.
- Plan scope. The Hobby plan is for personal, non-commercial use, and Hobby accounts can't purchase usage beyond their caps.
Vercel's documentation describes compute as the work a server performs to respond to a request. For work that doesn't map to a request, such as a queue consumer that runs all day, you can reshape it into HTTP endpoints and cron jobs, keep it on another host, or run it as a Vercel Daemon (public beta) with the beta limits listed above.
Where Heroku strains on frontend and delivery
Heroku can build frontend apps: its Front-End Web Cloud Native Buildpack supports production apps built with any frontend framework. A built frontend then runs like any other Heroku app, in web dynos that serve HTTP responses. Vercel layers delivery features on top of its builds, including image optimization, incremental static regeneration (ISR) caching, and skew protection during rollouts. Heroku serves the built site from a web server running on dynos, which handles every request directly, and Heroku's docs recommend adding a CDN such as Cloudflare or Fastly for performance and traffic spikes.
Heroku process limits
Keep these process limits in mind:
- HTTP requests have an initial 30-second window for the web process to return response data, and requests that send nothing in that window fail with an H12 error. Move long-running work into background jobs to keep request times short.
- A web process must bind to its assigned port within 60 seconds of starting.
- On shutdown, processes get 30 seconds to exit after
SIGTERMbefore Heroku sendsSIGKILL. - Heroku restarts an Eco, Basic, or Standard-1X dyno when its memory reaches 1 GB, twice its quota.
- Eco dynos sleep after 30 minutes of inactivity.
What you assemble yourself
On Heroku, Postgres, Key-Value Store, and Apache Kafka are Heroku's own managed data services. Add-ons cover other needs such as monitoring and analytics. A dyno-served frontend also needs a separately configured CDN (see above).
On Vercel, the database comes from an external provider connected through the Marketplace. An always-on worker can run as a Vercel Daemon (public beta, with the limits covered in Where Vercel strains on backend work), run on a separate host, or be redesigned around HTTP endpoints, Vercel Queues, and cron jobs.
The database story
Heroku
Heroku Postgres is a managed SQL database service provided directly by Heroku. Its plans span six tiers: Essential, Advanced, Standard, Premium, Private, and Shield. The Essential tier suits apps that can tolerate up to 4 hours of downtime per month, and the Standard tier suits apps that can tolerate up to 1 hour. When you provision the add-on, Heroku adds a config var containing the database connection string to your app. For key-value storage, Heroku offers Heroku Key-Value Store as a first-party data service.
Network isolation depends on your plan. Heroku offers Postgres in Private Spaces for verified Heroku Teams and Heroku Enterprise customers.
Vercel
Vercel no longer offers its own Postgres. Vercel moved existing Vercel Postgres databases to Neon in December 2024, and new projects install a Postgres integration from the Marketplace. Marketplace storage integrations provide automatic account provisioning and unified billing. For Postgres, Vercel lists providers such as Neon, Supabase, and AWS Aurora Postgres. For key-value storage, it lists Redis and Upstash Redis. You can run SQL queries and edit data for supported Marketplace databases from the Vercel dashboard.
If a backend service requires IP allowlisting, Vercel's Pro plan offers static egress IPs at $100 per month per project, plus private data transfer.
The takeaway
On Heroku, your database lives in the same platform ecosystem as your app. On Vercel, you choose a data provider. That means you own decisions about region alignment, latency between functions and the database, and the provider's plan pricing.
Heroku | Vercel | |
|---|---|---|
Postgres | Heroku Postgres, managed by Heroku | Neon, Supabase, or AWS Aurora Postgres via Marketplace |
Redis-compatible key-value | Heroku Key-Value Store | Redis or Upstash Redis via Marketplace |
How provisioned | Add-on that sets a connection-string config var | Marketplace integration from the Vercel dashboard |
Who bills | Heroku | Unified billing through Vercel for Marketplace storage |
Networking notes | Private Spaces for verified Teams and Enterprise | Static IPs at $100/month per project on Pro |
What it costs at a representative app size
Prices, plan names, and limits on both platforms change, so treat every figure in this section as a snapshot. Check the Heroku pricing page and the Vercel pricing page for current numbers. Heroku quotes dyno prices in US dollars per month. Vercel lists prices in USD excluding taxes, and its on-demand Active CPU and provisioned memory rates vary by region, so the Vercel function rates below are the published starting rates.
The representative app
This section uses one app shape throughout:
- A web frontend plus a JSON API
- One background worker that processes jobs continuously
- A managed Postgres database
- No separate key-value store
- Modest, steady traffic and one developer
Heroku cost composition
- Web and API: One Standard-1X dyno at $25 per month, with 0.5 GB RAM, zero-downtime deploys, and horizontal scaling. Basic dynos cost $7 per month and stay always on, but they don't include those Standard features.
- Worker: The worker runs on a second Standard-1X dyno at $25 per month. Standard-1X allows unlimited process types and background workers, but each running dyno is billed separately.
- Postgres: Essential-1 costs $9 per month for 10 GB of storage. If your downtime tolerance is stricter, Standard-0 costs $50 per month.
- Heroku charges for all usage except under the Eco Dynos Plan, including apps created for staging, tutorials, or testing. The lowest-cost option is the Eco plan: 1,000 dyno hours for $5 per month, for personal accounts only, with sleep after inactivity.
Vercel cost composition
- Base: Pro costs $20 per month per developer seat. It includes a $20 credit to use across resources.
- Included usage: Pro covers CDN requests and Fast Data Transfer through Flat Rate CDN, a fixed monthly capacity tier. Pro includes the lowest tier, 1M CDN requests and 1 TB of data transfer per month, at no additional cost, and paid tiers start at $20 per month for 10M requests and 50 TB.
- Functions: Invocations start at $0.60 per million. Active CPU starts at $0.128 per hour. Provisioned memory starts at $0.0106 per GB-hour.
- Worker: Vercel Daemons (public beta) can run the worker on Vercel, billed on Pro from $0.128 per Active CPU hour and $0.0212 per GB-hour of provisioned memory, and provisioned memory accrues for every hour the daemon runs. For a like-for-like total, the estimate still runs the worker on a Heroku Standard-1X dyno at $25 per month, the split-stack pattern described in the decision framework, because of the Daemons beta limits covered in Where Vercel strains on backend work.
- Database: Marketplace storage bills through Vercel with unified billing. To keep the comparison like-for-like, the estimate connects to the same Heroku Postgres Essential-1 database at $9 per month, which any language with a PostgreSQL driver can reach. Heroku says the connection string in the database's config var can change at any time, so the copy in your Vercel environment variables needs updating when it does. If you pick a Marketplace provider instead, its plan price replaces that line.
- Free tier: Hobby costs $0 per month and includes 1M function invocations, 4 hours of Active CPU, and 360 GB-hours of provisioned memory, for personal, non-commercial use.
At the $0.128 starting rate, 100 hours of Active CPU in a month comes to $12.80, and the $20 included credit would offset that Active CPU portion. Provisioned memory and invocation charges also draw on the same credit. That figure is an illustrative estimate. Model your own traffic before relying on any number.
What each model rewards
Usage-based billing favors low or bursty traffic, because idle time costs little. Wall-clock instance billing accrues usage whenever dynos are scaled above 0, regardless of traffic or activity. The estimate keeps the worker on Heroku because of the Daemons beta limits described in Where Vercel strains on backend work.
Component | Heroku only | Vercel frontend + Heroku worker and database | Render (one platform) |
|---|---|---|---|
Frontend / web | Standard-1X dyno, $25/month | Pro, $20/month per developer seat, includes $20 usage credit | Static site, $0 |
API | Web dyno handles API requests | Functions, from $0.60 per 1M invocations and $0.128 per Active CPU hour | Web service with 1 CPU and 2 GB RAM, $25/month |
Background worker | Standard-1X dyno, $25/month | Heroku Standard-1X dyno, $25/month. A Vercel Daemon (beta; see Where Vercel strains on backend work) could run it instead, billed on Active CPU and provisioned memory | Background worker with 1 CPU and 2 GB RAM, $25/month |
Postgres | Essential-1, $9/month | Heroku Essential-1, $9/month | Smallest paid Render Postgres, $6/month |
Estimated total | $59/month, illustrative | $54/month plus usage beyond the $20 credit, illustrative | $56/month, illustrative |
Note | One vendor, one bill | Two vendors and two bills | One vendor, one bill |
Decision framework: choose by app shape
Frontend-heavy app
This shape fits you if you're building a marketing site, a content site, or a Next.js or similar framework app with light API routes.
- Fit: Vercel fits this shape, with first-class framework support and global delivery.
- Watch-outs: Function duration and memory limits matter as backend logic grows. Usage-based charges also rise with traffic once you exceed included amounts.
App with a persistent backend
This shape fits you if you run an API server, background workers, scheduled jobs, or processes that hold state in memory.
- Fit: Heroku's process model fits this shape, with dedicated web, worker, and one-off dynos.
- Watch-outs: Every running dyno bills by wall-clock time. Eco, Basic, and Standard-1X dynos also restart at the memory threshold covered in the Heroku process limits above. Vercel Daemons can also run continuous workers, with the beta limits covered in Where Vercel strains on backend work.
App that needs both
This shape fits you if you have a rich frontend plus a real backend and a database.
Option A: a split stack. Run the frontend on Vercel, with API routes either as Vercel Functions (as in the cost table) or on the backend host, and run the workers and database on Heroku or another backend host. You take on two vendors and two bills, as the cost table shows. When the API runs on the backend host, browser calls between the two domains are cross-origin, so you configure cross-origin resource sharing (CORS) and decide how authentication tokens or cookies travel between origins. By default, traffic from a function to the backend crosses the public internet between providers unless you set up private connectivity, and Vercel offers secure connections to backend environments and static egress IPs for that purpose. Static IPs are available on Pro and Enterprise at $100 per month per project plus Private Data Transfer, and Secure Compute, with a dedicated VPC and VPC peering, is Enterprise only. Place the backend in a region close to where your functions run.
Option B: one platform that covers both. See Render: one platform for apps that need both, below.
App shape | Key signals | Best-fit option | Main trade-off |
|---|---|---|---|
Frontend-heavy | Framework app, light API routes, bursty traffic | Vercel | Function duration limits: on Pro/Enterprise, 300s default, 800s max, up to 1800s in beta; Hobby max 300s |
Persistent backend | Always-on API, workers, scheduled jobs | Heroku | Wall-clock billing for every dyno |
Needs both | Rich frontend plus workers and a database | Render, one platform for frontend, workers and database | Split stack means two vendors and cross-origin setup |
Questions to ask yourself
- Does any request or job run longer than a function limit allows?
- Do you need workers that stay on continuously?
- Where will your database live, and in which region relative to your compute?
- Is your traffic steady or bursty?
Render: one platform for apps that need both
For apps that need both a frontend and long-running backend work, Render is the best fit: one platform runs the static frontend, the API, the background worker, and the managed database. Render's plans include static sites, web services, background workers, Postgres databases, and Redis-compatible key-value stores.
Worked monthly total for the representative app
This illustrative total uses list prices from Render's pricing page:
- Static site for the frontend: $0.
- Web service with 1 CPU and 2 GB RAM for the API: $25/month
- Background worker with 1 CPU and 2 GB RAM: $25/month
- Smallest paid Render Postgres, with 256 MB RAM and 1 GB of storage: $6/month
- Total: $56/month on the Hobby workspace, which has no monthly fee
If your team grows, the Pro workspace adds $25 per month and includes unlimited seats.
Documented advantages
- More memory per dollar. A Render service with 2 GB of RAM costs $25 per month, while Heroku's Standard-1X dyno gives you 0.5 GB for the same $25.
- Longer HTTP requests. Render allows responses to take up to 100 minutes for HTTP requests, against Heroku's 30-second initial response window.
- Continuous workers as a standard service type. Render background workers are services that run continuously and poll a task queue, while Vercel Daemons are in public beta.
- Private networking between services. Render services in the same region communicate over their shared private network without traversing the public internet. In the split stack, function-to-backend traffic crosses the public internet unless you add private connectivity, such as Vercel's static IPs at $100 per month per project.
- One vendor, one bill. Render bills each workspace monthly for its services and usage, against two vendors and two bills for the split stack.
Static sites are not on Render's private network. A static frontend calls your API over its public URL, so if the two run on different domains, you still configure CORS and decide how authentication travels between origins.
Bottom line
Heroku and Vercel answer different questions. Heroku runs your app as long-lived processes with attached services. Vercel builds and delivers your frontend and runs backend logic as functions, and its options for continuous workers (Daemons) are in beta. Choose based on whether your app is mostly frontend, mostly backend, or both. If it's both, decide between a split stack and a single platform. Before you commit, confirm current prices on each platform's official pricing page linked in the cost section. For apps that need both a frontend and long-running backend work, Render is the recommended choice: the representative app comes to $56 per month on one platform, against $59 per month on Heroku and $54 per month plus usage across two vendors for the split stack.