Install Symfony 6

Symfony has been around for some while — but it doesn't look old. Learn how to install and tune Symfony 6 on fortrabbit.

Get ready

We assume you've already created a new App and chose Symfony in the Software Preset. If not: You can do so in the fortrabbit Dashboard. You should also have a PHP development environment running on your local machine. If you are using Symfony 4 or 5, you can safely follow this guide, given Symfony 6 did not break compatibility changes.

Root path

If you did not choose Symfony when creating the App in the Dashboard at first, please set the following: Go to the Dashboard and set the root path of your App's domains to public.

Change the root path for App URL of App: {{app-name}}

ENV vars

Symfony 6 environments are controlled by the APP_ENV ENV var. You can even use ENV vars in the .yml configurations now. To get you started quickly, we provide you with the following ENV vars by default when you have chosen the Symfony from when creating the App:

APP_ENV=prod
APP_DEBUG=0
APP_SECRET=ClickToGenerate
DATABASE_URL=mysql://${MYSQL_USER}:${MYSQL_PASSWORD}@${MYSQL_HOST}/${MYSQL_DATABASE}

Within the Dashboard under your App settings you can modify the ENV vars. Modify APP_DEBUG or APP_ENV to change the behavior of your application. You can also define your own key-value-pairs and use them in your configuration files.

Go to ENV vars for the App: {{app-name}}

Quick start

It is assumed that you already have a Symfony project installed and running locally. This can be an existing project or a new one, see the official download page for instructions for your local Operating System.

Given that fortrabbit uses Apache as a web server, consider fetching the default .htaccess file for Symfony, via flex (since this is from contrib repository, you will be asked to confirm the installation. Do it by pressing y):

$ composer require symfony/apache-pack

If your project is not under Git version control yet, follow these steps to be prepared for your first git push.

# 1. Initialize a local Git repo
$ git init .

# 2. Add all files
$ git add -A

# 3. Commit files for the first time
$ git commit -m 'Initial'

# 4. Add fortrabbit as a remote
$ git remote add fortrabbit {{ssh-user}}@deploy.{{region}}.frbit.com:{{app-name}}.git

# 5. Initial push and set upstream
$ git push -u fortrabbit main
# Lots of output

# 6. From there on only
$ git push

Got an error? Please see the access troubleshooting. Did it work? Cool! This first push can take a bit, since all the Composer packages need to be installed. When the first push is done you can visit your App URL in the browser and see the Symfony welcome screen:

MySQL

Until now you just deployed some code. If you want to use doctrine and Mysql it requires some more tinkering to make it yours.

Configuration

The DATABASE_URL ENV var stores all DB access information already (see above). You just need to use it in doctrine.yaml like so:

doctrine:
    dbal:
        # All in one single line (default)
        url: '%env(DATABASE_URL)%'

Doctrine & symfony console

Once doctrine is configured and the changes are deployed, you may want to run migrations and maybe load fixtures. You can login via ssh in to your App, or instead just fire single commands like so:

# doctrine
$ ssh {{ssh-user}}@deploy.{{region}}.frbit.com 'php bin/console doctrine:migrations:migrate'
$ ssh {{ssh-user}}@deploy.{{region}}.frbit.com 'php bin/console doctrine:fixtures:load'

# cache clear
$ ssh {{ssh-user}}@deploy.{{region}}.frbit.com 'php bin/console cache:clear'

You can also add this migrate command to your composer.json to have it run automatically every time you push changes.

"scripts": {
    "post-install-cmd": [
        "php bin/console doctrine:migrations:migrate --no-interaction",
    ],
}

With that in place, any time you deploy your code, database changes will be applied immediately. If no database changes are required, nothing happens, so it is safe to run all the time. Just make sure to test your upgrades and migrations locally first.

Deploying compiled JS & CSS

There currently is no possibility to use Node.js with our services. The build process to compile JS and CSS needs to run locally - whether with Encore, Webpack, Gulp, Grunt, or the solution of your choice).

Compiled assets should not be under version control. So, instead of committing the build files to Git, you deploy them separately. Given the way our stacks are designed (Universal having persistent storage and Professional allowing horizontal scaling), deploying your assets will be done differently.

Deploying compiled assets for Universal Apps

To deploy your compiled assets to your app, when using Universal Stack, you can simply use rsync. It works great for this and it's easier than you might think:

# Deploy the build folder
$ rsync -av ./public/build/ {{app-name}}@deploy.{{region}}.frbit.com:~/public/build/

Deploying compiled assets for Professional Apps

These is no persistent storage with the Professional Stack. We provide the Object Storage for this, see the main article on how to access.

Advanced configurations

Still reading? Let's go on:

Logging

In Universal Stack, you can access all log files your App writes on the file system. If you want to use live logging in Universal Stack or in Professional Stack, then you should configure Symfony to use error_log. After having installed monolog bundle (composer require symfony/monolog-bundle), modify the config/packages/prod/monolog.yml file:

monolog:
    # ..
    handlers:
        # ..
        nested:
            type: error_log
            # ..

Sending emails

You can not use sendmail on fortrabbit but you can use the Swiftmailer. Symfony provides a Mailer component that makes things easy. To configure the way your emails are sent, mind setting a MAILER_DSN environment variable. More on this in the official documentation.

Cache

In Universal Stack you can use the default file cache. In Professional Stack, when you deploy your app, the old code is removed and the new one is deployed. If you need at some point to store custom information in the cache (through cache pools), you then need to avoid filesystem (because of the way the Professional Stack works, with its distributed nodes): instead, use an adapter amongst doctrine, redis or memcached.

All articles

Craft CMS

Statamic

Install guides

Code access

Deployment

Git

SSH

SFTP

Troubleshooting

DNS

MySQL

TLS (SSL)

htaccess

Development

Teamwork

Platform

Billing

The Dashboard

Stacks

Tips & tricks

Quirks

Support

FAQ

Need individual help?
Learn about Company plans ›
Looking for an old article?
See the full list of articles ›
Found an error?
Contribute on GitHub ›