Drupack

Running Drupal locally usually means Docker and a few containers, or installing PHP and a web server yourself. Drupack is one executable with FrankenPHP, PHP and Caddy configured for Drupal. It serves a Drupal project you already have, or packs your site's code on top of that runtime so a deploy becomes moving one file. Linux, macOS and Windows.

Try it in 5 minutes

The Drupacked Demo is Drupal CMS on the Mercury demo recipe, with WordPal and Agent Access, packed as one binary. No PHP, Node.js or database to install.

$ mkdir my-site && cd my-site 
$ curl -fsSL https://drupack.tresbien.tech/demo.sh | sh 
$ ./drupacked-demo

The first start installs the site on SQLite, opens your browser on the dashboard with a one-time login link, and keeps serving in the background. ./drupacked-demo stop stops it. Your content lives in data next to the binary, copy that folder to back the site up. On Windows, install from PowerShell with irm https://drupack.tresbien.tech/demo.ps1 | iex and run .\drupacked-demo.exe.

Serve your own project

From a Drupal Composer project:

$ composer require --dev 'drupal/drupack:^1.0@alpha' 
$ vendor/bin/drupack-install 
$ ./drupack

Drupack serves the project on http://127.0.0.1:3787 with the project's own settings.php: your database, your files, your hash salt. It writes nothing into the project. ./drupack drush runs the project's Drush on the same PHP that serves it, and ./drupack stop stops the server. If the project's composer.lock needs a PHP extension Drupack doesn't ship, it refuses to start and names the extension and the packages that need it, so you find out before deploying. If you already use DDEV, point settings.local.php at the database port DDEV publishes and Drupack serves against it.

Package and deploy your site

Drupack can also build an executable of your whole site: the runtime plus your Composer project, and Node.js if the site needs it. A drupack.yml next to your composer.json names the executable and the platforms to build. Deploying is then moving one file to the server, pointing it at the production database and running the database updates. The server runs the same PHP, extensions and web server config you tested with.

Linux builds run on GitHub, Gitea or any CI that runs a container, macOS and Windows builds on GitHub's runners. A site that needs a PHP extension Drupack doesn't ship builds for Linux only today, because that extension means compiling PHP for the site on each system. Build your own site has the setup, and the Drupacked Demo repository is a complete example.

Drupack serves plain HTTP. Put a TLS proxy in front of it before anyone logs in from another computer.

What's inside

Bundling everything means Drupack is responsible for PHP and FrankenPHP security releases, so I automated it. Every day a job checks for new patch releases, builds and tests them on every platform, and publishes a release only if the whole test suite passes. The demo gets the same treatment for Drupal core and contrib. If you serve your own project, Composer keeps updating your Drupal like it always did.

drupack --version lists every component and its version. Each release publishes SHA-256 checksums, GitHub build attestations and a CycloneDX SBOM, and the install scripts and drupack self-update check the checksum before they replace anything. The PHP extensions come from one list that says why each one is there, and the tests fail a build that loads anything else.

What it doesn't do

• The database and update hooks are exactly as hard as on any other host, no easier, no harder. Backups and drush updatedb stay your job.
• SQLite fits one person on a laptop. I measured 377 requests per second with one user and 139 with 64, the same binary on MariaDB reached 5,050. Start with --database mysql or --database pgsql for anything bigger, a SQLite site can't move to another database yet.
• Drupack's PHP has no Xdebug, so step debugging stays on your usual setup.
• The binaries aren't signed on macOS and Windows. The install scripts avoid the warning, but a file downloaded by hand gets stopped by Gatekeeper or SmartScreen the first time, and the README says how to get past it.

Status

Beta. My own site runs on it, and I'd use it today to try Drupal, serve a project locally, or host a small site on a cheap VPS (the demo runs in 512 MB). Before a stable 1.0 I'd want:

1. A newer release that walks you through pending database updates of an existing site.
2. A start that checks the database answers before it says the site is ready.
3. macOS and Windows builds for sites that need a PHP extension Drupack doesn't ship.
4. More people running it on real sites, and telling me what breaks.

Help wanted

The test suite tells me Drupack starts on every platform, it can't tell me what breaks on your site. If you serve or package a real project with it, open an issue with what went wrong, especially on macOS and Windows.

I'm also looking for a co-maintainer or two, and for sponsored time. Every day there are PHP, FrankenPHP and Drupal releases to ship, and keeping three platforms green takes some effort. If your company is interested, let me know in the issue queue or in #drupal Slack.

About the code

I designed Drupack and review every change, and most of the code was written with help from LLMs. The test suite runs the built binary on every platform before a release, which is how I keep that honest.