Payload CMS: Why we build our website platform on it

Until now, almost every website we look after had its own technical foundation. Most ran on WordPress, some on Laravel, others with Storyblok. That works, but it turns every security vulnerability into a separate task: we have to close it website by website. That is why, since September, we have been building Rocketsite, our own platform on which our customers' websites will run in future. It is based on Payload CMS.

What we wanted to solve

With WordPress, we see one main problem: attacks usually come through plugins that someone installed at some point. Every website has a different mix of them. Each one needs its own updates and its own checks.

Our goal was a shared core for all websites. It contains the things every website needs and that we do not want to build again for every project: content blocks, users and roles, forms with spam protection without cookies, search engine basics, backups and data protection. What sets each customer apart goes on top: the design, the selection of blocks and, if needed, custom content types.

Why Payload

Payload is a content management system that runs directly in Next.js. Next.js is the framework we also use to build the websites themselves. Admin and website are therefore one project, not two systems that have to talk to each other. Four points tipped the balance.

Open source. Payload is released under the MIT licence. You pay no licence fee, and we are not tied to any pricing model. Since 2025, the team behind Payload has been part of Figma. The source code is still under the MIT licence. Even if that were to change: the version we run remains usable.

Self-hosted in the EU. We run Payload on our own servers at Hetzner in Germany, with each customer in its own container. There is no third-party service your content passes through.

Your data in your database. Every customer gets their own database. Your content does not sit in one big pot with that of other customers. If you leave, you take your database with you.

Typed content models. With Payload, we describe each content type in code: which fields exist, which are required, what links to what. Types are generated from this automatically. The system therefore knows exactly what an offer looks like, for example. Errors such as a misnamed field show up during the build and not only when a visitor sees a broken page.

One core, many websites

The shared core is a software package with a version number. Each customer website has its own project that contains only the design, settings and content. When we release a new version of the core, every website automatically receives a proposed change.

Before it is accepted, automated checks run. The database changes are tested on an empty database, the website is built and key pages are loaded. Only then do we review the change and approve it. During rollout, the new version starts alongside the old one. Visitor traffic only switches over once it responds correctly. If something goes wrong, the old version stays online.

For you, this means a security update that we build into the core once reaches all websites in the same way. Nobody has to remember your site.

What matters to us is what the core is not: a site builder with a free layout. Editors combine prepared blocks. The data model of the blocks is the same for everyone, but we design their appearance anew for each customer. Two websites on Rocketsite therefore do not have to look alike.

Two projects where we are currently testing this

P·S·P GmbH and MediSafe. The two websites belong together. The P·S·P GmbH website previously ran on Storyblok, MediSafe on Laravel. In Rocketsite, both run in one shared instance. The team logs in once, selects the website and maintains it in the same system. Each site has its own design and its own selection of blocks. We migrated the content by script, and the page addresses stay the same. The customer is currently reviewing both sites on our test environment.

Dr. Sabine Wölbl, Leadership Performance. Here, pages made of blocks are not enough. The website works with offers, starting situations, areas of tension, practical examples and articles that refer to each other. Anyone who reads about a situation that fits their company ends up at the matching offers and articles. For this, we created custom content types. The core provides drafts, preview, search engine settings and a sitemap for each of them. The customer wanted a website she can expand over the years without having it reprogrammed each time. The site is currently being built.

When Storyblok remains the better choice

We are still a certified Storyblok partner. Rocketsite does not replace Storyblok in every case.

Storyblok is an online service. Neither you nor we have to take care of servers and operations. The Visual Editor is also closer to the finished page: you click on a heading in the preview and edit it right there. Payload also has a live preview, but you work in a form next to it.

We therefore still recommend Storyblok when a large editorial team works a lot on page layout and wants to stay as close to the page as possible. The same applies if you deliberately want to run your CMS independently of our hosting. What we have learned in Storyblok projects is in our article Storyblok in practice.

To be honest, Rocketsite is also still young. The first customer websites are still in acceptance testing. If you want a proven solution with a long track record today, Storyblok offers more experience.

Conclusion

Payload gives us what we need for a shared core: open code, operation on our own servers in the EU, a separate database for each customer and content types that fit a business exactly. For you, this means less sprawl, faster security updates and a website that belongs to you.

If your website should do more than display pages, you can read how we deliver such projects under Custom Web Solutions.