Install Symfony

Symfony has been around for some while — but it doesn't look old. Learn how to install and tune Symfony 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, 5 or 6, you can safely follow this guide, given Symfony 7 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 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 if you chose the Symfony preset:

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

You can view and edit the env vars in the Dashboard under your App settings. 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.

Get Apache pack

Given that fortrabbit uses Apache as a web server, fetch the default .htaccess file for Symfony, via Flex:

$ composer require symfony/apache-pack
# This is from the "contrib" repository, you will be asked to confirm. Press `y`.

After running the command, the .htaccess should have been copied to your /public folder.

Deploy with Git

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 to your App via ssh, 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 JavaScript & 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 AssetMapper, 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 the 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

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

Advanced configurations

Still reading? Let's go on:

Logging

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

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

Sending emails

You can not use sendmail on fortrabbit but you can use Swiftmailer.

Symfony provides a Mailer component that makes things easy. To configure the way your emails are sent, set the MAILER_DSN environment variable.

More on this in the official documentation.

Cache

In the Universal Stack you can use the default file cache. In the 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 the filesystem (because of the way the Professional Stack works, with its distributed nodes): instead, choose an adapter from 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 ›