Posts tagged "Framework"

TanStack Start is now 1.0, and Start apps deploy on Netlify. SSR, server routes, server functions, and middleware run on Netlify Functions. It’s also what new Agent Runners projects start with by default.

Start a new app

Deploy the official template, or generate your own:

npx create-tsrouter-app@latest --template file-router --add-ons tanchat,netlify

Deploy an existing app

Install the Netlify plugin:

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

Then add it to vite.config.ts after tanstackStart():

import { defineConfig } from 'vite'
import { tanstackStart } from '@tanstack/react-start/plugin/vite'
import netlify from '@netlify/vite-plugin-tanstack-start'

export default defineConfig({
  plugins: [tanstackStart(), netlify()],
})

Add a netlify.toml with your build settings:

[build]
  command = "vite build"
  publish = "dist/client"

Develop locally against the real platform

The plugin emulates Netlify in your dev server, so you can build against the same primitives you’ll use in production, without the Netlify CLI:

• Serverless functions and edge functions
• Blobs and Netlify Database
• Cache API and Image CDN
• Redirects, rewrites, and headers
• Environment variables
• AI Gateway

Start with Agent Runners

New projects you start with Agent Runners use TanStack Start 1.0 unless another framework is specified.

Read the TanStack Start guide · Explore the template

SvelteKit 3 is out today, and it just works on Netlify on day one. To upgrade, run:

npx sv migrate sveltekit-3

The migration tool handles most of the mechanical changes for you, including moving your config and updating imports. You can also check out the official migration guide.

What’s new

Some highlights include:

• Vite 8 — SvelteKit 3 requires Vite 8, bringing faster builds powered by Rolldown.
• Config lives in vite.config.ts — SvelteKit configuration moves out of svelte.config.js and into your Vite config, so Vite plugins can read it right away.
• Explicit environment variables are stable — Declare the environment variables your app depends on in src/env.ts, and specify whether each one is public and whether it’s resolved at build time or when the app boots. You get validation and type safety out of the box.
• $lib is now #lib — The $lib alias is replaced by #lib, using Node’s subpath imports. Imports need to be unambiguous, so write #lib/foo.ts or #lib/foo/index.ts.
• Shallow routing is built into goto — Use goto() with shallow: true instead of pushState and replaceState.
• Consistent error handling — All errors, including ones you throw with error(...), now go through your handleError hook.
• New service worker modules — $service-worker is replaced by imports from $app/env, $app/paths, and $app/manifest, with better type checking in service workers.
• Tracing is stable — Tracing support has moved out of the experimental namespace.

Check the full migration guide for all the details.

Watch out for the #lib alias

Nearly every SvelteKit project imports from $lib, so this is the change you’re most likely to run into. The migration tool rewrites these imports for you, but because #lib relies on Node’s subpath imports, directory imports without an explicit file no longer resolve:

// Before
import { formatDate } from '$lib/utils';

// After
import { formatDate } from '#lib/utils/index.ts';

If a build fails after upgrading with a module resolution error, look for #lib imports that point to a directory or leave off the file extension.

Deploy a SvelteKit 3 site on Netlify

If you want to get started with a new site, start with the SvelteKit on Netlify doc, or just click this button:

The TanStack team has disclosed a critical cross-site scripting (XSS) vulnerability in TanStack Start. A crafted URL can cause an affected app to return attacker-controlled HTML from its own origin, which may run attacker-supplied JavaScript in a visitor’s browser. Here’s what Netlify customers need to know.

Vulnerabilities

GHSA-qx66-fv34-fjm8 (CVE-2026-102989): Unauthenticated reflected XSS in server-function responses.

Impact on Netlify

This is a client-side cross-site scripting (XSS) vulnerability in TanStack Start’s server-function response handling. Because the malicious response is returned from the app’s own origin, an attacker who gets a victim to open a crafted link can run JavaScript in that visitor’s session — for example, to read their data or act as them on the site. All applications on an affected version should upgrade.

What should I do?

We strongly recommend upgrading as soon as possible to the patched releases:

• @tanstack/react-start 1.168.60 or later
• @tanstack/solid-start 1.168.57 or later
• @tanstack/vue-start 1.168.56 or later
• @tanstack/start-server-core 1.169.39 or later

Not sure if you’re affected?

Open your project in Agent Runners in ask mode and try this prompt:

Does this project use TanStack Start? If so, which versions of `@tanstack/react-start`, `@tanstack/solid-start`, `@tanstack/vue-start`, and `@tanstack/start-server-core` are resolved in the lockfile? Is the resolved `@tanstack/start-server-core` version 1.169.39 or later? If not, what do I need to change to upgrade? (Advisory: GHSA-qx66-fv34-fjm8)

Ask mode answers without changing your code. If an upgrade is needed, switch to Build mode to make the change, preview, and redeploy.

Deploy previews and branch deploys

Note that any publicly available deploy previews and branch deploys may remain vulnerable until they are automatically deleted. Consider deleting these deploys manually.

Resources

• GitHub security advisory (GHSA-qx66-fv34-fjm8)
• TanStack security update: CVE-2026-102989
• CVE-2026-102989

SolidStart 2 is out, and it deploys to Netlify with no framework-specific adapter to install, a first for full-stack frameworks on Netlify.

While SolidStart 1 deployed to Netlify through Nitro under the hood, SolidStart 2 no longer includes Nitro, building directly on Vite’s Environment API instead. The Netlify Vite plugin can now take the server build Vite produces and prepare it for deployment on its own, with no SolidStart-specific Netlify adapter needed in between.

How to deploy

Install the Netlify Vite plugin:

npm install -D @netlify/vite-plugin

Then add it to your Vite config with its build support turned on:

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 } })],
});

That’s the whole setup for a new project. Netlify detects SolidStart and fills in your build settings, and your SSR pages, API routes, server functions, and middleware deploy to Netlify Functions.

Prefer to build with Nitro? It became a Vite plugin in Nitro 3 and auto-detects Netlify, so adding nitro() works too. Just remove build.enabled from the Netlify Vite plugin.

Either way, vite dev gives you the full Netlify platform emulated right in your dev server without reaching for the Netlify CLI.

Already on SolidStart 1?

Nothing breaks, and your Nitro netlify preset keeps working. When you’re ready to upgrade, follow the framework upgrade guide. We recommend then moving to the Netlify Vite plugin with build support as described above and changing your publish directory from dist to dist/client. (If you keep building with Nitro, dist stays as it is.)

Why there’s no SolidStart adapter

Every framework used to need its own adapter for every platform, and every adapter needed someone to keep it current.

Frameworks converging on Vite’s Environment API doesn’t change this on its own. What removes it is the build support in @netlify/vite-plugin: it takes the server bundle a Vite-powered framework emits and turns it into Netlify deployment configuration (we call this the Frameworks API), without knowing or caring which framework produced it. Supporting SolidStart 2 required no SolidStart-specific code and, in fact, no changes at all. This is the same code that’s been powering TanStack Start on Netlify the past year.

It’s the direction we’re heading, in collaboration with the Vite team, framework authors, other platforms like Cloudflare, and the broader ecosystem: fewer adapters to maintain, more consistent feature sets across frameworks, and more niche frameworks supported out of the box, helping to support a healthy web ecosystem.

Resources

• SolidStart 2 announcement
• SolidStart 2 upgrade guide
• SolidStart on Netlify docs

The React Router team has disclosed five security vulnerabilities affecting React Router. These issues are patched in React Router 7.18.0 (one issue was patched earlier, in 7.13.0). Here’s what Netlify customers need to know.

Vulnerabilities

Impact on Netlify

Open redirect leading to XSS

Attacker-controlled redirect targets combined with path concatenation and useNavigate can escape the intended app path, resulting in open redirects or XSS via javascript: URLs. This affects Declarative, Data, and Framework mode apps that pass user-controlled values into navigation APIs.

Regardless of hosting provider, all apps passing untrusted data into navigation APIs may be vulnerable.

Unauthenticated Denial of Service in React Router __manifest endpoint

Deep, attacker-controlled paths can trigger expensive synchronous route matching, blocking the Node.js event loop with a single unauthenticated request to manifest endpoints (__manifest, and *.manifest in unstable RSC mode). This affects Framework mode with SSR only, including unstable RSC framework mode.

This is a server-side denial-of-service (DoS) vulnerability. On Netlify, this has minimal impact: our autoscaling serverless architecture means that a malicious request resulting in a crashed or hung function does not affect other requests. However, active exploitation could increase your function costs.

RSCErrorHandler Missing Protocol Validation (XSS)

One RSC redirect handling path was missing protocol validation. Apps that redirect to attacker-controlled values may execute dangerous schemes such as javascript:. This only affects apps using unstable RSC Data or RSC Framework mode.

Regardless of hosting provider, all RSC apps redirecting to untrusted values may be vulnerable. Note that this affects an experimental feature only.

Arbitrary client-side constructor injection via React Router SSR Hydration

Serialized server errors can carry a subtype that’s resolved against window during hydration. Apps that set user-controlled input into error.name could have this instantiate browser constructors such as EventSource, WebSocket, Worker, or Image. This affects Data and Framework mode SSR hydration.

Regardless of hosting provider, apps setting user-controlled values into error.name may be vulnerable. This requires an unusual application code path, so real-world impact is expected to be low.

Unexpected external redirect via untrusted paths

Backslash-based URL forms such as \\evil.com, /\evil.com, or \/evil.com can be interpreted by browsers as cross-origin navigations, bypassing protections that only account for //. This affects <Link>, useNavigate, and redirects across Declarative, Data, Framework, and RSC modes.

Regardless of hosting provider, all apps passing untrusted destinations to <Link>, useNavigate, or redirects may be vulnerable.

What should I do?

We strongly recommend upgrading as soon as possible to patched releases:

• react-router 7.18.0 or later (all five issues)
• react-router 7.13.0 or later addresses the open redirect leading to XSS issue only — upgrade to 7.18.0 for full coverage

Note that any publicly available deploy previews and branch deploys may remain vulnerable until they are automatically deleted. Consider deleting these deploys manually.

Resources

• Open redirect leading to XSS (CVE-2026-53668)
• Unauthenticated Denial of Service in React Router __manifest endpoint (CVE-2026-55685)
• RSCErrorHandler Missing Protocol Validation (XSS) (CVE-2026-53667)
• Arbitrary client-side constructor injection via React Router SSR Hydration (CVE-2026-53666)
• Unexpected external redirect via untrusted paths (CVE-2026-53669)

Astro 7 is out today, and it just works on Netlify on day one. To upgrade, run:

npx @astrojs/upgrade

This will update Astro, the Netlify adapter, and all other official integrations together. You can also check out the official migration guide.

What’s new

Some highlights include:

• Vite 8 — Astro 7 upgrades to Vite 8, bringing faster builds and improved dev tooling.
• Sätteri is now the default markdown processor — Astro’s new native markdown pipeline replaces remark/rehype as the default. If your project uses remark or rehype plugins, you’ll need to install @astrojs/markdown-remark separately to keep them working.
• Advanced routing is stable — Previously behind an experimental flag, advanced routing is now enabled by default. The default entry point has moved from src/app.ts to src/fetch.ts.
• Streaming rendering is stable — The streaming-based rendering engine is now the default, replacing the legacy queued approach.
• Background dev server for AI coding agents — astro dev now detects AI coding environments and runs as a background process automatically. New astro dev stop, astro dev status, and astro dev logs commands let you manage it directly.
• Astro DB is deprecated — The astro db, astro login, astro logout, astro link, and astro init CLI commands have been removed. Switch to a dedicated database client.
• Custom logger is stable — context.logger is now always available in API routes and middleware, with built-in json, node, and console handlers.

Check the full upgrade guide for all the details.

Watch out for the new markdown defaults

If your site uses remark or rehype plugins, you’ll need to take action before upgrading. In Astro 7, the default markdown pipeline is Sätteri — Astro’s own native processor. The remark/rehype pipeline is no longer included by default.

To keep your existing plugins working, install the remark package separately:

npm install @astrojs/markdown-remark

Once installed, your existing markdown.remarkPlugins, markdown.rehypePlugins, and markdown.remarkRehype config options will continue to work as before. If you’re not using any remark or rehype plugins, no changes are needed — Sätteri handles standard Markdown out of the box.

Deploy an Astro 7 site on Netlify

If you want to get started with a new site, start with the Astro on Netlify doc, or just click this button:

React Router 8 was just released and is already supported on Netlify.

The breaking changes are largely limited to these new minimums:

• Node.js 22.22.0+
• React 19.2.7+
• Vite 7+

How to upgrade

To upgrade your existing Netlify project follow the React Router 8 upgrade guide and upgrade the Netlify React Router Vite plugin to v4.0.0+:

npm i @netlify/vite-plugin-react-router@latest

Try it now

To deploy a brand new, React Router 8 application to Netlify, click this button:

What you get

Full framework feature support, serverless and edge functions included, plus full Netlify platform emulation in local dev for you and your agents.

• React Router on Netlify
• @netlify/vite-plugin-react-router release notes

Angular v22 was released today and it is supported on Netlify on day one.

To upgrade, follow the Angular upgrade steps and update @netlify/angular-runtime to v4.0.0 or later.

Notable changes

• Minimum Node.js version: Angular v22 requires Node.js 22.12.0 or later. Make sure your Netlify site is configured to use a supported Node.js version.
• allowedHosts config: Angular v21.x (specifically, @angular/ssr) introduced an allowedHosts option in the AngularAppEngine configuration, giving you explicit control over which hosts are permitted to connect. Angular 22 started returning a HTTP 400 for requests with other host headers. @netlify/angular-runtime handles adding the most common URLs for a Netlify deploy to the allowedHosts config automatically allowing developers to use Netlify’s branch and deploy previews without the HTTP 400 error.
• Forwarded headers support withtrustProxyHeaders: A new trustProxyHeaders option lets Angular applications behind a reverse proxy correctly read forwarded headers such as X-Forwarded-For and X-Forwarded-Proto. @netlify/angular-runtime handles adding the required headers automatically.

Learn more:

• Angular v22 Release
• Angular on Netlify
• Angular Runtime

Shopify’s Hydrogen framework now works on Netlify with React Router 7 and Hydrogen 2026.1.0. The Netlify Hydrogen template has been fully rebuilt, and @netlify/vite-plugin-react-router now supports Hydrogen sites out of the box.

The updated template also comes with two meaningful improvements:

• Netlify Cache API integration — Data fetching is cached using the Netlify Cache API, giving you low-latency responses without extra configuration.
• Full local platform emulation — The Netlify Vite Plugin provides zero-config local emulation of Blobs, Functions, Edge Functions, and AI Gateway during development, so what you test locally matches what runs in production.

To get started with a new Hydrogen site on Netlify, deploy the updated template:

To move an existing Hydrogen site over to Netlify, follow the How to deploy a Shopify Hydrogen storefront to Netlify guide.

Learn more:

• Hydrogen template on GitHub
• @netlify/vite-plugin-react-router v3.1.0 release notes
• How to deploy a Shopify Hydrogen storefront to Netlify