vercel/examples: a monorepo of deployable Next.js and edge patterns

What vercel/examples actually is, and who it is for

This repository is a catalogue, not a framework. The README describes it as a curated collection of examples and solutions, split into categories such as Solutions for demos and reference architecture, and Starter for applications that can act as a starting point. The top-level directories map onto that idea directly: app-directory, edge-middleware, storage, ci-cd, container-images, microfrontends, framework-boilerplates, and language-specific folders for go, python and rust.

The audience is narrow and specific. You are building on Vercel, most likely with Next.js, and you want a working reference for a pattern that is tedious to assemble from documentation alone: bot protection at the edge, a monorepo with Turborepo, an app directory layout, a storage integration. The MIT licence on the root package.json means you can lift code into your own project without a licensing conversation.

If you are evaluating Vercel as a platform without committing to it, this repository is also the cheapest way to see what the platform expects from your code. Each example is small, deployable, and readable in one sitting. That is a different job from choosing a general-purpose starter template, and the repository does not pretend otherwise.

How the monorepo is organised and how a single example runs

The root package.json is private and marked as such, which tells you the repository itself is never published as a package. Its scripts are tooling for contributors: new-example calls plop, prepare installs Husky, prettier rewrites the tree, and lint-staged runs Prettier plus ESLint over staged TypeScript files with max-warnings set to 0. The engines field pins node 22.x and pnpm 9.13.0, and packageManager repeats [email protected], so the intended workflow is pnpm rather than npm or yarn.

Each example is its own project with its own package.json and README. That is the important architectural fact: there is no shared runtime, no root-level server, and no build that compiles everything together. When you clone the repository you get dozens of independent applications side by side. Running one means changing into its directory and installing there, not at the root. The only shared code path is @vercel/examples-ui, the layout and styling package that the README says all Next.js examples should use, and it is consumed as a normal dependency by each example rather than through a workspace link that the root file declares.

Contributions follow the same shape. The README lists what a new example must contain: a .gitignore, a package.json with an MIT licence, a README with a demo URL and an .env.example when environment variables are needed, and an .eslintrc.json for Next.js examples. Front matter metadata at the top of a README is what promotes an example into a Vercel template, with the allowed fields defined in internal/fields.json.

Installing the repository and running one example

There is no package to install globally. You clone the repository and work inside one example folder. The root install exists so the contributor tooling works, and the README gives it as two commands.

pnpm i
pnpm new-example

The first installs the root devDependencies (eslint, husky, lint-staged, plop, prettier, typescript) and triggers the prepare script, which runs husky install. The second scaffolds a new example from the plop templates; it is not how you run an existing one. If Husky fails to configure itself during install, the README gives a single recovery command.

pnpm run prepare

To actually run something, pick a folder such as edge-middleware/bot-protection-datadome, read its README first, and follow the steps it documents. That README is where environment variables are described; the repository convention is that an example needing them ships a .env.example file. The root README does not list per-example start commands, so do not assume a single command works across folders.

cd edge-middleware/bot-protection-datadome
pnpm i

When you commit, lint-staged runs Prettier on JSON, Markdown, CSS, HTML, YAML and SCSS files, and Prettier plus ESLint on staged TypeScript files. The README asks contributors not to skip these steps unless they are broken, in which case it asks for an issue rather than a bypass.

The published package and what it does not cover

Only one artefact from this repository ships to a registry: @vercel/examples-ui. Its release history is the clearest signal about the project's own maintenance rhythm. Version 2.0.4 was released on 2025-12-12, and before that the previous releases listed are 2.0.3 on 2023-08-23 and 2.0.1 on 2023-07-17. That is a two-year gap between published versions, which is worth knowing if you plan to depend on the package for layout rather than copying files.

The package is a presentation layer. The README says all Next.js examples should use the same styling and layout provided by it, and points at the plop template as the usage reference. It does not provide routing, data fetching, authentication or deployment logic. Everything that makes an example interesting lives in the example folder itself.

This split matters when you decide how to consume the repository. Copying a folder gives you code you own and can edit freely under MIT. Depending on @vercel/examples-ui gives you a small external package with an irregular release cadence. For most readers the first option is the one that matches what the repository is for.

Where vercel/examples is the wrong tool

The repository does not document rollback, migration paths or upgrade procedures for the examples themselves, and there is no changelog at the root that tracks breaking changes across folders. If you fork an example and the underlying framework moves, you are the maintainer of that fork. Nothing in the README suggests otherwise.

A second limitation is version drift inside the tree. The root package.json pins node 22.x and pnpm 9.13.0, and it carries devDependencies pinned to ranges rather than exact versions, including eslint-config-next set to canary. Individual examples may have been written against older Next.js releases and may not have been revisited since. The README's contribution rules describe what new examples must look like, not a process that keeps every existing example current.

Finally, this is a Vercel-shaped collection. The examples assume Vercel deployment, Vercel environment variables, and in several cases Vercel-specific products. If you are deploying the same Next.js application to a self-managed container platform, some folders will translate and others will not. The ci-cd and container-images directories exist precisely because those cases need different plumbing, and they are the ones to read first if you are outside the default path.

How it compares with create-next-app and framework boilerplates

create-next-app generates one project from a fixed template and leaves you to add the interesting parts. vercel/examples does the opposite: it gives you many finished parts and no generator for the whole. If you already know you need edge middleware with bot protection, the relevant example saves you from writing that middleware and its configuration from scratch. If you just need a blank Next.js project, create-next-app is faster and produces less to delete.

The framework-boilerplates directory is the middle ground, and it is worth understanding before you pick. Boilerplates are minimal framework setups, closer in spirit to create-next-app but living inside this repository's conventions. Starter projects are functional applications you can build on. Solutions are demos and reference architecture, which the README frames as best practices rather than starting points. Choosing the wrong category is the most common way to end up with either too much scaffolding or too little.

Licence and the cost of keeping a copied example current

The root package.json declares MIT, and the README requires new examples to use the MIT licence as well. That is permissive: you can copy an example into a commercial codebase, modify it, and ship it, provided you keep the licence notice. This is a description of what the files say, not legal advice, and you should confirm the licence on the specific example folder you copy rather than assuming the root applies unchanged.

The ongoing cost is maintenance you inherit. A copied example is a snapshot. When Next.js changes a routing convention or an API route signature, the example in the repository may be updated while your copy is not, or the example may sit untouched while your dependencies move. Because the repository publishes no root changelog, tracking that drift means watching the folder you copied from. There is no upgrade command, no codemod, and no version matrix that tells you which examples target which Next.js release. Budget for reading the diff yourself.

Editorial conclusion

Adopt vercel/examples if you are starting a Next.js or edge project on Vercel and want a working reference for routing, middleware, storage or CI/CD rather than a blank directory. Do not adopt it as a dependency, and do not expect a maintained library: the only published artefact, @vercel/examples-ui, last shipped as 2.0.4 on 2025-12-12 after a gap from 2023. Before copying anything, open the README inside the specific example folder and confirm it still matches the Next.js and Node versions you run, since the root package.json pins node 22.x and pnpm 9.13.0.

Frequently asked questions

Official sources

1. Issues
2. License: MIT
3. README
4. Releases
5. vercel/examples on GitHub