Skip to Content
StatixFlow Next Docs
Deployment & Build

Deployment & Build

Build & run

npm run build # produces a static export in ./out

npm run dev uses Turbopack by default (Next.js 16’s dev-server default). next.config.ts configures a full static export (output: "export", trailingSlash: true, and images: { unoptimized: true } — a static export has no server to run the /_next/image optimizer, so images are emitted as plain <img> tags instead). Because of output: "export", npm run start does not apply here — there is no server build for it to serve. Deploy by serving the generated out/ directory with any static file server.

No environment variables required

There are no required environment variables — nothing reads secrets, API keys, or external config at build or runtime. The one exception is an optional demo NEXT_PUBLIC_GTM_ID analytics variable used by app/layout.tsx, which is stripped out of the marketplace-distributed build. If you add integrations (a CMS, a form-submission backend, analytics), that’s where you’d introduce env vars — there’s no existing convention to follow beyond Next.js’s standard .env.local handling.

Content ships as part of the build

Articles (see Writing Articles) are read from the filesystem at content/articles/{blog,case-studies}/*.mdx at build/request time via fs.readFileSync — not fetched from a remote service. This means:

  • The content/articles/ directory must be present in whatever you deploy — it’s part of the app’s source, not an external dependency.
  • generateStaticParams in app/blog/[slug]/page.tsx and app/case-studies/[slug]/page.tsx pre-renders one static route per .mdx file found at build time. Adding a new article requires a rebuild/redeploy for it to appear as a static route (there’s no ISR/on-demand revalidation configured).

Hosting

Nothing in this template requires a specific host — npm run build produces a fully static out/ directory (no database, no server-only runtime dependencies, no Node server needed at runtime). Upload out/ to any static host or CDN (Vercel, Netlify, GitHub Pages, S3 + CloudFront, etc.), or serve it from a VPS with a static file server like nginx — any of these work equally well.

Switching to a server deployment (non-static)

The template ships as a static export by default — that’s the recommended default, not a hard requirement. If you need a Next.js server (to add API routes, Server Actions, middleware, cookies()/headers(), real /_next/image optimization, or ISR instead of build-time-only article routes), you can opt out:

  1. In next.config.ts, remove output: "export" and trailingSlash: true. You can also drop images: { unoptimized: true } to restore the /_next/image optimizer — that requires a Node runtime rather than a CDN-only static host.
  2. npm run build now produces a server build instead of an out/ directory, so npm run start becomes meaningful again (under static export it’s a no-op, since there’s no server build for it to serve).
  3. None of these Next.js features exist in the shipped codebase today — there’s no app/api/, no middleware.ts, no route.ts handlers, and no ISR/revalidate usage anywhere. Removing static export doesn’t turn on a hidden capability; it just lifts the restriction so you can add them yourself. The most immediate use case is the contact form (components/organisms/forms/contact-form.tsx) and newsletter form (components/organisms/forms/newsletter-form.tsx) — both are UI-only as shipped (no fetch call, preventDefault() only) and need a Route Handler or an external service to actually submit anywhere.
  4. Static-only hosts (GitHub Pages, S3 + CloudFront without a compute layer) no longer work once you remove output: "export". Deploy to Vercel, or any Node-capable host or container that can run next start.

Formatting/linting in CI

If you wire this template into CI, npm run lint runs ESLint (flat config, eslint-config-next core-web-vitals + typescript). There is no test suite configured, so CI has nothing to run beyond lint and build unless you add tests yourself.

Last updated on