Open by Default: How Varbase Keeps the Keys in Your Hands
Vendor lock-in is rarely a clause in a contract. It is the accumulated cost of features wired so deeply into a platform that removing them stops being realistic. Varbase is built so leaving stays possible.
Key Takeaways
- Vendor lock-in is features wired so deeply that removing them becomes prohibitively costly.
- Disable the Varbase Installer and your site keeps running on plain Drupal core.
- Recipes are a box you unpack: the configuration stays, the packaging does not.
- AI ships as recipes too. Adopt them or leave them out, and the rest carries on.
We have maintained Varbase, Vardot's open-source Drupal distribution, for more than a decade, and the answer we are proudest of is that you can add what you need, reshape what you want, and set aside what you don't, with your site running the whole time.
That is our philosophy, and we call it open by default. You should always be able to take what you need and put back what you don’t. Let me show you how Varbase is built to keep that promise at every level.
From One Big Bundle to Building Blocks
Drupal, like most software, used to be delivered as a single bulk package, with everything wired together. If you switched a feature on a newsletter, a web form, or a sharing widget and later changed your mind, taking it back out again took real effort. That was simply how software was distributed at the time.
The modern Drupal world works differently, and Varbase is built entirely on the new way. Features now arrive as building blocks you can add and remove on their own.
Open source takes it further: you hold the keys to costs, you can help shape the roadmap through the community, and your content lives in open, readable formats that you fully own. Those are freedoms you gain, and they’re the foundation everything else in Varbase is built on.
Open Source Is the First Freedom
Open source means anyone can read the code, modify it, and use it however they want. On top of that, you get a whole community that finds and fixes things together. Nobody owns the exit, and nobody can take the project away from you.
Varbase is Vardot’s standard for building a website on Drupal. We took the modules and configurations we assembled on almost every project, packaged them together, and placed them on top of a Drupal theme.
That is the whole idea: a tested, opinionated, open way to start. Because it is open source, you can read every line, fork it, and keep it running with or without us, a kind of ownership only open source gives you.
The Pillars on Top of Drupal
Varbase is a set of pillars built on top of Drupal. The pillars are modules we add on top of Drupal core, and we keep them strong by applying fixes and patches over time.
We also keep them flexible. We used to rely on Drupal’s Tour module, which was one of our pillars. When Drupal core moved on from it, we built a smooth path to migrate and update without depending on that pillar at all, so every site kept standing while the structure underneath it changed.
That is the part I care about most: adding a pillar is easy; the real craft is being able to change one out gracefully, with the building still standing.
Recipes: A Box You Unpack
The biggest change in the Drupal world and the reason I’m so optimistic about Varbase’s future is the recipe system. I was part of the Drupal recipes initiative for two years, so this one is close to my heart.
A recipe is flexible by design. Instead of a feature being wired permanently into your site, it arrives as its own recipe. Think of it as a box: you open it, take what you need, and then set the box aside.
The configuration stays; the packaging doesn’t. A modern distribution like Drupal CMS (the official name for the project once codenamed Starshot) is itself built from twenty or thirty of these recipes rather than one inseparable bundle.
This is why I happily tell people that Varbase gives you a choice at every step. We use recipes, and years ago I built a mechanism we call config bit it lets Varbase suggest and install modules without making them permanent dependencies.
A suggestion is an offer, not an obligation. If a feature isn’t for you, set it aside and move on, and the rest of your site carries on without noticing.
AI, Shipped As Recipes
The most recent test of this philosophy is AI. In Varbase 11, built on Drupal 11, AI features are powered by the Drupal AI module, an initiative Vardot proudly supports as a Gold Sponsor, and we deliver them the same way we now deliver everything else: as recipes you can adopt or leave out. I built two of them.
- The Varbase AI Context recipe installs the Context Control Center and pre-populates it with starter context items: Varbase brand knowledge, editorial standards, and AI safety limits.
- The Varbase AI Safety recipe bundles a complete AI safety stack on top of that: guardrails, logging, and observability for everything the AI does on your site.
The context items are worth pausing on because they apply the open-by-default idea to AI itself. One item I created is the Varbase Brand & Identity Guidelines: the terminology, capitalization, and tone of voice an AI assistant consults before it writes anything about Varbase on a Varbase site.
Those guidelines live as content on your site, open for you to read, edit, or replace with your own brand, and that is exactly what we expect teams to do. The Varbase guidelines ship as a working starter, and you shape the same structure around your own organization and projects.
The choice stays yours at every level. If AI has a place on your site, the recipes are ready; if it doesn’t, you simply leave them out, and the rest of Varbase carries on. A feature this new, delivered with this little entanglement, is the clearest proof I can offer that open by default is an architecture, not a slogan.
What If My Needs Change?
Sometimes a team’s needs change, and they ask what that means for Varbase. The answer is reassuring: disable the Varbase Installer, and your site keeps working.
Why? Because Varbase is the ultimate starter kit and not a modest one. Its drupal.org project page has described it as the ultimate Drupal CMS starter kit for years, more than a decade before Drupal CMS itself existed. Disabling the Varbase Installer doesn’t take your site down with it, and the other pieces can be set aside the same way if you choose. As of Drupal 10.3, you can uninstall an installation profile cleanly, which makes this smoother than ever.
I think of a website as a pocket where we place configurations and logs. Varbase fills that pocket with good things and keeps them all auto-updated for you, but it is always your pocket. We designed Varbase to be easy to grow with, and just as easy to grow beyond.
This isn’t only a theory. When Acquia retired its Lightning distribution, it did so with clear documentation and a clean wind-down, and teams moved on in a day or two. That is open source working exactly as it should: you can bring something to life, and you can hand it forward when the time comes. The whole lifecycle is yours.
Open Stays Open Because We Maintain It: 14 Years and Counting
A fair question to ask about any open-source project is what keeps it healthy. So let me be clear about what keeps Varbase current and well-maintained after fourteen years.
Varbase is a set of features nearly every Drupal site needs: a contact page, a blog, a home page, SEO, security, and editorial tools.
Keeping those maintained and updated is not one person’s hobby; it is Vardot’s responsibility as a company. We treat Varbase as the standard way we kickstart a Drupal site, which means it stays healthy because our own projects depend on it every day. Every feature has continuous integration behind it; if something breaks, CI catches it, and we fix it. Real clients, such as UNHCR and UNICEF, run on this, and that is what funds the discipline of maintaining it.
The official Varbase documentation is maintained with the same discipline, so the path forward is documented as carefully as the path in.
Why Building This Way Keeps You Free
Let me leave you with the picture I always come back to.
Varbase is a highway or a bridge. When the road ahead is bumpy, full of canyons and mountains that are slow to cross, you take the highway and arrive quickly, with no detours. Every new version is a newer, more modern highway, because we fold in the lessons we’ve learned and the latest best practices each time.
And the best highways always have exits. The recipe system means you can unpack everything from day one. You start a Varbase project, and underneath it is plain Drupal core the whole time. If you ever want to continue on Drupal core alone, the road is right there, already open. You don’t rebuild, you simply unpack.
That is what open by default means to me. Not a marketing line, but an architecture. Take what you need. Put back what you don’t. And always keep the keys to your own site.
If you want to see it for yourself, explore Varbase, browse the official documentation, or find the project on Drupal.org, all open and all yours to take as far as you like.
See it for yourself.
FAQs
CMS vendor lock-in is the situation where a platform's features, data formats, and licensing are entangled so tightly that removing a feature or migrating off the vendor becomes slow and expensive. With proprietary platforms, it includes both technical entanglement and business constraints like license fees and a roadmap the customer does not control.
Yes. Varbase is an installation profile, so disabling the Varbase Installer leaves the underlying site running on plain Drupal core. As of Drupal 10.3, an installation profile can be uninstalled cleanly. Individual modules and recipes can be removed the same way, and the rest of the site continues to function.
A Drupal recipe applies configuration and then steps out of the way. You unpack what a feature needs, and the configuration stays while the packaging does not. Because features arrive as separate recipes rather than one inseparable bundle, you can adopt or remove them individually without rebuilding the site.
Varbase is open source, so anyone can read, fork, and run the code with or without Vardot. Vardot maintains it as the standard way the company builds Drupal sites, backed by continuous integration. It has been maintained for fourteen years and runs on production sites including UNHCR, George Washington University, and the City of Detroit.
Varbase delivers AI as optional recipes. The Varbase AI Context recipe installs the Context Control Center with starter context items, and the Varbase AI Safety recipe adds guardrails, logging, and observability. If AI has no place on your site, you never install the recipes, and the rest of Varbase is unaffected.