Are recipes replacing Drupal installation profiles?
For many years, installation profiles have been the main way to set up a Drupal site. They define which modules are enabled, what configuration is applied, and often include demo content to help teams get started quickly. Well-known distributions have relied on this approach to deliver ready-made solutions for specific use cases. That approach made sense when most Drupal projects started from scratch. But that isn’t always the case today. Many teams are working with existing sites that are live and need changes. These might be new features, performance improvements, or updated design elements. Installation profiles are not built for that kind of workflow. Once they are applied during setup, they can’t be reused later.

At the same time, we still need solid starting points for users to launch a new site. This is where Site Templates come in. A Site Template bundles configuration, design, and content to deliver a complete website experience on installation. It builds on Recipes under the hood, offering a full setup that can be extended as needed. For teams working on active projects, Recipes allow features to be added or adjusted without having to rebuild anything. They’re also easier to share, maintain, and apply across multiple projects.
Together, they are opening up new options for how Drupal functionality can be packaged and delivered, which brings up a key question: where do installation profiles fit into all of this? Are they still useful in modern workflows, or are they being phased out in favor of newer, more flexible tools?

The Role Installation Profiles Have Played
For a long time, installation profiles filled an important gap in Drupal. They gave developers and site builders a way to bundle configuration and modules into a single starting point. This made it easier to spin up new sites that followed a familiar structure, especially when working across multiple projects or teams.
Agencies often relied on custom profiles to apply a base setup. This might include user roles, language settings, or standard content types. It saved time and helped keep projects consistent. Larger distributions used profiles to package full-featured products, allowing users to launch a working site without needing to set everything up manually.
But the design of installation profiles limits when and how they can be used. They only run during site installation. Once the site is up, the profile has no further role. It can't be reused, updated, or combined with other profiles later in the project. This makes installation profiles a one-time tool. They're useful at the start, but they don’t support changes or new features added later. Profiles also tend to include several features at once, which may not always fit what a specific project needs. In those cases, developers often end up turning things off or removing parts that aren't needed.
As Drupal projects have become more varied and less predictable, these limits have started to show. Installation profiles helped in the past, but today’s projects often need something more flexible that works throughout the site’s lifecycle.
What Drupal Recipes Bring to the Table
Recipes were introduced to solve some of the key limitations of installation profiles. Unlike profiles, they aren't tied to the installation process. A Recipe can be applied at any point during a project's life, whether the site is brand new or has been running for years.
Each Recipe defines a specific feature or set of related features. For example, a Recipe might set up a blog section, enable editorial workflows, or add a contact form with the necessary configuration. Once applied, the Recipe's changes become part of the site's configuration. There's nothing left running in the background, and no added maintenance overhead.
What makes Recipes useful is their flexibility. They can be created to focus on one feature at a time, making them easier to understand and reuse. Teams can apply just what they need, when they need it, instead of relying on larger bundles that may not fit the project.
Recipes also support a more collaborative and controlled way of working. Since they are made of standard configuration and well-known modules, they can be versioned, reviewed, and shared like any other part of a project. The integration with Drupal’s Checkpoint API makes it possible to create restore points before a Recipe is applied. This gives developers a rollback option if something doesn’t go as expected, which is especially helpful when adding new features to a live site.
As Drupal continues to evolve, Recipes are becoming a key part of how functionality is packaged, reused, and shared. They don’t replace every tool from earlier versions of Drupal, but they give site builders more control over how and when features are introduced, with less risk and more flexibility.
Recipes and Site Templates
While Recipes and Site Templates are separate concepts, they’re closely connected in how they work and what they aim to solve.
A Site Template provides a full starting point for a new Drupal site. It includes a design, layout, sample content, and a set of features that match a specific use case. This could be a portfolio, a nonprofit site, a small online store, or anything else that benefits from a complete setup at install time. Behind the scenes, Site Templates rely on Recipes to deliver those features. Each template combines multiple Recipes, along with a theme and any necessary configuration, to create a working site right after installation.
That might sound similar to what installation profiles have done in the past, but there are important differences. A Site Template is designed to be clearer, more maintainable, and easier to build upon. It separates features into Recipes, which can be reused in other contexts. The setup process is also more flexible. Instead of locking users into a predefined structure, the new installer experience allows some choices and optional features to be included or skipped, depending on the project’s needs.
In that sense, Recipes are the building blocks, and Site Templates are the assembled result. The advantage is that Recipes can also be reused independently. If a team likes the blog setup in a Site Template, they can take that Recipe and apply it to a different project without having to start from the template again. This makes the system more modular and gives developers more options depending on what they need.
This model also encourages clearer separation between design and functionality. A Recipe can define the structure and behavior of a feature, while the visual style is handled by the theme. That separation makes it easier to mix and match elements, which helps teams customize their sites without getting locked into one specific solution.
As Site Templates start to roll out more widely, they’ll likely become the go-to option for starting new projects. Recipes will serve both as the foundation of those templates and as tools for extending or improving existing sites. This shared foundation brings consistency across projects, without sacrificing the flexibility Drupal is known for.
Why This Shift Matters
The move from installation profiles to Recipes and Site Templates is more than just a technical change. It reflects a shift in how Drupal sites are planned, built, and maintained.
In the past, setting up a site meant committing to everything the installation profile came with. If it didn’t fit your needs exactly, there was often cleanup involved. And if you wanted to apply a feature to an existing site later, you were out of luck unless you built it manually. This created friction not only for developers, but also for teams that needed to adapt sites over time.
Recipes address that by giving people a way to apply specific features, when and where they’re needed. They support gradual growth, not just a single starting point. Teams can add functionality as the project evolves, which fits how many Drupal sites are managed today.
Site Templates, on the other hand, lower the barrier for getting started. They bundle good practices, common features, and a usable design into something ready to install. That helps new users see Drupal’s potential faster and gives experienced teams a clean foundation they don’t have to piece together themselves.
This shift also changes the way features are shared in the community. With Recipes and Site Templates, developers can contribute smaller, more focused solutions instead of maintaining large, complex distributions. That makes it easier to share improvements and keep them up to date.
It’s not just about flexibility; it’s about making Drupal work better for different types of users. From agencies managing multiple client sites to nonprofits and universities updating their own content, these tools open the door to workflows that feel more modern and less tied to how things used to be done.
Where Things Are Headed
Drupal is in the middle of a shift that affects not only how sites are built, but also how the community collaborates and shares solutions. Installation profiles still have a place in some workflows, especially for agencies or distributions that rely on tightly controlled setups during installation. But the momentum is clearly moving toward Recipes and Site Templates. These new tools are changing how developers and site builders approach both new and existing projects.
This change allows teams to work in smaller, more focused steps. Instead of setting everything up at once, it’s now easier to apply individual features over time. Site Templates give projects a strong, use-case-driven starting point. Recipes help teams make updates later without needing to rebuild or reconfigure things from scratch. This makes it easier to keep sites up to date and aligned with changing needs.
It also encourages more sharing within the community. A well-built Recipe can be used across many different projects, without extra baggage. A Site Template can show what’s possible for a specific audience, like nonprofits, schools, or small publishers, and become a model others can learn from. These formats are easier to understand, maintain, and improve together.
For developers, this shift brings more flexibility and fewer workarounds. For site builders, it offers more predictable tools. For newcomers, it lowers the barrier to getting started. And for the Drupal community as a whole, it opens the door to a more modular and accessible future.
If you’re interested in exploring how these modern tools can benefit your projects, our team is here to help.
Related posts

Accessibility has always been part of Drupal’s DNA but keeping it consistent across large sites takes more than good intentions. As standards evolve, developers and editors must balance WCAG compliance with design, content, and performance. This post looks at how automation and AI can make that work easier. From adding automated WCAG checks to CI pipelines to using AI tools that guide content editors, Drupal teams can spot problems earlier and fix them faster. At Cheppers, we’ve built a reliable, developer-friendly testing system for real Drupal projects, and we’re already preparing it for the next generation of WCAG guidelines.

Drupal is changing, and it feels like a return to what made it exciting in the first place. With tools like the Drupal CMS Launcher, Experience Builder, Site Templates and a potential Marketplace, there’s a clear focus on simplifying the process for newcomers, without the unnecessary barriers. These features have the potential to reshape how sites are built, especially for those just getting started, while still preserving the power and flexibility that make Drupal stand out.

