Server

Early Access

Netlify Server is in Early Access. Some of its functionality is limited and subject to change. Refer to Early Access for more details.

Netlify Server gives your application everything a server can do, with none of the work of running one. Netlify provisions it, deploys your code to it, scales it automatically based on demand, and monitors it. When nothing is using it, it scales down to zero, so an app with occasional traffic stays cost-efficient.

Because a server is a long-lived process, it can do what a backend usually needs a server for. It handles many requests at once, keeps state between them (such as database connection pools, caches, and SDK clients), and holds WebSocket and Server-Sent Events connections open.

It's also fast. A new deploy's server is started before the deploy goes live, which virtually eliminates cold starts when you ship.

Your server is fully integrated with the rest of the platform. It can use Netlify Database, Netlify Blobs, the AI Gateway, and the Cache API with no setup, and it's built and deployed alongside the rest of your project, so every deploy, including branch deploys and Deploy Previews, runs its own version of your backend.

Use cases

• Web APIs, REST or GraphQL, that keep database connection pools and caches warm between requests.
• Real-time apps, such as chat, multiplayer, and live dashboards, that hold WebSocket or Server-Sent Events connections open.
• AI backends and agents that stream responses, hold sessions, and reuse clients that are expensive to recreate.
• Existing Node.js servers, built with Express, Fastify, Hono, or Koa, moving to Netlify as they are.
• Microservices that serve their own traffic and scale on their own.

You can use a server for a public site or for an internal tool your team uses. For internal tools, make the project private or turn on team login protection. Your server can then read the signed-in user from context.user.

How it works

You write your server the way you prefer, either as a handler with the same signature as Netlify Functions, or with a Node.js web framework or server, such as Express, Hono, or Fastify.

A project has at most one server, defined in a single entry file at netlify/server/index.ts (or .mts, .js, .mjs).

Request handler

Your handler receives the request's Context as its second argument, the same as in functions and edge functions, with platform features such as the visitor's geolocation.

netlify/server/index.ts

import type { Context } from "@netlify/server";

export default async (req: Request, context: Context) => {
  return Response.json({ message: `Hello from ${context.geo.city}` });
};

Framework

When you need platform features, such as the visitor's geolocation, getContext() gives you the request's context from anywhere in your code, including your framework's route handlers and middleware. Here is an example using the Express framework:

netlify/server/index.mjs

import express from "express";
import { getContext } from "@netlify/server";

const app = express();

app.get("/api/hello", (req, res) => {
  res.json({ message: `Hello from ${getContext().geo.city}` });
});

app.listen(process.env.PORT);

If your project also has edge functions, redirect rules, static files or functions, these handle requests first, and your server then gets everything else. Refer to Routing for the full order.

Netlify runs your server as instances, adding and removing them as traffic changes, down to none when idle. A new production deploy goes live once its instances have started, and the previous ones shut down gracefully. Refer to Lifecycle.

Capabilities

• Many requests per instance. Like any web server, an instance serves many requests at once. Time spent waiting on a database, an API, or a model doesn't hold up other requests, and running instances absorb bursts of traffic, so fewer requests wait for a new instance to start. Refer to Limits.
• WebSockets and Server-Sent Events. Hold connections open for real-time features and streaming. Refer to Real-time.
• Keep state between requests. Keep connection pools, caches, loaded models, and warm SDK clients in memory.
• Standard Node.js servers. Run your app with any Node.js web framework or server, as it is, with no Netlify-specific adapters or wrappers. Refer to Get started.
• Lifecycle hooks. Run code when an instance starts and before it stops, with onStart and onShutdown.
• Warm deploys. A production deploy is published only once its server has started, so a server that can't start never takes over, and visitors don't hit a cold start when you ship. Refer to Deploys.
• Load-aware routing. Netlify sends new requests to the instances with the most room, judged by Node.js runtime metrics, such as event loop utilization, and by any custom utilization metrics you report with onHealthCheck. Refer to Load-aware routing.
• Edge caching. Cache responses on Netlify's CDN, so repeat requests are served close to your visitors, faster and without using your server's compute. Refer to Caching.
• Built-in platform primitives. Use Netlify Blobs, Netlify Database, the Cache API, and the AI Gateway with no setup or configuration.

Early Access

Netlify Server is in Early Access, available on credit-based plans and on Enterprise plans with credits enabled. Its APIs and behavior might change during this period.

Some of its functionality is limited during Early Access, and we'll be adding extra functionality over time. While it's in Early Access:

• A server runs up to 3 instances at a time. Netlify scales it automatically, up to 3 instances, or 1 on Free and Personal plans. Refer to Instances.
• A server always scales to zero when idle. An instance keeps running while it has requests or open connections, and goes to sleep after a few minutes of being idle. After Early Access, you'll be able to keep a minimum number of instances running, so requests don't wait for your server to start.

When to use a server

A server is built to serve your app's traffic as one long-lived process that handles many requests together, with your routes, middleware, state, startup, and shutdown in one place.

In the same project, you can also use:

• Functions to run discrete pieces of work, each triggered and scaled on its own, such as a webhook, a scheduled job, or a background task.
• Edge functions run on Netlify's network, close to your visitors, to change requests and responses on their way through.

If you're building a new backend, start with a server. Add functions for standalone tasks that don't need to be part of your app, such as a webhook receiver, a scheduled job, or work triggered by events on Netlify, and edge functions for logic that should run close to your visitors. All three work together in the same project.

	Server	Functions	Edge functions
Best for	Your app's backend	Standalone tasks, such as low-volume API endpoints, webhooks, scheduled jobs, event handlers, and background work	Personalization, access checks, and rewrites close to visitors
Runs when	Requests arrive	Requests arrive, on a schedule, or when platform events are triggered	Requests arrive, before the rest of your project
Open connections, such as WebSockets	Yes	No	No
State between requests	Kept in the instance's memory	Not guaranteed	Not guaranteed
Requests at once	Many per instance	One per instance	Many at once
Start and shutdown hooks	Yes, with graceful shutdown	No	No
Existing Node.js server apps	Run as they are	Need adapting to a handler	Need adapting to a handler

Functions can be more cost-effective for a backend that's only used occasionally. A function runs only while it handles a request, while a server's instance keeps running for a while after its last request before it scales to zero.

Not sure which fits your project? Answer a few questions:

Does your app hold connections open, such as WebSockets or Server-Sent Events?

Yes No

Do you already have a Node.js server app, built with a framework like Express, Fastify, Hono, or Koa?

Yes No

Does your backend keep things in memory between requests, such as connection pools, caches, or loaded models?

Yes No

Do many requests happen at once and mostly wait on databases, APIs, or AI models?

Yes No

Is your backend only used occasionally?

Yes No

Do you need to run code on a schedule, or when something happens on Netlify, such as a deploy or a form submission?

Yes No

Do you need to change requests or responses close to your visitors, such as personalizing pages, checking access, or rewriting URLs?

Yes No

Start a new backend on Netlify Server. Add functions for standalone tasks, such as webhooks, scheduled jobs, and work triggered by events on Netlify, and edge functions for logic that should run close to your visitors. If your backend is only used occasionally, functions can be more cost-effective.

Full-stack frameworks

Full-stack frameworks, such as Next.js, Astro, Nuxt, SvelteKit, React Router, and TanStack Start, don't run on Netlify Server yet. Netlify runs their server-side code as functions, through each framework's adapter.

These adapters usually handle every path that isn't a static file, so a server in the same project doesn't receive any requests. For now, we recommend that you use a server in projects that don't use one of these frameworks.

Pricing

Netlify Server is free to use during Early Access. When it reaches General Availability (GA), usage will be charged in credits, based on two meters:

• Reserved memory, in GB-hours.
• Active CPU time, in vCPU-hours.

Before GA, we will announce the cost in credits per unit. If your usage during Early Access suggests you’ll need to upgrade your plan or buy more credits, we will let you know. You can see how many instances your server ran, and their memory and CPU use, on its Server page in the Netlify UI.

Metered billing for other features in the same project, such as production deploys, bandwidth, and functions, applies as usual. Every request your server handles counts toward the web requests meter.

Netlify Server’s limits allow for flexible experimentation while avoiding runaway costs once its usage is billed. For example, every instance stops after 5 minutes without requests. Some limits also differ per plan, such as how many instances a server can scale up to and how long a request can run.

If you need higher limits, or you’re concerned about cost once Netlify Server reaches GA, contact us.

Acceptable use

During Early Access, Netlify Server is meant for evaluation, experimentation, and low-volume production use. Our Acceptable Use Policy applies, so a server should only run workloads related to your site or app that is on Netlify.

We may limit accounts with sustained heavy use of server instances, and in some cases block accounts that violate the Acceptable Use Policy.

Learn more

• Get started. Create a server with a handler or your framework, run it locally, and deploy it.
• API reference. Look up the entry file, the Config and Context objects, and the @netlify/server module.
• Configuration. Choose the paths your server handles, cache its responses, and set its region and instance size.
• Lifecycle. Learn how instances start and stop, how deploys move traffic, and how to run work after a response.
• Real-time. Hold connections open for chat, live updates, and streamed responses.
• Monitoring and logs. Monitor your server’s requests and resource use. Find and search what it logs.
• Limits. Review how many requests an instance handles, how long they can run, and when instances stop.
• Local development. Run your server on your machine alongside the rest of your project.
• Troubleshooting. Understand error responses and fix common problems.