The new Symfony binary, announced during SymfonyCon Lisbon 2018, is getting better by the day.

If you haven't heard about the Symfony local web server yet, you can discover it in the official documentation

With 30+ releases since the first public release, we have been hard at work fixing bugs and adding features.

We now auto-detect more PHP versions installed on your machine (MacOS, Windows, and Linux) from many different vendors (in addition to the PHP binaries located under your $PATH). In no particular order: Homebrew, phpenv, Liip PHP, Ondrej PPA, Remi's RPM repository, XAMPP, MAMP, phpbrew, Cygwin, Chocolatey, WAMP, and MacPorts.

We claimed support for HTTP/2, but this was partially true. We falled back to HTTP/1 when you were using local domain names. Not anymore. HTTP/2 is now supported even when using nice domain names ending with .wip.

One convenient feature of the local web server is the ability to run different versions of PHP depending on the project (via a .php-version file for instance). That also works on the console when running symfony run script.php. In addition, it also automatically reads environment variables (from .env files). That's very useful when running a script that does not use the Symfony Dotenv component. Use `symfony php script.php` and done. The same features are now available for many commands: pecl, pear, php-config, php-fpm, php-cgi, composer, and phpdbg.

By default, the local web server reads the Symfony environment (dev or prod for instance) from your .env configuration. You can force the production environment by running symfony local:server:prod (disable it via symfony local:server:prod --off).

Pure HTML websites or SPAs can also use the local web server; no need for something else.

Last but not least, we have added support for Docker. We think this provides the ideal local working environment: local native PHP performance with local domains, TLS, HTTP2, and logs aggregation and service management via Docker Compose (or SymfonyCloud). Integration is almost automatic if you are exposing the ports of your services. The services are then exposed as environment variables to the Symfony application. The documentation explains how you can do it. One nice feature is that ports being random on the host, you can work on several projects using Docker without having to shutdown one to work on the next. Having random ports works because the environment variables are exposed automatically by the symfony CLI.

Also note that checking for vulnerabilities in your project should now be done via the symfony CLI as well, more specifically via the security:check command. It does the checks locally without using the HTTP API (it clones the security advisories database to determine issues). That's ideal to use in your CI as well.

Published in #Community