PluginBench
Skill
Review
Audit score 70

netlify-frameworks

netlify/context-and-tools

Deploy and configure web frameworks on Netlify with SSR adapters, build settings, and local platform emulation.

What is netlify-frameworks?

Handles framework-specific deployment setup on Netlify across 15+ frameworks (Next.js, Astro, Nuxt, SvelteKit, Remix, React Router, and more). Use this when configuring builds, adding SSR or edge functions, fixing SPA redirects, managing environment variables, or debugging deployment failures.

  • Deploy 15+ frameworks (Next.js, Astro, Nuxt, SvelteKit, Remix, React Router, TanStack Start, SolidStart, Gatsby, Angular, Vite, Express, Hydrogen, Hugo, Eleventy, Vue, React) with correct build commands and publish directories
  • Install and configure framework-specific SSR and edge function adapters
  • Emulate Netlify platform features locally (functions, edge functions, blobs, database, cache, image CDN, redirects, env vars) without Netlify CLI for Vite-based frameworks
  • Manage environment variables with correct scoping (build-time vs runtime, client vs server prefixes) and handle redeploy requirements
  • Fix SPA catch-all redirect conflicts and configure proper rewrite rules for server-rendered apps
  • Debug build failures and environment variable propagation issues

How to install netlify-frameworks

npx skills add https://github.com/netlify/context-and-tools --skill netlify-frameworks
Prerequisites
  • Netlify account and project
  • Framework already installed locally (Next.js, Astro, Nuxt, SvelteKit, Remix, React Router, etc.)
  • For local platform emulation: Vite-based framework or Netlify CLI installed
Claude Code
Cursor
Windsurf
Cline

How to use netlify-frameworks

  1. 1.Identify your framework in the build settings table and note the correct build command and publish directory
  2. 2.Install the framework-specific adapter if using SSR (e.g., `npx astro add netlify` for Astro, `npm install @sveltejs/adapter-netlify` for SvelteKit)
  3. 3.Configure environment variables with correct prefixes (never use client prefixes for secrets) and set appropriate scopes (Builds, Functions, or both)
  4. 4.Remove any SPA catch-all redirects (`/* /index.html 200`) if adopting SSR
  5. 5.For local development, use the framework's dev command with Vite plugin (e.g., `astro dev`, `nuxt dev`) or `netlify dev` for non-Vite frameworks
  6. 6.Update `netlify.toml` with build command, publish directory, and any custom environment or redirect rules
  7. 7.Redeploy after any environment variable changes to ensure they propagate to the live site

Use cases

Good for
  • Setting up a new Next.js or Astro deployment on Netlify with SSR enabled
  • Converting a static SPA (React, Vue) to server-side rendering and removing conflicting catch-all rules
  • Configuring environment variables that work correctly across build and runtime contexts
  • Debugging why an env var change isn't reflected on the live site (requires redeploy)
  • Adding edge functions or middleware to a framework deployment
Who it's for
  • Full-stack developers deploying web frameworks to Netlify
  • DevOps engineers configuring build pipelines and environment management
  • Frontend developers migrating from static to server-rendered deployments
  • Teams using Next.js, Astro, Nuxt, SvelteKit, Remix, or other modern frameworks

netlify-frameworks FAQ

Why isn't my environment variable showing up on the live site after I changed it?

Environment variables are injected at build time. Changing a var in the UI or CLI does not update the live site — you must trigger a new deploy/build for the change to take effect.

Can I use client-prefixed environment variables (NEXT_PUBLIC_, VITE_, etc.) for secrets?

No. Client-prefixed variables are inlined into the browser bundle and visible to users. Never use them for secrets; use server-side variables instead and access them only in server functions or SSR code.

What's the difference between `netlify dev` and running my framework's dev command directly?

Framework dev commands (with Vite plugins) emulate Netlify features locally for most modern frameworks. `netlify dev` is needed for Gatsby (after `netlify build`), Angular SSR, and frameworks without Vite plugins. If you set both a custom `command` and `targetPort` in `[dev]`, you must set `framework = "#custom"` to avoid the detector silently ignoring your command.

I have a static SPA with a catch-all redirect rule. Can I add SSR without changes?

No. Remove the `/* /index.html 200` catch-all rule before adopting an SSR adapter. A leftover catch-all silently serves static `index.html` for SSR pages and API routes, breaking your server-rendered content.

Which frameworks need a Netlify adapter for SSR?

Astro, Next.js, SvelteKit, Remix, and Nuxt all have Netlify adapters. React Router and SolidStart 2 use the `@netlify/vite-plugin`. Others like Gatsby and Hydrogen have framework-specific setup. Check the SSR/adapter setup section for your framework.

Full instructions (SKILL.md)

Source of truth, from netlify/context-and-tools.


name: netlify-frameworks description: Deploy and configure web frameworks on Netlify — build settings and SSR/edge adapters plus local platform emulation and env vars. Use when setting up or fixing a framework deploy (Next.js / Astro / Nuxt / SvelteKit / Remix / React Router / TanStack Start / SolidStart / Gatsby / Angular / Vite / Express / Hydrogen / Hugo / Eleventy / Vue / React), adding SSR or edge functions or middleware wired to Netlify context, fixing SPA redirect and catch-all rules, setting a build command or publish directory, or debugging "why isn't my env var updating" and framework build failures.

Route framework-specific deep work to the guides in this skill: references/astro.md, references/nextjs.md, references/nuxt.md, references/sveltekit.md, references/tanstack.md, references/vite.md.

Env vars: modern rules (read first)

Env values are injected at build time. Any change (client- or server-side) requires a redeploy — editing a var in the UI/CLI does NOT reach the live site or already-deployed functions until a new build runs.

Never use a client prefix for secrets. Client-prefixed vars are inlined into the browser bundle: VITE_, NEXT_PUBLIC_, PUBLIC_, NUXT_PUBLIC_, REACT_APP_, GATSBY_, VUE_APP_.

Client-embed prefixes by framework: CRA REACT_APP_, Gatsby GATSBY_, Next NEXT_PUBLIC_, Nuxt NUXT_ENV_, Vue CLI VUE_APP_.

Scopes: build-time access needs Builds scope; SSR/DSG runtime access needs both Functions and Builds. netlify.toml is read only during build — functions cannot read it at runtime; set runtime vars in UI/CLI/API.

Netlify build variables can't be used as values in the UI or netlify.toml env sections. Set them inline before the build command:

[build]
  command = "REACT_APP_CONTEXT=$CONTEXT npm run build"

SPA redirects and the SSR catch-all footgun

SPAs (React, Vue CLI, Vite, Nuxt in SPA mode) need a rewrite to serve index.html for pushState:

/* /index.html 200

Remove any SPA catch-all when adopting an SSR adapter. A leftover /* → /index.html 200 silently serves static index.html for SSR pages and API routes — user redirects beat adapter-generated routes.

Local dev with platform emulation (no Netlify CLI)

Vite-based frameworks emulate Netlify primitives (functions, edge functions, blobs, Netlify Database, Cache API, Image CDN, redirects/rewrites, headers, env vars, AI Gateway) in the dev server:

FrameworkPlugin/moduleRun
Astro (5.12+)built-in (Netlify Vite plugin auto-loaded)astro dev
Nuxt@netlify/nuxtnuxt dev
React Router@netlify/vite-pluginreact-router dev
SolidStart 2@netlify/vite-pluginvite dev
TanStack Start@netlify/vite-plugin-tanstack-start(vite)
Vite@netlify/vite-pluginnpx vite

Still need netlify dev (Netlify CLI) for: Gatsby generated functions (run netlify build first), Angular SSR local test (netlify serve), and frameworks without a Vite plugin.

netlify dev gotcha: with both a custom command and a targetPort in [dev], you must set framework = "#custom" — otherwise the detector runs and your custom command is silently ignored.

Build settings by framework

FrameworkBuild commandPublish
Angular (standard)ng build --proddist/YOUR_PROJECT_NAME
Astroastro builddist
Create React Appreact-scripts buildbuild
Eleventyeleventy_site
Gatsbygatsby buildpublic
Hugohugopublic
Hydrogenremix vite:builddist/client
Next.js (SSR/hybrid)next build.next
Next.js (static export)next build && next exportout (NETLIFY_NEXT_PLUGIN_SKIP=true)
Nuxt 3nuxt builddist
Nuxt 2nuxt generatedist
React Routerreact-router buildbuild/client
Remix (Vite)remix vite:buildbuild/client
SolidStart 2 (Vite plugin)vite builddist/client
SolidStart 2 (Nitro)vite builddist
SolidStart 1.xvinxi builddist
SvelteKitvite buildbuild
TanStack Start (1.132.0+)vite builddist/client
Vitevite builddist
Vue CLIvue-cli-service builddist

Detection suggests these; override in netlify.toml or UI (project configuration > Build & deploy > Continuous deployment > Build settings).

SSR / adapter setup

Astro

npx astro add netlify installs the adapter and edits astro.config.mjs. Adapter needed for SSR and out-of-the-box Image CDN for <Image />. SSR → Netlify Functions; middleware → Edge Functions. Adapter-less deploy only if no server features and no Image CDN need. Skew protection from 5.15.0.

Next.js (13.5+ only)

Zero-config via the OpenNext adapter (@netlify/plugin-nextjs). Do NOT pin the version — Netlify auto-updates each build. Treat the legacy adapter as read-only history, never a recommendation. Adapter provisions: serverless function for SSR/ISR/PPR/route handlers/Server Actions; Edge Function for Middleware; Full Route + Data Cache; Image CDN with next/image. Skew protection is opt-in: set NETLIFY_NEXT_SKEW_PROTECTION=true, redeploy. No automatic support for client fetch — direct calls with x-deployment-id: process.env.NEXT_DEPLOYMENT_ID. Details in references/nextjs.md.

SvelteKit

npm install -D @sveltejs/adapter-netlify
import adapter from '@sveltejs/adapter-netlify';
export default { kit: { adapter: adapter() } };

Replace @sveltejs/adapter-auto with the specific import. SSR routes → a render function.

  • split: true → one function per route. Incompatible with Edge Functions (edge: false or omit).
  • edge: true → SSR in a Deno edge function; can't combine with split.
  • Redirects NOT supported in netlify.toml — use _redirects.
  • Edge functions don't work locally with netlify dev for SvelteKit.

React Router (7+)

New: npx create-react-router@latest --template netlify/react-router-template. Existing:

npm install @netlify/vite-plugin-react-router

Add netlifyReactRouter() to Vite plugins. Default target = Serverless Functions. Edge (Deno): needs plugin v2.1.1+, set edge: true, and you must create app/entry.server.tsx:

export { default } from 'virtual:netlify-server-entry'

Exclude your own function paths: netlifyReactRouter({ edge: true, excludedPaths: ['/api/*'] }). Moving back to Serverless: remove edge: true AND delete app/entry.server.tsx. Middleware (React Router v7.9.0+, plugin v2.0.0+): opt in via future.v8_middleware; import netlifyRouterContext from @netlify/vite-plugin-react-router/serverless (or /edge when edge: true); access context.get(netlifyRouterContext).

Remix

New: npx create-remix@latest --template netlify/remix-template (CLI prompts functions vs Edge Functions). Manual (Remix Vite required):

npm install --save-dev @netlify/remix-adapter

Add netlifyPlugin() from @netlify/remix-adapter/plugin to Vite plugins.

Nuxt

SSR via Nitro, automatic on Nuxt 3. Local parity via @netlify/nuxt (npx nuxi module add @netlify/nuxt).

  • SSR on Edge Functions requires a different Nitro deployment preset (not auto-detected).
  • pnpm + Nuxt 3: set PNPM_FLAGS=--shamefully-hoist.
  • nuxt/image auto-uses Netlify Image CDN; set remote domains in nuxt.config.ts.

SolidStart

SolidStart 2 builds on Vite — no SolidStart-specific adapter. Install @netlify/vite-plugin:

import netlify from "@netlify/vite-plugin";
import { solidStart } from "@solidjs/start/config";
import { defineConfig } from "vite";
export default defineConfig({
  plugins: [solidStart(), netlify({ build: { enabled: true } })],
});

Publish dist/client. SSR routes, server functions, middleware → Netlify Functions, zero extra config. Nitro alternative: add nitro(), use plain netlify() (no build.enabled), publish dist. SolidStart 1: Nitro auto-configures; optionally set preset: "netlify" in app.config.ts; vinxi build / dist.

TanStack Start

React (and Solid.js) full-stack; SSR/Server Routes/Server Functions/middleware → serverless functions.

npm install -D @netlify/vite-plugin-tanstack-start

Add netlify() to Vite plugins alongside tanstackStart(); vite build / dist/client (1.132.0+). Netlify CLI deploys require netlify-cli 17.31+. Older versions: see references/tanstack.md.

Gatsby

  • 5.12.0+ (adapter): auto-detects and installs gatsby-adapter-netlify (zero-config). Generates functions SSR, DSG. No Essential Gatsby plugin needed.
  • 5.11.0 or earlier (Essential Gatsby plugin): auto-installs @netlify/plugin-gatsby; also manually install gatsby-plugin-netlify (required for SSR, Gatsby redirects, asset caching). Generates __api, __ssr, __dsg, __ipx. Skip via NETLIFY_SKIP_GATSBY_FUNCTIONS (all) / NETLIFY_SKIP_API_FUNCTION / NETLIFY_SKIP_SSR_FUNCTION / NETLIFY_SKIP_DSG_FUNCTION.
  • Gatsby 5 requires Node 18.
  • Large sites: set GATSBY_EXCLUDE_DATASTORE_FROM_BUNDLE to load datastore from CDN (avoids max function deploy size; slower first SSR/DSG load).
  • Image CDN: set NETLIFY_IMAGE_CDN=true (Contentful/Drupal/WordPress source plugins). Not supported on 5.12.x with adapter — upgrade to 5.13.0+.
  • StaticImage and gatsby-transformer-sharp don't work for SSR/DSG — host images on a CDN.

Angular

SSR auto-configured via an Edge Function. Suggested dev: ng serve / 4200.

  • SSR pages are NOT subject to _redirects or netlify.toml redirects — SSR uses Edge Functions that run before redirects. Use Angular's built-in redirects.
  • Access Request/Context in SSR via netlify.request / netlify.context providers (from @netlify/edge-functions); unavailable client-side or during prerendering. Test locally with netlify serve.
  • NgOptimizedImage auto-uses Image CDN; set remote_images (array of regex) under [images] in netlify.toml.

Express

Node 18.14.0+. Deploy as a Netlify Function via serverless-http:

npm i express serverless-http @netlify/functions @types/express
// netlify/functions/api.ts
import express, { Router } from "express";
import serverless from "serverless-http";
const api = express();
const router = Router();
router.get("/hello", (req, res) => res.send("Hello World!"));
api.use("/api/", router);
export const handler = serverless(api);
[functions]
  external_node_modules = ["express"]
  node_bundler = "esbuild"
[[redirects]]
  force = true
  from = "/api/*"
  status = 200
  to = "/.netlify/functions/api/:splat"

No frontend: set a placeholder build command (e.g. echo Building Functions). All Function limits apply; not recommended as background/scheduled functions.

Hydrogen

Shopify stack on React Router 7. SSR only on Netlify Edge Functions — Netlify Functions NOT officially supported. Node 24+. Use the starter:

npm create @shopify/hydrogen@latest -- --template https://github.com/netlify/hydrogen-template
cp .env.example .env && npm run dev

Static-site gotchas

Hugo

Set HUGO_VERSION (any release after 0.19) in [build.environment] — a missing/mismatched version causes exit code: 255. Install themes as git submodules (git submodule add ...), not git clone.

Eleventy

eleventy / _site. Build plugins require editing .gitignore: change node_modules to **/node_modules/** — otherwise Netlify plugins and Eleventy collide on .netlify/plugins/node_modules/ and the build errors.

Vite meta-framework support matrix

Astro (auto on 5.12+), Nuxt (via @netlify/nuxt), TanStack Start (via @netlify/vite-plugin-tanstack-start), React Router, SolidStart — all full. SvelteKit — experimental.

Deploy via CLI (Express, Nuxt, React, Vite)

npm install netlify-cli -g
netlify init

Follow prompts to create/link the site and set build settings.

<!-- Node version floors (18.14.0+) are stated per-framework where documented; no cross-framework build-image default is given in sources. --> <!-- system: agent-context/frameworks/system.md — human-owned, merged by ctx-gen; edit system.md, not this section -->

Netlify house rules (frameworks)

These are org conventions, not docs facts — merged into the rendered skill by ctx-gen and never generated. Owned by the skills maintainer.

  1. Per-framework deep guides live in this skill: references/astro.md, references/nextjs.md, references/nuxt.md, references/sveltekit.md, references/tanstack.md, references/vite.md — route framework-specific work there before improvising.
  2. Next.js: modern runtime (v5, Next ≥13.5) only — treat the legacy adapter as read-only history, never a recommendation.
  3. Remove any SPA catch-all (/* → /index.html 200) when adopting an SSR adapter — user redirects beat adapter-generated routes, so a leftover catch-all silently serves static index.html for SSR pages and API routes.
  4. Any env var change — client- or server-side — requires a redeploy. Values are injected at build time; editing one in the UI/CLI does not reach the live site or already-deployed functions until a new build runs.
  5. netlify dev with both a custom command and a targetPort requires framework = "#custom" in the [dev] block — otherwise the detector runs and the custom command is silently ignored.
  6. Never use a client prefix (VITE_, NEXT_PUBLIC_, PUBLIC_, NUXT_PUBLIC_, REACT_APP_, GATSBY_, VUE_APP_) for secrets — client-prefixed vars are inlined into the browser bundle.
  7. Next.js skew protection is version-conditional: below Next 14.1.4 the NETLIFY_NEXT_SKEW_PROTECTION env var is not sufficient on its own — experimental.useDeploymentId (plus useDeploymentIdServerActions when server actions are used) must also go in next.config.js. Always ask for or state the version condition; never present the env var as the whole setup.
  8. Client fetch calls are not covered by Next.js skew protection by default. Give both options. Next.js 15.4+ has an experimental useSkewCookie flag that carries the deployment identifier in a cookie so it rides along on client fetch calls; Netlify supports it, but say it is not production-ready and that it holds visitors on the older deploy until the cookie clears. The other option, on any version, is adding x-deployment-id with process.env.NEXT_DEPLOYMENT_ID per call.