Categories

Laravel Vapor – getting started

Intro

This post contains a basic overview of the most-commonly used Vapor setup commands. This is by-far not a comprehensive list, think of this as a cheat-sheet.

What’s Laravel Vapor?

Here’s a quote from the makers themselves:

Laravel Vapor is an auto-scaling, serverless deployment platform for Laravel, powered by AWS Lambda. Manage your Laravel infrastructure on Vapor and fall in love with the scalability and simplicity of serverless.

Vapor abstracts the complexity of managing Laravel applications on AWS Lambda, as well as interfacing those applications with SQS queues, databases, Redis clusters, networks, CloudFront CDN, and more.

Source: https://docs.vapor.build/1.0/introduction.html#introduction

Note

This service is provided by both Vapor and AWS, so it will not be free to use!

Getting started

Ensure your application is built to support PHP 7.3+ and Laravel 6.0+. If the latter is true – head on over to the Vapor sign-up page, and create an account sign-up-link

Deployment

Vapor is basically an orchestrator, so you’ll need to access it’s intricacies somehow – that’s done via the Vapor CLI. To add it globally, use composer:

composer global require laravel/vapor-cli

You can access the CLI by using the following command structure, after a successful install:

php vendor/bin/vapor {command}
php vendor/bin/vapor list - displays all available commands
php vendor/bin/vapor help deploy - shows further info for a given command

Setting up your application to use Vapor

This has been pre-made for us by the Vapor team, and the link is generated by calling composer require laravel/vapor-core from within your project structure. From there-on-out your project knows that it’s deployments will be handled by Vapor, and vise-versa.

Creating projects

This can be handled within the UI, or done in the CLI by typing: vapor init. Make sure to call that command from within your project’s root directory, so that all the files are attached correctly. Beware that the command will prompt you for AWS account selection, similar to a Kubernetes+AWS setup. After the command has ran successfully, you should see a vapor.yml file appear in your root dir. Again, super similar to a Kubernetes setup.

Deleting projects

Hey, sometimes a project is not meant to be, if you want to drop it from your Vapor stack use: vapor project:delete. Running the latter from within your project’s root directory, will ensure that it’s gone from Vapor.

UI

Vapor also has an amazing UI, here’s a screenshot of that:

UI screenshot (Source)

Environments

You know that a high quality project nowadays contains limited information or resources within them. The latter are usually fetched via a composer install command, that is ran in the build phase of the deployment pipeline. The latter differs when you’re building your project to go to a test, staging, or a production environment. Handling the build commands is done by using Vapor enviroments.

Creating an environment

Super simple: vapor env my-environment. This will add a new env entry to your vapor.yml file, and you can go and fine-tune the instructions from there. Here’s a brilliant example of the above YML file, from the creators themselves:

id: 1
name: vapor-app
environments:
    staging:
        build:
            - 'composer install --no-dev'
    test:
        build:
            - 'composer install'
    my-environment:
        build:
            - 'composer install --no-dev'

Updating vars in real-time

To see what variables are loaded on a running instance, you should call: vapor env:pull production from your root dir. That generates a .env.production file in you directory. Edit the values in there, and then call vapor env:push production. Note that you need to re-deploy the application, for the variables to be consumed! If you need to rollback, the variable values will be rolled-back as well!

Reserved variable names

You cannot use any of the following names within your variable lists:

  • _HANDLER
  • AWS_ACCESS_KEY_ID
  • AWS_EXECUTION_ENV
  • AWS_LAMBDA_FUNCTION_MEMORY_SIZE
  • AWS_LAMBDA_FUNCTION_NAME
  • AWS_LAMBDA_FUNCTION_VERSION
  • AWS_LAMBDA_LOG_GROUP_NAME
  • AWS_LAMBDA_LOG_STREAM_NAME
  • AWS_LAMBDA_RUNTIME_API
  • AWS_REGION
  • AWS_SECRET_ACCESS_KEY
  • AWS_SESSION_TOKEN
  • LAMBDA_RUNTIME_DIR
  • LAMBDA_TASK_ROOT
  • TZ

Custom domains

If you need to give a custom domain to a given deployment, say your prod and staging URLs are different, simply refer back to the vapor.yml and edit the values like so:

id: 1
name: vapor-app
environments:
    production:
        domain: sudorambles.com
        build:
            - 'composer install --no-dev'

Timeouts

By default the configuration is set to timeout at 10 seconds. If you need to override that value, edit your vapor.yml like so:

id: 1
name: vapor-app
environments:
    production:
        timeout: 35
        build:
            - 'composer install --no-dev'

Schedulers

Vapor contains an auto-start and pre-configured Laravel task scheduler within it. If for any reason you want to skip that additional feature, edit your vapor.yml file:

id: 1
name: vapor-app
environments:
    production:
        scheduler: off
        build:
            - 'composer install --no-dev'

Documentation quick-links

All of the latter links will take you directly to the Vapor’s documentation, for topics we couldn’t cover here:

Conclusion

Vapor is an amazing tool to use as an orchestrator, combining that with an AWS deployment environment, you can build concrete services that will be scalable and truly unbreakable. One stopper is exactly that though, AWS can get expensive very quickly. If you decide to move your project over to Vapor, beware of the potential costs.

Home