Skip to main content
Next.js apps deploy on Suga straight from a GitHub repo. Suga detects next build and next start from your package.json, so no Dockerfile is needed. This guide explains how to deploy a Next.js app in two ways:
  1. Step-by-step via the canvas
  2. Using a coding agent
If you have your own Next.js repo, follow the steps with it. If not, scaffold a fresh app and push it to a GitHub repo to follow along:

Deploy using the Canvas

1

Create a project from your repo

In the Suga dashboard, click New project and pick your Next.js repo from the GitHub list, installing the Suga GitHub App if prompted. On the import page, name the project and leave the build method on auto-detect; Suga picks up next build and next start from your package.json. Set the branch you want deployed, and a root directory if the app lives in a subdirectory. See Import from a GitHub repository for the full set of import options.Click Create project. Suga opens the canvas with a service already connected to your repo.
2

Expose the app on HTTPS

Select the service. On its Config tab, in the Private Network section, set the port to 3000 (Next.js’s default). Then, in the Public Network section, click Add Endpoint → HTTPS Domain and choose port 3000. Suga reserves a hostname immediately and shows the URL in the properties panel.
3

Apply to deploy

Click Apply in the top right. Suga clones the repo, runs next build, and starts the app. A fresh Next.js app takes 60-90 seconds end to end.
Suga canvas showing the deployed nextjs container with the connected GitHub repo and generated URL in the properties panel
The default Next.js landing page loads at the public URL.
The default Next.js landing page served at the container's public URL

Deploy using an Agent

To deploy with a coding agent such as Claude Code, Codex, or OpenCode, follow these steps:
1

Connect the Suga MCP

If you haven’t already, connect your agent to the Suga MCP server.
2

Ask your agent to deploy

Ask your agent to deploy your repo to Suga. Here’s a basic prompt you can use, with your repo and branch filled in:
Prompt
The agent will give you a link to the new environment on the Suga canvas. Open it to review the setup.
3

Apply to deploy

Click Apply in the top right. Suga clones the repo, runs next build, and starts the app. Your app loads at the public URL 60-90 seconds later.

FAQ

No. Suga detects Next.js from package.json and runs the right build and start commands. If you already have a Dockerfile, you can tell the agent to use it instead; otherwise Suga’s default handles the standard flow.
Any version. Suga runs the version pinned in your package.json, both the pages router and the app router. Node.js version comes from engines in package.json or a .nvmrc file if you have one.
Add them as build args on the container, not as regular env vars. Build args are set during the build, which is when Next.js inlines NEXT_PUBLIC_* values into the client bundle. Runtime env vars are only visible on the server after the build finishes.
Yes. They run on the same container as the rest of the app in the Node.js runtime. No separate function service or edge runtime configuration is needed.
Yes. Next.js’s built-in image optimization runs on the container using the default sharp-based loader. No extra configuration required. For a CDN-backed loader, configure it in next.config.js as usual.
ISR and the data cache work in-container. Regenerated pages and cached fetches live on the container’s local disk, so with more than one replica each instance keeps its own copy. For cross-instance persistence, add a Redis service on the canvas and point the cache at it.
Yes. When configuring the container, set the build context to your Next.js subdirectory, or pass RAILPACK_BUILD_CMD and RAILPACK_START_CMD as build args to target the specific app.
Yes. Attach your domain to the container in the dashboard once the app is deployed.
The Free tier fits a small Next.js app plus its build history. Pro is per-seat with hosting credits that offset compute and storage. Full pricing at suga.app/pricing.