New in Symfony 3.2: Runtime Environment Variables
![Avatar of Javier Eguiluz](https://connect.symfony.com/api/images/17170f22-52c0-4adf-a75d-29cb01d53176.png?format=80x80)
Warning: This post is about an unsupported Symfony version. Some of this information may be out of date. Read the most recent Symfony Docs.
Contributed by
Nicolas Grekas
in #19681.
Environment variables are becoming increasingly popular to manage the application configuration. They are one of the main concepts of the twelve-factor app methodology. Their main advantages are that they can be changed between deploys without changing any code and that they don't need to be checked into the code repository.
Symfony has supported environment variables since day one thanks to the
SYMFONY__
special variables. However their behavior was rather simple: when
the application container was built, the values of those environment variables
were dumped into the compiled container. Therefore, if those variables changed
during the application execution, the updated values were ignored.
In Symfony 3.2 we added full support for environment variables. The first
improvement is that you no longer have to prefix those variables with SYMFONY__
(any variable name will work). The second improvement is that their value is
resolved at runtime, so the application will always use the updated value.
In order to use an environment variable in any Symfony configuration file, use
the new %env(VARIABLE_NAME)%
syntax:
1 2 3 4 5
# app/config/config.yml
doctrine:
dbal:
# ...
password: "%env(DB_PASSWORD)%"
In the previous example, whenever Symfony/Doctrine need the database password,
they'll make a call to get the value of the DB_PASSWORD
environment variable.
To avoid undefined variable errors, you can define default values for these
variables using the syntax env(VARIABLE_NAME): VARIABLE_VALUE
:
1 2 3
# app/config/parameters.yml
parameters:
env(DB_PASSWORD): s3cr3t_1234
Help the Symfony project!
As with any Open-Source project, contributing code or documentation is the most common way to help, but we also have a wide range of sponsoring opportunities.
Comments
Comments are closed.
To ensure that comments stay relevant, they are closed for old posts.
Is there a typo: "they can can be"?
[1]: http://symfony.com/doc/current/contributing/code/bc.html
[2]: http://symfony.com/doc/current/contributing/community/releases.html
"incenteev-parameters": {
"file": "app/config/parameters.yml",
"env-map": {
"database_driver": "DATABASE_DRIVER",
......
}
}
}
However in my opinion changing the root URL(s) of an application is THE premium use case of all to be defined by the environment, especially in face of the twelve-factor app methodology.
To be honest I think I'm just very skeptical about the whole runtime part. Every change in a Symfony production application requires a cache clear and container recompile, why not a, usually highly dangerous, change in the application's deployment configuration?
@Nirmal Thanks, I didn't know that. It will have to do for a while, before we migrate everything to latest.
Let's go to contenerizzzzzz