How to Deploy a Symfony Application

Deploying a Symfony application can be a complex and varied task depending onthe setup and the requirements of your application. This article is not a step-by-step guide, but is a general list of the most common requirements and ideasfor deployment.

Symfony Deployment Basics

The typical steps taken while deploying a Symfony application include:

  • Upload your code to the production server;
  • Install your vendor dependencies (typically done via Composer and may be donebefore uploading);
  • Running database migrations or similar tasks to update any changed data structures;

  • Clearing (and optionally, warming up) your cache.A deployment may also include other tasks, such as:

  • Tagging a particular version of your code as a release in your source controlrepository;

  • Creating a temporary staging area to build your updated setup "offline";
  • Running any tests available to ensure code and/or server stability;
  • Removal of any unnecessary files from the public/ directory to keep yourproduction environment clean;
  • Clearing of external cache systems (like Memcached or Redis).

How to Deploy a Symfony Application

There are several ways you can deploy a Symfony application. Start with a fewbasic deployment strategies and build up from there.

Basic File Transfer

The most basic way of deploying an application is copying the files manuallyvia FTP/SCP (or similar method). This has its disadvantages as you lack controlover the system as the upgrade progresses. This method also requires youto take some manual steps after transferring the files (see Common Post-Deployment Tasks)

Using Source Control

If you're using source control (e.g. Git or SVN), you can simplify by havingyour live installation also be a copy of your repository. When you're ready toupgrade, fetch the latest updates from your source controlsystem. When using Git, a common approach is to create a tag for each releaseand check out the appropriate tag on deployment (see Git Tagging).

This makes updating your files easier, but you still need to worry aboutmanually taking other steps (see Common Post-Deployment Tasks).

Using Platforms as a Service

Using a Platform as a Service (PaaS) can be a great way to deploy your Symfonyapp quickly. There are many PaaS - below are a few that work well with Symfony:

Using Build Scripts and other Tools

There are also tools to help ease the pain of deployment. Some of them have beenspecifically tailored to the requirements of Symfony.

  • EasyDeployBundle
  • A Symfony bundle that adds deploy tools to your application.
  • Deployer
  • This is another native PHP rewrite of Capistrano, with some ready recipes forSymfony.
  • Ansistrano
  • An Ansible role that allows you to configure a powerful deploy via YAML files.
  • Magallanes
  • This Capistrano-like deployment tool is built in PHP, and may be easierfor PHP developers to extend for their needs.
  • Fabric
  • This Python-based library provides a basic suite of operations for executinglocal or remote shell commands and uploading/downloading files.
  • Capistrano with Symfony plugin
  • Capistrano is a remote server automation and deployment tool written in Ruby.Symfony plugin is a plugin to ease Symfony related tasks, inspired by Capifony(which works only with Capistrano 2).
  • sf2debpkg
  • Helps you build a native Debian package for your Symfony project.
  • Basic scripting
  • You can use a shell script, Ant or any other build tool to scriptthe deploying of your project.

Common Post-Deployment Tasks

After deploying your actual source code, there are a number of common thingsyou'll need to do:

A) Check Requirements

Use the check:requirements command to check if your server meets thetechnical requirements for running Symfony applications.

B) Configure your Environment Variables

Most Symfony applications read their configuration from environment variables.While developing locally, you'll usually store these in .env and .env.local(for local overrides). On production, you have two options:

  • Create "real" environment variables. How you set environment variables, dependson your setup: they can be set at the command line, in your Nginx configuration,or via other methods provided by your hosting service.
  • Or, create a .env.local file just like your local development (see note below)There is no significant advantage to either of the two options: use whatever ismost natural in your hosting environment.

Note

If you use the .env.* files on production, you may need to move yoursymfony/dotenv dependency from require-dev to require in composer.json:

  1. $ composer require symfony/dotenv

C) Install/Update your Vendors

Your vendors can be updated before transferring your source code (i.e.update the vendor/ directory, then transfer that with your sourcecode) or afterwards on the server. Either way, update your vendorsas you normally do:

  1. $ composer install --no-dev --optimize-autoloader

Tip

The —optimize-autoloader flag improves Composer's autoloader performancesignificantly by building a "class map". The —no-dev flag ensures thatdevelopment packages are not installed in the production environment.

Caution

If you get a "class not found" error during this step, you may need torun export APP_ENV=prod (or export SYMFONY_ENV=prod if you're notusing Symfony Flex) before running this command sothat the post-install-cmd scripts run in the prod environment.

D) Clear your Symfony Cache

Make sure you clear and warm-up your Symfony cache:

  1. $ APP_ENV=prod APP_DEBUG=0 php bin/console cache:clear

E) Other Things!

There may be lots of other things that you need to do, depending on yoursetup:

Application Lifecycle: Continuous Integration, QA, etc.

While this article covers the technical details of deploying, the full lifecycleof taking code from development up to production may have more steps:deploying to staging, QA (Quality Assurance), running tests, etc.

The use of staging, testing, QA, continuous integration, database migrationsand the capability to roll back in case of failure are all strongly advised. Thereare simple and more complex tools and one can make the deployment as easy(or sophisticated) as your environment requires.

Don't forget that deploying your application also involves updating any dependency(typically via Composer), migrating your database, clearing your cache andother potential things like pushing assets to a CDN (see Common Post-Deployment Tasks).

Troubleshooting

Deployments not Using the composer.json File

The project root directory(whose value is used via the kernel.project_dir parameter and thegetProjectDir() method) iscalculated automatically by Symfony as the directory where the maincomposer.json file is stored.

In deployments not using the composer.json file, you'll need to override thegetProjectDir() methodas explained in this section.

Learn More