PHPackages codinglabsau/yolo - PHPackages - PHPackages [Skip to content](#main-content)[PHPackages](/)[Directory](/)[Categories](/categories)[Trending](/trending)[Leaderboard](/leaderboard)[Changelog](/changelog)[Analyze](/analyze)[Collections](/collections)[Log in](/login)[Sign up](/register) 1. [Directory](/) 2. / 3. [CLI & Console](/categories/cli) 4. / 5. codinglabsau/yolo ActiveLibrary[CLI & Console](/categories/cli) codinglabsau/yolo ================= YOLO infrastructure cli tool for deploying Laravel apps v1.0.0-alpha.31(1mo ago)021.8k↓39.1%1[2 PRs](https://github.com/codinglabsau/yolo/pulls)proprietaryPHPPHP ^8.3CI passing Since Feb 7Pushed 4mo ago2 watchersCompare [ Source](https://github.com/codinglabsau/yolo)[ Packagist](https://packagist.org/packages/codinglabsau/yolo)[ Docs](https://github.com/codinglabsau/yolo)[ RSS](/packages/codinglabsau-yolo/feed)WikiDiscussions main Synced 1mo ago READMEChangelog (10)Dependencies (28)Versions (38)Used By (0) YOLO ==== [](#yolo) Important This package is in active development - contributions are welcome! YOLO helps you deploy high-availability PHP applications to AWS. The CLI tool lives inside your Laravel app in `vendor/bin/yolo`, and takes care of provisioning and configuring all required resources on AWS, coupled with build and deployment commands to deploy applications to production from your local machine or CI pipeline. YOLO has been battle-tested on apps that serve 2 million requests per day. Features -------- [](#features) ### Autoscaling Worker Groups [](#autoscaling-worker-groups) YOLO provisions an Application Load Balancer and autoscaling groups (web, queue, scheduler) for each environment. Each group is self-healing should an instance become unresponsive, and the web group automatically scales up to handle traffic bursts. In addition, worker groups can be combined (coming soon) to a single EC2 instance to consolidate small workloads. ### Resource Sharing [](#resource-sharing) YOLO shares various resources between applications to reduce costs. ### Zero-downtime Deployments [](#zero-downtime-deployments) YOLO leverages AWS CodeDeploy to perform zero-downtime deployments, which can be triggered from the CLI or via a CI pipeline. ### Multi-tenancy [](#multi-tenancy) Specify tenants in the manifest and YOLO will take care of provisioning resources for each tenant. ### .env Management [](#env-management) Manage .env files locally with push and pull commands. Preview changes before deploying. ### S3 [](#s3) Leverage S3 for storing build artefacts and user data files. ### Octane (experimental) [](#octane-experimental) YOLO supports Laravel Octane for turbocharged PHP applications. ### Video Transcoding [](#video-transcoding) YOLO can configure your app environment to utilise video transcoding using AWS Elemental MediaConvert. ### And Much More... [](#and-much-more) - Least priviledge permissions with strong segregation across environments and apps - Seperate commands that run on deployment across worker groups - Scheduled MySQL backups using `mysqldump` - Control of build and deploy commands - Re-use existing VPCs, subnets, internet gateways and more --- Disclaimer ---------- [](#disclaimer) YOLO is designed for PHP developers who are comfortable managing AWS using an infrastructure-as-code approach. It is, at it's core, a Symfony CLI app that leverages the AWS SDK, rather than CloudFormation / Terraform / K8s / Elastic Beanstalk / . While YOLO has underpinned very large, mission-critical production applications, it is not intended to be a set and forget solution; rather it acts as a control plane that allows you to manage and expand your AWS footprint over time. It goes without saying, but use YOLO at your own risk. Prerequisites ------------- [](#prerequisites) You'll need access to an AWS account, and some knowledge of AWS services. ### Domains on Route53 [](#domains-on-route53) The domains for your app should be added to Route53 on the same AWS account as where the app is hosted in advance. ### Permissions & Authentication [](#permissions--authentication) YOLO uses AWS profiles for authentication. Profiles are stored in `~/.aws/credentials` for authentication. You'll need to set a `YOLO_{ENVIRONMENT}_AWS_PROFILE` in the app `.env` file to point to the correct profile; eg. ``` YOLO_PRODUCTION_AWS_PROFILE=my-project-profile ``` Once configured, future operations will authenticate using this profile. You will need wide-ranging AWS credentials to provision everything required by YOLO; administrative permissions are recommended. For CI environments like GitHub Actions, `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are used instead. Ensure that any access keys provided in CI are using least-privileged scope. Step 1: Installation -------------------- [](#step-1-installation) ### a) Install With Composer [](#a-install-with-composer) ``` composer require codinglabsau/yolo ``` The entry point to the YOLO CLI is `vendor/bin/yolo` or `yolo` if you have `./vendor/bin` in your path. Run `yolo` to see the available commands. ### b) Initialise yolo [](#b-initialise-yolo) Next, run `yolo init`. The init command does the following: 1. initialises the yolo.yml file in the app with a boilerplate production environment 2. adds some entries to `.gitignore` 3. prompts for a few bits of information to setup the manifest file After initialising, you can customise the `yolo.yml` manifest file to suit your app's requirements. Step 2: Provision resources --------------------------- [](#step-2-provision-resources) YOLO is designed to create and manage all AWS resources required to run your application. Provision all resources by running `yolo sync `. This command runs all `sync` commands in the correct order. The full list of available sync commands are: - `yolo sync:network ` prepares the VPC, subnets, security groups and SSH keys - `yolo sync:standalone ` prepares standalone app resources (standalone apps only) - `yolo sync:landlord ` prepares landlord resources (multitenancy apps only) - `yolo sync:tenant ` prepares tenant resources (multitenancy apps only) - `yolo sync:compute ` prepares the compute resources - `yolo sync:ci ` prepares the continuous integration pipeline - `yolo sync:iam ` prepares necessary permissions Tip All sync commands support a `--dry-run` argument; this is a great starting point to see what resources will be created or modified without any actual changes occurring on AWS. Step 3: Prepare a server image ------------------------------ [](#step-3-prepare-a-server-image) With all the low-level resource provisioned via the `sync` commands, the next step is to create an Amazon Machine Image ( AMI) with Ubuntu OS as the foundation. The image will be used as the initial disk image for all server instances, and can be updated over time to bring in improvements, such as new PHP versions. ### a) Create an image [](#a-create-an-image) Run `yolo image:create ` to generate a new AMI. ### b) Prepare the image for traffic [](#b-prepare-the-image-for-traffic) To prepare a new stage, run `yolo stage `. This interactive command walks you through updating or replacing the current stage configuration. New stages have the benefit of allowing testing before migrating production workloads over, however simply updating the existing stage is recommended for minor changes. SituationRecommended strategyUpdate EC2 security groupupdateUpdate EC2 typeupdateUpdate EC2 instance profileupdateUpdate AMIcreateWhen creating a new stage, the yolo.yml manifest will also be updated to point to the new autoscaling groups on the next deployment. Note Rotating in a new image does not have any impact on existing traffic until the updated manifest is deployed - the previous deployment will continue serving requests and autoscaling as per normal. Step 4. Setup .env file ----------------------- [](#step-4-setup-env-file) You'll need to push the initial .env file for the environment. Environment files are stored in the S3 artefacts bucket, and retrieved during deployment. If you have an existing .env file, be sure to copy that over to `.env.` in the root of the app, otherwise you can build on the stub provided by the `init` command. To push the .env file to the artefacts bucket, run `yolo env:push `. After the initial push, you can retrieve the .env file with `yolo env:pull `. Step 5. Building and deploying ------------------------------ [](#step-5-building-and-deploying) Builds can be created with `yolo build `. The build command takes care of building a deployment-ready directory in `./yolo`. Builds can be deployed with `yolo deploy `. Tip You can also build and deploy in a single command with `yolo deploy `. yolo.yml -------- [](#yoloyml) This is a complete yolo.yml manifest file, showing default values where applicable. Note that some keys below are intentionally omitted from the stub generated by `yolo init`. ``` name: codinglabs timezone: UTC environments: production: aws: account-id: region: ap-southeast-2 vpc: internet-gateway: public-subnets: route-table: bucket: artefacts-bucket: cloudfront: alb: mediaconvert: false autoscaling: web: queue: scheduler: combine: false ec2: instance-type: t3.small queue-instance-type: scheduler-instance-type: octane: false nightwatch: false key-pair: security-group: rds: subnet: security-group: codedeploy: strategy: without-load-balancing|with-load-balancing sqs: depth-alarm-evaluation-periods: 3 depth-alarm-period: 300 depth-alarm-threshold: 100 asset-url: # defaults to aws.cloudfront mysqldump: false domain: example.com # standalone apps only apex: # standalone apps only tenants: # multi-tenanted apps only boating: # unique key for the tenant domain: boating-with-yolo.com fishing: # unique key for the tenant domain: fishing-with-yolo.com build: - composer install --no-cache --no-interaction --optimize-autoloader --no-progress --classmap-authoritative --no-dev - npm ci - npm run build - rm -rf package-lock.json resources/js resources/css node_modules database/seeders database/factories resources/seeding deploy: #runs on scheduler - php artisan migrate --force deploy-queue: # runs on queue - deploy-web: # runs on web - deploy-all: # runs on all instances - php artisan optimize ``` ### Continuous Integration [](#continuous-integration) The app version can be specified as an option with `--app-version` to the `build` and `deploy` commands. The recommended approach is to tag your GitHub releases with a date-based naming convention, and then forward the tag to your deploy action, similar to the following: ``` - name: Deploy run: php vendor/bin/yolo deploy production --app-version=${{ github.event.release.tag_name }} env: AWS_ACCESS_KEY_ID: ${{ secrets.PRODUCTION_AWS_ACCESS_KEY_ID }} AWS_SECRET_ACCESS_KEY: ${{ secrets.PRODUCTION_AWS_SECRET_ACCESS_KEY }} ``` The current app version must start with `year.week`, for example `25.3` to represent the third week of 2025. After the year and week, use whatever convention you like; a common approach is to increment the third digit for each release, for example `25.3.1`, `25.3.2`, etc. Because the app version is validated during the build and utilises the UTC timezone by default, you may wish to set the manifest `timezone` option to the timezone of your team to prevent validation errors at the start of the week if your timezone is ahead of UTC. ### Domains [](#domains) Applications hosted with yolo can be served on any domain or subdomain that you own. The domain should be added to Route53 in advance. For a standalone application, the domain key can be used: ``` domain: codinglabs.com.au ``` In this example, the app will be served on `codinglabs.com.au`, and `www.codinglabs.com.au` will redirect to `codinglabs.com.au`. If the application is served on any subdomain (including [www](http://www).) you'll need to specify the apex record as well. ``` apex: codinglabs.com.au domain: www.codinglabs.com.au ``` In this example, the app will be served on `www.codinglabs.com.au`, and `codinglabs.com.au` will redirect to `www.codinglabs.com.au`. Multi-tenant applications follow the same logic, except that domains are configured under the `tenants` key. ``` tenants: boating: domain: boating.outdoors-with-yolo.com apex: outdoors-with-yolo.com camping: domain: camping.outdoors-with-yolo.com apex: outdoors-with-yolo.com fishing: domain: fishing-with-yolo.com ``` Development ----------- [](#development) To debug or add features to YOLO, it is recommended to symlink to the local repository. Add this to composer.json with the path to the local repository: ``` "repositories": [ { "type": "path", "url": "/Users/username/code/yolo" } ], ``` To call yolo from the app you are debugging, you'll need to tell yolo the path to the app. Set the `YOLO_BASE_PATH`environment to the root of the app as follows: ``` YOLO_BASE_PATH=$(pwd) yolo ``` Credits ------- [](#credits) - [Steve Thomas](https://github.com/stevethomas) - [All Contributors](https://github.com/codinglabsau/yolo/contributors) License ------- [](#license) MIT ### Health Score 46 — FairBetter than 93% of packages Maintenance82 Actively maintained with recent releases Popularity30 Limited adoption so far Community11 Small or concentrated contributor base Maturity51 Maturing project, gaining track record Bus Factor1 Top contributor holds 99.7% of commits — single point of failure How is this calculated?**Maintenance (25%)** — Last commit recency, latest release date, and issue-to-star ratio. Uses a 2-year decay window. **Popularity (30%)** — Total and monthly downloads, GitHub stars, and forks. Logarithmic scaling prevents top-heavy scores. **Community (15%)** — Contributors, dependents, forks, watchers, and maintainers. Measures real ecosystem engagement. **Maturity (30%)** — Project age, version count, PHP version support, and release stability. ### Release Activity Cadence Every ~13 days Total 31 Last Release 53d ago ### Community Maintainers ![](https://www.gravatar.com/avatar/6324d6d1a5b089cfa3d7519b590f0762281ff3bad210c6139209a1c6394d6f5c?d=identicon)[stevethomas](/maintainers/stevethomas) --- Top Contributors [![stevethomas](https://avatars.githubusercontent.com/u/1127412?v=4)](https://github.com/stevethomas "stevethomas (341 commits)")[![SethSharp](https://avatars.githubusercontent.com/u/58869086?v=4)](https://github.com/SethSharp "SethSharp (1 commits)") --- Tags awscontinuous-integrationlaravel ### Code Quality TestsPest Static AnalysisPHPStan Code StyleLaravel Pint Type Coverage Yes ### Embed Badge ![Health badge](/badges/codinglabsau-yolo/health.svg) ``` [![Health](https://phpackages.com/badges/codinglabsau-yolo/health.svg)](https://phpackages.com/packages/codinglabsau-yolo) ``` ### Alternatives [laravel/vapor-cli The Laravel Vapor CLI 31310.7M8](/packages/laravel-vapor-cli)[tightenco/jigsaw Simple static sites with Laravel's Blade. 2.2k438.5k29](/packages/tightenco-jigsaw)[aedart/athenaeum Athenaeum is a mono repository; a collection of various PHP packages 245.2k](/packages/aedart-athenaeum)[laravel-zero/framework The Laravel Zero Framework. 3371.4M369](/packages/laravel-zero-framework)[roots/acorn Framework for Roots WordPress projects built with Laravel components. 9682.1M97](/packages/roots-acorn)[flarum/core Delightfully simple forum software. 211.3M1.9k](/packages/flarum-core) PHPackages © 2026 [Directory](/)[Categories](/categories)[Trending](/trending)[Changelog](/changelog)[Analyze](/analyze)