nextjs-starter is a lite Next.js 16 template with i18n already wired

A lite cut of a commercial boilerplate, not the full product

The repository describes itself as the lite version of the Nexty.dev SaaS boilerplate, a multilingual Next.js 16 starter with built-in i18n support, and it points readers who want the full-featured version to nexty.dev. That framing matters for anyone deciding what to base a product on. What sits in the tree is a working application skeleton: App Router pages, a blog, an about page, components, translations, a content directory and a set of configuration files. What it does not contain is the commercial package's feature list, because that product lives elsewhere. The homepage field points to nextjsstarter.io, described in the documentation as a live demo, and the repository carries separate README files in English, Simplified Chinese and Japanese. The primary language of the code is TypeScript, and the topics listed for the repository mention app-router, i18n, multilingual, nextjs, nextjs15, shadcn-ui and tailwindcss, which is a fair description of what you get and also a reminder that the project has moved across Next.js major versions before.

Locale routing runs through middleware and a shared Link

The i18n setup is the part of this template that carries the most engineering, and it is worth understanding before you start. Pages live under app/[locale]/, translation files sit in i18n/messages/, and the supported languages are declared in i18n/routing.ts. Routing is set up in middleware.ts, and the documentation instructs you to use the Link component exported from i18n/routing.ts rather than the default Next.js one, so that locale prefixes are applied consistently. Components read strings through the useTranslations hook from next-intl, with a namespace argument:

import { useTranslations } from 'next-intl';

export default function MyComponent() {
  const t = useTranslations('namespace');
  return <h1>{t('title')}</h1>;
}

Adding a fourth language means adding message files in i18n/messages/, updating i18n/routing.ts, and creating matching directories under blog/ and content/. That last requirement is the one teams forget: the message catalogue and the per-locale content directories are separate, and a missing folder produces empty pages rather than an error. The i18n directory also holds a request.ts file, which is where request scoped configuration lives alongside the routing definition.

Blog posts and static pages are MDX files with a fixed frontmatter shape

Content is not stored in a database or fetched through a CMS. Blog posts are MDX files placed under blog/[locale], with language subdirectories such as en, ja and zh in the tree, and each file carries a frontmatter block:

---
title: Post Title
description: Post Description
image: /image.png
slug: /url-path
tags: tag1,tag2
date: 2025-02-20
visible: published
pin: true
---

Post content...

The visible field decides whether a post is published, and pin marks it to be featured, so hiding an article is a metadata edit rather than a file move. The field list is documented as types/blog.ts, which is the place to look when you need to know what the loader accepts. Static pages follow a different convention: they are managed as content/[page]/[locale].mdx, so a page name and a locale make the path. Two directories in the repository, blogs/ and blog/, appear in the tree at the same time, and the documentation refers to blog/ as the location for posts. If your posts do not appear, that mismatch between the two directory names is the first thing to check, and the troubleshooting section for missing MDX output points at the file path and the visible field for the same reason.

Cloning, enabling pnpm, and starting the dev server

The setup path is short and worth following exactly, because the project pins its tooling. The prerequisites are Node.js 20.9 or higher and pnpm 9.0 or higher, with pnpm recommended since the packageManager field is configured in package.json. Clone and enter the directory:

git clone https://github.com/weijunext/nextjs-starter.git
cd nextjs-starter

Then enable Corepack so the pinned pnpm version is used:

corepack enable

Install dependencies, and copy the environment template:

pnpm install
cp .env.example .env

The documentation notes that npm install and yarn also work, though the team guidance is that everyone should use the same pnpm version, since the lockfile is pnpm-lock.yaml. Start the development server:

pnpm dev

The site then answers on http://localhost:3000. For a production build on a platform other than Vercel, the same two commands apply:

pnpm build
pnpm start

The package.json scripts map dev to next dev, build to next build and start to next start, so the npm script names match the framework's own.

Configuration is spread across config/site.ts, the env file and the analytics IDs

There is no single config screen, and a reader coming from the full Nexty.dev product may expect one. The documented touchpoints are individual files. Site name and description live in config/site.ts, icons and the logo go in public/, the sitemap is configured in app/sitemap.ts and robots.txt in app/robots.ts. Analytics and advertising are driven by environment variables, and the documentation lists three of them:

NEXT_PUBLIC_GOOGLE_ANALYTICS=
NEXT_PUBLIC_BAIDU_TONGJI=
NEXT_PUBLIC_GOOGLE_ADSENSE=

The .env.example file shipped in the repository uses different names for the same kind of setting, with NEXT_PUBLIC_GOOGLE_ID, NEXT_PUBLIC_BAIDU_TONGJI, NEXT_PUBLIC_PLAUSIBLE_DOMAIN, NEXT_PUBLIC_PLAUSIBLE_SRC and NEXT_PUBLIC_GOOGLE_ADSENSE_ID, plus site settings such as NEXT_PUBLIC_SITE_URL, NEXT_PUBLIC_LOCALE_DETECTION and NEXT_PUBLIC_OPTIMIZED_IMAGES. The documentation also says analytics tools include Google Analytics, Baidu Analytics, Google Adsense and Vercel Analytics, and the dependency list contains @vercel/analytics. The mismatch between the two lists of variable names is a real trap: copy the example file and fill in the names it actually contains rather than the names printed in the guide. Email is configured separately, with EMAIL_PROVIDER set to resend or cloudflare and a RESEND_API_KEY entry for the Resend path.

Upgrade paths are scripted, but there are no GitHub releases

The repository is not archived and the last push was on 2026-08-08, but there are no GitHub releases, so a version number in package.json is the only marker you get, and it currently reads 2.2.0. That version is a template version rather than a published artifact, and it says nothing about compatibility with the Next.js version you install. The template does, however, provide two maintenance scripts worth knowing about. One is named update:next and it installs the latest next, react, react-dom, @next/env, @next/bundle-analyzer and the matching React type packages. The other is named fix and it installs and runs fix-react2shell-next, which addresses a React Server Components vulnerability. That fix script is also the reason fix-react2shell-next appears in the dependency list rather than only as a script. Because there is no release channel, upgrading means pulling main and running those scripts yourself, then verifying that the three-language routing still resolves and that your MDX posts still parse. The documentation also lists pnpm lint and pnpm type-check as the quality commands to run before shipping.

Where this template stops and what the alternative costs

The honest limits are visible in the dependency list and the folder names. The template ships more service integrations than a minimal app needs: axios, resend with @react-email/render for building emails, @upstash/redis with @upstash/ratelimit for rate limiting, winston with winston-daily-rotate-file for logging, and zod for validation. Every one of those is a decision you inherit and a key you have to provision before the code paths that use them matter. The repository also carries top level folders for emails/, actions/, hooks/, stores/ and log/, so the starter is closer to an application skeleton than a set of examples. The real alternative is to assemble the same stack yourself: create a Next.js App Router project, add next-intl and wire middleware.ts and i18n/routing.ts, add Tailwind and shadcn/ui, then decide on a content approach. That route takes longer up front and gives you no content conventions, no visible and pin frontmatter semantics and no analytics variable set to reason about. This template wins when you want those decisions already made, and it costs you when the default choices, such as English, Chinese and Japanese as the locale set, or MDX files on disk rather than a CMS, are not the ones you would have picked.

Editorial conclusion

Adopt nextjs-starter when you want a Next.js 16 App Router application that already handles locale routing, MDX content and analytics wiring, and you are prepared to delete the parts you do not use. Do not adopt it expecting the paid Nexty.dev feature set or a maintained framework, since this repository has no GitHub releases and the last push was on 2026-08-08. Verify first that your Node runtime matches the engines field of 20.x, that the packageManager pin of [email protected] matches what your team uses, and that the analytics variable names in the documentation match the ones in .env.example, because they differ.

Frequently asked questions

Official sources

1. Issues
2. Project website
3. README
4. weijunext/nextjs-starter on GitHub