Deploy Symfony to Production and Symfony Hosting on Your Own Servers With Zero Downtime

How do you deploy a Symfony app to production?

Deploy a Symfony app by installing vendors without dev packages, setting real production environment variables, warming the prod cache and running migrations, all inside a new release directory, then switching traffic to it. Symfony's deployment guide lists the same core tasks: check requirements, configure environment variables (optionally compiled with composer dump-env prod), run composer install --no-dev --optimize-autoloader, clear the prod cache, then the extras such as migrations, asset compilation and restarting workers.

On a DeployManage zero downtime site the panel clones the commit into releases/<timestamp>, links the shared .env, sets DM_SITE_DIR and DM_RELEASE_DIR, and runs your script inside the release. A typical Symfony script with AssetMapper looks like this:

composer install --no-dev --no-interaction --prefer-dist --optimize-autoloader
composer dump-env prod
mkdir -p "$DM_SITE_DIR/shared/log" "$DM_SITE_DIR/shared/uploads"
rm -rf var/log && ln -sfn "$DM_SITE_DIR/shared/log" var/log
ln -sfn "$DM_SITE_DIR/shared/uploads" public/uploads
php bin/console asset-map:compile
php bin/console cache:warmup --env=prod
php bin/console doctrine:migrations:migrate --no-interaction --allow-no-migration

If you build assets with Webpack Encore, swap the asset-map line for npm ci and npm run build, or build them in CI and commit the output (Node is not part of the default server stack). Only when every line exits cleanly does the current symlink move. The previous release keeps serving until that moment, and the last five releases stay on disk.

If your team also ships Laravel or WordPress sites, the same flow covers them from one panel; the PHP deployment tool comparison shows the price and scope against Deployer and Envoyer.

Which Symfony folders must be shared between releases?

Share anything written at runtime that must outlive a deploy: the production .env, var/log, user uploads such as public/uploads, file based sessions if you use them, and generated keys such as config/jwt. The var/cache directory is the exception. It belongs to each release, because the cache is compiled for that exact code, and warming it inside the new release is what makes the switch instant.

DeployManage links the shared .env automatically and keeps the environment editor as the single source of truth for secrets. Every other shared path is one ln -sfn line in your script, pointing at a folder under $DM_SITE_DIR, so you decide exactly what persists. Store anything larger, like customer documents, in S3 compatible object storage through Flysystem instead of local disk if more than one server serves the app.

Running Symfony Messenger workers in production

Run Messenger consumers under Supervisor with a time or memory limit, and call messenger:stop-workers after every deploy so they restart on the new code. Symfony's Messenger docs recommend exactly this: a process manager keeps the worker alive, flags such as --time-limit=3600 or --memory-limit=128M stop leaks from piling up, and stop-workers signals each consumer to finish its current message and exit.

In DeployManage you add the worker as a daemon, for example php bin/console messenger:consume async --time-limit=3600, with as many processes as the queue needs. The daemon runs from the current symlink, so after the switch a restart picks up the new release automatically. Failed messages stay in your failure transport, where messenger:failed:retry works as usual.

Symfony hosting requirements for a VPS

Symfony 8.1 needs PHP 8.4 or higher, Symfony 7.4 LTS needs PHP 8.2 and Symfony 6.4 needs PHP 8.1, according to symfony.com/releases. All three run on a DeployManage server, which offers PHP 8.1, 8.2, 8.3 and 8.4 per site, so a 6.4 client app and a new 8.1 project can share one machine.

For sizing, a typical Symfony app with Doctrine, a Redis cache and two Messenger workers runs comfortably on a 4 GB, 2 vCPU server such as the DigitalOcean $24 Droplet or a Hetzner CX33. Several client apps fit on an 8 GB server at $48 on DigitalOcean. Keep OPcache on, set APP_ENV=prod and APP_DEBUG=0, and point Nginx at public/ with the standard front controller rule, which the panel writes for you.

Symfony hosting cost on your own servers

Three common setups, priced in USD with DigitalOcean Basic Droplets ($12 for 2 GB, $24 for 4 GB, $48 for 8 GB). Upsun figures use its own calculator rates: $25 per app vCPU and $10 per GB of app memory a month, $37 and $15 for service containers such as MySQL, $0.50 per GB of disk, $9 per project, $10 per user and the Standard support tier at 10% on top.

Forge is cheaper than DeployManage in every row, and for a single developer with one app it is the right buy. DeployManage pays off when a team needs the same release on several servers without adding Envoyer, ten seats with an audit log, and one plan across many client apps. Against per project platforms, owning the servers saves several hundred dollars a month from the second or third project onward. Upsun new accounts also get a first project credit of $19 a month, which covers one project fee and one user.

Moving a Symfony app from Upsun, Heroku or shared hosting

Move the database first, then the code, then the DNS. Dump the production database (pg_dump or mysqldump), restore it on the new server, copy uploaded files from the old mounts or object storage, and paste the environment variables into the shared .env. Translate the old platform's build and deploy hooks into the deploy script above, and its workers into daemons.

Deploy once to the new server and test it through a hosts file entry or a temporary subdomain. When it works, lower the DNS TTL, put the old app in maintenance mode, take a final database dump, restore it, and switch the DNS. Most Symfony apps move in an afternoon this way, and the old platform can stay up as a fallback until the TTL has expired everywhere.