Build, env vars & commando's

Wanneer je een Next.js- of Go-app deployt, wordt je code eerst gebouwd in een container. Deze gids legt uit wat er tijdens een build gebeurt, hoe je npm run build stuurt met pre- en post-build commando's, en hoe je omgevingsvariabelen goed gebruikt.

Niet elk type wordt gebouwd
Statische en PHP-projecten hebben geen build-stap: hun bestanden worden direct geserveerd. De build-instellingen hieronder gelden alleen voor Next.js en Go. Wel voor iedereen relevant: het stuk Omgevingsvariabelen verderop.

Het buildproces, stap voor stap

Bij een deploy van een Next.js- of Go-app gebeurt dit, in deze volgorde:

StapWat er gebeurt
1. OphalenDe branch wordt van GitHub gekloond.
2. HoofdmapEr wordt naar je hoofdmap gegaan (zie hieronder).
3. InstallerenDependencies installeren (npm install / Go-modules).
4. Pre-buildJe pre-build commando draait (optioneel).
5. BouwenDe build zelf — npm run build (Next.js) of compileren (Go).
6. StartenDe container start; je server gaat draaien.
7. Post-buildJe post-build commando draait in de draaiende container (optioneel).

Je vindt en wijzigt deze instellingen op de detailpagina van je app, onder Project Informatie → Build instellingen. Ze staan ook in de laatste stap van de aanmaak-wizard.

Hoofdmap (root directory)

Staat je project in een submap van je repository (bijvoorbeeld een monorepo met een map app/, client/ of frontend/)? Vul dan die submap in als hoofdmap. EduInsights gebruikt die map als startpunt voor het installeren en bouwen.

text
mijn-repo/
├─ app/          ← hoofdmap = "app"
│  ├─ package.json
│  └─ ...
└─ README.md

Laat de hoofdmap leeg als je package.json (of go.mod) in de root van de repo staat.

Pre-build commando

Draait na het installeren, vóór de build (stap 4). Gebruik dit voor code die je build nodig heeft, zoals het genereren van een Prisma-client:

bash
npx prisma generate
Wanneer gebruik je dit?
Altijd als je iets moet genereren voordat npm run build draait. Bij Prisma faalt de build zonder npx prisma generate, omdat de gegenereerde client dan ontbreekt.

Post-build commando

Draait nadat de build klaar is, in de draaiende container (stap 7). De container heeft op dat moment toegang tot je gekoppelde database, dus dit is dé plek voor migraties of seeding:

bash
# Tabellen aanmaken/bijwerken op basis van je Prisma-migraties
npx prisma migrate deploy
bash
# Of: schema direct pushen én testdata inladen
npx prisma db push && npx prisma db seed
Migraties horen in post-build, niet in pre-build
Tijdens de pre-build is er nog geen gegarandeerde database-verbinding — draai migraties dus in post-build. Gebruik prisma migrate deploy (niet migrate dev) op de server: die past alleen bestaande migraties toe en stelt geen vragen.

Omgevingsvariabelen

Onder het tabblad Env (of Omgevingsvariabelen) van je app stel je sleutel/waarde-paren in. Die zijn beschikbaar tijdens de build én als je app draait. Lees ze uit in je code:

ts
// Next.js (server component / route handler / server action)
const apiKey = process.env.MIJN_API_KEY;
php
// PHP
$apiKey = getenv('MIJN_API_KEY');
python
import os
api_key = os.environ["MIJN_API_KEY"]

DB_* komt automatisch

Koppel je een database aan je app, dan worden deze variabelen automatisch ingespoten — je hoeft ze niet zelf toe te voegen:

VariabeleBetekenis
DB_HOSTHostnaam binnen het platform (mysql)
DB_PORTPoort (3306)
DB_NAMENaam van je database
DB_USERGebruikersnaam
DB_PASSWachtwoord

Meer hierover in Verbindingsgegevens.

Zet geheimen nooit in je repo
API-sleutels en wachtwoorden horen in de omgevingsvariabelen, niet in je code of een gepusht bestand. Gebruik je lokaal een .env-bestand? Zet het in je .gitignore. Zie Veiligheid.
Next.js: NEXT_PUBLIC_ wordt in de build gebakken
Variabelen die met NEXT_PUBLIC_ beginnen worden tijdens de build in je JavaScript gezet en zijn zichtbaar in de browser — zet daar dus nooit geheimen in. Pas je zo'n variabele aan? Dan moet je opnieuw deployen zodat de build hem meeneemt. Server-only variabelen (zonder NEXT_PUBLIC_) worden tijdens het draaien gelezen.

Een eigen Dockerfile (gevorderd)

Heb je speciale wensen voor je build? Vul dan een Dockerfile pad in (bijv. Dockerfile of docker/Dockerfile.prod). Laat het veld leeg om de standaard-build te gebruiken — voor de meeste projecten is dat precies goed.

Debug je build lokaal (vóór je deployt)

De snelste manier om een mislukte deploy te voorkomen: draai dezelfde build eerst op je eigen computer. Slaagt hij lokaal, dan slaagt hij bijna altijd ook op EduInsights. Per taal:

Next.js
Draai precies wat EduInsights draait:
bash
npm ci                # schone install, net als op de server
npx prisma generate   # alleen als je Prisma gebruikt (je pre-build commando)
npm run build         # hier komen build-fouten naar boven

Krijg je hier een fout, dan faalt de deploy ook. Los hem lokaal op en push daarna pas.

Go
bash
go build ./...   # compileert alles; faalt bij type- en syntaxfouten
go vet ./...     # vindt veelgemaakte fouten
PHP
PHP heeft geen build-stap, maar je kunt syntaxfouten vooraf opsporen:
bash
php -l index.php       # controleert één bestand op syntaxfouten
php -S localhost:8000  # draai je site lokaal en test hem
Statische site
Er valt niets te bouwen — open je index.html lokaal in de browser en controleer of alle paden (CSS, JS, afbeeldingen) kloppen.
Gebruik dezelfde versies als de server
Bouwt het lokaal wél, maar op de server niet? Vaak verschilt je Node-versie. Controleer met node -v en zet eventueel een "engines"-veld in je package.json. Commit ook je package-lock.json, zodat de server exact dezelfde dependencies installeert.

Logs lezen

Gaat er iets mis, dan zijn de logs je beste vriend. Je vindt ze op de detailpagina van je app:

  • Deployments — elke build/deploy heeft hier zijn eigen logboek, met status en tijdstip. Klik een deploy open om de build-uitvoer te zien (git clone, installeren, pre-build, de build zelf en post-build). Hier zie je waarom een build mislukt.
  • Logs — console-uitvoer van je draaiende server (jouw console.log, errors, enz.).
Eerst de build-uitvoer van de meest recente (mislukte) deploy
Staat je app op Mislukt? Open onder Deployments de bovenste (mislukte) deploy en scroll naar de laatste regels — de echte fout staat meestal onderaan.

Veelvoorkomende fouten

SymptoomOorzaak & oplossing
Build faalt op een ontbrekende Prisma-clientZet npx prisma generate als pre-build commando.
package.json (of go.mod) niet gevondenControleer je hoofdmap — staat je project in een submap?
Databaseverbinding misluktKoppel een database aan je app en controleer dat de DB_* variabelen aanwezig zijn (tabblad Env).
Werkt lokaal, maar niet liveLees waarden via process.env / getenv() in plaats van uit een lokale .env. Pas je een variabele aan? Deploy daarna opnieuw.

Volgende stappen

Meer in Aan de slag