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 deploying means 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 in one binary. PHP, Node.js and the database come with it, so there's nothing else 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 with a one-time login link, and keeps serving in the background. ./drupacked-demo stop stops it. Your content lives in the data folder next to the binary. Copy that folder and you have a backup.

On Windows, from PowerShell:

irm https://drupack.tresbien.tech/demo.ps1 | iex
.\drupacked-demo.exe

Serve your own project

Install Drupack once, then start it from a Drupal Composer project:

$ curl -fsSL https://drupack.tresbien.tech/install.sh | sh
$ mkdir -p ~/.local/bin && mv drupack ~/.local/bin/
$ cd path/to/your/project
$ drupack

On Windows, run irm https://drupack.tresbien.tech/install.ps1 | iex in PowerShell. The script checks the download's SHA-256 and prints the command that puts it on your PATH.

A project can also pin its Drupack version with Composer:

$ composer require --dev 'drupal/drupack:^1.0@beta'
$ 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 the site, and drupack stop stops the server. When the project's composer.lock needs a PHP extension Drupack doesn't ship, Drupack 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 that database.

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 build on GitHub's runners. A site that needs a PHP extension Drupack doesn't ship builds for Linux only for now, since 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 trust sets up HTTPS on your own machine. Anywhere else Drupack serves plain HTTP. Put a TLS proxy in front of it before anyone logs in from another computer.

What's inside

Bundling everything makes Drupack responsible for PHP and FrankenPHP security releases. Every day a job checks for new patch releases, builds and tests them on every platform, and publishes a release only when 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. 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 a build that loads anything else fails the tests.

What it doesn't do

• Backups and drush updatedb stay your job, like on any other host.
• SQLite fits one person on a laptop. I measured 377 requests per second with one user and 139 with 64 users, and the same binary on MariaDB reached 5,050. For anything bigger, start with --database mysql or --database pgsql: 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. 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 want:

1. A release that walks you through the 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. There are PHP, FrankenPHP and Drupal releases to ship every day, 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 I review every change. Most of the code was written with help from LLMs. Before each release the test suite runs the built binary on Linux, macOS and Windows, and nothing ships unless it passes.