Devilbox

What Devilbox actually is

Devilbox is a free, open-source, Docker-based local development environment for PHP stacks. It is not a hosting product, and we review it here because it sits where our WordPress and PHP readers actually spend their time: on the laptop, before anything is deployed anywhere. The project was created on GitHub in October 2016 by the developer known as cytopia, out of a very specific frustration — the maintainer was juggling around thirty PHP projects with different version and configuration requirements, and bouncing between local macOS and various Linux virtual machines to satisfy each one. Devilbox is the answer to that: a single Docker Compose stack in which every project can have its own PHP version, its own database, and its own hostname, without any manual configuration.

The way it works is that you clone the repository, start the containers you need, and drop project directories into a shared folder. Vhosts, DNS entries and SSL certificates are generated automatically for every project — unlimited projects, each reachable on its own subdomain of dvl.to with browser-trusted HTTPS out of the box. Only the web server and PHP containers are mandatory; everything else is opt-in. That zero-configuration promise is the point of the project, and after several years of using this category of tool, we consider Devilbox one of the most complete realisations of it.

Pricing: what you really pay

The software costs nothing. It is MIT-licensed, the source is public, and there is no paid tier, no cloud account, and no telemetry that we are aware of. The real costs are indirect, and they are the ones to plan for. Docker on a laptop consumes RAM and disk aggressively once you start stacking containers — a full Devilbox with Nginx, PHP-FPM, MySQL, MariaDB, Redis, ElasticSearch and the tooling containers can eat 6 to 8 GB of memory comfortably. On a 16 GB machine that is the difference between a smooth day and a swap-bound one, and on an 8 GB machine it is a non-starter for the full stack.

There is also your time. Devilbox saves configuration time but demands Docker literacy, and there is no support contract behind it — help comes from GitHub issues and community answers when they exist. If your organisation values a supported toolchain, the honest way to price Devilbox is $0 in licence fees plus the hours an engineer spends learning Compose semantics and debugging volume permissions. For a freelance developer or an agency running many client sites, that trade is usually excellent. For a single non-technical site owner who just wants WordPress running locally, a prebuilt local WordPress app is the better use of an afternoon.

Performance & infrastructure

The container catalogue is the strongest argument for Devilbox. Pre-configured images cover the full LEMP and LAMP range plus adjacent stacks: Apache or Nginx (with HAProxy and Varnish as accelerators), PHP versions spanning 5.2 all the way to 8.2 with per-project switching, and databases including MariaDB, MySQL, PerconaDB, PostgreSQL, MongoDB and Redis, alongside Memcached, Solr, RabbitMQ and the ElasticSearch/Logstash/Kibana trio. Language backends extend past PHP to Node.js, Python (Flask) and Golang via the automated reverse proxy, and the utility row includes Bind DNS, MailHog for email interception, Ngrok for tunneling, and Blackfire for profiling.

The developer tooling is what makes it feel finished. phpMyAdmin, Adminer, phpPgAdmin and phpRedMind ship for database management; Xdebug, XHProf and an OpCache GUI handle debugging and profiling; project directories auto-register as vhosts with generated certificates and DNS records, and the stack synchronises file ownership between the host and containers — the perennial Docker pain point on macOS and Linux — in an automated way. Projects can talk to each other, so you can emulate microservice architectures locally. The images themselves are built and tested nightly through an automated Ansible-based pipeline with CI coverage, on both amd64 and arm64.

Performance in practice is as good as the host machine allows. There is no benchmarking of Devilbox in our /benchmarks programme — it is local tooling, not infrastructure — and we would not trust any vendor-independent speed claims for it either way. What matters is that the stack is reproducible: the same Compose file that runs your project today runs it on a colleague's machine, which is the entire value proposition of containerising local development.

The workflow details are worth spelling out, because they are what you actually touch daily. Starting a project is a docker-compose up httpd php mysql away; you drop a directory with an htdocs folder into the shared volume and it appears at its own hostname immediately, with a virtual-host control page listing every project for quick jumping. Service versions are selected through the .env file — flip a PHP or database version, restart that container, and the rest of the stack keeps running, which is exactly the behaviour that makes multi-project maintenance bearable. Containers can be started selectively, added or removed while the stack is running, or all at once, and the whole setup is portable across Linux, macOS and Windows because everything of consequence lives inside Docker rather than on the host.

The email interception and debugging story deserves a second look too. MailHog captures every outbound message the stack sends, so testing a WordPress contact form or a password-reset flow never involves a real inbox or a risk of mailing a client by accident. Xdebug and Blackfire cover interactive debugging and profiling respectively, with an OpCache GUI for the cases where PHP caching is the culprit. These are small things individually, but they are exactly the small things that make people keep a tool installed for years — and they are included rather than sold.

Where it falls short

The maintenance question is the one we would put first in 2026. The repository shows a healthy history — roughly 4,400 stars, 650 forks and 51 tagged releases — but the last recorded push was in April 2024, and the PHP image list topping out at 8.2 reflects that. If you need PHP 8.3 or 8.4 locally today, you will be building or swapping images yourself. A stalled upstream does not break a working setup, but it does mean security updates and new-version support are on you, which is a real consideration for a tool whose main job is mirroring production.

Second, the learning curve is genuine. Devilbox assumes you understand Docker and Compose: service startup order, volume mounts, environment variables and port conflicts are your problems when something goes wrong. Third, resource consumption is high by design — the whole idea of running many services simultaneously means the tool wants memory and disk. Fourth, the project is PHP-centric despite the extra language backends; if your world is Python, Go or Java, purpose-built alternatives will fit better. Finally, there is no managed option and no vendor behind it — if your team cannot debug its own container issues, that is disqualifying regardless of the price.

There is also a question of fit with modern deployment practice. Devilbox mirrors a classic LEMP/LAMP production shape very well; it mirrors a container-native Kubernetes production shape less well, because your local environment then diverges from your runtime in the ways that matter. If your production is containers orchestrated elsewhere, you may get more value from running the production images locally with plain Compose files of your own. Devilbox's magic is most valuable when production is a conventional PHP host — the kind of setup covered in /category/wordpress-hosting — and local fidelity to that shape is what you are buying with your configuration time.

Who should pick this

Our pick for WordPress and PHP developers — freelancers, agencies, plugin and theme shops — who maintain many projects across multiple PHP versions and want one reproducible local environment instead of a graveyard of virtual machines. It is especially good for agencies handing projects between developers: the configuration lives in the repository, the certificates and DNS are automatic, and version switching is per project rather than per machine.

We would not point non-technical site owners, teams without Docker experience, or anyone needing guaranteed maintenance and support at Devilbox. For single-site WordPress users, a hosted local-development app is faster to value; for teams that want their local environment to track current PHP releases indefinitely, check whether the images are still moving before committing. And once your project is ready to go live, the production end of that journey is covered in /category/wordpress-hosting, where the hosting choices are live products rather than local tooling.

Key takeaways

• Devilbox is free, MIT-licensed local development tooling — a Docker Compose stack for PHP/LEMP/LAMP projects, not a hosting service.
• Zero-configuration by design: automatic vhosts, DNS and trusted SSL for unlimited projects, with per-project PHP version switching across 5.2 to 8.2.
• Broad container catalogue — Apache/Nginx, five database engines, Redis, ElasticSearch, MailHog, Xdebug, Blackfire and more — plus Node, Python and Golang backends.
• Created in 2016 and popular (4,400-plus GitHub stars), but the last recorded push was April 2024 and the PHP list stops at 8.2 — plan for self-maintained images.
• Costs nothing to licence but wants real hardware (6 to 8 GB of free RAM for a full stack) and real Docker literacy.
• Best for agencies and freelancers running many PHP projects; wrong choice for non-technical users or teams needing a supported toolchain.

Sources

• https://github.com/cytopia/devilbox
• https://github.com/cytopia/devilbox/blob/master/README.md
• https://github.com/cytopia/devilbox/blob/master/docs/devilbox-purpose.rst
• https://github.com/zalwan/devilbox
• https://awesome.ecosyste.ms/projects/github.com%2Fcytopia%2Fdevilbox