Changelog

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 AI Gateway now supports OpenRouter, giving you access to models from providers beyond Netlify’s direct integrations (OpenAI, Anthropic, Google Gemini).

This partnership opens up models from providers like DeepSeek, Meta, Mistral, Qwen, and xAI, all billed through your existing Netlify credits.

Learn more about our OpenRouter partnership through the Netlify blog on open models.

Supported models

For a full list of models available on OpenRouter, visit OpenRouter’s models page.

Note that Netlify only allows requests through OpenRouter for model providers that support a Zero Data Retention (ZDR) policy, meaning your prompts and outputs are never stored nor trained on. Models on OpenRouter that do not have any available provider guaranteeing this policy (at the time of your request) are not available via Netlify.

Set up OpenRouter for AI Gateway

As with the other providers, Netlify automatically injects OPENROUTER_API_KEY and OPENROUTER_BASE_URL into your Netlify Functions, Edge Functions, and Preview Server (unless you’ve already set your own values for either).

You can call an OpenRouter-served model using whichever client you prefer:

• OpenRouter SDK (@openrouter/sdk): pass OPENROUTER_BASE_URL explicitly as serverURL when constructing the client, this is the one exception where the base URL isn’t picked up automatically.
• OpenAI SDK: works out of the box, no extra config. Just pass a model ID in OpenRouter notation (e.g. deepseek/deepseek-v4-flash-0731).
• REST API: call ${OPENROUTER_BASE_URL}/chat/completions with a bearer token from OPENROUTER_API_KEY.

Whichever client you use, you can find model IDs to pass in the OpenRouter models directory.

Note that a model listed in OpenRouter’s directory will not work through the AI Gateway if it does not support a Zero Data Retention (ZDR) policy since Netlify only routes to OpenRouter providers with this support.

To learn more about using AI Gateway, check out our official AI Gateway Netlify docs.

Through a new partnership with OpenRouter, you can now choose OpenCode as an AI agent with Agent Runners. OpenCode allows you to choose many different AI models, including Kimi, DeepSeek, and GLM.

Learn more about our OpenRouter partnership through the Netlify blog on open models.

Previously, you could only choose Claude, Gemini, or Codex as your AI agent, but now you can choose the OpenCode agent, which offers even more models from different AI providers.

Requests made through OpenCode are only routed to model providers with a Zero Data Retention (ZDR) policy, so your prompts and outputs are never stored.

AI model selection

As part of this release, you can now also specify which model any agent uses with Agent Runners. Previously, Claude, Gemini, and Codex agents all automatically chose a model for the task you prompted with Agent Runners.

Agents can still auto-select a model for you, but now you can also choose different models for your agents, with these preferences saved just for you on your device.

This means you can experiment with which AI models best fit your needs.

To open your AI model options for Agent Runners, select agent near your prompt box.

Choosing the best AI model for your needs

To help you choose the best AI model for your needs, within Agent Runners you can browse details about each model, including a link to learn more, a visual way to compare cost across all supported models with a 1-5 dot scale, and the option to set an effort level for that model.

To get the most out of your credits, consider the following strategies:

• Use a more expensive, capable model to help you plan your project updates and design a clear prompt with Agent Runners’ ask mode, then switch to a cheaper model to implement the changes.
• Experiment with using different AI models for different tasks.
• Be explicit about the functionality you want when using models that are cheaper or set to a lower effort level. These models may fill in placeholder functionality. For example, a model might render a contact page without fully setting up working Netlify Forms, so the page looks complete but doesn’t actually work as expected.

Learn more

To learn more, check out our docs:

• Agent Runners overview
• Make changes with Agent Runners

Netlify Agent Runners now have a mode selector. Pick Ask and the agent reads, investigates, and answers questions about your project. Build is still the default and works exactly as before.

Ask mode is strictly read-only. The agent can’t edit files, run commands, deploy, or change settings. With no build or Deploy Preview, Ask runs are often faster and use fewer credits.

It answers with real context: your repository, your project context, and your project’s Netlify Database. Your data is often the fastest way to answer a question about your app, and Ask mode can query it with no risk of a write.

A few prompts to steal:

• “How many users are in the database?”
• “Walk me through how authentication is implemented in this project. Which files handle it, and where is the token stored?”
• “Our Largest Contentful Paint is bad on mobile. Read the code and tell me what’s most likely responsible.”
• “Plan out how we can migrate to the latest version of Astro.”

Because it’s a mode on the same run, you can switch to Build the moment an answer turns into a task — same run, same context, no re-explaining.

Ask mode is available on all agents, Claude Code, Google Gemini, and OpenAI Codex, in Agent Runners today. See the docs on Ask and Build modes.

GPT-5.6 Luna now costs 80% less and GPT-5.6 Terra is 20% less through Netlify AI Gateway, making both models more cost-efficient for production AI workloads.

These reductions improve the price-performance tradeoff across the GPT-5.6 model family, giving teams more flexibility to choose the right balance of capability and cost for each workload.

Learn more in OpenAI’s announcement, Advancing the price-performance frontier with GPT-5.6.

Teams on a Free, Personal, or Pro plan now have project visibility settings to ensure that all of your project stay private until you decide to make them public.

More people are shipping prototypes, internal tools, early client work, and projects built with agents. A deploy is often a work in progress, not a publication. Netlify now reflects that distinction.

Project visibility settings allow you to:

• quickly ensure your project stays internal for your Netlify team until you’re ready to launch more publicly.
• ensure that your project stays private for you and your Netlify team.
• choose defaults that keep internal-only projects private, such as for internal apps and tools or sensitive releases.

While project access affects who on your team can access a project from the Netlify dashboard, project visibility impacts who can view your project, both at the live URL and inside of Netlify, and requires Netlify login credentials if a project is set to private.

Starting defaults

Starting today, all new Netlify teams on a Free, Personal, or Pro plan will have their projects set to private by default. This means that new Netlify teams will need to adjust the project visibility of each new site or app to decide when to make them publicly available.

If you have an existing Free, Personal, or Pro plan (all credit-based plans), then your starting project visibility settings are set differently to keep the previous default behavior before project visibility settings launched.

This means all your project URLs stay publicly available unless you’ve set up other authentication with code or Netlify’s password protection options.

Change your project visibility

To change your project’s visibility, you can set a team default for all new and existing projects at: Team settings > General > Visitor access > Default project visibility

To change only one project’s visibility settings: Project configuration > General > Visitor access > Project visibility

Availability

Project visibility settings are only available for Credit-based Free, Personal, or Pro plans.

If you have a Legacy pricing plan, an Enterprise plan, an Open Source plan, you will not find project visibility settings. In this case though, you can still use password protection, Team login protection (for Enterprise only) or configure authentication with code.

Learn more

Learn more about setting up and managing project visibility in our docs.

The Nuxt team has disclosed several security vulnerabilities fixed in Nuxt 4.5.1 and 3.21.10, ranging from a high-severity server-side remote code execution (under specific conditions) to lower-severity and development-only issues. Here’s what Netlify customers need to know.

Vulnerabilities

• GHSA-9473-5f9j-94wq (High): remote code execution via server island props
• GHSA-48hr-524c-v5w3 (Medium): unauthorized component instantiation via server island props
• GHSA-hxvh-4h3w-prp9 (High): route rule authorization bypass when a route rule key contains an uppercase character
• GHSA-hxcr-hm88-mpq6 and GHSA-9pgf-384g-p7mv (High): server component denial of service
• GHSA-wm8w-6qjm-cv43 (High): cross-user disclosure of cached payloads (Nuxt 4.x only, 4.4.0 and later)
• GHSA-7c4v-fwgw-9rf7 (Low): dev server path disclosure
• GHSA-279x-mwfv-vcqv (Critical, development only): remote code execution in Nuxt DevTools, fixed in @nuxt/devtools@3.3.1

Impact on Netlify

Remote code execution (GHSA-9473-5f9j-94wq)

This issue only applies under uncommon conditions: it requires Vue’s runtime compiler (vue.runtimeCompiler: true, which is off by default) and a server island that forwards untrusted input into a component. Few applications meet both conditions, so real-world exposure is limited. We’ve proactively reached out to the very small number of Netlify customers whose projects could potentially be affected.

Route rule authorization bypass (GHSA-hxvh-4h3w-prp9)

This is a framework-level issue that affects Nuxt apps regardless of hosting provider. It is not specific to Netlify. You’re affected if you use routeRules with appMiddleware as an authorization gate and any rule key contains an uppercase character, such as a rule derived from a page like pages/Admin.vue or written explicitly as routeRules: { '/Admin': ... }. Because routing is case-insensitive by default, the page was served while its route rule (and the middleware guarding it) was silently skipped. This is a regression in the earlier fix for CVE-2026-53721, so upgrading only to 4.4.7 or 3.21.7 does not protect you. Upgrade to Nuxt 4.5.1 or 3.21.10, then audit any uppercase route rule keys used for access control.

Denial of service (GHSA-hxcr-hm88-mpq6, GHSA-9pgf-384g-p7mv)

These are server-side denial-of-service (DoS) vulnerabilities. On Netlify, these have 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.

Cross-user payload disclosure (GHSA-wm8w-6qjm-cv43)

If you use the cache, swr, or isr route rules on authenticated pages that render user-specific data, a cached payload could be served to the wrong user. After upgrading, purge any upstream CDN cache (e.g. Akamai or Cloudflare) that may already be holding a leaked payload. Upgrading alone won’t evict it.

Development-only issues (GHSA-279x-mwfv-vcqv, GHSA-7c4v-fwgw-9rf7)

The Nuxt DevTools remote code execution and the dev server path disclosure only affect local development, not deployed Netlify sites. Still, refresh your lockfile so it picks up @nuxt/devtools@3.3.1.

What should I do?

We strongly recommend upgrading as soon as possible to a patched release:

• nuxt 4.5.1 or later (for Nuxt 4)
• nuxt 3.21.10 or later (for Nuxt 3)

Running npx nuxt upgrade --dedupe also refreshes your lockfile so it pulls in @nuxt/devtools@3.3.1, which fixes the critical development-only issue above.

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

Resources

• Nuxt security post
• Nuxt security advisories

Netlify Drop has a refreshed look, with even more support for your questions and guidance on what’s next after you drop your latest site or app.

We first launched Netlify Drop 13 years ago when we introduced the web to a simpler way to deploy your web project and get a custom link for it.

Since that time we’ve learned a lot about how people (and now agents) use Drop. You can learn more from our official blog post revisiting Netlify Drop and how it’s evolved over time.

Same core functionality with more context

The newly improved Drop page keeps the same core functionality, letting you drag and drop your project files or folder, while making it easier for you or an agent to find answers along the way.

For example, did you know Netlify can detect your framework and run a build step for you?

You don’t have to build your project first. If you drop a project folder that uses a framework requiring a build, we’ll direct you to log in first, then take care of the build step for you.

Try it out

Try it out at app.netlify.com/drop.

After you drop

After you drop a project, claim it to keep your project online and join millions of others, from solo builders to global brands, who manage their sites and apps on Netlify.

After you claim your project, you can keep building in your preferred workflow.

We’ve got you covered with more ways than ever to keep building and deploying:

• Keep dropping to update the same production URL
• Push your deployed project to a newly created GitHub repo
• Keep deploying with dev tools, such as our CLI or API
• Keep developing with popular AI agents directly from your Netlify dashboard using Agent Runners

From there you can keep launching with confidence, undo mistakes (even without Git), build with a team, and grow to any size, all starting from a drop.

Anthropic’s Claude Opus 5 model is now available through Netlify’s AI Gateway and Agent Runners with zero configuration required.

Use the Anthropic SDK directly in your Netlify Functions without managing API keys or authentication. The AI Gateway handles everything automatically. Here’s an example using the Claude Opus 5 model:

import Anthropic from '@anthropic-ai/sdk';

export default async () => {
    const anthropic = new Anthropic();

    const response = await anthropic.messages.create({
        model: 'claude-opus-5',
        max_tokens: 4096,
        output_config: { effort: 'medium' },
        messages: [
            {
                role: 'user',
                content: 'How can AI improve my coding?'
            }
        ]
    });

    return new Response(JSON.stringify(response), {
        headers: { 'Content-Type': 'application/json' }
    });
};

Claude Opus 5 is available for all Function types and Agent Runners. You get automatic access to Netlify’s caching, rate limiting, and authentication infrastructure.

Learn more in the AI Gateway documentation and Agent Runners documentation.