Skip to content
Starters

Next.js starter

Start a Next.js app from our starter in the dashboard, or with create-next-app. What we run, how variables reach the build, and when to build again.

Updated 17 Oct 20263 min read

A new Next.js app deploys on Tanzahost as it is: we see next in package.json, run npm run build, and start it with its own npm run start, on the port in PORT. The quickest start is our Next.js starter, in the dashboard. With code of your own, the only thing worth adding is a file that pins your Node.js version.

Start from our starter

  1. On a new account, choose Next.js or Node.js under What are you building? on the dashboard's home, then make your project. In a project you already have, choose Add a service, then App, and under Where's your code? choose Starter, then Next.js.

  2. Give the app a name, set its limits, and choose Deploy.

The starter is a Next.js 16 site without TypeScript, with its package-lock.json, so every first build installs the same packages. Its home page is app/page.js. It becomes the app's first version. To change it, send your own code from GitHub or a ZIP file with Send new code on the app's Code card. The steps below start a project of your own.

Start with create-next-app

For a project of your own, made on your computer, follow these steps.

1. Make the app with create-next-app

You need Node.js 20.9 or newer on your computer. Then, as Next.js's own installation guide shows:

Terminal
npx create-next-app@latest duka-web --yes
cd duka-web
npm run dev

--yes takes Next.js's recommended defaults: TypeScript, Tailwind CSS, ESLint and the App Router. Open http://localhost:3000 to see it.

2. Pin the Node.js version

We offer Node.js 22 and 24. Without a version in your code, we build with the newest. To choose one, add a file called .nvmrc at the top of the project:

text
24

The engines field of package.json works too.

3. Push it to GitHub

create-next-app already made a Git repository and a .gitignore that keeps node_modules, .next and .env* files out. Commit package-lock.json with the rest: it makes every build install the same packages, with npm ci.

Terminal
git add .
git commit -m "First version of duka-web"
git branch -M main
git remote add origin https://github.com/asha/duka-web.git
git push -u origin main

4. Add it as an app

  1. On your project's page, in the Add a service card, choose App.

  2. Give it the App name duka-web.

  3. Under Where's your code?, choose GitHub, then the repository asha/duka-web and the branch main.

  4. Choose Deploy.

The build runs npm ci and npm run build, line by line. The new version starts with npm run start, which is next start, and goes live on its free address, like https://duka-web-7h3k.tanzahost.co, once / answers. Every push to main then deploys by itself, without downtime.

.next/cache can't be written while the app runs

Your app's files, .next included, are read-only once deployed. Whatever Next.js tries to save in .next/cache while it runs, like optimised images, isn't kept, and its log may show errors about it.

Variables and the build

Open the project's Variables tab and choose the app to add settings and secrets. Variables reach the build as well as the app, and that matters for Next.js:

Kind of variableRead whenAfter you change it
NEXT_PUBLIC_…, like NEXT_PUBLIC_SHOP_NAMEDuring the build: Next.js writes it into the pagesChoose Build again on the app's Code card
Anything else, like STRIPE_SECRET_KEYWhile the app runs, on the server onlyRedeploy, no new build needed
Only public values in NEXT_PUBLIC_

A NEXT_PUBLIC_ value ends up in the browser's code, where anyone can read it. Keep secrets in variables without that prefix.

A database, if you need one

Add one in the project's Add a service card: Database, then PostgreSQL, with Add its connection details to duka-web's variables ticked. Your app gets DATABASE_URL, through connection pooling, and DATABASE_DIRECT_URL for migrations. With an ORM such as Prisma, set the app's Before going live command, in Build and run, to its migrate command, like npx prisma migrate deploy, and point its migrations at DATABASE_DIRECT_URL. They then run before visitors see the new version.

What's next

PreviousLaravel starterNextDjango starter