{"id":50925234,"url":"https://github.com/codinglabsau/yolo-alpha","last_synced_at":"2026-06-16T22:02:19.239Z","repository":{"id":358772678,"uuid":"1242970500","full_name":"codinglabsau/yolo-alpha","owner":"codinglabsau","description":null,"archived":false,"fork":false,"pushed_at":"2026-06-08T07:15:02.000Z","size":243,"stargazers_count":0,"open_issues_count":2,"forks_count":0,"subscribers_count":0,"default_branch":"main","last_synced_at":"2026-06-08T09:12:20.557Z","etag":null,"topics":[],"latest_commit_sha":null,"homepage":null,"language":"PHP","has_issues":false,"has_wiki":null,"has_pages":null,"mirror_url":null,"source_name":null,"license":"mit","status":null,"scm":"git","pull_requests_enabled":true,"icon_url":"https://github.com/codinglabsau.png","metadata":{"files":{"readme":"README.md","changelog":null,"contributing":null,"funding":null,"license":"LICENSE.md","code_of_conduct":null,"threat_model":null,"audit":null,"citation":null,"codeowners":null,"security":null,"support":null,"governance":null,"roadmap":null,"authors":null,"dei":null,"publiccode":null,"codemeta":null,"zenodo":null,"notice":null,"maintainers":null,"copyright":null,"agents":null,"dco":null,"cla":null}},"created_at":"2026-05-18T23:51:54.000Z","updated_at":"2026-05-19T01:37:00.000Z","dependencies_parsed_at":null,"dependency_job_id":null,"html_url":"https://github.com/codinglabsau/yolo-alpha","commit_stats":null,"previous_names":["codinglabsau/yolo-alpha"],"tags_count":1,"template":false,"template_full_name":null,"purl":"pkg:github/codinglabsau/yolo-alpha","repository_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/codinglabsau%2Fyolo-alpha","tags_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/codinglabsau%2Fyolo-alpha/tags","releases_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/codinglabsau%2Fyolo-alpha/releases","manifests_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/codinglabsau%2Fyolo-alpha/manifests","owner_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners/codinglabsau","download_url":"https://codeload.github.com/codinglabsau/yolo-alpha/tar.gz/refs/heads/main","sbom_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories/codinglabsau%2Fyolo-alpha/sbom","scorecard":null,"host":{"name":"GitHub","url":"https://github.com","kind":"github","repositories_count":286080680,"owners_count":34425024,"icon_url":"https://github.com/github.png","version":null,"created_at":"2022-05-30T11:31:42.601Z","updated_at":"2026-05-26T15:22:16.424Z","status":"online","status_checked_at":"2026-06-16T02:00:06.860Z","response_time":126,"last_error":null,"robots_txt_status":"success","robots_txt_updated_at":"2025-07-24T06:49:26.215Z","robots_txt_url":"https://github.com/robots.txt","online":true,"can_crawl_api":true,"host_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub","repositories_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repositories","repository_names_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/repository_names","owners_url":"https://repos.ecosyste.ms/api/v1/hosts/GitHub/owners"}},"keywords":[],"created_at":"2026-06-16T22:02:14.889Z","updated_at":"2026-06-16T22:02:19.230Z","avatar_url":"https://github.com/codinglabsau.png","language":"PHP","funding_links":[],"categories":[],"sub_categories":[],"readme":"\u003cp align=\"center\"\u003e\n  \u003cimg src=\"art/logo.png\" alt=\"YOLO\" height=\"80\"\u003e\n\u003c/p\u003e\n\n\u003cp align=\"center\"\u003e\n  \u003ca href=\"https://github.com/codinglabsau/yolo-alpha/actions/workflows/test.yml\"\u003e\u003cimg src=\"https://github.com/codinglabsau/yolo-alpha/actions/workflows/test.yml/badge.svg\" alt=\"Test\"\u003e\u003c/a\u003e\n  \u003ca href=\"https://github.com/codinglabsau/yolo-alpha/actions/workflows/analyse.yml\"\u003e\u003cimg src=\"https://github.com/codinglabsau/yolo-alpha/actions/workflows/analyse.yml/badge.svg\" alt=\"Analyse\"\u003e\u003c/a\u003e\n  \u003ca href=\"LICENSE.md\"\u003e\u003cimg src=\"https://img.shields.io/badge/License-MIT-blue.svg\" alt=\"License: MIT\"\u003e\u003c/a\u003e\n  \u003ca href=\"https://php.net\"\u003e\u003cimg src=\"https://img.shields.io/badge/PHP-8.3%2B-777BB4.svg\" alt=\"PHP 8.3+\"\u003e\u003c/a\u003e\n\u003c/p\u003e\n\n\u003e [!IMPORTANT]\n\u003e **YOLO Alpha is frozen — bug fixes only.** This is the pre-1.0 EC2/ASG deployer extracted from `codinglabsau/yolo` so it can run side-by-side with YOLO 1.0 (Fargate) during the LP cutover window. New work happens on [`codinglabsau/yolo`](https://github.com/codinglabsau/yolo).\n\nYOLO helps you deploy high-availability PHP applications to AWS.\n\nThe CLI tool lives inside your Laravel app in `vendor/bin/yolo-alpha`, and takes care of provisioning and configuring all\nrequired resources on\nAWS, coupled with build and deployment\ncommands to deploy applications to production from your local machine or CI pipeline.\n\nYOLO has been battle-tested on apps that serve 2 million requests per day.\n\n## Features\n\n### Autoscaling Worker Groups\n\nYOLO provisions an Application Load Balancer and autoscaling groups (web, queue, scheduler) for each environment.\n\nEach group is self-healing should an instance become unresponsive, and the web group automatically scales up to handle\ntraffic bursts.\n\nIn addition, worker groups can be combined (coming soon) to a single EC2 instance to consolidate small workloads.\n\n### Resource Sharing\n\nYOLO shares various resources between applications to reduce costs.\n\n### Zero-downtime Deployments\n\nYOLO leverages AWS CodeDeploy to perform zero-downtime deployments, which can be triggered from the CLI or via a CI\npipeline.\n\n### Multi-tenancy\n\nSpecify tenants in the manifest and YOLO will take care of provisioning resources for each tenant.\n\n### .env Management\n\nManage .env files locally with push and pull commands. Preview changes before deploying.\n\n### S3\n\nLeverage S3 for storing build artefacts and user data files.\n\n### Octane (experimental)\n\nYOLO supports Laravel Octane for turbocharged PHP applications.\n\n### Video Transcoding\n\nYOLO can configure your app environment to utilise video transcoding using AWS Elemental MediaConvert.\n\n### Interactive Video Service (IVS)\n\nAWS IVS is Amazon's managed low-latency live video streaming service. For apps that use IVS, YOLO captures all IVS state-change events to CloudWatch via EventBridge for audit and debugging.\n\n### And Much More...\n\n- Least priviledge permissions with strong segregation across environments and apps\n- Seperate commands that run on deployment across worker groups\n- Scheduled MySQL backups using `mysqldump`\n- Control of build and deploy commands\n- Re-use existing VPCs, subnets, internet gateways and more\n\n___\n\n## Disclaimer\n\nYOLO is designed for PHP developers who are comfortable managing AWS using an infrastructure-as-code approach.\n\nIt is, at it's core, a Symfony CLI app that leverages the AWS SDK, rather than CloudFormation / Terraform / K8s /\nElastic\nBeanstalk / \u003csome-other-fancy-alternative\u003e.\n\nWhile YOLO has underpinned very large, mission-critical production applications, it is not intended to be a set and\nforget solution; rather it acts as a control plane that allows you to manage and expand your AWS footprint over time.\n\nIt goes without saying, but use YOLO at your own risk.\n\n## Prerequisites\n\nYou'll need access to an AWS account, and some knowledge of AWS services.\n\n### Domains on Route53\n\nThe domains for your app should be added to Route53 on the same AWS account as where the app is hosted in advance.\n\n### Permissions \u0026 Authentication\n\nYOLO uses AWS profiles for authentication.\n\nProfiles are stored in `~/.aws/credentials` for authentication. You'll need to set a\n`YOLO_{ENVIRONMENT}_AWS_PROFILE` in the app `.env` file to point to the correct profile; eg.\n\n```bash\nYOLO_PRODUCTION_AWS_PROFILE=my-project-profile\n```\n\nOnce configured, future operations will authenticate using this profile.\n\nYou will need wide-ranging AWS credentials to provision everything required by YOLO; administrative permissions are\nrecommended.\n\nFor CI environments like GitHub Actions, `AWS_ACCESS_KEY_ID` and `AWS_SECRET_ACCESS_KEY` are used instead. Ensure that\nany access keys provided in CI are using least-privileged scope.\n\n## Step 1: Installation\n\n### a) Install With Composer\n\n```bash\ncomposer require codinglabsau/yolo-alpha\n```\n\nThe entry point to the YOLO Alpha CLI is `vendor/bin/yolo-alpha` or `yolo-alpha` if you have `./vendor/bin` in your path.\n\nRun `yolo-alpha` to see the available commands.\n\n### b) Initialise yolo-alpha\n\nNext, run `yolo-alpha init`. The init command does the following:\n\n1. initialises the yolo-alpha.yml file in the app with a boilerplate production environment\n2. adds some entries to `.gitignore`\n3. prompts for a few bits of information to setup the manifest file\n\nAfter initialising, you can customise the `yolo-alpha.yml` manifest file to suit your app's requirements.\n\n## Step 2: Provision resources\n\nYOLO is designed to create and manage all AWS resources required to run your application.\n\nProvision all resources by running `yolo-alpha sync \u003cenvironment\u003e`. This command runs all `sync` commands in the correct\norder.\n\nThe full list of available sync commands are:\n\n- `yolo-alpha sync:network \u003cenvironment\u003e` prepares the VPC, subnets, security groups and SSH keys\n- `yolo-alpha sync:standalone \u003cenvironment\u003e` prepares standalone app resources (standalone apps only)\n- `yolo-alpha sync:landlord \u003cenvironment\u003e` prepares landlord resources (multitenancy apps only)\n- `yolo-alpha sync:tenant \u003cenvironment\u003e` prepares tenant resources (multitenancy apps only)\n- `yolo-alpha sync:compute \u003cenvironment\u003e` prepares the compute resources\n- `yolo-alpha sync:ci \u003cenvironment\u003e` prepares the continuous integration pipeline\n- `yolo-alpha sync:iam \u003cenvironment\u003e` prepares necessary permissions\n- `yolo-alpha sync:logging \u003cenvironment\u003e` prepares observability infrastructure (e.g. IVS state-change events)\n\n\u003e [!TIP]\n\u003e All sync commands support a `--dry-run` argument; this is a great starting point to see what resources will be created\n\u003e or modified without any actual changes occurring on AWS.\n\n## Step 3: Prepare a server image\n\nWith all the low-level resource provisioned via the `sync` commands, the next step is to create an Amazon Machine\nImage (\nAMI) with Ubuntu OS as the foundation.\n\nThe image will be used as the initial disk image for all server instances, and can be updated\nover time to bring in improvements, such as new PHP versions.\n\n### a) Create an image\n\nRun `yolo-alpha image:create \u003cenvironment\u003e` to generate a new AMI.\n\n### b) Prepare the image for traffic\n\nTo prepare a new stage, run `yolo-alpha stage \u003cenvironment\u003e`.\n\nThis interactive command walks you through updating or replacing the current stage configuration.\n\nNew stages have the benefit of allowing testing before migrating production workloads over, however simply updating the\nexisting stage is recommended for minor changes.\n\n| Situation                   | Recommended strategy |\n|-----------------------------|----------------------|\n| Update EC2 security group   | update               |\n| Update EC2 type             | update               |\n| Update EC2 instance profile | update               |\n| Update AMI                  | create               |\n\nWhen creating a new stage, the yolo-alpha.yml manifest will also be updated to point to the new autoscaling groups on the next\ndeployment.\n\n\u003e [!NOTE]\n\u003e Rotating in a new image does not have any impact on existing traffic until the updated manifest is deployed - the\n\u003e previous deployment will continue serving requests and autoscaling as per normal.\n\n## Step 4. Setup .env file\n\nYou'll need to push the initial .env file for the environment. Environment files are stored in the S3 artefacts bucket,\nand retrieved during deployment.\n\nIf you have an existing .env file, be sure to copy that over to `.env.\u003cenvironment\u003e` in the root of the app, otherwise\nyou can build on the stub provided by the `init` command.\n\nTo push the .env file to the artefacts bucket, run `yolo-alpha env:push \u003cenvironment\u003e`.\n\nAfter the initial push, you can retrieve the .env file with `yolo-alpha env:pull \u003cenvironment\u003e`.\n\n## Step 5. Building and deploying\n\nBuilds can be created with `yolo-alpha build \u003cenvironment\u003e`.\n\nThe build command takes care of building a deployment-ready directory in `./yolo`.\n\nBuilds can be deployed with `yolo-alpha deploy \u003cenvironment\u003e`.\n\n\u003e [!TIP]\n\u003e You can also build and deploy in a single command with `yolo-alpha deploy \u003cenvironment\u003e`.\n\n## yolo-alpha.yml\n\nThis is a complete yolo-alpha.yml manifest file, showing default values where applicable.\n\nNote that some keys below are intentionally omitted from the stub generated by `yolo-alpha init`.\n\n```yaml\nname: codinglabs\ntimezone: UTC\n\nenvironments:\n  production:\n    aws:\n      account-id:\n      region: ap-southeast-2\n      vpc:\n      internet-gateway:\n      public-subnets:\n      route-table:\n      bucket:\n      artefacts-bucket:\n      cloudfront:\n      alb:\n      mediaconvert: false\n      ivs: false\n      autoscaling:\n        web:\n        queue:\n        scheduler:\n        combine: false\n      ec2:\n        instance-type: t3.small\n        queue-instance-type:\n        scheduler-instance-type:\n        octane: false\n        nightwatch: false\n        key-pair:\n        security-group:\n      rds:\n        subnet:\n        security-group:\n      codedeploy:\n        strategy: without-load-balancing|with-load-balancing\n      sqs:\n        depth-alarm-evaluation-periods: 3\n        depth-alarm-period: 300\n        depth-alarm-threshold: 100\n\n    asset-url: # defaults to aws.cloudfront\n    mysqldump: false\n\n    domain: example.com # standalone apps only\n    apex: # standalone apps only\n\n    tenants: # multi-tenanted apps only\n      boating: # unique key for the tenant\n        domain: boating-with-yolo.com\n\n      fishing: # unique key for the tenant\n        domain: fishing-with-yolo.com\n\n    build:\n      - composer install --no-cache --no-interaction --optimize-autoloader --no-progress --classmap-authoritative --no-dev\n      - npm ci\n      - npm run build\n      - rm -rf package-lock.json resources/js resources/css node_modules database/seeders database/factories resources/seeding\n\n    deploy: #runs on scheduler\n      - php artisan migrate --force\n\n    deploy-queue: # runs on queue\n      -\n\n    deploy-web: # runs on web\n      -\n\n    deploy-all: # runs on all instances\n      - php artisan optimize\n```\n\n### Continuous Integration\n\nThe app version can be specified as an option with `--app-version` to the `build` and `deploy` commands.\n\nThe recommended approach is to tag your GitHub releases with a date-based naming convention, and then forward the tag to\nyour deploy action, similar to the following:\n\n```yaml\n- name: Deploy\n    run: php vendor/bin/yolo-alpha deploy production --app-version=${{ github.event.release.tag_name }}\n    env:\n      AWS_ACCESS_KEY_ID: ${{ secrets.PRODUCTION_AWS_ACCESS_KEY_ID }}\n      AWS_SECRET_ACCESS_KEY: ${{ secrets.PRODUCTION_AWS_SECRET_ACCESS_KEY }}\n```\n\nThe current app version must start with `year.week`, for example `25.3` to represent the third week of 2025. After the\nyear and week,\nuse whatever convention you like; a common approach is to increment the third digit for each release, for example\n`25.3.1`,\n`25.3.2`, etc.\n\nBecause the app version is validated during the build and utilises the UTC timezone by default, you may wish to set the\nmanifest `timezone` option to the timezone of your team to prevent validation errors at the start of the week if your\ntimezone is ahead of UTC.\n\n### Domains\n\nApplications hosted with yolo-alpha can be served on any domain or subdomain that you own.\n\nThe domain should be added to Route53 in advance.\n\nFor a standalone application, the domain key can be used:\n\n```yaml\n    domain: codinglabs.com.au\n```\n\nIn this example, the app will be served on `codinglabs.com.au`, and `www.codinglabs.com.au` will redirect to\n`codinglabs.com.au`.\n\nIf the application is served on any subdomain (including www.) you'll need to specify the apex record as well.\n\n```yaml\n    apex: codinglabs.com.au\n    domain: www.codinglabs.com.au\n```\n\nIn this example, the app will be served on `www.codinglabs.com.au`, and `codinglabs.com.au` will redirect to\n`www.codinglabs.com.au`.\n\nMulti-tenant applications follow the same logic, except that domains are configured under the `tenants` key.\n\n```yaml\n    tenants:\n      boating:\n        domain: boating.outdoors-with-yolo.com\n        apex: outdoors-with-yolo.com\n\n      camping:\n        domain: camping.outdoors-with-yolo.com\n        apex: outdoors-with-yolo.com\n\n      fishing:\n        domain: fishing-with-yolo.com\n```\n\n## Development\n\nTo debug or add features to YOLO, it is recommended to symlink to the local repository.\n\nAdd this to composer.json with the path to the local repository:\n\n```\n\"repositories\": [\n    {\n    \"type\": \"path\",\n    \"url\": \"/Users/username/code/yolo-alpha\"\n    }\n],\n```\n\nTo call yolo-alpha from the app you are debugging, you'll need to tell yolo-alpha the path to the app. Set the `YOLO_BASE_PATH`\nenvironment to the root of the app as follows:\n\n```bash\nYOLO_BASE_PATH=$(pwd) yolo-alpha\n```\n\n## Credits\n\n- [Steve Thomas](https://github.com/stevethomas)\n- [All Contributors](https://github.com/codinglabsau/yolo-alpha/contributors)\n\n## License\n\nMIT\n","project_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcodinglabsau%2Fyolo-alpha","html_url":"https://awesome.ecosyste.ms/projects/github.com%2Fcodinglabsau%2Fyolo-alpha","lists_url":"https://awesome.ecosyste.ms/api/v1/projects/github.com%2Fcodinglabsau%2Fyolo-alpha/lists"}