Configuration

Configuration

Configuration usually involves different application parts (such as infrastructure and security credentials) and different environments (development, production). That's why Symfony recommends that you split the application configuration into three parts.

Semantic Configuration: Don't Do It

Best Practice

Best Practice

Don't define a semantic dependency injection configuration for your bundles.

As explained in How to Load Service Configuration inside a Bundle article, Symfony bundles have two choices on how to handle configuration: normal service configuration through the services.yml file and semantic configuration through a special *Extension class.

Although semantic configuration is much more powerful and provides nice features such as configuration validation, the amount of work needed to define that configuration isn't worth it for bundles that aren't meant to be shared as third-party bundles.

Moving Sensitive Options Outside of Symfony Entirely

When dealing with sensitive options, like database credentials, we also recommend that you store them outside the Symfony project and make them available through environment variables:

1
2
3
4
5
# app/config/config.yml
doctrine:
    dbal:
        # ...
        password: "%env(DB_PASSWORD)%"

New in version 3.2: Support for runtime environment variables via the %env(...)% syntax was added in Symfony 3.2. Prior to version 3.2, you needed to use the special SYMFONY__ variables.

This work, including the code samples, is licensed under a Creative Commons BY-SA 3.0 license.