Environments

​

Introduction

Laravel Cloud applications can be made up of many environments, such as “production”, “staging”, or even short-lived environments used for trialing new features you’re developing for your application.

Compute infrastructure, resources, and deployment settings are unique to each environment, allowing you to fine-tune each environment based on its purpose.

For example, you might wish to assign small, hibernating compute instances to your staging environment, while larger, non-hibernating compute instances are assigned to your production environment.

​

Build and Deploy Commands

You may define how both the frontend and backend of your application are built during deployment from the “Deployments” section of your environment settings.

​

Build Commands

Build commands allow you to customize the build process for your application. Typically, this will involve customizing how you want Composer and NPM dependencies to be installed. In addition, you may add any custom build scripts or commands that are specific to your Laravel application.

​

Private Composer Packages

To allow the installation of private Composer packages, you will need to configure your application’s Composer HTTP authentication credentials for each package using the composer config command. You should add this command to your build commands prior to invoking composer install:

composer config http-basic.composer.fluxui.dev your-username your-license-key

composer install --no-dev

​

Deploy Commands

Your environment’s “Deploy Commands” are run on your Laravel Cloud infrastructure just before a new deployment goes “live”. Typically, these commands will be used to migrate your environment’s database.

Unlike build commands, changes made to the filesystem by deploy commands will not be persisted to your application.

​

Environment Settings

​

Environment Variables

Within your environment’s settings, the environment variables section allows you to customize the .env variables available to your environment.

In addition to injecting your custom environment variables, Laravel Cloud will automatically inject a variety of environment variables into your environment on your behalf, including any credentials necessary to connect to Laravel Cloud resources like databases, key-value storage, or object storage.

After changing an environment’s variables, a re-deployment is required in order for the changes to take effect.

​

PHP Version

Currently, Laravel Cloud supports PHP 8.2, 8.3, and 8.4.

You may select the PHP version that should be used by an environment on the environment’s General Settings page. After changing the PHP version, a re-deployment is required in order for the changes to take effect.

​

PHP Extensions

Laravel Cloud currently supports the following PHP extensions:

apcu, bcmath, calendar, Core, ctype, curl, date, dom, ev, excimer, exif,
fileinfo, filter, ftp, gd, gettext, gmp, hash, iconv, igbinary, imagick,
imap, intl, json, ldap, libxml, mbstring, mongodb, msgpack, mysqli,
mysqlnd, openssl, pcntl, pcre, PDO, pdo_mysql, pdo_pgsql, pdo_sqlite,
Phar, posix, pspell, random, readline, redis, Reflection, session, shmop,
SimpleXML, soap, sockets, sodium, SPL, sqlite3, standard, tokenizer, xml,
xmlreader, xmlwriter, xsl, Zend OPcache, zip, zlib, Zend OPcache.

You can also list the currently loaded extensions by running php -m using Laravel Cloud’s “Command” feature in your environment dashboard.

​

PHP Memory Limit

Laravel Cloud allocates PHP memory dynamically based on a percentage of your instance’s total memory. If your application requires a specific amount, you can override this by defining a new memory_limit.

You can override the default memory limit by adding configuration directly in your application code. The most common method is to update your public/index.php file:

<?php

// Set memory limit to 512 MB...
ini_set('memory_limit', '512M');

// Or, remove memory limits entirely...
ini_set('memory_limit', -1);

Memory adjustments should be made early in your application’s lifecycle to ensure optimal performance. Excessive memory usage can negatively impact overall application efficiency. While setting the memory limit to -1 removes all memory restrictions, this option should be used with caution, especially in production environments, as it can lead to unpredictable behavior.

For more information regarding PHP memory configuration, consult the official PHP documentation.

​

Node Version

From your environment’s General Settings page, you may select the Node version that should be available to the build commands used to build your application during a deployment. After changing the Node version, a re-deployment is required in order for the changes to take effect.

​

Cloud Domains

Each Laravel Cloud environment is assigned a free laravel.cloud domain the first time it is deployed successfully. This makes it easy to test and build your application before attaching a custom domain.

Laravel Cloud domains are constructed using a combination of your application and environment name. If either of these names are changed, the Laravel Cloud domain will be updated to reflect the changes. A redeployment is required for this change to take effect.

​

Custom Domains

Of course, before shipping your application to the world, you will likely want to assign your own custom domain name to your production environment.

To get started, click “Add domain” on your environment’s infrastructure canvas dashboard. From the domain settings page, you will be able to add a custom domain to the environment. When adding the domain, Laravel Cloud will guide you through the steps necessary to verify your ownership of the domain being added. The domain verification process will require you to add several DNS records to you domain registrar or DNS provider’s DNS settings.

Once your custom domain has been verified, you will be able to access the corresponding environment via the domain.

You may detach the custom domain from an environment or re-assign the custom domain to another environment at any time from your environment’s domain settings page.

​

Wildcard Domains

If you require wildcard subdomain support on your custom domain, you must carry out pre-verification in order to prove ownership of the entire domain.

Therefore, you should make sure you add the DCV delegation record provided to you in the Laravel Cloud dashboard to ensure the wildcard SSL certificates continue to be issued.

Finally, if your domain / DNS is managed by Cloudflare, you should disable the Cloudflare proxy (Orange Cloud) to allow the domain to be verified.

​

Troubleshooting Domain Verification

If your domain fails verification or seems to be taking a long time to verify, there are a few things you should check:

• If you are carrying out pre-verification, ensure you have added the records correctly. Some DNS providers require you to add the domain when setting the name of the DNS records, while others do not. This can result in an invalid record. For example, if the DNS provider adds the domain portion of the record name on your behalf, but you also add it when creating the record, you may end up with a record that contains a duplicate domain e.g. _cf-custom-hostname.example.com.example.com vs. _cf-custom-hostname.example.com

• If you are carrying out real-time verification, ensure the domain is pointed correctly at Laravel Cloud’s A record provided to you in the UI. You can also try making a request to the domain to allow us to pick up the traffic flowing into our network.

​

Stop and Restart

To stop an environment, click the ”…” button next to the environment’s “Deploy” button. Then, click “Stop”. When you stop an environment, all App and Worker clusters within the environment will be shutdown. This means all web traffic, background processes, and scheduled tasks will stop processing. You will not be charged for the environment’s compute, but you will still be charged for any attached resources.

You can restart the environment using the same dropdown menu. A full deployment is required to restart an environment.

​

Replicate

It is common for environments in the same application to have similar or identical resource and settings configurations. Therefore, when creating new environments, it is often more convenient to clone an existing environment and make changes rather than creating a new environment from scratch.

To replicate an environment, click the ”…” button next to the environment’s “Deploy” button. Then, click “Replicate”. Confirm you are replicating the correct environment and git branch, then enter a name for your new environment. By default, all General, Environment, and Deployment settings will be duplicated. You can optionally edit the default replication settings for compute and resources. The default replication behavior is:

• Compute: duplicate all clusters (including size, autoscaling, hibernation, scheduler, Octane, Inertia, and background process settings)
• Database: use the same database compute / storage cluster, but create a new logical database schema
• Cache: use the same KV Store instance, but add a unique CACHE_PREFIX environment variable to your application
• Object storage: no replication