Over a decade ago, Netlify set out to change how developers build for the web. We replaced provisioning servers and shared staging environments with a workflow where every change got its own isolated preview environment, every deploy went live atomically on a global edge network, and a bad deploy could be rolled back instantly.
Teams loved shipping their frontends on Netlify, but most backends still lived somewhere else, and deploying them was a very different experience. It meant wrestling with Dockerfiles and Kubernetes, applying security patches, provisioning servers and scaling them up and down. We kept getting the same question from our customers: how can the simplicity and velocity of Netlify apply to the whole stack?
Then, AI changed the world. We’ve welcomed millions of new builders to our platform, who want to ship ambitious, dynamic software at a pace that was unimaginable just a couple of years ago, such as real-time collaborative canvases, multiplayer apps, live chat, and agent workflows that run for long periods of time. Their complex backends kept running into the limits of what our platform could host.
Telling them to host part of their project somewhere else goes against our mission of empowering builders of any technical background to bring their ideas to life. So we started imagining what it would look like to bring the simplicity of the Netlify workflow and the power of our platform primitives to the rest of the stack.
Today we’re introducing Netlify Server, a long-running server for your application’s backend. It gives your application everything a server can do, from WebSockets to in-memory state, with none of the work of running one. You build, preview and deploy it exactly like the rest of your Netlify project, and we handle the rest.
Netlify Server is available in Early Access today.
Why a server #
We launched Netlify Functions back in 2018 with a simple idea: you drop a JavaScript file in your project and get a backend endpoint that is built, previewed and deployed alongside your frontend, without a server to manage. We’ve kept building on these foundations, with Edge Functions that run snappy operations close to your visitors, Background Functions for asynchronous work that can take several minutes, and Scheduled Functions for recurring jobs. Today, our platform handles hundreds of millions of function requests a day, powering everything from hobby projects to the websites of some of the largest companies in the world.
So why build a server? Because functions are built around the idea that each invocation handles one request. A function is a bit like a vending machine, where each person gets served on their own, one at a time.
That’s often exactly what you want, and it’s a big part of what makes functions so easy to scale and reason about. But it starts getting in the way once your backend grows past a collection of endpoints and starts to look like an application of its own:
- Waiting is expensive. A function that spends ten seconds waiting for an AI model to finish its answer, or holding a session open while a user types their next message, occupies an entire instance for those ten seconds while doing almost nothing. A hundred people chatting with your app at once usually means a hundred runtimes, each with its own cold start, its own memory and its own database connections.
- Connections can’t stay open. A function responds and finishes, so it can’t hold a WebSocket open. That rules out the two-way connection that multiplayer games, collaborative editors and live chat are built on, where every participant sees what the others do as it happens.
- State doesn’t stick around. Connection pools, caches and SDK clients sometimes survive from one invocation to the next, but you can’t plan around when, so every invocation has to be ready to start from scratch.
- Existing servers need adapting. An Express or Hono app has to be reshaped into handlers or wrapped in an adapter before it can run as a function.
Serverless was designed around short, independent invocations, and these needs challenge that paradigm. And yes, we could have stretched functions to cover them, but we would end up with a confusing primitive that sits somewhere between serverless and a server without being good at either.
We’d rather keep functions for what they’re excellent at, and introduce a new primitive that was built from the ground up for these kinds of workloads.
Meet Netlify Server #
With Netlify Server, we went back to first principles. Backends have had these needs for as long as the web has existed, and for decades they’ve been handled by the same thing: a server. Rather than inventing something new, we took that model and built it with everything Netlify is known and loved for. It has the same workflow, the same zero-config experience and the same platform primitives you already use for the rest of your project.
You write a server, and Netlify provisions it, deploys your code to it, scales it with demand and monitors it. When nothing is using it, it scales down to zero.
Under the hood, an instance of your server is a long-lived Node.js process that handles many requests at the same time. While one request waits on a database or an AI model, the event loop serves the others, so a single instance absorbs a burst of traffic that would have meant dozens of cold starts with functions.
Because the process stays alive between requests, anything you set up once stays set up for as long as the instance runs. Connection pools, caches, warm SDK clients and open WebSocket connections can live in memory and be reused, instead of being recreated on every request.
To go back to the analogy, a server is more like a shop with staff behind the counter. It stays open, serves many people at once, and keeps things ready for the next customer.
Writing a server
A server is a single file at netlify/server/index.ts. You can write it as a request handler, with the same signature as a Netlify function:
Or you can bring a Node.js server built with Express, Hono, or Fastify, as it is, with no wrappers or adapters:
You don’t have to configure ports, add health check endpoints or install adapters. Netlify works out how to run your server and handles the rest.
The same is true of all the platform primitives: Netlify Database, Netlify Blobs, the AI Gateway, the Cache API and others work out of the box.
Because it’s part of your project, it’s built and deployed with everything else. Every branch deploy and every Deploy Preview runs its own version of your backend, with its own branch of your database, so a pull request that changes your API, your schema and your UI at the same time can be reviewed in one place, on one URL.
Instances you can see and control #
Rather than hiding server instances behind opaque abstractions, we chose to make them visible and give you a say in how they start, how they stop, and even how Netlify decides when one is too busy to take more work, while we handle the scaling itself.
We expose lifecycle hooks for the entire lifetime of an instance. onStart runs when an instance starts, before it receives any traffic, so you can warm things up. onHealthCheck runs while it’s serving, and lets you report how busy your server is by its own measures, such as how deep a job queue is. And onShutdown runs before it stops, so you can flush anything you’ve been holding in memory on the way out.
Netlify scales your server automatically, so it keeps up with demand without running more instances than it needs. Rather than looking only at CPU usage, we read a range of signals from the JavaScript runtime and from your application to decide when an instance has room for more work and when it’s time to start another one.
The defaults work well for most apps, but you can also define your own signals, such as how full a queue or a connection pool is, and we’ll take them into account when routing requests and scaling your server.
What you can build #
Netlify Server unlocks a whole universe of use cases that were previously impossible or impractical to build on Netlify. We’ve been using it internally for a while, and it’s been truly inspiring to watch all the amazing and creative things people have built.
Teams across Netlify are using Server to power all sorts of workloads, and in several cases they’ve replaced entire products we used to buy with tools built in-house, with Agent Runners and other AI agents.
Here are a handful of examples we can talk about today. We’ll share many more over the coming weeks.
Real-time collaboration
A server can hold a WebSocket open with every visitor in a room and push each change to the others the moment it happens. With Netlify Database as the shared source of truth, several instances can serve the same room without drifting apart.
Elad built Live Rooms exactly this way. It’s a collaborative board where several people move notes around the same room at once. Hearthlight, by Youval, applies the same ideas to a virtual tabletop for playing Dungeons & Dragons online with your friends. And Wade blew our minds with Quiver Hollow, a multiplayer first-person-shooter game where you run around a small valley with a bow and try to outlast the other archers, human and AI alike.
AI agents and long-running jobs
A process that stays up can run an agent loop for as long as it takes, keep its working state in memory between steps, and stream progress to the page over a WebSocket while it serves other visitors. The same holds for any job that waits on a model, with the AI Gateway and Netlify Database covering model access and storage.
Elad built a personal AI assistant that you talk to on Telegram. It remembers things about you, sets reminders, watches pages for changes and searches the web. The server runs the agent loop, Netlify Database keeps its memory and schedules, and the AI Gateway provides the model, so there are no API keys to manage.
Tokyo Now is a mesmerizing pixel-art map of everything happening in Tokyo right now. Every five minutes the server pulls from listings, news and social posts, runs them through an AI model, and pushes every change to open pages within seconds. There’s a step-by-step too, and everything behind it, including the job queue and the database, runs on Netlify.
Where a server fits #
You might be wondering whether launching a server means Netlify is walking back on composable architectures and returning to the kind of monolith we set out to untangle over a decade ago. The answer is no, absolutely not.
We still believe that your backend and its business logic shouldn’t dictate the web experience, that an API-first design is the right way to connect the two, and that you should use the best tool the ecosystem has for each part of the job. Netlify’s edge still serves your static assets, runs your edge functions and caches responses before a request ever reaches your server.
What changes is that your backend can now live in the same repository, build in the same pipeline and ship in the same atomic deploy as your frontend. We’re bringing the Netlify workflow to the backend, and leaving the architecture to you.
Netlify Server also doesn’t replace functions. A server is built to serve your app’s traffic as one process, with your routes, middleware, state, startup and shutdown in one place. Functions run discrete pieces of work that are triggered and scaled on their own, such as a webhook, a scheduled job or something that should happen when a deploy finishes. Edge functions run close to your visitors and change requests and responses on their way through.
For more information about when to use a server, a function or an edge function, refer to When to use a server in the documentation.
Available in Early Access today #
Netlify Server is available today in Early Access, on credit-based plans and on Enterprise plans with credits enabled. To build and run a server locally, you’ll need Netlify CLI 27.17.0 or later. If you build with a coding agent, run netlify init in your project to pull in the latest agent skills.
Our goal for this period is to get you building, evaluating and stress-testing real workloads, so we can gather feedback before General Availability.
During Early Access, a server scales up to 3 instances (1 on Free and Personal plans), and it always scales to zero after 5 minutes without requests. After Early Access, you’ll be able to keep a minimum number of instances running, so requests never wait for your server to start. The limits page in the documentation has the full list.
Netlify Server is free to use during Early Access. We want to be upfront about how pricing will work when it reaches General Availability, though. Usage will be billed based on two meters: reserved memory (in GB of RAM per hour) and active CPU time (in vCPU hours), at rates we’ll announce before GA. We might still adjust these meters as we learn from Early Access.
Other metered features in your project, such as bandwidth and web requests, are billed as they are today. You can track your usage in the Netlify dashboard, and before GA we’ll reach out to anyone whose usage suggests they’d need a bigger plan or more credits to keep going at the same pace, so you won’t be caught off guard.
What’s next #
Netlify Server is the first primitive we’ve shipped on a brand new compute platform, built from the ground up on what we’ve learned running Netlify’s infrastructure for over a decade. It’s a foundation we’re excited about, and we’re hard at work building on it to unlock new capabilities on Netlify, with the goal of powering the next generation of applications and the new generation of builders creating them. Expect to hear more from us on that soon.
In the meantime, we can’t wait to see what you build with Netlify Server. To get started, head over to the documentation, which walks you through creating your first server, running it locally and deploying it. The guides also come with ready-made Agent Runners prompts, so you can have an agent build you a working example with a couple of clicks.
As always, we’d love to hear what you build and where it falls short. Reach out through our support portal or our Discord server.