Learn how to deploy your Laravel applications to Laravel Vapor.
build
steps of your vapor.yml
file on the local machine that the deployment is running on. This might be your personal machine or a continuous integration platform.
deploy
CLI command from the root of your application:
vapor deploy production
, Vapor will look for a vapor.yml
manifest file. However, you can specify a custom manifest using the --manifest
option:
build
key within your vapor.yml
file. These commands are executed on the local machine that the deployment is running on and may be used to prepare your application for deployment. During deployment, your application is built within a temporary .vapor
directory that is created by the CLI and all of your build
commands will run within that temporary directory:
deploy
key within your vapor.yml
file. These commands are executed against the deployed environment before it is activated for general availability. If any of these commands fail, the deployment will not be activated.
vapor deploy
command, the CLI output will contain the failing hook output. Of course, you may review the output at any time using the hook:output
command:
hook:log
command:
public
directory and upload them to S3. In addition, Vapor will create a AWS CloudFront (CDN) distribution to distribute these assets efficiently around the world.
Because all of your assets will be served via S3 / CloudFront, you should always generate URLs to these assets using Laravel’s asset
helper. Vapor injects an ASSET_URL
environment variable which Laravel’s asset
helper will use when constructing your URLs:
us-east-1
region.
Next, set the asset-domain
option of your vapor.yml
file to your chosen domain:
Vapor.asset
helper that will behave like Laravel’s asset
helper but on the client. To get started, install the laravel-vapor
NPM package:
app.js
file, initialize the global Vapor JavaScript object:
Vapor.asset
helper in your JavaScript code:
asset
helper when you are referencing assets you don’t want bundled, such as those that already live in your public directory.If you want to use the asset
helper with your Vite project, you will also need to specify the base URL for assets in your application’s entry point, for example in your resources/js/app.js
, like so: Vapor.withBaseAssetUrl(import.meta.env.VITE_VAPOR_ASSET_URL)
vapor.yml
configuration file, you may need your build script to be able to access your environment variables. An excellent example of this requirement is instantiating a frontend SDK such as Pusher.
Build steps are executed in the environment where a deployment is initiated - typically, this will be your local machine or your CI pipeline. As such, you must ensure the required environment variables are available in that environment.
To assist with this, Vapor will attempt to load variables first from .env.[environment]
(e.g. .env.staging
). If that file does not exist, Vapor will attempt to load variables from the .env
file. You should ensure one of these file contains all of the environment variables needed by that environment’s build script.
When using CI platforms, you may not have access to the environment files as these are typically omitted from version control. In this scenario, your CI provider will typically provide a mechanism for injecting variables into the build pipeline. For instance, with GitHub Actions, your GitHub Action configuration might look like the following:
npm run build
, Vite will always use the .env.production
file if it is present, even if you are deploying a different environment. If you maintain multiple environment files in your deployment environment, you should set the Vite build mode explicitly:ASSET_URL
variable that Laravel Vapor injects into your environment during your build step:
mix
helper locally and the asset
helper when deploying to Vapor:
background-image
property that references an image via URL. Obviously, you are not able to use the PHP asset
helper within your CSS. For this reason, Vapor will automatically prepend the correct asset base URL to all relative URLs in your CSS during the build process. After your build steps have executed, Vapor performs this action against any CSS files in your application’s public
directory (including directories nested under public
).
serve_assets
configuration option within your vapor
configuration file:
vapor
configuration file, you can publish it using the vendor:publish
Artisan command:
dot-files-as-assets
key to true
in your vapor.yml
file:
robots.txt
file to the S3 asset bucket or CloudFront’s asset URL. If you would like the robots.txt
file to be served directly from your application, you may set the redirect_robots_txt
configuration value to false
within your application’s config/vapor.php
configuration file:
vapor
configuration file, you can publish it using the vendor:publish
Artisan command:
redeploy
CLI command:
rollback
CLI command. The rollback
command’s “—select” option will allow you to select which deployment to rollback to from a list of recent deployments. If the rollback
command is executed without this option, it will simply rollback to the most previous successful deployment:
vapor deploy
command in your CI platform’s deployment pipeline.
In order to authenticate with Vapor from your CI platform, you will need to add a VAPOR_API_TOKEN
environment variable to your CI build environment. You may generate an API token in your Vapor API settings dashboard.
vapor deploy
command. For example, if using CodeShip:
VAPOR_COMMIT_HASH
.
master
branch:
VAPOR_API_TOKEN
environment variable to your “GitHub > Project Settings > Secrets” settings so that GitHub can authenticate with Vapor while running actions.
deploy.yml
file within the your-project/.github/workflows
directory. The file should have the following contents:
deploy.yml
file to fit your application’s deployment needs, as it may require a different PHP version or a library like npm
. Once you are done, commit and push the deploy.yml
file to master
so GitHub Actions can run the first deployment job.x86_64
architecture, they are unable to natively compile arm64
based images. In order to compile the docker-arm
runtime, the arm64
platform can be emulated using QEMU. To get started, add the following to your deploy.yml
, directly after the “Checkout Code” step:
master
branch:
VAPOR_API_TOKEN
environment variable to your “Chipper CI > Project Settings > Project Environment Variables” settings so that Chipper CI can authenticate with Vapor while running your build pipeline.
Deploy
and the following content:
master
branch so that Chipper CI will deploy your application.