Skip to content

Symfony

The Wodby Symfony catalog stack runs Symfony on PHP-FPM behind Nginx, with PostgreSQL and Mailpit. OpenSMTPD and a managed PostgreSQL database are optional. The current services and defaults are documented in wodby/stack-symfony.

Create the environment

Start from Symfony on Wodby, a Symfony 7.4 LTS application with Doctrine, Twig, Mailer and a /healthz endpoint, or connect your own repository. The boilerplate needs PHP 8.4 or later; your own repository can use any PHP version the service offers.

PHP, Nginx and PostgreSQL are required. The PHP service links to PostgreSQL for the database and to Mailpit for mail. Change a link under Connections > Links on the PHP app service. To use a managed database instead of the PostgreSQL container, see Managed databases.

Build and deployment

The boilerplate's .wodby/pipeline.yml runs composer install with development packages, so the same build also works in a development environment, then builds the PHP and Nginx images. See Application builds.

Only the document root (Nginx docroot, public by default) goes into the Nginx image. Put front-end build output there during the build. Code and vendor stay in the PHP image. Runtime variables and the database are not available during the build, so don't warm the prod cache there.

After every deployment, php bin/console doctrine:migrations:migrate --no-interaction --allow-no-migration runs on the PHP service. Commit your migrations and don't add migration commands to the build or a start script. The step fails when the application doesn't have Doctrine Migrations.

Environments and requests

  • Development environments run Symfony with APP_ENV=dev. Other environment types use prod; a test environment is a deployed application, not Symfony's test environment. APP_DEBUG follows APP_ENV unless you set it.
  • APP_SECRET is generated by Wodby. Find it in the PHP app service's Configuration > Tokens tab.
  • Variables set on the PHP service take precedence over your committed .env files. Keep .env with safe defaults only, and set secrets as environment variables.
  • Wodby's gateway terminates HTTPS. The service sets SYMFONY_TRUSTED_PROXIES and SYMFONY_TRUSTED_HEADERS, which Symfony 7.2 and later read, so request schemes, generated URLs and client addresses are those of the visitor.
  • The boilerplate sets DEFAULT_URI, used for URLs generated outside a request, to the environment's primary URL.
  • Symfony accepts any host name unless you set SYMFONY_TRUSTED_HOSTS on the PHP service.

Database and mail

Link What the PHP service receives
DBMS DATABASE_URL for Doctrine, and the PHP service's DB_* variables
Mail Transfer Agent MAILER_DSN for Symfony Mailer, and MSMTP_HOST and MSMTP_PORT for PHP's mail()

A variable is present only while its link exists and the linked service is enabled. DATABASE_URL holds the password in encoded form. If you connect your own application:

  • Read it with %env(DATABASE_URL)%, not %env(resolve:DATABASE_URL)%, which fails on an encoded password.
  • The URL has no serverVersion and no charset. On PostgreSQL, set charset: utf8 or server_version under doctrine.dbal in config/packages/doctrine.yaml, or Doctrine fails before it connects. The boilerplate already handles both.

With a managed database that requires TLS, the boilerplate connects with the server's certificate, which Wodby mounts in the container. See Managed databases.

Mailpit captures every message and delivers none. Its public domains are protected by basic auth by default. Find the password under Endpoints > Auths, see Endpoints. For real delivery, enable OpenSMTPD, point the PHP service's Mail Transfer Agent link to it, and attach an SMTP provider. See the OpenSMTPD guide.

Files and sessions

Symfony's var/ directory, with its cache, logs and file-based sessions, is in the container's file system and is lost when the container is replaced. File-based sessions are also not shared between replicas: store sessions in the database or a Redis-compatible service before you run more than one PHP replica. The stack has no files volume; add one for user uploads. See Application persistent storage.

Data and backups

PostgreSQL stores data on a data volume of 20 GB. Its backups are gzipped SQL dumps of the environment's database. An import replaces the contents of the data volume. See Application backups and Application imports.

Development workspace

In a development workspace:

  • PHP serves the code from the checkout as it is on disk, so changes show on the next request. With APP_ENV=dev, Symfony rebuilds its cache when code or configuration changes, and the web profiler is available.
  • Setup runs composer install and then the Doctrine migrations. Deployments of a workspace don't run migrations: after adding one, run php bin/console doctrine:migrations:migrate yourself.
  • After changing variables and deploying, run php bin/console cache:clear.
  • vendor/ stays out of Git status without changes to .gitignore.