# How to Deploy a Next.js App on Heroku in 2026

> Learn how to deploy a Next.js app on Heroku in 2026. Covers Procfile setup, environment variables, SSR support, real dyno costs, and a faster alternative.
- **Author**: james-whitfield
- **Published**: 2026-05-09
- **Modified**: 2026-05-09
- **Category**: Deployment Guides
- **URL**: https://kuberns.com/blogs/how-to-deploy-nextjs-on-heroku/

---

Deploying a Next.js app on Heroku takes about 15 minutes if your project is set up correctly. Heroku runs Next.js as a standard Node.js server using `next build` and `next start`, which means full SSR, API routes, and middleware all work out of the box. The deployment requires a `Procfile`, the right `package.json` scripts, and careful handling of environment variables - particularly `NEXT_PUBLIC_` variables, which most guides get wrong.

One thing to know upfront: Heroku has no free tier in 2026. The minimum cost to run a Next.js app is $5 per month for an Eco dyno, and Eco dynos sleep after 30 minutes of inactivity, which directly affects SSR performance.

This guide walks you through every step from project preparation to a live production URL. You will learn how to configure the Procfile correctly, why `NEXT_PUBLIC_` variables must be set before you push (not after), how SSR and ISR behave on Heroku dynos, what the real 2026 costs look like, and where Heroku starts to fall short for Next.js workloads. If those limitations matter to your project, the last section covers a faster zero-config alternative built specifically for modern full-stack frameworks.

## What You Need Before You Start

Before running a single command, make sure you have the following in place:

- **Node.js 18 or higher** installed locally
- **Git** installed and your Next.js project already in a repository
- **Heroku CLI** installed - download from [devcenter.heroku.com/articles/heroku-cli](https://devcenter.heroku.com/articles/heroku-cli)
- **A Heroku account** with a paid plan - the minimum is an Eco dyno at $5/month
- **Your `package.json`** must include both a `build` script (`next build`) and a `start` script (`next start`)

If your project is not in a Git repository yet, run `git init && git add . && git commit -m "initial commit"` before continuing.

> Before creating your Heroku account, it helps to know exactly what you will pay. The [complete Heroku pricing breakdown](https://kuberns.com/blogs/heroku-pricing-explained/) covers dynos, add-ons, and how costs scale as your traffic grows.

## How to Deploy a Next.js App on Heroku

![How to Deploy Next.js on Heroku](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/guide-to-deploy-nextjs-on-heroku.png)

Heroku treats Next.js as a standard Node.js application. There is no special Next.js buildpack required. As long as your project has the right scripts and a Procfile, Heroku handles the rest automatically.

### Step 1 - Prepare Your Next.js Project

Open your `package.json` and confirm these two scripts exist:

```json
{
  "scripts": {
    "build": "next build",
    "start": "next start"
  }
}
```

`next build` generates the optimised production build. `next start` launches the Node.js server that serves it. Both are required.

Next, create a file named `Procfile` at the root of your project. No file extension:

```
web: npm run start
```

This tells Heroku to start a web dyno and run `npm run start`, which executes `next start` from your `package.json`. Do not use `next dev` here. The dev server is single-process, unoptimised, and not safe for production traffic. `next start` runs the full production Node.js server with SSR, API routes, and middleware all active.

Finally, make sure your `.gitignore` excludes the build output and local environment files:

```
.next/
node_modules/
.env.local
.env
```

Commit everything before moving to the next step:

```bash
git add .
git commit -m "add Procfile and confirm package.json scripts"
```

### Step 2 - Create the Heroku App

Log in to Heroku from the CLI:

```bash
heroku login
```

This opens a browser window for authentication. Once logged in, create your Heroku app:

```bash
heroku create your-app-name
```

Replace `your-app-name` with a unique name. If you leave it blank, Heroku auto-generates one. The command also adds a `heroku` Git remote to your local repository automatically.

Heroku detects Node.js automatically from the presence of `package.json`. No manual buildpack selection is needed.

> If you want deployments to trigger automatically on every GitHub push, set up [Heroku GitHub integration](https://kuberns.com/blogs/heroku-github-integration/) before your first deploy.

### Step 3 - Deploy to Heroku

Push your code to Heroku:

```bash
git push heroku main
```

You will see Heroku work through the build in real time:

```
remote: -----> Node.js app detected
remote: -----> Installing Node.js v20.x
remote: -----> Installing dependencies
remote: -----> Build succeeded
remote: -----> Discovering process types
remote:        Procfile declares types -> web
remote: -----> Launching...
remote:        Released v3
remote:        https://your-app-name.herokuapp.com/ deployed to Heroku
```

Once the push completes, scale your web dyno. Heroku does not do this automatically on a new app:

```bash
heroku ps:scale web=1
```

Skipping this step causes an H14 error where your app is deployed but no dyno is running to serve traffic.

Open your live app:

```bash
heroku open
```

### Step 4 - Handle Environment Variables Correctly

This is the step most guides skip, and it causes the most post-deployment confusion.

Next.js has two types of environment variables and they behave very differently on Heroku:

**`NEXT_PUBLIC_` variables** are embedded into the browser JavaScript bundle at build time. This happens during `next build`, which Heroku runs as part of `git push heroku main`. If you set these config vars after the push, they will not appear in the current build. You must set them before pushing:

```bash
heroku config:set NEXT_PUBLIC_API_URL=https://api.yoursite.com
heroku config:set NEXT_PUBLIC_ANALYTICS_ID=UA-XXXXXXX
```

Then push your code. Any time you change a `NEXT_PUBLIC_` variable, you need to trigger a new build by pushing again.

**Server-side variables** (API keys, database URLs, secrets) are read at runtime, not build time. These can be set or updated at any time:

```bash
heroku config:set DATABASE_URL=postgres://...
heroku config:set NEXTAUTH_SECRET=your-secret
```

There is also a Heroku pipeline gotcha worth knowing: if you use Heroku Pipelines to promote a slug from staging to production, all `NEXT_PUBLIC_` values are frozen at the time the slug was originally built. Promoting does not rebuild. If your staging and production environments need different public URLs, you cannot use slug promotion for `NEXT_PUBLIC_` variables.

> Managing environment variables across staging and production is much simpler with the [Heroku GitHub integration](https://kuberns.com/blogs/heroku-github-integration/) pipeline setup, which triggers fresh builds per environment.

### Step 5 - SSR, ISR, and API Routes on Heroku

Heroku runs `next start`, which means it operates as a full Node.js server. Here is how each Next.js rendering mode behaves:

**Server-Side Rendering (SSR)** works fully. Every request hits the Node.js server, `getServerSideProps` runs, and the page is rendered on the fly. No limitations here.

**Incremental Static Regeneration (ISR)** works but with an important caveat. Heroku dynos are stateless and ephemeral. When a dyno restarts or sleeps and wakes up, the ISR cache is wiped. This means your revalidation intervals may behave inconsistently, and cache warming happens more often than expected.

**API Routes** work exactly like any Node.js endpoint. No extra configuration is needed.

**Cold starts on Eco dynos** are a real problem for SSR. Eco dynos sleep after 30 minutes of inactivity. The first request after a sleep cycle can take 10 to 30 seconds while the dyno wakes up and the Node.js server initialises. For any app where response time matters, an Eco dyno is not suitable for SSR workloads.

> Deploying a plain Node.js backend on Heroku follows the same pattern. See the [Heroku Node.js deployment guide](https://kuberns.com/blogs/heroku-nodejs-deploy/) if you are running a separate API service alongside your Next.js app.

## Heroku Next.js Costs in 2026

Heroku pricing for a Next.js app in 2026 starts at $5 per month and grows quickly once you add a database or need more reliable performance.

| Resource | Plan | Monthly Cost | Notes |
|---|---|---|---|
| Web Dyno | Eco | $5/month | Sleeps after 30 min inactivity, 1000 hours shared across all apps |
| Web Dyno | Basic | $7/month | No sleep, dedicated hours, suitable for production |
| Web Dyno | Standard-1X | $25/month | 512 MB RAM, suitable for moderate SSR traffic |
| Postgres | Essential-0 | $5/month | 1 GB storage, suitable for small apps |
| Postgres | Essential-1 | $9/month | 10 GB storage, suitable for growing apps |

For a minimal Next.js app with no database, the Eco dyno at $5/month is the floor. For anything with real users, the Eco dyno's sleep behaviour makes it unsuitable for SSR. The Basic dyno at $7/month removes sleep but still only gives you 512 MB RAM, which can be tight during `next build` on larger projects.

A realistic production setup for a Next.js app with Postgres runs $12 to $34 per month depending on the dyno tier you choose.

The cost that catches teams off guard is the build memory limit. Heroku's build environment has a 512 MB RAM cap on most dyno types. Large Next.js apps with heavy page counts or complex webpack configurations can exceed this during `next build` and fail with an out-of-memory error. The fix is to upgrade to a Standard-2X dyno ($50/month) or optimise your Next.js build configuration.

> Dyno costs are just one line item. The [full Heroku pricing guide](https://kuberns.com/blogs/heroku-pricing-explained/) covers add-ons, data services, and how the total bill grows as you scale.

## Heroku Limitations for Next.js in 2026

![Heroku Next.js Limitations](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/heroku-nextjs-limitations.png)

Heroku works for Next.js, but there are five limitations that affect real production workloads. Knowing them upfront saves a lot of debugging later.

**No free tier.** Every deployment costs money from day one. There is no free plan, no trial period, and no free hobby dyno since November 2022. If you are evaluating Heroku for a side project or prototype, you are paying at minimum $5 per month from the first deployment.

**Eco dyno cold starts break SSR.** The Eco dyno sleeps after 30 minutes of inactivity. When a user hits a sleeping dyno, the Node.js server has to restart before it can serve the request. For a Next.js app using SSR, this means the first visitor after an idle period waits 10 to 30 seconds for a response. This is not a minor annoyance - it is a broken user experience for SSR-heavy applications.

**Memory pressure on large Next.js builds.** The `next build` command is memory-intensive, especially for apps with many pages, heavy dependencies, or complex webpack configurations. Heroku's build container caps at 512 MB RAM on lower dyno tiers. Hitting that limit causes the build to fail with a cryptic out-of-memory error. The only fix is to upgrade to a more expensive dyno or reduce build complexity.

**Stateless dynos break ISR cache.** Heroku dynos are ephemeral. Every time a dyno restarts - which happens on every deployment, every dyno sleep cycle, and on Heroku's periodic restarts - the ISR cache is wiped. Pages that rely on ISR for fast delivery will fall back to full server-side rendering more often than expected, increasing latency and server load.

**Costs escalate quickly at scale.** A single Basic dyno with Postgres is manageable. But as soon as you need multiple dynos for horizontal scaling, a production-grade database, log management, and monitoring add-ons, the monthly bill climbs fast. Teams that start on Heroku for convenience often find themselves paying significantly more than comparable setups on other platforms once they hit real traffic.

> If these trade-offs are not acceptable for your project, there are strong options available today. The [complete guide to Heroku alternatives](https://kuberns.com/blogs/the-ultimate-guide-to-heroku-alternatives-in-2025/) lays out every major platform with honest comparisons on pricing, features, and Next.js compatibility.

## Switch to Kuberns for Deploying Next.js with AI Agent

![Deploy Next.js with Kuberns AI Agent](https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/kuberns-home-page-new.png)

Every limitation listed above has a direct fix on [Kuberns](https://kuberns.com). Kuberns is an Agentic AI cloud deployment platform built on AWS. It is designed for teams who want production-grade infrastructure without the operational overhead that comes with Heroku at scale.

Here is how Kuberns addresses each Heroku limitation for Next.js:

**Agentic AI stack detection.** Kuberns reads your repository and identifies Next.js automatically. It sets `next build` and `next start` as the build and start commands without you writing a Procfile, selecting a buildpack, or touching any configuration file. Connect your repo and the AI handles the rest.

**Zero cold starts.** Kuberns runs on persistent AWS infrastructure. There are no sleeping dynos and no wake-up delays. Your Next.js SSR responses are fast from the first request, regardless of how long the app has been idle.

**NEXT_PUBLIC_ environment variables handled at the right time.** The Kuberns dashboard injects build-time variables before the build runs. You set them once in the UI and they are always applied correctly on every deploy. No manual ordering, no forgotten variables, no rebuilds to pick up missed config.

**Persistent infrastructure for ISR.** Kuberns does not use ephemeral containers that wipe state on restart. Your ISR cache persists across deployments, so revalidation works as Next.js intends and your users get cached pages instead of on-demand server renders.

**Automatic scaling without manual commands.** Traffic spikes are handled by Kuberns automatically. There is no `heroku ps:scale` command, no dyno count to manage, and no risk of your app going down because you forgot to scale up before a launch.

**Built-in CI/CD.** Every push to your connected GitHub branch triggers a fresh build and deployment automatically. No webhook configuration, no third-party CI setup, no extra steps.

**Unified monitoring and logs.** Real-time metrics, request logs, and deployment history are available directly in the Kuberns dashboard. No add-ons, no Papertrail, no Datadog subscription needed for basic observability.

**Up to 40% cost savings vs direct AWS.** Kuberns runs on AWS infrastructure and passes through significant cost efficiency compared to managing EC2 or ECS directly. Teams that move from Heroku Standard dynos to Kuberns consistently report lower monthly bills for the same workload.

> See how Kuberns and Heroku compare side by side on pricing, features, and deployment experience in the [Heroku vs Render vs Kuberns breakdown](https://kuberns.com/blogs/heroku-vs-render-vs-kuberns/).

<a href="https://dashboard.kuberns.com" target="_blank" rel="noopener noreferrer">
  <img src="https://kuberns-blogs-media.s3.ap-south-1.amazonaws.com/deploy-on-kuberns-bannner6.png" alt="Deploy Next.js with Kuberns" style={{ width: "100%", height: "auto" }} />
</a>

## Conclusion

Deploying a Next.js app on Heroku comes down to four files: a `Procfile` with `web: npm run start`, a `package.json` with `build` and `start` scripts, a `.gitignore` that excludes `.next/` and `.env.local`, and your environment variables set correctly before the first push.

The process works. Heroku runs Next.js as a Node.js server, SSR and API routes function as expected, and the git-based deployment workflow is genuinely simple. For a quick deployment with minimal setup, it gets the job done.

That said, the limitations are real in 2026. No free tier, cold starts on Eco dynos, stateless ISR cache, build memory pressure, and costs that scale faster than the workload justify make Heroku a harder choice for Next.js compared to what it was a few years ago.

If you want the same simplicity without those trade-offs, Kuberns handles everything automatically on persistent AWS infrastructure with zero configuration files required.

[Deploy with AI Agent Now](https://dashboard.kuberns.com/)

## Frequently Asked Questions

### Q: Can I deploy a Next.js app on Heroku for free in 2026?

No. Heroku removed its free tier in November 2022. The cheapest option in 2026 is the Eco dyno at $5 per month, which gives you 1000 shared dyno hours across all your apps. There is no free plan, no trial period, and no hobby dyno. If cost is a concern, the [complete guide to Heroku alternatives](https://kuberns.com/blogs/the-ultimate-guide-to-heroku-alternatives-in-2025/) covers platforms that still offer free tiers for small projects.

### Q: Does Heroku support Next.js SSR and API routes?

Yes. Heroku runs Next.js as a Node.js server using `next start`, which supports full SSR, API routes, and middleware. The Procfile entry `web: npm run start` handles this. Static export mode also works but you lose SSR and API route support entirely, so it is only suitable for purely static Next.js apps.

### Q: Why are my NEXT_PUBLIC_ environment variables undefined after deployment?

`NEXT_PUBLIC_` variables are baked into the browser JavaScript bundle at build time during `next build`. If you set them in Heroku config vars after pushing your code, they are not included in the current build. You must set all `NEXT_PUBLIC_` config vars before running `git push heroku main`, then trigger a fresh build by pushing again.

### Q: How do I fix H14 no web dynos running on Heroku?

Run `heroku ps:scale web=1` after your first deployment. Heroku does not automatically scale dynos on a new app. Without this command your code is deployed but no dyno is running to serve HTTP traffic, which is what causes the H14 error. Check your current dyno state at any time with `heroku ps`.

### Q: Does Heroku support Next.js 14 and 15 App Router?

Yes. Heroku runs Next.js as a standard Node.js server, so any version including Next.js 14 and 15 with the App Router works without any special configuration. The deployment steps are identical regardless of Next.js version. Make sure the `engines` field in your `package.json` specifies a Node.js version that Heroku supports to avoid unexpected version mismatches.

### Q: How do I set up auto-deploy for Next.js on Heroku from GitHub?

In the Heroku dashboard, go to your app, open the Deploy tab, and connect your GitHub repository under Deployment Method. Once connected, enable Automatic Deploys for your target branch. Every push to that branch triggers a new build and deployment. You can also enable the option to wait for your CI checks to pass before Heroku deploys.

### Q: What is the minimum cost to run a Next.js app on Heroku in 2026?

The absolute minimum is $5 per month for one Eco dyno. If your app needs a database, add $5 per month for the Essential-0 Postgres plan, bringing the total to $10 per month. For a production app where cold starts are not acceptable, a Basic dyno at $7 per month is the practical minimum, putting the total at $12 per month with Postgres.

---
- [More Deployment Guides articles](https://kuberns.com/blogs/category/deployment-guides/1/)
- [All articles](https://kuberns.com/blogs/)