Drupal As A Service: A Year In Open Source

It's been about a year since I started building and maintaining the Drupal service integration for NixOS, and the next nixpkgs stable release is comming up this May, so it seems like a good time to take stock and talk about what has been going on with this project in that time.

Changes Since June 2025

Sole Maintainer

Not too long after it's release, I became the only maintainer on this project. Pol Dellaiera (username drupol on GitHub) created the first unfinished Drupal service and we worked together pretty closely to get the first PR merged. But soon after, he took himself off of the project.

I think this was about the time he ran for the Nix Steering Comittie and wanted to scale back his involvement in nix as a developer.

Since then Pol has helped out a lot with code review and mentorship along the way.

Automated Package Tests

The Drupal package in nixpkgs now has some passthru tests that check to make sure the base package, which just comes from Drupal Core, is installable under some basic conditions.

This has been really helpful for expediting some of the busy work involved in testing Drupal installations.

Automated Upgrades

I wrote an update script so the ryantm bot can fetch and package the latest release from Drupal core each week.

I've made it a policy to try and keep the latest Drupal security release in the stable branch of nixpkgs, while making sure unstable always has whatever the latest release is.

This makes it possible for me to package the latest Drupal release within a week.

Support For Custom Drupal Packages

From my experience working with Drupal, most people are going to want to package their own Drupal and use git or some other VCS to manage updates, config, and custom development.

So, I did a flury of updates over the last two months to help make that possible.

Here are the noteworthy changes in the service module:

• Added support for detecting a webroot. The Drupal core package doesn't have a webroot, it just serves all of its content out of the project root, but most custom Drupal projects will have a webroot of some sort by convention. So it makes sense to have an nix option (conveniently called webRoot) that makes switching between webroot and non-webroot project possible. The value is just a simple file path with a leading slash relative to the project root, but it helps with a bunch of path related work in the service module.
• Refactored the way the sites directory gets mounted. The sites directory is a beast. It has both public and private content stored in it side-by-side and nearly all of it needs to be writeable by Drupal at install time. Initially, I copied the entire sites directory into the user-managed state directory in /var/lib, and then symlinked up the files directory and the settings file. But this was too fragile and didn't stay updated with changes from the upstream code over time. So instead, I made a new derivation for the sites directory code (sans the user uploads in files) and used rsync to synchronize it with the state directory during each rebuild. This allowed me to symlink the entire sites directory back up to the Drupal package in /nix/store.
• Likewise, I did something similar for the config sync directory. Not all Drupal projects use a config sync directory. Some folks just use database bakcups and never import or export any database updates using files. So this tool needed an new option called configRoot, which is used to find the location of the config directory in the project's source code. If a value for this option is provided, a new derivation gets built that handles rsyncing the code from the derivation into the state directory. This gives admins the power to import, export, and manually override config files (just in case) all in one place.

Bugfixes and More Bugfixes

Along with all of the new features, I also caught and fixed a few bugs along the way which I'm struggling to recal. No show stoppers, though, other than debugging the automatic updates routine a few times because I noticed it would go eerily silent for weeks at a time. This experience was helpful for learning about the quirks of the Drupal core release tags feed and the wonderful xmlstarlet tool. Sometimes, Drupal would order release tags for updates to older versions before updates to newer versions, and that would cause the updater to get confused.

Most of the debugging work outside of that one issue was in the service of allowing the Drupal service to be able to run custom Drupal packages, which have a lot more complexity than the Drupal core distribution.

Finding A Home on Drupal.org

I've also set up a project on Drupal.org to help track todos and set goals for this project without having to send Drupalers to the nixpkgs issue queue for support. 

I'm also hoping to set aside some time to write a comprehensive guide on how to use Drupal with NixOS once I get a little more time. I think this will be a really helpful resource once more people start taking interest in the project.

Looking Forward

I'm getting really excited about the possibilities that this tool will bring, especially now that it is staring to offer some built-in solutions for continuous deployment and integration.

One thing I want to get figured out is a small but annoying bug with the state directory init script. Each Drupal site gets its own shell script that preps the state directory in between (some) rebuilds and reboots, but it isn't firing at one all-important time: directly after the first build on a running system. This makes it so if you are testing out the tool you have to reboot your system to get it to fire for the first time.

A small inconvenience, but enough of a pain that it needs fixing. I'm currently looking hard at the activationScripts option, but that will involve debugging the bash script to a point where it never throws errors, and can handle unexpected states with grace. Plus, I would need to extend the activation script tool for each Drupal site, which gets me worried about delays in boot time.

It's not quite there yet, but I feel it getting closer to that goal with each update.

Another goal-- I want to provide support to the binary scripts that get packaged in the vendor directory. Currently, you would need to know the derivstion hash and be able to call it up to access things like drush and behat on a per-site basis. It would be better if there was some interface that let's you shell into just one site at a time. A Drupal shell anyone? That would be a good project to make and ship with nix at some point.

Sharing This Project With More People

Also, I suppose this is a good as time as any to announce that I will he talking about this project at DrupalSouth in Wellington NZ next month! It'll be nice to share the work I'm doing with the first group of people who will actually be able to try it out. I'll be speaking in breakout room 2 first thing in May 14th if anyone has a mind to visit. It'll probably also be recorded to some extent. The talk title is Reproducible Drupal Environments The Easy Way: A Hands-On Look At Using Drupal With Nix & Nixos. I'm looking forward to getting this project in front of some Drupalers who are (or will soon be) interested in functional declarative software.