Nextplate: a Next.js and Tailwind starter with the unglamorous parts done

What the template is for

Nextplate is a free starter template built with Next.js and TailwindCSS, providing everything you need to jumpstart your Next project and save valuable time. The project description frames it as saving hours of work, and the topic tags give a fuller picture of the scope: js-boilerplate, nextjs-starter, nextjs-template, nextjs-blog, jamstack, jamstack-theme, static-site, static-site-generator, starter-kit, boilerplate-template and tailwind-css-template.

So it is a content site template rather than an application template. The presence of nextjs-blog and jamstack-theme among the tags, alongside a Pages section listing fifteen pages, tells you what you get: a blog with authors, tags, categories, single post pages, an about page, a contact form, a custom 404, a search page and a privacy policy.

That is a recognisable and widely needed shape, and the argument for a template is that assembling it is tedious in exactly the same way every time. Wiring up the metadata for a blog post, the author page, the tag archive and the category archive so that they all agree with each other and with the sitemap is not interesting work, and doing it from scratch on each project is how days disappear.

The project is by Zeon Studio, and the README says made with love by Zeon Studio and asks for a star if you find it useful. The version badge is on Next.js 16.1.1, the licence is MIT, the primary language is TypeScript, the default branch is main, and the last push was on 2026-07-25. The package manifest is at version 5.8.0, so the template itself has been through a good number of iterations, and there is a live demo at nextplate.netlify.app plus a multilingual demo at nextplate-multilang.netlify.app.

There is a PageSpeed link in the README for the demo, reported at 100 percent, which is the sort of claim a template author has reason to make and a person evaluating it has reason to check.

The Netlify configuration is pre-configured, and there is a `netlify.toml` at the repository root, so deploying to Netlify is a case of connecting the repository rather than working out the build command and publish directory.

The feature list

The key features list is the fastest way to see what the template covers, and there are fifteen entries.

Multi-authors is the first, and it is the one that shapes the data model most. Rather than a single post author, the template has an Authors page and an Author Single page, so a post belongs to one of several author records. Multi-Authors Suggestion, the second entry, is a related feature, and similar posts suggestion is another.

Search functionality and dark mode come next. Then tags and categories, which are separate concepts with separate pages: a Tags index, a Tag Single, a Categories index and a Category Single. Having both is a choice. Many blogs have one taxonomy, and a template that ships both means you can use whichever you need and the routing for both is already consistent.

The support contact form is the next entry, and it comes with a page for it. Fully responsive is listed after that. Then the content workflow: write and update content in Markdown or MDX.

The LLM-ready docs generation is the entry that distinguishes this template from the other dozens of Next.js starters, and it is worth its own section later.

The remaining entries are Disqus comment, syntax highlighting, and multilingual support, or i18n.

The fifteen pre-designed pages then follow as a list: Homepage, About, Contact, Authors, Author Single, Blog, Blog Single, Custom 404, Elements, Privacy Policy, Tags, Tag Single, Categories, Category Single and Search.

The Elements page is the one that is specific to templates rather than to sites. It exists to show the component library, which is how a template lets you evaluate the visual result before committing to it. The Custom 404 is listed as a design element, which is a small sign of the care taken.

The dependencies in the manifest explain several of the features. `disqus-react` is the Disqus comment integration, `marked` and `next-mdx-remote` are the Markdown and MDX rendering, `next-themes` is the dark mode implementation, `remark-gfm` and `rehype-slug` handle GitHub-flavoured Markdown and heading anchors, `swiper` is the carousel library, `lite-youtube` and `@next/third-parties` are for embedded third-party content, `date-fns` for dates, `gray-matter` for frontmatter parsing and `github-slugger` for slug generation. And `react-gtm-module` is the Google Tag Manager integration, with a `next-sitemap` for the sitemap.

The LLM file generation, and its configuration

After the build, this project can generate LLM-friendly files from its built HTML. The outputs are `llms.txt`, an index of pages, `llms-full.txt`, the full combined content, and optional per-page Markdown files.

This is the feature that makes the template interesting rather than merely competent. The idea is that a site can publish a machine-readable version of itself alongside the human-readable one, so a tool that fetches the site can get a compact index or a full text dump without parsing the HTML.

There are two ways to run it. It is included in the build:

# included in build
npm run build

# or run manually after build
npm run generate-llms

The package manifest shows where it actually runs. The build script chains the theme generator, the JSON generator and `next build`, and there is a `postbuild` script that runs `next-sitemap` and then `node scripts/llmsGenerator.mjs`. So the sitemap and the LLM files are produced after the build, from the built output, which is the right place to do it.

The configuration lives in `src/config/config.json` under an `llms` key, and there are five settings. `generate_llms_txt` creates `llms.txt`. `generate_llms_full_txt` creates `llms-full.txt`. `generate_individual_md` creates individual `.md` files. And `include` and `exclude` select routes or globs, with empty meaning all.

The include and exclude behaviour has a rule worth stating exactly, because it is the kind of thing that produces surprises otherwise: `include` overrides `exclude`, so you use `exclude` to remove broad sections and `include` to add back specific pages.

The pattern syntax is glob-like, with four forms. `/blog` matches the exact `/blog` path. `/blog/` matches `/blog` and everything under it. `/blog/*` matches one segment under `/blog/`, for example `/blog/post-1`. And `/blog/**` matches any depth under `/blog/`.

So the examples read like a progression in specificity. Exclude all blog pages and add back only single posts:

"llms": {
  "exclude": ["/blog/"],
  "include": ["/blog/*"]
}

Or exclude everything and whitelist only the authors and blog singles:

"llms": {
  "exclude": ["/"],
  "include": ["/authors", "/authors/*", "/blog/*"]
}

The second example is the one that shows the design working. Excluding `/` removes the whole tree, and the include list then adds back exactly the pages you want, which is a whitelist expressed as an exclude plus a small include. That pattern is easier to maintain than a long include list, because adding a new top-level section to the site does not silently start appearing in the output.

Getting it running, and the Docker path

The dependency requirements are specific: next 16.1 or newer, node v22.10 or newer, npm v10.2 or newer and tailwind v4.0 or newer.

The three commands are the standard ones:

npm install

npm run dev

npm run build

But the package manifest shows that the dev script is not just `next dev`. It is `concurrently "node scripts/themeGenerator.mjs --watch" "node scripts/jsonGenerator.mjs && next dev"`, and the build script is `node scripts/themeGenerator.mjs && node scripts/jsonGenerator.mjs && next build`.

So there are two generator scripts that run before the framework does anything. The theme generator has a watch mode in development and a one-shot run in the build, which suggests it derives theme values from somewhere and writes them out. The JSON generator runs before the dev server and before the build in both cases, which suggests it derives data from the content, and the fact that it runs in both is because the development server and the production build both need it.

That is the kind of detail a template README rarely explains and a user always wants to know: the generators are part of the build contract, not optional extras. And the `remove-darkmode` script, which runs the removal script and then formats the source, shows the template supports being trimmed rather than only extended, which matters if you are building something that does not need the dark mode.

There is a Dockerfile for a containerised run:

docker build -t nextplate .
docker run -p 3000:3000 nextplate

The Dockerfile itself is a careful piece of work. It starts from a node alpine base, enables corepack so pnpm is available, and splits into stages: a deps stage that installs only dependencies, a builder stage that copies the node_modules and the source and builds, and a runner stage that carries the output. The deps stage copies the lockfiles first and installs with a frozen lockfile, so a source change does not invalidate the dependency layer.

The runner stage creates a system user and group with uid 1001 and copies the built output with the correct ownership, and the build stage has the Next.js telemetry disable line present but commented out, so a user who cares can uncomment it in either the build or the runtime stage. The comment about output file tracing points at the advanced feature that reduces image size by copying only the files actually needed at runtime.

The `pnpm-lock.yaml` and `pnpm-workspace.yaml` are present, and the manifest declares pnpm 11.5.1 as the package manager, which is consistent with the Dockerfile preferring pnpm while the README documenting npm.

The CMS option, the repository, and the licensing caveat

The template comes pre-configured with Sitepins, a Git-based Headless CMS designed for seamless content management, and you can update your site's text, images and configuration without touching a single line of code. The instruction is to click the Edit with Sitepins button and follow the on-screen instructions.

That is a deliberate addition to a template that already supports Markdown and MDX files. The distinction is worth understanding: a Git-based headless CMS still stores the content in the repository, so the content stays in version control and in the same workflow as the code, but the editing surface is a visual editor rather than a text editor. For a non-technical editor on a team, that is a meaningful difference, and it is the reason the `.sitepins/` directory is in the repository root.

The repository root shows a template that has been worked on. There is an `AGENTS.md` and a `CLAUDE.md` for the working conventions, an `eslint.config.mjs`, a `.markdownlint.json` for the Markdown content, a `next-sitemap.config.js` and `next.config.mjs`, a `postcss.config.mjs` for Tailwind, a `scripts/` directory holding the generator scripts, a `src/` directory with the application, and a `public/` directory with the static assets. There is a `.dockerignore`, an `.editorconfig`, a `.vscode/` directory and a `skills-lock.json`.

The licence section is where the honesty is, and it is worth reading fully. The code is released under MIT, copyright Zeon Studio. But the images are only for demonstration purposes, they have their own licence, and the authors do not have permission to share those images.

That last clause matters more than it looks. A template's images are usually its most visible contribution and the part you would most like to reuse, and this template is explicit that the pictures are off limits. So the practical position is that the code is yours to build on and the pictures are placeholders you replace.

The final section is a pointer to commercial work: if you need a custom theme, theme customization, or complete website development services from scratch, the answer is to hire the studio that made the template. That is a reasonable thing for a template from a studio to say, and it also tells you the template is positioned as the free entry point to a paid offering rather than as a finished product.

Editorial conclusion

Adopt Nextplate if you are starting a content site on Next.js and want the standard pages, metadata handling and content pipeline already wired, since that is what the template provides. Do not expect it to be a finished design, since it is explicitly a starter with demonstration content and images whose licence the authors do not hold, and check first whether the LLM file generation suits your deployment, because it runs on every build and writes output into the site.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. Project website
4. README
5. zeon-studio/nextplate on GitHub