Vike: a Vite-based SSR framework with an explicit render-mode config

What Vike solves, and the team it is aimed at

Vike is a rendering layer, not a full application framework. The README describes it as a replacement for Next.js and Nuxt, and the repository topics list server-side rendering, static-site generation, React SSR, Vue SSR and Solid SSR side by side. That combination is the point: the same routing and rendering engine sits under three different UI libraries, and the UI library is chosen by installing a separate package from a separate monorepo (vike-react, vike-vue, vike-solid) rather than by picking a framework fork.

The audience is narrower than the tagline suggests. Vike assumes you already use Vite, and the repository is organized as a Vite plugin monorepo: packages/vike builds the vike package, packages/create-vike-core builds the scaffolder, and docs/ builds the vike.dev website. If your build already runs on webpack or a custom bundler, Vike is not a drop-in; it is a migration. Teams that want a framework to decide routing, data fetching and deployment for them will find Vike gives less than Next.js or Nuxt, not more. Teams that want to keep Vite's plugin ecosystem and control rendering per route are the ones it fits.

How Vike's render modes and hooks actually fit together

The mechanism visible in the repository is a Vite plugin plus a page-level configuration model. The examples directory is the clearest evidence of the shape: examples/render-modes exists as its own example, which means rendering strategy is configured per page rather than set globally for the whole app. Alongside it are examples/react-minimal and examples/vue-minimal, examples/react-full and examples/vue-full, examples/react-streaming, examples/html-fragments, examples/i18n, examples/auth, examples/base-url, examples/base-url-cdn and examples/base-url-server, examples/path-aliases, examples/custom-preload, examples/file-structure-domain-driven, examples/telefunc, and a set of Cloudflare Workers examples for React and Vue.

That list tells you what the framework exposes: base URL handling split between server and CDN, HTML fragment rendering, path aliases, preload control, domain-driven file structure, and a separate integration for server functions (telefunc). Each of those is a page-level or app-level setting rather than a convention baked into a directory name. The trade-off is real. A framework that fixes conventions gives you fewer decisions and less to learn; Vike hands the decisions back, and the examples directory is doing the work that a convention would otherwise do. If you cannot articulate which render mode a given route needs, Vike will not decide for you.

Installing Vike and getting a first page rendering

The README points at vike.dev for what Vike is, and the monorepo ships a scaffolder package, create-vike-core, whose output is published on npm. The repository does not print the exact scaffolder invocation in the README, so the safest path is to start from the published example directories, which are checked into this repository and use the same package names.

The minimal React example is the smallest complete setup. From the repository root, the example's own package.json defines its scripts, and installing its dependencies follows the workspace's pnpm setup:

cd examples/react-minimal
pnpm install

Running the dev server is the standard Vite command for that example, and the output is the Vite dev server banner with the local URL:

pnpm run dev

For a production build, the example builds through Vite, which emits the client and server bundles before the server renders them:

pnpm run build
pnpm run preview

If you would rather scaffold from scratch than copy an example, create-vike-core is the package to look at on npm; the README does not document its flags, so check the package's own page before running it. The repository root's own scripts are for developing Vike itself, not for consuming it: pnpm run dev at the root runs cd packages/vike/ && pnpm run dev, and pnpm run docs serves the vike.dev website from docs/. Do not confuse those with an application setup.

Where Vike is the wrong choice

The clearest limitation is that Vike is not a complete framework, and the README does not pretend otherwise. There is no mention of a built-in data-fetching cache, no image component, no deployment adapter list, and no incremental static regeneration. The examples for server functions go through telefunc, a separate project, which means the server-function story is an integration rather than a core feature.

A second constraint is the version line. The most recent releases listed are v0.4.266 on 2026-09-02, v0.4.265 on 2026-09-02 and v0.4.264 on 2026-08-26. A 0.x version number with frequent patch releases is a signal about API stability, and the README points at packages/vike/CHANGELOG.md for breaking changes rather than promising none. Teams that need a frozen API surface for a multi-year project should read that changelog before committing.

A third case: if your application is a single-page app with no server rendering, Vike's render-mode machinery and SSR examples are overhead. Vite alone, or a lighter router, covers that ground with less configuration. Vike earns its place when server rendering, static generation, or a mix of both per route is the actual requirement.

How Vike differs from Next.js and Nuxt in approach

Next.js and Nuxt are frameworks that own the whole application: file-system routing, data fetching, caching, image optimization and deployment targets are all defined by the framework, and you configure within its model. Vike inverts that. It supplies the rendering engine and the page-level configuration, and it stays out of data fetching, caching and deployment. The README's own framing, that it replaces Next.js and Nuxt, is about the rendering role, not about matching their feature surface.

The practical difference shows up in two places. First, Vike is UI-library agnostic at the core, with vike-react, vike-vue and vike-solid living in separate monorepos, so switching from React to Vue does not mean switching rendering engines. Second, because Vike is a Vite plugin, anything that works as a Vite plugin is available to you, and the examples for Cloudflare Workers show that the deployment target is something you wire up rather than something the framework selects from a list. The cost is that you write more glue. The benefit is that no framework decision is made behind your back.

Maintenance, releases and what the MIT licence means here

The repository is not archived, and the last push was on 2026-09-22. Release cadence in the listed history is frequent: three releases between 2026-08-26 and 2026-09-02 alone. Frequent patch releases on a 0.x line mean upgrades are cheap to apply but the changelog is not optional reading; packages/vike/CHANGELOG.md is where the README sends you for breaking changes.

Licensing is MIT, declared in LICENSE.md at the repository root. That permits commercial use, modification and redistribution provided the copyright notice and permission notice are retained, but it comes with no warranty. This is a description of the licence text, not legal advice; if you redistribute Vike inside a product, have your own counsel read LICENSE.md rather than relying on this summary. Note also that the companion packages live in separate repositories (vikejs/vike-react, vikejs/vike-vue, vikejs/vike-solid), so your dependency and licence review has to cover those too, not just the vike package.

Editorial conclusion

Adopt Vike if you already run Vite and want per-page control over rendering instead of a framework that decides it for you, and start from the examples/react-minimal or examples/vue-minimal directory rather than a blank folder. Do not adopt it if you want a framework that owns your data fetching, cache invalidation and deployment story end to end, because Vike deliberately leaves those to you. Before committing, verify three things against the version you actually install: which render mode each of your routes needs, how your host handles the streaming output that examples/react-streaming produces, and what CHANGELOG.md says about breaking changes between the release you pin and the one you upgrade to.

Frequently asked questions

Official sources

1. License: MIT
2. Project website
3. README
4. Releases
5. vikejs/vike on GitHub