Need Drupal as a backend?
Headless Drupal with Next.js
Drupal 11 as a content API with a Next.js front end, and custom API development, built only where the decoupled model actually pays off.
This is for you if
- the same content has to feed a website, an app and a third-party channel from one editorial source
- your front-end team already works in React and wants to own the presentation layer
- the site has interactive features that a Drupal theme is fighting rather than supporting
- you need Drupal to expose or consume APIs for an integration that does not exist as a module
What is included
- Fit assessment first
- Five working days spent on your content model, your team and your roadmap. It has a fixed fee, quoted after a free initial review and deducted from whichever build you choose. If a conventional Drupal 11 theme would serve you better, the assessment says so.
- Drupal 11 as a content API
- Content types designed for reuse, exposed through JSON:API or GraphQL, with preview, revisions and editorial workflow kept intact for editors.
- Next.js front end
- A Next.js application that renders from the Drupal API, with static generation where content is stable, on-demand revalidation when editors publish, and draft preview for unpublished content.
- Custom modules and integrations
- Custom Drupal modules for business logic, webhooks and integrations with CRM, search, payment or identity providers, written to Drupal coding standards and covered by tests.
- Deployment and hosting for both halves
- Two applications, one deployment story. Drupal and Next.js are hosted in EU regions with staging environments and a runbook that explains how they connect.
- Thirty days of post-launch monitoring
- Build times, revalidation, API errors and Core Web Vitals are watched for a month after launch, and problems are fixed at no extra cost.
Decoupling Drupal from its front end is a real architectural choice with real costs. It suits some organisations well and most not at all. We build both kinds of site, so the advice you get is not shaped by which one we can sell.
Deciding whether it pays off
The assessment starts with three questions. Where does the content go: one website, or several channels that need the same source? Who will own the front end for the next five years: a team that writes React already, or a team that would have to hire for it? How do editors build pages today: from structured content types, or by composing layouts with Layout Builder and blocks?
If the answers are one website, no React capacity and Layout Builder, decoupling would cost you money and editor autonomy for no benefit. The assessment says that plainly and recommends a conventional Drupal 11 build instead. If the answers are multiple channels, a front-end team in place and structured content, the decoupled model starts to earn its keep, and the assessment sets out a scope, a fixed price and the engineer who will build it.
How the build is structured
Drupal 11 becomes the content backend. Content types are designed for reuse across channels, which usually means fewer, more structured types than a themed site would have. Content is exposed through JSON:API, which is in core, or GraphQL where the query patterns justify it. Moderation workflows, revisions and the media library work as before.
The Next.js application reads from that API. Pages whose content changes rarely are generated statically; when an editor publishes, Drupal notifies Next.js and the affected pages are regenerated on demand. Draft content is visible through Next.js draft mode so editors can preview before publishing. Metadata, sitemaps, redirects and structured data are generated from Drupal data on the Next.js side.
Custom API work, whether Drupal exposing endpoints for another system or consuming external services, is built as Drupal modules with tests, following Drupal coding standards, so a future Drupal team can maintain them without reading our minds.
What can go wrong
The common failure is a front end that slowly reimplements Drupal. Menus, breadcrumbs, redirects, access rules and image styles all exist in Drupal and are easy to rebuild badly in JavaScript. We map each of these early and decide, per feature, which side owns it. The second failure is preview: a decoupled site where editors cannot see what they are publishing loses their trust fast, so preview is built in the first weeks, not the last.
Performance is a third. Headless does not make a site fast by itself. Cache invalidation, image handling and API payload size are measured during the build, and Core Web Vitals are part of the launch checklist.
After launch
You receive both repositories, the hosting accounts and a runbook that explains how the two applications connect and deploy. Thirty days of monitoring cover build failures, revalidation errors and API problems. Ongoing work on either half fits in a support retainer, and we can optimise and manage the hosting for both halves. If you are unsure whether decoupling fits your case, the assessment exists to answer that question. Ask us.
Common questions
- When is headless Drupal the wrong choice?
- Often. A small editorial site with a few templates gains nothing and loses editor conveniences. A team without in-house or contracted front-end capacity ends up with two systems and one skill set. A site that relies heavily on Layout Builder for editors to compose pages loses that ability, because Layout Builder output is tied to Drupal's rendering. In all three cases we recommend a conventional Drupal 11 theme, and we build those too.
- What do editors lose and keep?
- They keep the Drupal editing interface, revisions, moderation workflow, media library and CKEditor 5. They lose in-place editing and page composition tools such as Layout Builder, unless the front end is built to interpret layout data, which is extra work. Preview is kept: Next.js draft mode shows unpublished content from Drupal.
- Does Next.js replace Drupal's theme layer entirely?
- Yes. Drupal serves data, not HTML. Twig templates, the theme, and Drupal's render cache are no longer in the request path for visitors. That is why the fit assessment matters: it moves a lot of responsibility out of Drupal and into a codebase your team has to own.
- What about search, forms and SEO?
- Search is served by an index such as Search API with a backend the front end queries directly, or by an external service. Forms are built in Next.js and post to Drupal or a dedicated endpoint. Metadata, structured data, sitemaps and redirects are generated by the Next.js side from Drupal data and are checked as part of launch, the same as on any of our sites.
Not sure which one you need?
Send us the URL and a sentence about what is bothering you. We will tell you which service fits, or whether you need one at all. The first reply is free and commits you to nothing.