Phanssible: a generator for Vagrant and Ansible PHP environments

A web page that assembles a development box for you

Phanssible is a simple generator for Vagrant projects, targeting PHP development environments, using Ansible as the provisioner. The framing in the README is that it is a web application you run locally, you fill in a form, and it produces a Vagrant project with the Ansible roles needed to stand up a PHP development machine. The project was inspired by PuPHPet, which is worth naming because it explains the shape of the thing. PuPHPet was a browser-based generator for Vagrant boxes for PHP developers, and Phanssible takes that idea and puts the generator on the server side, where the templates live in the repository rather than in a browser. The audience is a PHP developer or team who wants a repeatable development environment described in a text file, and who would rather assemble it from a form than write a Vagrantfile and a pile of Ansible roles from scratch.

Silex and Flint, and what the templates directory holds

The technical base is stated in one line: the project is built on top of Silex, using Flint. Silex was the microframework that provided the routing and the request handling for a small PHP application, and Flint is the templating layer that renders the generator's pages. The repository layout explains the rest. There is a src directory with the application code, a public directory that the built-in PHP server exposes, a templates directory holding the page templates, an ansible directory with the provisioning content, a Vagrantfile, a config directory, a tests directory, and a bootstrap.php and composer.json for the application itself. A symfony.lock file is present, which is the marker of the Flex plugin era of Composer, and the .env file plus a local-deploy.sh script suggest a configuration and deployment path that is separate from the generated output. The separation is the important architectural point. The generator is a web app, and the artefact it produces is a Vagrant project whose Ansible content lives in the repository rather than being assembled at request time.

Running the generator with the built-in PHP server

The setup steps are short and assume a local PHP environment. You clone the repository, change into the phansible folder, install the dependencies with composer, and start the PHP built-in server on port 8080 with the public directory as the document root, using the commands in the README's setup list, which are a git clone of the repository, a cd into the phansible folder, php composer install and php -S 0.0.0.0:8080 -t public/. You then open http://localhost:8080 to see the generator. The binding to 0.0.0.0 rather than localhost is deliberate, since the built-in server is meant to be reachable from the host machine running the Vagrant box, and the public directory as the document root is what the framework expects. There is an alternative the README mentions, an included Vagrant setup that requires Ansible, which is the more self-contained route, since the Vagrantfile at the root of the repository sets up a machine for running the generator itself rather than the generated projects.

Roles that were meant to be tested and generated outside the browser

The to do list at the top of the README is the most revealing part of the document, because it describes the architecture the author intended. The first item is to deprecate the 1.0 branch and put master into production. The second is to run CI on the generated roles, with a contributor working on it. The third is an API for generating roles outside the web interface, also with a contributor named. Those three together describe a design where the Ansible roles are first-class artefacts in their own right, tested in continuous integration and callable from a script or another tool, rather than templates that only exist as rendered output of a form submission. The remaining items are more open-ended: support for new technologies on request, more documentation on how to customise things, and a pointer to the issue tracker. The generated-roles-in-CI item is the one that would have made the tool dependable, since a role that compiles against real Ansible is a role that works.

Tests and static analysis are one command each

The project documents two command lines, and they are worth copying into your own workflow if you work on PHP. The tests run with PHPUnit:

 ./vendor/bin/phpunit

And the style checks are two separate tools, the PSR-2 standard through PHP CodeSniffer and a mess-detector pass over the source:

 ./vendor/bin/phpcs --standard=psr2 ./src
 ./vendor/bin/phpmd src/ text codesize,controversial,design,naming,unusedcode

The message that follows is that when no errors appear you are ready to push your commits, which tells you the intended workflow, since a change is only pushed once the suite passes and the style rules are clean. The phpcs.xml.dist file in the repository root carries the configuration for that first command, and phpunit.xml.dist carries the test configuration. The repository also has a .scrutinizer.yml and a .travis.yml for continuous integration, plus a CODE_OF_CONDUCT.md and a CONTRIBUTING.md, and the README invites contributors to the issue tracker and to a Gitter chat room.

Releases from 2015, a push in 2026, and an unticked to do list

The maintenance picture needs stating carefully. The recent releases are 0.7 on 2015-08-02, 0.7.1 the same day, and 0.7.2 on 2015-08-17, so the last tagged artefact is more than a decade old. The last push to the repository was on 2026-04-18, which is more than six months before this writing, so it is not accurate to describe the project as actively developed. The licence is MIT, the default branch is main, and the project site is phanssible.com. The topic tags are ansible, hacktoberfest, php and vagrant, and the hacktoberfest tag dates the era in which the repository was most active. The honest summary is that this is a complete, small and readable implementation of a good idea, from a period when Silex was the natural way to build a PHP web application, left in a state where the to do list still has every box unticked. The ideas in it, generate the roles separately, test them, offer an API, remain worth copying into whatever tool you use now.

Editorial conclusion

Phanssible fits a PHP team that wants a web interface for assembling a Vagrant plus Ansible development box, with a set of composable roles rather than a single monolithic script, and that is willing to read and adjust the generated Ansible. It does not fit a team starting a new project today, since the last tagged release is from 2015 and the toolchain it assumes, Silex and Travis, has moved on. Before adopting it, read the to do list at the top of the README, check that the roles it generates still target a supported Vagrant and Ansible version, and be ready to maintain the generator yourself rather than to expect upstream fixes.

Frequently asked questions

Official sources

1. License: MIT
2. phansible/phansible on GitHub
3. Project website
4. README
5. Releases