Cara menggunakan php-fpm environment variables

• Installation
• Getting Started
• Enabling PHP-FPM
• Enabling TLS
• Different PHP Settings Per Project
  • Selecting a Different PHP Version
  • Overriding PHP Config Options Per Project
  • Running Commands with Different PHP Versions
• Local Domain Names
  • Setting up the Local Proxy
  • Defining the Local Domain
• Long-Running Commands
• Docker Integration
• SymfonyCloud Integration

Symfony Local Web Server

You can run Symfony applications with any web server (Apache, nginx, the internal PHP web server, etc.). However, Symfony provides its own web server to make you more productive while developing your applications.

Although this server is not intended for production use, it supports HTTP/2, TLS/SSL, automatic generation of security certificates, local domains, and many other features that sooner or later you'll need when developing web projects. Moreover, the server is not tied to Symfony and you can also use it with any PHP application and even with HTML or single page applications.

Installation

The Symfony server is part of the symfony binary created when you install Symfony and has support for Linux, macOS and Windows.

Getting Started

The Symfony server is started once per project, so you may end up with several instances (each of them listening to a different port). This is the common workflow to serve a Symfony project:

Running the server this way makes it display the log messages in the console, so you won't be able to run other commands at the same time. If you prefer, you can run the Symfony server in the background:

Enabling PHP-FPM

Note

PHP-FPM must be installed locally for the Symfony server to utilize.

When the server starts, it checks for web/index_dev.php, web/index.php, public/app_dev.php, public/app.php in that order. If one is found, the server will automatically start with PHP-FPM enabled. Otherwise the server will start without PHP-FPM and will show a Page not found page when trying to access a .php file in the browser.

Tip

When an index.html and a front controller like e.g. index.php are both present the server will still start with PHP-FPM enabled but the index.html will take precedence over the front controller. This means when an index.html file is present in public or web, it will be displayed instead of the index.php which would show e.g. the Symfony application.

Enabling TLS

Browsing the secure version of your applications locally is important to detect problems with mixed content early, and to run libraries that only run in HTTPS. Traditionally this has been painful and complicated to set up, but the Symfony server automates everything. First, run this command:

This command creates a local certificate authority, registers it in your system trust store, registers it in Firefox (this is required only for that browser) and creates a default certificate for localhost and 127.0.0.1. In other words, it does everything for you.

Before browsing your local application with HTTPS instead of HTTP, restart its server stopping and starting it again.

Different PHP Settings Per Project

Selecting a Different PHP Version

If you have multiple PHP versions installed on your computer, you can tell Symfony which one to use creating a file called .php-version at the project root directory:

Tip

The Symfony server traverses the directory structure up to the root directory, so you can create a .php-version file in some parent directory to set the same PHP version for a group of projects under that directory.

Run the command below if you don't remember all the PHP versions installed on your computer:

Overriding PHP Config Options Per Project

You can change the value of any PHP runtime config option per project by creating a file called php.ini at the project root directory. Add only the options you want to override:

Running Commands with Different PHP Versions

When running different PHP versions, it is useful to use the main symfony command as a wrapper for the php command. This allows you to always select the most appropriate PHP version according to the project which is running the commands. It also loads the env vars automatically, which is important when running non-Symfony commands:

Local Domain Names

By default, projects are accessible at some random port of the 127.0.0.1 local IP. However, sometimes it is preferable to associate a domain name to them:

• It's more convenient when you work continuously on the same project because port numbers can change but domains don't;
• The behavior of some applications depend on their domains/subdomains;
• To have stable endpoints, such as the local redirection URL for OAuth2.

Setting up the Local Proxy

Local domains are possible thanks to a local proxy provided by the Symfony server. If this is the first time you run the proxy, you must configure it as follows:

1. Open the proxy settings of your operating system:

   • Proxy settings in Windows;
   • Proxy settings in macOS;
   • Proxy settings in Ubuntu.
2. Set the following URL as the value of the Automatic Proxy Configuration: http://127.0.0.1:7080/proxy.pac

Now run this command to start the proxy:

If the proxy doesn't work as explained in the following sections, check these:

• Some browsers (e.g. Chrome) require to re-apply proxy settings (clicking on Re-apply settings button on the chrome://net-internals/#proxy page) or a full restart after starting the proxy. Otherwise, you'll see a "This webpage is not available" error (ERR_NAME_NOT_RESOLVED);
• Some Operating Systems (e.g. macOS) don't apply by default the proxy settings to local hosts and domains. You may need to remove *.local and/or other IP addresses from that list.

Defining the Local Domain

By default, Symfony proposes .wip (for Work in Progress) for the local domains. You can define a local domain for your project as follows:

If you have installed the local proxy as explained in the previous section, you can now browse https://my-domain.wip to access your local project with the new custom domain.

Tip

Browse the http://127.0.0.1:7080 URL to get the full list of local project directories, their custom domains, and port numbers.

When running console commands, add the https_proxy env var to make custom domains work:

Note

Although env var names are always defined in uppercase, the https_proxy env var is treated differently than other env vars and its name must be spelled in lowercase.

Tip

If you prefer to use a different TLD, edit the ~/.symfony/proxy.json file (where ~ means the path to your user directory) and change the value of the tld option from wip to any other TLD.

Long-Running Commands

Long-running commands, such as the ones that compile front-end web assets, block the terminal and you can't run other commands at the same time. The Symfony server provides a run command to wrap them as follows:

Docker Integration

The local Symfony server provides full Docker integration for projects that use it. To learn more about Docker & Symfony, see Using Docker with Symfony.

When the web server detects that Docker Compose is running for the project, it automatically exposes some environment variables.

Via the docker-compose API, it looks for exposed ports used for common services. When it detects one it knows about, it uses the service name to expose environment variables.

Consider the following configuration:

The web server detects that a service exposing port 3306 is running for the project. It understands that this is a MySQL service and creates environment variables accordingly with the service name (database) as a prefix: DATABASE_URL, DATABASE_HOST, ...

If the service is not in the supported list below, generic environment variables are set: PORT, IP, and HOST.

If the docker-compose.yaml names do not match Symfony's conventions, add a label to override the environment variables prefix:

In this example, the service is named db, so environment variables would be prefixed with DB_, but as the com.symfony.server.service-prefix is set to DATABASE, the web server creates environment variables starting with DATABASE_ instead as expected by the default Symfony configuration.

Here is the list of supported services with their ports and default Symfony prefixes:

You can open web management interfaces for the services that expose them:

Or click on the links in the "Server" section of the web debug toolbar.

Tip

To debug and list all exported environment variables, run symfony var:export --debug.

Tip

For some services, the web server also exposes environment variables understood by CLI tools related to the service. For instance, running symfony run psql will connect you automatically to the PostgreSQL server running in a container without having to specify the username, password, or database name.

When Docker services are running, browse a page of your Symfony application and check the "Symfony Server" section in the web debug toolbar; you'll see that "Docker Compose" is "Up".

Note

If you don't want environment variables to be exposed for a service, set the com.symfony.server.service-ignore label to true:

If your Docker Compose file is not at the root of the project, use the COMPOSE_FILE and COMPOSE_PROJECT_NAME environment variables to define its location, same as for docker-compose:

Caution

When using the Symfony binary with php bin/console (symfony console ...), the binary will always use environment variables detected via Docker and will ignore local environment variables. For example if you set up a different database name in your .env.test file (DATABASE_URL=mysql://db_user::3306/test) and if you run symfony console doctrine:database:drop --force --env=test, the command will drop the database defined in your Docker configuration and not the "test" one.

SymfonyCloud Integration

The local Symfony server provides full, but optional, integration with SymfonyCloud, a service optimized to run your Symfony applications on the cloud. It provides features such as creating environments, backups/snapshots, and even access to a copy of the production data from your local machine to help debug any issues.

Read SymfonyCloud technical docs.