FlashDrive automatically builds your Laravel app from your code.
In order to do that FlashDrive uses buildpacks to detect and build automatically your app.

To be able to build your app, FlashDrive needs a composer.json and a composer.lock files committed in your repository.

Create your app on FlashDrive

Create a new app and link it with your repository using SSH keys.

Read this article for a detailed procedure or check this video :

Prepare your app

You can create a new laravel project locally by using composer create :

composer create-project laravel/laravel --prefer-dist test_flashdrive

Then, initialize a git repository and commit your code :

git init
Initialized empty Git repository in ~/test_flashdrive/.git/
git add .
git commit -m "new laravel project"


Procfile is used to instruct the FlashDrive cluster to route the traffic to the correct file, a default Procfile for Laravel would be like that :

web: vendor/bin/heroku-php-apache2 public/

FlashDrive uses the PHP buildpack published by Heroku, the heroku mention above is not a typo πŸ™‚

You can also use Nginx by using this Procfile :

web: vendor/bin/heroku-php-nginx public/

Note : public/ is the standard default root directory for Laravel.

FlashDrive supports Apache 2.4 (2.4.48) and Nginx 1.18 (1.20.1) as Web servers.

Setting a Laravel encryption Key

The application’s encryption key is used by Laravel to encrypt user sessions and other information. Its value will be read from the APP_KEY environment variable.

You can run php artisan key:generate --show locally, this will display a key you can add to your app environment variable BEFORE building your application for the first time. Environment variables can be set on the App settings page.

Configuring reverse proxy

FlashDrive route the request to your app through a layer of Nginx reverse proxies. This proxy is responsible, among other things, to route the SSL traffic and negotiate the SSL certificates.
This means that requests received by an app will will always be made using the HTTP protocol, even if the original request was made over HTTPS.

FlashDrive provides the original request information in X-Forwarded-… headers and since Laravel uses components from the Symfony framework for HTTP request handling, it can easily be configured to trust such headers.

Do not make Laravel trusting the Forwarded and X-Forwarded-Host headers, because FlashDrive doesn’t set those headers.

PHP Version

You can select the version of PHP using the composer.json file, for example :

  "require": {
    "php": "^7.4.19"

At this time, only the following version are supported :


If you don’t specify a version, FlashDrive will use automatically the latest version of PHP7.


composer.json is mandatory.
composer.lock must also be present. To generate the composer.lock file run composer install locally before pushing your code.

It’s a good practice to remove the /vendor folder from your Git repository as it will be ignored during the build process.

FlashDrive doesn’t install development dependencies from the require-dev section of composer.json

Built-in extensions

The following table lists which of the built-in extensions that are bundled with PHP are available for each release series of PHP, and whether the extension in question is loaded by default, or whether it has to be explicitly enabled via composer.json.

ExtensionPHP 7.4PHP 8.0
βœ”: enabled by default
✱: optional, can be enabled via composer.json
Source :

Third-party extensions

The following table lists which third-party extensions are available for each release series of PHP. As these are distributed independently of the PHP runtime, their versions are also listed. They are never loaded by default and thus have to be explicitly enabled via composer.json.

ExtensionPHP 7.4PHP 8.0
ext-event (2.x)2.5.7
ext-event (3.x)
ext-newrelic (8.x)
ext-newrelic (9.x)
ext-phalcon (3.x)
ext-phalcon (4.x)4.1.2
ext-psr (0.x)0.7.0​
ext-psr (1.x)
ext-rdkafka (3.x)
ext-rdkafka (4.x)4.1.2
ext-rdkafka (5.x)
ext-redis (3.x)
ext-redis (4.x)
ext-redis (5.x)
Source :

Using Optional Extensions

You can declare extensions that are not available directly inside the PHP buildpack using the Composer Platform Packages. Just add ext- as a prefix of the package name.

Example to install mcrypt, bcmath, Memcached, and the third party MongoDB extension:

    "require": {
        "ext-bcmath": "*",
        "ext-mcrypt": "*",
        "ext-memcached": "*",
        "ext-mongodb": "^1.1.0"

Private Composer repositories

To use private composer repositories such as Private Packagist, you need to pass Authentification values as an environment variable.
Make sure to add this environment variable before requesting the build of your app or the build will fail :

The COMPOSER_AUTH environment variable is similar to the auth.json variable used on development environments :

When using GitHub Enterprise or the Self-Managed version of GitLab, remember to also set the github-domains or gitlab-domains config option inside your project’s composer.json.

Composer configuration

  • $COMPOSER_MEMORY_LIMIT defaults to the available app memory;
  • $COMPOSER_MIRROR_PATH_REPOS defaults to 1;
  • $COMPOSER_NO_INTERACTION defaults to 1.

Build Behavior

The following is run during build unless composer.json is empty and no composer.lock is present :

composer install --no-dev --prefer-dist --optimize-autoloader --no-interaction

Note: FlashDrive will not install development dependencies from the require-dev section of composer.json.

Custom compile scripts

Custom compile scripts can be added into the composer.json in form of a single line or multiple arguments :

"scripts": {
"compile": [
"php app/console assetic:dump --env=prod --no-debug",

The custom compile command will be executed by the builder like this :

composer compile --no-dev --no-interaction

Default Behavior

Default web server is Apache2, you can use Nginx by editing the Procfile but .htaccess files are not available with Nginx.

FlashDrive will launch a Fast CGI Process Managed and treats your Git root folder as the document root of the application, serving the .php files directly from that folder. Subsequent folders are served as well and you can alter this behavior using a .htaccess file.

Apache is set up with a Virtual Host that will respond to all hostnames. The document root is set up to be reachable without limitations and AllowOverride All is activated to allow for the use of .htaccess files.

Apache Configuration (Not working with Nginx servers)

Similar to httpd.conf configuration you can create an apache_app.conf file inside the root directory of your app to alter the behavior of Apache. This can be especially useful if you need, for instance, to alter the behavior of the Proxy timeout settings (30 seconds by default). This file can also contain htaccess directives or any other directives you can set inside an httpd.conf file

Edit your Procfile to load the apache_app.conf file with the -C directive when your app starts :

web: vendor/bin/heroku-php-apache2 -C apache_app.conf public/

Nginx Configuration (Not working with Apache Servers)

The default Nginx configuration file, similar to sites_availables, included with FlashDrive PHP apps is basic :

location / {
	index  index.php index.html index.htm;

# for people with app root as doc root, restrict access to a few things
location ~ ^/(composer\.(json|lock|phar)$|Procfile$|<?=getenv('COMPOSER_VENDOR_DIR')?>/|<?=getenv('COMPOSER_BIN_DIR')?>/) {
	deny all;

You can add a nginx_app.conf at the root directory of your app and add more directives at startup of your app, for example :

client_max_body_size 256m;

More information about Nginx configuration files

Then edit the Procfile of your app to load this configuration file when your app starts with the -C directive :

web: vendor/bin/heroku-php-nginx -C nginx_app.conf public/

php.ini configuration file

To alter the default settings of the php.ini file, you can create a .user.ini file at the root directory of your app and starts your app (inside the Procfile) with the -i directive. Here’s an example of .user.ini directives :

post_max_size = 50
upload_max_filesize = 128M
max_execution_time = 60
rlimit_files = 35645

See the instructions in the PHP manual for more details.

You can use these to set any directive permitted in PHP_INI_ALL, PHP_INI_USER and PHP_INI_PERDIR contexts.

php-fpm configuration

Some of the php.ini values are not modifiable directly from the .user.ini file. For example to set the always_poplate_raw_post_data to -1 you will need to create fpm_custom.conf file with the following contents :


Then, you’ll need to tell your application to start with -F directive and load the fpm_custom.conf file :

web: vendor/bin/heroku-php-apache2 -F fpm_custom.conf public/

In addition to php_value and php_flag for php.ini specific settings, any pool-specific PHP-FPM configuration directives are valid in that configuration file, so you can use it to fine-tune PHP-FPM’s behavior.

Note : .user.ini files are not evaluated if PHP is started with -F directive and a fpm_custom.conf file are present, all directives can be placed inside the fpm_custom.conf instead of .user.ini using the php_value tag.

Incorrect PHP-FPM configuration directives may easily cause your application to stop working or behave unexpectedly, so use with caution.

Maximum Execution Time

The maximum execution time of all PHP scripts is set to 30 seconds. This is governed by several configuration files at several levels of FlashDrive infrastructure.
By design, it’s not recommended to increase this value but instead to optimize your scripts or to run large queries and processing files in the background (which are not limited to 30 seconds).

If you absolutely need to run scripts for more than 30 seconds this can be done by altering several configuration files :

.user.ini file :

max_execution_time = 300

fpm_custom.conf :

request_terminate_timeout = 0

apache_app.conf file (or nginx_app.conf with appropriate instructions) :

TimeOut 300
ProxyTimeout 300

Then edit your Procfile to load all configuration files at startup :

web: vendor/bin/heroku-php-apache2 -i .user.ini -C apache_app.conf -F fpm_custom.conf public/

Create persistent storage

One of the major improvements of FlashDrive in comparison to others app hosting solutions is the ability to create Virtual Disks available for any copy of your app inside the same stack.

Virtual disks allow you to store data safely and securely, without the need to use an additional S3 bucket, and every app size gets free disk space depending on its size (see our pricing for more information).

In addition to that, Virtual disks are backup every day with 10 days history and ransomware protection at no additional cost.

Read this article for more information about virtual disks and how to add one to your app.

Add a domain name

Please check this article for a detailed method on how to use your domain name with FlashDrive apps.

Define environment variables

Note: Environment variables set in your app settings are injected during the build process. If the build of your app needs to use an env variable make sure to set it before requesting the build.

FlashDrive lets you externalize the configuration of your app : the FlashDrive cluster will automatically injects the data when the app start or restart.

Environment variables can include any external data your app needs to run like external resources, databases addresses, encryption keys etc…

To add an environment variable, access your app settings and click “Add ENV Variable” :

Enter the key (like DATABASE_USER) and the value and click “Add”. FlashDrive will automatically add your environment variable and restart your app after a one-minute delay (to let you add more env variables if necessary without restarting the app each time a new variable is added).

Provision a database

FlashDrive Marketplace includes all popular datastore engines including Mysql, Postgres, MongoDB, and Redis.
To add a database to your app, click on Marketplace and select the database you want to run, then create the new app database inside the same stack as your PHP app.

Once the app is running, visit the database app’s settings and retrieve the “internal name” :

Use this internal name as you would use a server address, for instance for MySQL this name replaces the usual “localhost”. Some scripts require you to add the database port at the end of the server address. FlashDrive uses a common port for each database software, for MySQL it will be 3306 and you can write it like that inside your scripts: internal-name:3306
Postgres usually uses credentials sent inside the login URL, like that : postgres://<user>:<password>@<internalname>:5432/<database>

The login and password information is available inside the Environment Variables of the database app.

Reach your app from another app

Inside your app stack, you can reach any other FlashDrive app member of this stack on any port. FlashDrive automatically routes the traffic internally and opens the appropriate port. By opposition, your app is only reachable on ports 80/443 from outside of FlashDrive.

To reach your app internally, retrieve the internal name from your app settings page :

This name can be used to reach your app from another app inside the same stack. Use it in any form that works with your script :


Note: https:// is not available, all the traffic inside apps is already encrypted by the cluster.


FlashDrive uses at rest encryption for the app virtual disks, build images, and encrypted transport from inside the cluster. To make sure the traffic is encrypted between your app and the browser of your users you can set up SSL certificates for any domain name connected to the app (including the FlashDrive’s default domain name).

Scale your App

From your app settings you can scale your app vertically and horizontally: by upgrading the app size (refer to our pricing for app sizes details) or by adding more nodes.

Additional nodes will run another copy of your app inside another FlashDrive server located inside the same cluster (same geographical location). Traffic is automatically sent to the least occupied node by FlashDrive’s load balancer.

Note: Apps that use Virtual Disks will share the same file structure and read/write on the same disk. It’s fine in most cases for intensive read activity but can create bottlenecks and corrupted data if several nodes of the same app write on the same file at the same time. If your apps use intensive reads on virtual disks consider upgrading the app size instead of adding more nodes.

Was this helpful?

2 / 0