Théodore Biadala on Building Drupack, Simplifying Drupal Hosting and What Comes Next

Running a Drupal website should not require assembling an entire hosting environment first. That is the problem Théodore Biadala is trying to address with Drupack, an experimental tool that combines PHP, FrankenPHP, and the Caddy web server into a single executable. The project can serve an existing Drupal installation or package a website's application code and runtime into one deployable file. Speaking to The DropTimes, Théodore outlined the engineering decisions behind Drupack, its approach to security and cross-platform consistency, and the work that remains before the tool can become a dependable option for more Drupal developers.

The goal is to make Drupal easier to start with while simplifying how existing websites are served and deployed. Drupack targets two groups: people exploring Drupal for the first time and developers or small agencies that want to run their projects without configuring a separate PHP installation, web server, or Docker-based environment. Its downloadable runtime is designed to remove those initial requirements, but it does not replace the tools and responsibilities involved in developing, maintaining, and operating a Drupal website.

He explained that although he appreciates DDEV, which provides container-based development environments, he dislikes needing Docker and multiple containers simply to serve a local website. His preference is for an executable that can start an application with minimal setup while leaving developers free to manage their projects through familiar workflows.

Théodore, a Drupal core JavaScript maintainer and founder of Très Bien Tech, has been interested in reducing Drupal's infrastructure requirements for several years. A blog post published on 30 May 2022 examined whether Drupal could become more practical for small websites with limited hosting resources. He discussed SQLite, static site generation, integrated web servers and the possibility of distributing Drupal as a standalone executable. His concern was that Drupal's content modelling and extensibility could suit smaller projects, but the effort and expense of running the application made it less attractive for some of those use cases.

He revisited the subject in 2024 after encountering FrankenPHP, which can replace a conventional Apache or Nginx and PHP-FPM arrangement and embed PHP applications into executables. The technology brought his earlier ideas about integrated hosting closer to something that could be implemented. By September 2026, he had released the first version of Drupack and described it in a blog post titled "Drupack: Drupal infrastructure in a single binary," published on 22 September 2026. That initial demonstration made it possible to download an executable and start a Drupal CMS website using SQLite, without separately installing PHP, Apache or Docker.

The project has since developed beyond that introductory demonstration. Théodore explained that Drupack performs two distinct functions, comparable to the capabilities available through FrankenPHP. The first provides an executable containing FrankenPHP, PHP and Caddy, configured to serve Drupal. Developers can add it to an existing Composer project, retain the project's configuration and run the website using the bundled runtime. The second combines the same runtime with the application's code, and Node.js when required, to create an executable that can be transferred and deployed as a single file.

This separation is central to Drupack's design. Developers do not need to adopt a new project structure or abandon Composer to use it. An existing Drupal installation continues to manage its dependencies, database settings, files and configuration through its normal project files. Drupack reads those settings and serves the application. Its PHP runtime also executes Drush, allowing developers to run Drupal command-line operations using the same PHP version and extensions that serve the website.

For regular development, Théodore recommends beginning with a conventional Composer-managed Drupal project rather than extending the introductory demonstration. A developer can add Drupack as a project dependency, install the matching executable and use it to serve the application locally. MySQL and PostgreSQL remain available through Drupal's configuration, while Composer and PHPUnit continue to operate in the environments where developers already use them. Teams with existing DDEV environments can also point Drupack at a database exposed by DDEV, allowing the tools to operate against the same website.

The project's demonstration package serves a different purpose. The Drupacked Demo provides a preconfigured Drupal CMS website built around the Mercury Demo recipe, with WordPal and the Agent Access recipe included. A user downloads the appropriate executable for Linux, macOS or Windows and starts it without installing PHP, Node.js or a separate database server. The initial run creates a SQLite-backed Drupal installation, starts the local server and opens the browser with a one-time login link. The process provides a working demonstration without requiring the user to understand Drupal's hosting infrastructure first.

Although the demonstration is distributed as one executable, its persistent website data is not locked inside that file. Drupack stores the SQLite database and other site data in a directory beside the executable. That directory can be copied to preserve the demonstration's state. The distinction becomes more important with deployed applications, where uploaded files, database contents and other writable data must survive application updates. Packaging the code simplifies how a release is distributed, but does not eliminate the need to maintain persistent data separately.

Drupack's application packaging process is intended to extend that principle to existing websites. Developers describe the site using a drupack.yml file alongside the Composer project. The configuration identifies the executable name, target platforms and other build requirements. It can also specify a Drupal recipe for initial installation, site settings, writable directories, additional PHP extensions and whether Node.js is required. The build process then creates platform-specific executables containing the application and the runtime needed to serve it.

For an established Drupal site, the packaged executable can connect to an existing MySQL or PostgreSQL database rather than installing another copy of Drupal. This makes it possible to use the same application runtime across development and deployment. Théodore sees that consistency as an important advantage: the server can use the PHP version, bundled extensions and web-server configuration selected during packaging, reducing differences between the application environment that was tested and the one used to serve the deployed site.

Moving the executable, however, is not the same as moving the complete website. The production database still needs to exist and be configured, persistent files must be retained, and database updates must be performed when application changes require them. Backups, operational monitoring and routine site administration also remain outside the single-file deployment process. Théodore emphasised that these responsibilities are not made simpler merely by changing how the runtime is distributed.

His distinction is that Drupack simplifies the application server and deployment artefact, not the underlying responsibilities associated with running Drupal. Administrators must still manage database backups and execute updates such as drush updatedb when necessary.

Database choice is particularly important because Drupack uses SQLite to make the introductory experience straightforward. SQLite requires no separate database server, making it suitable for a person experimenting with Drupal on a laptop. Théodore nevertheless considers MySQL or PostgreSQL more appropriate for larger or more demanding workloads, and he shared measurements from his own testing to illustrate the difference.

Using SQLite, he recorded 377 requests per second with one user and 139 requests per second with 64 concurrent users. The same Drupack binary connected to MariaDB reached 5,050 requests per second. These are measurements reported by Théodore, rather than independently verified Drupal performance benchmarks, and the interview does not provide enough information about the test conditions to generalise the results to other websites. They nevertheless explain why his recommended database configuration changes when moving beyond a simple local demonstration.

That transition currently exposes another limitation. Users who begin with a SQLite demonstration cannot yet migrate their existing Drupack site to MySQL or PostgreSQL through a built-in conversion process while preserving its content and configuration. They must start again with the new database system. Théodore is working on a mechanism that would allow existing sites to move between database backends with their data intact. He is also interested in feedback about how developers expect that migration to work, particularly when moving from an exploratory installation to ongoing development.

Development workflows have other boundaries. Drupack's bundled PHP does not include Xdebug, so developers who require step debugging must continue using their usual debugging environment. The project can run Drush through its PHP runtime and serve a site against an existing database, but it is not intended to replace every function provided by DDEV or other established development setups. Théodore's approach is to reduce the infrastructure needed to serve Drupal while keeping specialised development tools available where they already work.

PHP extension compatibility is another consideration. Drupal projects can depend on extensions not included in Drupack's standard runtime. When serving an existing Composer-managed project, Drupack examines the locked dependencies and refuses to start if a required extension is unavailable. The error identifies the missing extension and the packages that require it. This is intended to reveal a compatibility problem before deployment rather than allow the application to start with an incomplete runtime.

Packaging such a project requires more work. Drupack supports compiling additional PHP extensions into custom Linux runtimes, but the same process does not yet produce equivalent macOS and Windows builds. Théodore explained that supporting an additional extension means compiling PHP with that extension for each target environment, rather than simply reusing the published runtime. Providing cross-platform builds for these projects is one of the improvements he wants to complete.

The security implications of bundling an application server have also influenced Drupack's development. Conventional Drupal hosting environments receive PHP and web-server updates through their respective package management, hosting or container workflows. Drupack instead distributes its own PHP and FrankenPHP runtime, making the project responsible for producing updated executables when those components receive security fixes.

Théodore said he has automated this responsibility. A scheduled job checks daily for new PHP and FrankenPHP patch releases, builds updated binaries for the supported platforms and runs the test suite before publishing a release. If the tests fail, the release is not published through that process. The Drupacked Demo has similar automation for updates to Drupal core and contributed dependencies. The intention is to reduce the interval between an upstream security fix and an updated Drupack release without requiring him to perform every build and publication manually.

The arrangement does not mean that every deployed Drupack website automatically receives new application code or security patches. Developers serving their own Composer projects continue to update Drupal core and contributed modules through Composer. Drupack provides runtime update mechanisms, including a self-update command that checks downloads before replacing the installed executable. Project-managed installations can receive updated Drupack versions through their Composer workflow. The availability of an updated executable therefore remains distinct from the work required to apply and operate that update on a particular website.

Théodore has introduced further measures intended to make the distributed binaries verifiable and their contents transparent. Each release publishes SHA-256 checksums and GitHub build attestations, allowing downloads to be checked and providing information about where the binaries were built. A CycloneDX software bill of materials identifies bundled components. The executable can report the versions of its included software, while a defined PHP extension list records which extensions are present and the reasons for including them.

The test suite checks that the loaded PHP extensions match this approved list, rejecting builds that unexpectedly include additional extensions. Drupack's installation and self-update mechanisms also verify download checksums before replacing files. Together, these measures address different parts of the software distribution process, including reproducible build information, component visibility, and download integrity. They do not, however, eliminate every risk associated with executing bundled application code.

One unresolved issue is native code signing on macOS and Windows. Théodore acknowledged that binaries downloaded manually can be stopped by Apple's Gatekeeper or Microsoft's SmartScreen when first opened. He said the installation scripts are designed to avoid those initial warnings, while the documentation describes the current procedures for running manually downloaded files. Native signing remains unavailable, and he has not committed to its cost without better understanding whether users consider it a priority.

Production access also requires attention to transport security. Drupack serves plain HTTP by default, and the project documentation advises placing a TLS-enabled reverse proxy in front of an application before anyone logs in from another computer. Although the runtime includes Caddy, that does not mean every Drupack deployment automatically has HTTPS configured for external access. Developers remain responsible for securing the public connection and operating the website appropriately for its environment.

Platform consistency is an equally significant part of the engineering effort. Drupack publishes builds for Linux, macOS and Windows, with each platform receiving a release built from the same source commit. Théodore said the binaries undergo a shared test suite before publication, covering installation, first startup, one-time login links, shutdown, Node.js functionality and PHP extension availability. This is a more developed testing arrangement than the initial September experiment, when his blog post acknowledged that he had not personally tested the macOS builds.

The supported environments are nevertheless not identical. Linux receives the most extensive coverage, particularly for tests involving MySQL, PostgreSQL, offline startup and interrupted installations. Théodore explained that these scenarios are currently tested primarily on Linux because they depend on Docker-based test infrastructure. The requirement applies to those development and testing scenarios, not to the normal use of Drupack's downloaded executable, which is designed to run without Docker.

Linux also introduces differences between runtime builds. Drupack provides builds suited to systems using glibc and musl, the latter being relevant to Alpine Linux and other lightweight environments. The Alpine-compatible build does not carry Node.js, even when other supported platform builds can include it. For applications that require Node.js during site operation or Drush commands, that distinction affects which executable can satisfy the project's requirements.

The packaging documentation identifies additional constraints for developers building their own applications. Linux builds can run through compatible container-based continuous integration systems, while macOS and Windows application builds use GitHub runners. Projects with extra PHP extensions currently need custom Linux runtime compilation. Application developers must also declare directories that the packaged site needs to write to at runtime so that changes can be preserved outside the immutable application contents. These requirements mean the simple download experience of Drupacked Demo does not necessarily describe the work involved in packaging every existing Drupal project.

Drupack also contains an optional route for real-time functionality. Its application packaging documentation describes support for a Mercure hub, which can be enabled through project configuration to distribute live updates. This capability connects with Théodore's longer-standing interest in making modern PHP application servers more useful to Drupal, including scenarios that would otherwise require a separate service for real-time communication. Whether a particular site benefits from that capability depends on its own implementation and requirements.

The project's current maturity is an important consideration for anyone evaluating it. Drupal.org lists Drupack 1.0.0-beta13, released on 31 October 2026, and identifies the project as minimally maintained, with no supported stable release. Théodore considers it suitable for trying Drupal, serving projects locally and experimenting with smaller hosting deployments. His own website already runs on the technology, which provides a practical use case, but that experience does not establish reliability across other production applications and environments.

Before a stable 1.0 release, Théodore wants the tool to provide clearer guidance when an existing Drupal site has pending database updates and to verify database connectivity before reporting that a website is ready. He also wants macOS and Windows support for packaged sites requiring additional PHP extensions, alongside broader real-world testing. These improvements are aimed at making startup behaviour more dependable and reducing the gap between a successful automated test and the experience of running an individual Drupal project.

The project documentation also discloses that much of Drupack's code was written with assistance from large language models. Théodore states that he designed the project and reviews its changes, using automated tests against the compiled executables as a major part of the verification process. The approach places particular importance on testing the actual binaries rather than relying only on source-code checks. It also leaves the project's broader reliability dependent on the quality of those tests and feedback from users running applications that the test suite does not cover.

Maintaining the project across three operating systems introduces a workload of its own. Théodore has invited developers to report problems when serving or packaging real projects, particularly on macOS and Windows, where he wants more practical evidence. He is also looking for additional maintainers and sponsored development time. Automated releases reduce recurring manual work, but keeping the build systems, dependencies, and platform tests functioning still requires ongoing maintenance.

For the coming year, Théodore's measure of success is adoption by developers using Drupack for their own applications rather than demonstrations alone. He wants other people to package their sites and deploy them using the same process that he uses. Another objective is to have security-related PHP, FrankenPHP and Drupal core releases available to Drupack users within days, without depending on manual intervention for every release. He also wants someone unfamiliar with Drupal to be able to obtain a running website from one download and a small number of commands, regardless of whether they use Linux, Windows or macOS.

He is interested in how the same packaging approach could make experimental Drupal technologies easier to distribute. The growing number of artificial intelligence demonstrations built around Drupal has raised a practical question for him: whether sharing a ready-to-run application would sometimes be more useful than sharing only a recipe that requires additional installation and configuration.

The Drupacked Demo already includes the Agent Access recipe, providing an example of how agent-oriented Drupal functionality can be included in a preconfigured application. He believes AI agents could benefit from downloading a working executable and beginning their tasks immediately rather than first preparing the software environment needed to run the demonstration.

Drupal Canvas, previously known as Experience Builder, is another example he raised. Early versions required substantial effort to experiment with, and Théodore believes a packaged demonstration could make similar technologies easier to evaluate across operating systems. A small set of configuration files could potentially define the necessary runtime and application dependencies. Such packaging would be an additional distribution option rather than a replacement for Drupal recipes, which remain useful for configuring and extending ordinary Drupal installations.

His longer-term interest is not limited to Drupack becoming another development environment. Théodore would like FrankenPHP itself to become a recommended way of hosting Drupal websites, partly because of its performance characteristics and support for real-time capabilities. This remains his personal ambition rather than an announced Drupal project decision. Drupack serves as a practical experiment in how that application-server model might support Drupal locally, on an inexpensive virtual private server or as a more portable application package.

The project now offers a way to test that idea against actual Drupal development and deployment requirements. Its executable can remove much of the work involved in assembling an application runtime, but the same project must still confront database migration, security maintenance, platform differences, debugging, and the responsibilities of production hosting. For Théodore, the next stage is to establish whether other developers can use the approach reliably on their own sites, and whether the automation and packaging model can remain manageable as those applications become more complex.

More information about Drupack, its installation instructions, available releases, supported platforms, technical documentation and development plans can be found on the official Drupack project page on Drupal.org.