Magento 2 Experten — Hyvä Theme, Tailwind CSS & SEO aus einer Hand ›

Configuration and Environments

Configuration and Environments

~13 Min. Lesezeit Zuletzt aktualisiert am August 8, 2026

Symfony consistently separates configuration from code – a central principle we'll understand in this chapter, before setting up our task manager's database connection in chapter 5.

The three standard environments

EnvironmentPurpose
devFor local development: debug toolbar, verbose error pages, NO cache for configuration/routes (every change takes effect immediately).
testFor automated tests (block 7): isolated environment, often a separate test database.
prodFor production: aggressive caching, NO debug information in error pages (security risk), optimized for speed.

The APP_ENV variable determines which environment is active – dev by default when working locally with the Symfony CLI.

Understanding .env files

Symfony reads environment variables from SEVERAL .env* files, which override each other in a precisely defined order:

  1. .env – default values, gets VERSION-CONTROLLED (no real secrets!).
  2. .env.local – local overrides, NOT version-controlled, for your personal values.
  3. .env.$APP_ENV (e.g. .env.test) – environment-specific, version-controlled.
  4. .env.$APP_ENV.local – local, environment-specific override, NOT version-controlled.
.env
APP_ENV=dev
APP_SECRET=change_me_in_env_local
DATABASE_URL="postgresql://symfony:symfony@127.0.0.1:5432/aufgaben_manager?serverVersion=16&charset=utf8"

Achtung: .env ends up in the Git repository – NEVER write real passwords or API keys here, only harmless default values. Real secrets belong in .env.local, which is excluded via .gitignore (Symfony sets this up automatically at install time).

Configuration files in config/

Every installed bundle brings its own configuration file under config/packages/ – e.g. config/packages/doctrine.yaml for Doctrine (block 4) or config/packages/security.yaml for security (block 5). These YAML files frequently use environment variables as placeholders:

config/packages/doctrine.yaml
doctrine:
    dbal:
        url: '%env(resolve:DATABASE_URL)%'
    orm:
        auto_generate_proxy_classes: true
        enable_lazy_ghost_objects: true

%env(resolve:DATABASE_URL)% reads the DATABASE_URL environment variable's value from the .env* files – the actual configuration file stays identical across ALL environments this way, only the environment variable differs.

Environment-specific configuration overrides

Inside config/packages/, per-environment subfolders can be created, whose contents are loaded ONLY in that environment:

Environment-specific configuration

config/packages/
├── doctrine.yaml       (loaded in ALL environments)
├── dev/
│   └── monolog.yaml    (loaded ONLY in dev: verbose logging)
└── prod/
    └── monolog.yaml    (loaded ONLY in prod: reduced logging)

Understanding the configuration cache

In prod, Symfony compiles ALL configuration (routes, services, container) ONCE into highly optimized PHP code under var/cache/prod/ – later changes to config/ do NOT take effect automatically there until the cache is explicitly cleared:

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

Achtung: A COMMON beginner mistake: making a configuration change in production but forgetting to clear the cache – the old configuration stays in effect until the cache expires or is manually cleared. In dev, this does NOT happen, since configuration changes are detected automatically there – another reason why dev is noticeably slower than prod.