Getting Started

Install the package at ^1.4 and run the existing test suite plus one staging deploy before production. v1.4.0 does not show an obvious breaking API or migration change.
Look first at the README, the package docs, the publishable config (commonly config/yolo.php if present), and the package Artisan commands via php artisan list.
Inspect the generated Dockerfile and PHP baseline before relying on them. v1.4.0 changes build behavior around base-image resolution and php.ini, so verify what the package actually emits in your app.
First practical use case: add YOLO to a small Laravel app, run a staging build/deploy through the package, then confirm build logs, generated Dockerfile, PHP config, storage permissions, environment handling, and console access.

Implementation Patterns

Treat YOLO as build/deploy orchestration around your Laravel app: keep application config in the repo, review generated Dockerfile/php.ini changes like code, and avoid hand-editing generated build artifacts.
In CI, run Composer install, frontend asset build, then the YOLO build/deploy step. Cache Composer and npm aggressively, but be deliberate about Docker layer caching because v1.4.0 re-resolves the Dockerfile base image on every build.
Put PHP overrides in the package/app config or an app-level ini layer rather than patching the package baseline. This is especially relevant if you need session.upload_progress behavior back after v1.4.0 disabled it in the baseline.
Use the staged copy behavior intentionally: v1.4.0 seeds an empty .git so gitignore-aware tooling works during builds. Pass version metadata through build args or environment variables rather than expecting real Git history.
Treat the IAM change as a console/UI preference grant: every tier role can read the account colour setting, but authorization decisions should remain in Laravel policies/gates, not in that preference permission.
For custom roles/tiers, verify console access after upgrade and keep sensitive capabilities out of broad tier roles even if the package grants cosmetic console reads broadly.

The base-image re-resolution fix means builds can pick up a newer base image without a package version change. If a deploy becomes non-reproducible, pin the base image by digest in your own build configuration or use a controlled build cache.
The staged copy has an empty .git, so gitignore-aware tools should behave better, but commands that need history or remotes (git describe, git log, submodules depending on context) will fail. Use CI-provided version values instead.
session.upload_progress is disabled in the v1.4.0 PHP baseline. If your app or upload UI depends on PHP upload progress sessions, explicitly re-enable/configure it and test large uploads.
The IAM account-colour grant is additive and cosmetic, but it is still a permission change. Audit custom roles and console policies after upgrading, especially if you have non-standard tier definitions.
Build failures after v1.4.0 are most likely to come from Docker base-image drift, cached layers, or gitignore-aware tooling now seeing an empty .git. Debug by inspecting the generated Dockerfile, staged build context, base image digest, and full build logs.
Prefer package config overrides, app-level ini settings, and Laravel policies as extension points. Avoid forking the package for small runtime or permission customizations unless the package exposes no suitable hook.