Next.js on Kubernetes
Standalone output, a shared Redis cache and Prisma, ready for more than one pod.
larakube nextjs:newlarakube next:newYou write the Next.js app. LaraKube CLI gives it what it needs to run as more than one pod — a standalone build, a cache every replica shares, a database, a health check — and the Kubernetes manifests to run it on your machine and deploy it to your own cluster.
The Next.js scaffolder is written but has not been run end to end yet: scaffolded, built, run locally, deployed to a real cluster, and re-run with the same result. Try it, but don't promise it to a client until this badge turns green.
🚀 Create a project
larakube nextjs:new storefront
next:new is an alias. LaraKube CLI asks four questions first:
| Choice | Options | With --fast |
|---|---|---|
| Database (through Prisma) | PostgreSQL (recommended), MySQL, MariaDB | PostgreSQL |
| Cache | Redis — always, so every pod shares one ISR and RSC cache | Redis |
| Object storage | None, MinIO (recommended), SeaweedFS, Garage | MinIO |
| Search | None, Meilisearch, Typesense | None |
Then create-next-app runs its own wizard inside a node:24-alpine container, under Docker or Podman — you don't need Node on your machine. TypeScript, the App Router and a root-level app/ directory are fixed, because the steps that follow depend on them; everything else is create-next-app's to ask. Without a terminal, or with --fast, it takes LaraKube CLI's defaults instead: Tailwind, ESLint and the @/* import alias.
Already have a Next.js project?
Run this from its root instead:
larakube init
LaraKube CLI recognises Next.js and makes the same changes a new project gets: standalone output in next.config, the Redis cache handler, Prisma, the /api/health route and the .env connection values. It also joins the Commons unless you pass --no-plex. Add --dry-run to see the list first; the project stays untouched.
🧱 What LaraKube CLI adds
| File | What it does |
|---|---|
next.config.ts | Sets output: 'standalone' and plugs in the cache handler for production builds |
cache-handler.mjs | Keeps the ISR and RSC cache in Redis through @fortedigital/nextjs-cache-handler, so a page rendered by one pod is served by all of them. If Redis is unreachable, Next.js falls back to its own cache instead of failing |
prisma/schema.prisma | Prisma 6, with the datasource for your database (MariaDB uses Prisma's mysql provider) |
app/api/health/route.ts | The endpoint Kubernetes probes to decide the pod is healthy |
Dockerfile.nextjs and .infrastructure/ | The production image and the Kubernetes manifests |
🏘️ Shared services from the Plex Commons
Once the project exists, nextjs:new joins the cluster's Plex Commons: instead of running its own database and Redis, the app gets its own database, login and Redis slot on shared services. DATABASE_URL and REDIS_URL in .env are rebuilt from what was actually allocated.
- Rather keep your own pods? Pass
--no-plex, and the app runs its own database and Redis. - Commons Redis full? All 16 Redis slots can be taken. The app then keeps its own Redis pod and still joins for the database and storage.
💻 Run it locally
cd storefront
larakube up
Your app runs next dev inside the cluster on port 3000, with hot reload, and Kubernetes checks /api/health. Variables the browser needs must start with NEXT_PUBLIC_.
☁️ Deploy
larakube env production
larakube cloud:deploy production
env production adds the environment to your project; cloud:deploy builds the image and ships it. The image is built from Dockerfile.nextjs: the standalone server on node:24-alpine, with prisma migrate deploy running in an init container before new pods take traffic.
➡️ Next
- Cluster Tools and your apps — how your app sits beside Outline, Twenty and the other ready-made tools on the same cluster, sharing the same Commons.
- All frameworks — the other stacks LaraKube CLI scaffolds.