You can run Payload outside of Next.js in a standard Node server. The Local API works perfectly in that environment, giving you direct database access, collections, hooks, access control, and auth logic without going through REST or GraphQL. What you give up is the Admin Panel — and that distinction matters more than most people realize when they first explore this architecture.
If you are evaluating Payload for a setup with a custom Vite or React frontend and an Express backend, this article explains exactly what you get, what you give up, and when this approach makes practical sense.
What the Payload docs actually say about running outside Next.js
Payload's official documentation confirms that Payload can run in a standalone Node process for scripts, separate backend services, and Local API usage. The Local API lets your Node application execute Payload operations directly against the database — no HTTP round-trip, no REST, no GraphQL. It is a direct in-process call.
Here is a minimal example of initializing Payload in an Express server:
From that point, payload is available as your in-process content and data engine. Collections, fields, validation, hooks, access control — all of it runs.
Why the Admin Panel is the exception
The Admin Panel is built with React using the Next.js App Router. The REST and GraphQL APIs also live as Next.js routes alongside it. That is not a configuration detail — that is the architecture. If you strip Next.js out of the picture, you are removing the layer those three things live on.
So the rule looks like this in practice:
Capability
Available outside Next.js
Local API (create, read, update, delete)
Yes
Collections, fields, hooks
Yes
Access control and auth collections
Yes
Upload and media logic
Yes
Database adapter layer
Yes
Generated TypeScript types
Yes
REST API
No (requires Next.js routes)
GraphQL API
No (requires Next.js routes)
Official Payload Admin Panel
No (requires Next.js App Router)
The real trade-off when running Payload in Express
If you go with a Vite React frontend, an Express backend, and Payload's Local API wired into Express, the architecture works. The trade-off is that you are now responsible for everything the official Admin Panel provided.
That means you build your own content editing screens. You build your own media manager if your project needs one. You build your own preview workflow. You expose your own REST routes on top of the Local API where you need HTTP access. You handle auth and session integration yourself.
None of that is impossible. It is just real scope that the Payload Admin Panel eliminates when you run the standard Next.js setup.
When this architecture actually makes sense
This setup is worth considering in two specific situations. The first is when you already have a custom internal UI and you want Payload to serve as the backend data engine sitting behind it. The second is when your team has strong opinions against Next.js and you are committed to building your own management interface anyway.
I worked through a version of this recently when a project needed a fully custom admin experience — call it an "Albany UI" — where the product requirements were specific enough that the standard Payload Admin Panel would have required heavy customization either way. In that case, running Payload purely as a backend engine through the Local API made the architecture cleaner, not messier.
The stack in that scenario looks like this:
code
/admin (or internal app):
Custom React/Vite UI
/api:
Express routes
backend engine:
Payload Local API
database:
PostgreSQL or MongoDB
And a typical route that bridges Express to Payload looks like this:
Your Express route handles the HTTP layer. Payload handles validation, hooks, access control, and database writes. The separation is clean because Payload's Local API was designed to be called this way.
What Payload's value actually is in this setup
When Payload runs without Next.js, you are not getting a CMS product. You are getting a backend framework with a code-first schema, a structured collection model, a database adapter layer, typed outputs, and an auth system that all work out of the box.
That is genuinely useful. If your alternative was building a custom Express backend from scratch with manual schema definitions, validation logic, access control middleware, and file upload handling, then Payload's Local API reduces that work substantially.
The value proposition shifts from "managed CMS with Admin UI" to "structured backend engine with generated types and a collection model you configure in code." For teams that know going in that they want a custom management interface, that trade-off is a reasonable one.
FAQ
Can you add the Payload Admin Panel back into this setup later?
Yes. You can migrate the backend to a Next.js project and regain the Admin Panel. Payload's Local API calls are compatible with the Next.js setup — the collection configs, hooks, and access control all transfer directly.
Does running Payload outside Next.js affect database compatibility?
No. Payload's database adapters for PostgreSQL and MongoDB work the same way regardless of whether you are running inside or outside Next.js.
Can you expose REST routes from a Payload-powered Express server?
Yes. You write your own Express route handlers and call Payload's Local API inside them. You are essentially building your own HTTP layer on top of Payload's backend operations.
Does Payload's auth system still work in Express?
Payload includes auth collections with built-in login, logout, token refresh, and password reset logic. Those operations are accessible through the Local API. Session handling between your custom UI and Express is something you wire up yourself, but the underlying auth logic runs through Payload.
What is the main reason to choose the Next.js setup instead?
The Admin Panel, the REST API, and the GraphQL API. If you need any of those three out of the box without building them yourself, the Next.js setup is the right call.
Conclusion
Payload outside Next.js is a legitimate architecture for the right project. The Local API runs fine in Express, collections and hooks work exactly as documented, and the backend engine gives you real value. The Admin Panel is the line — that part requires Next.js, and there is no workaround in the standard Payload v3 architecture.
If your project already plans for a custom management UI, or your team is building internal tooling where the default Admin Panel would need heavy modification anyway, this approach lets you use Payload's backend model without coupling to Next.js at the application layer.
If you want the full CMS product — Admin Panel, REST API, GraphQL, preview tooling — run Payload with Next.js the way the docs intend.
Let me know in the comments if you have questions about wiring Payload into an Express backend, and subscribe for more practical Payload and Next.js guides.
