Cover of the book Symfony 5: The Fast Track

Symfony 5: The Fast Track is the best book to learn modern Symfony development, from zero to production. +300 pages in full color showing how to combine Symfony with Docker, APIs, queues & async tasks, Webpack, Single-Page Applications, etc.

Buy printed version
WARNING: You are browsing the documentation for Symfony 2.7 which is not maintained anymore. Consider upgrading your projects to Symfony 5.1.


2.7 version
Maintained Unmaintained


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.

Parameter Naming

Best Practice

The name of your configuration parameters should be as short as possible and should include a common prefix for the entire application.

Using app. as the prefix of your parameters is a common practice to avoid collisions with Symfony and third-party bundles/libraries parameters. Then, use just one or two words to describe the purpose of the parameter:

# app/config/config.yml
    # don't do this: 'dir' is too generic and it doesn't convey any meaning
    app.dir: '...'
    # do this: short but easy to understand names
    app.contents_dir: '...'
    # it's OK to use dots, underscores, dashes or nothing, but always
    # be consistent and use the same format for all the parameters
    app.dir.contents: '...'
    app.contents-dir: '...'

Semantic Configuration: Don’t Do It

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. Learn how to do it in the following article: How to Set external Parameters in the Service Container.

Next: Organizing Your Business Logic

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