flyctl into thinking it’s a Laravel app, having it generate the needed configuration for us, and then tweak it as needed.
Generating Configuration
We’ll start by trickingflyctl into thinking we have a Laravel application. The fly launch command just searches for a file named artisan. If it finds that, it will assume we have a Laravel application.
.fly directory) that are needed to serve a PHP application.
Environment Variables
By default, Symfony wants a.env file to exist. That’s fine if you want to include one in your build (you’ll need to remote .env from the .dockerignore file if so). However we prefer to add environment variables to the fly.toml file (and have secrets be set via fly secrets).
To accomplish this, we’ll create a custom SymfonyRuntime class and use that when we deploy to file.
Create file .fly/FlySymfonyRuntime.php with the following contents:
.env file to be present.
We can then update our Dockerfile to copy our new PHP file into the application when we deploy to Fly.io:
FlySymfonyRuntime by setting an environment variable in fly.toml:
The Fly Proxy
Symfony needs to be aware of the Fly Proxy to generate links correctly (among other things). The Fly proxy is a routing layer (similar to a load balancer) that sits between your application server and the public internet. The proxy terminates SSL connections, and sends “http” requests to your application. We need to tell Symfony to trust this proxy by editing fileconfig/packages/framework.yaml:
Detail Work
That’s basically it! From then on, runningfly deploy should let you deploy the application and run your Symfony application.
If you want to see examples of running queues or connecting to a database, check out this article which has details on that.