There are some really special parameters I need to tell you about. In this big list that debug:container gave us, find the group that starts with kernel.. You won't find these defined anywhere: they're baked right into Symfony and are some of the most useful parameters.

Notice kernel.debug - whether or not we're in debug mode - and kernel.environment. But the best ones to know about are kernel.cache_dir - where Symfony stores its cache - and kernel.root_dir - which is actually the app/ directory where the AppKernel class lives. Anytime you need to reference a path in your project, use kernel.root_dir and build the path from it.

Earlier, just to show off, we configured the DoctrineCacheBundle to store the markdown cache in /tmp/doctrine_cache:

80 lines app/config/config.yml
... lines 1 - 73
type: %cache_type%
directory: /tmp/doctrine_cache

Referencing absolute paths is a little weird: why not just store this stuff in Symfony's cache dir? Ok, ok, the bundle actually did this by default, before we started messing with the configuration. But we're learning people! So let's use one of these new kernel. parameters to fix this.

How? Just change the directory to %kernel.cache_dir% then /markdown_cache:

80 lines app/config/config.yml
... lines 1 - 73
type: %cache_type%
directory: %kernel.cache_dir%/markdown_cache

It's totally ok to mix the parameters inside larger strings.

Clear the cache in the prod environment:

./bin/console cache:clear --env=prod

And switch to the prod tab to try this all out. Now, in the terminal:

ls var/cache/prod/

And there's our cached markdown.

Why is parameters.yml Special?

I have a question: if config.yml imports parameters.yml, then why bother having this file at all? Why not just put all the parameters at the top of config.yml?

Here's why: parameters.yml holds any configuration that will be different from one machine where the code is deployed to another.

For example, your database password is most likely not the same as my database password and hopefully not the same as the production database password. But if we put that password right in the middle of config.yml, that would be a nightmare! In that scenario I would probably commit my password to git and then you would have to change it to your password but then try to not commit that change. Gross.

Instead of that confusing mess of seaweed, we use parameters in config.yml. This allows us to isolate all the machine-specific configuration to parameters.yml. And here's the final key: parameters.yml is not committed to the repository - you can see there's an entry for it in .gitignore:

17 lines .gitignore
... lines 2 - 17

Of course, if I just cloned this project, and I won't have a parameters.yml file: I have to create it manually. Actually, this is the exact reason for this other file: parameters.yml.dist:

20 lines app/config/parameters.yml.dist
# This file is a "template" of what your parameters.yml file should look like
# Set parameters here that may be different on each deployment target of the app, e.g. development, staging, production.
database_port: ~
database_name: symfony
database_user: root
database_password: ~
# You should uncomment this if you want use pdo_sqlite
# database_path: "%kernel.root_dir%/data.db3"
mailer_transport: smtp
mailer_user: ~
mailer_password: ~
# A secret key that's used to generate certain security-related tokens
secret: ThisTokenIsNotSoSecretChangeIt

This is not read by Symfony, it's just a template of all of the parameters this project needs. If you add or remove things from the parameters.yml, be sure to add or remove them from parameters.yml.dist. You do commit this file to git.


Due to a post-install command in your composer.json, after running composer install, Symfony will read parameters.yml.dist and ask you to fill in any values that are missing from parameters.yml.

Let's put this into practice. What if our app does not need to send emails. That means we don't need SwiftmailerBundle. And that means we don't need any of these mailer_ parameters: these are used in config.yml under swiftmailer. We could keep this stuff, but why not get rid of the extra stuff?

In AppKernel, start by removing the SwiftmailerBundle line completely:

55 lines app/AppKernel.php
... lines 1 - 5
class AppKernel extends Kernel
public function registerBundles()
$bundles = array(
... lines 11 - 14
//new Symfony\Bundle\SwiftmailerBundle\SwiftmailerBundle(),
... lines 16 - 22
... lines 24 - 32
... lines 34 - 53

Because that's gone, you'll need to remove the entire swiftmailer section in config.yml. And finally, we don't need the mailer_ parameters anymore, so delete them from parameters.yml and parameters.yml.dist so other devs won't worry about adding them. Awesome!

Head over to the terminal and run:

./bin/console debug:container mailer

Cool - the app still runs, but there are no services that match mailer anymore.

Leave a comment!

  • 2017-03-30 Victor Bocharsky

    Hey Richie,

    No, you don't have to create a separate "parameters" files for each environment - you already have config.yml, config_dev.yml and config_test.yml files, which already are imported out of the box, so just put any environment-related parameters inside of those files under the `parameters:` key. BUT if you have server-specific parameters, you need to put them into the special `parameters.yml` file (and also don't forget to add a parameter key with dummy value in your parameters.yml.dist file), i.e. those parameters which can be different on different servers: production, development, CI, etc. I think this article may be interesting for you:


  • 2017-03-30 Richie Hamburg

    So what is the recommended way to split out parameters for dev vs prod? simply create a parameters_dev.yml and import that into config_dev.yml after the import of config.yml?

  • 2016-08-30 Victor Bocharsky

    You're welcome! BTW, fixing deprecations beforehand is a good idea, keep it up! )

  • 2016-08-29 Greg

    Ok effectively it is very simple ;)
    Thanks for your answer.

  • 2016-08-29 Victor Bocharsky

    Hey Greg,

    Symfony deprecates using % symbol without quotes, but of course you still can use parameters in YAML config files. So just wrap all your parameters which starts and ends with % with a single or double quotes and that's it! It's easy fix!

    P.S. Thanks for your kind words.


  • 2016-08-27 Greg

    Great tuto, but I have a little question since sf 3.1 it is drepreacated to use % indicator in config.yml.
    So how can we do?
    Thanks again for your great job.