Sail Laravel Package

Product Decisions This Supports

• Time-to-first-commit (onboarding investment). Sail answers "how long until a new engineer, contractor, or vendor runs their first request?" with a single ./vendor/bin/sail up. That is a measurable onboarding KPI, not just a dev-convenience nicety — it lets you decide whether to fund a platform/DevEx initiative or accept the current friction.
• Build vs. buy vs. adopt for local dev environments. The realistic alternatives are: (a) hand-rolled compose.yaml + Dockerfiles, (b) a paid cloud dev environment provider, (c) Sail. Sail is MIT, first-party Laravel, and effectively zero-cost to adopt, so the comparison is mostly opportunity cost of an engineer owning bespoke container config versus owning product surface.
• Environment parity as a defect-reduction lever. Sail standardizes PHP version, extensions, database engine, cache, and search services across macOS, Windows/WSL2, and Linux. This directly targets the "works on my machine" class of bugs and off-hours support load — both of which you can baseline before adoption and track afterward.
• Roadmap gating for feature bets. Sail's service stubs reveal which backing services are cheap to explore locally: MySQL 8.4, PostgreSQL 18, Redis/Valkey, Meilisearch, Typesense, MongoDB, MinIO/RustFS (S3), RabbitMQ. If a proposed feature needs one of these, prototyping cost drops to a config flag — useful input to sequencing decisions like "ship search before or after we have an index strategy."
• CI and local environment convergence. Because Sail is Docker-based, the same container definitions can inform CI service containers. This supports a decision to unify local and pipeline dependencies rather than maintain two dependency matrices.
• Tooling standard in the hiring and contracting playbook. Standardizing on Sail means you can put "run sail up" in the README and stop writing per-machine setup docs. It is also a signal in technical due diligence that the stack is idiomatic Laravel rather than a custom snowflake.
• Ecosystem and version risk posture. The changelog shows sustained first-party maintenance: PHP 8.5 support, PostgreSQL 18, MySQL 8.4, Node 24 LTS, Podman support, Pest 4 browser tests, devcontainer stub, and AI-agent env passthrough. This supports a decision to treat local dev tooling as maintained upstream rather than internally owned — a real reduction in total cost of ownership.
• Note on the "0 dependents" signal. Do not read this as low adoption. Sail is a require-dev scaffold — nothing declares it as a library dependency, so dependent counts are structurally near-zero. Use Packagist download volume, the README badge, or composer require laravel/sail telemetry as the adoption proxy instead. Flagging this matters because a naive scorecard will misrank the package.

When to Consider This Package

Adopt when most of the following hold:

• The application is a standard Laravel app (or a small monorepo of Laravel services) on a supported PHP version.
• The team is small-to-medium without dedicated platform engineers, and you'd rather spend that headcount on product.
• You need multiple backing services (DB, cache, queue, search, object storage) and want them locally without per-engineer setup.
• The team is heterogeneous across macOS, Windows/WSL2, and Linux — this is Sail's strongest case.
• You are onboarding frequently (contractors, new hires, agencies) and setup cost is a recurring tax.
• You want idiomatic, upgradeable defaults rather than a bespoke container config that only one engineer understands.
• You are willing to treat local dev tooling as pinned and versioned (Sail version in composer.json, image tags reviewed on upgrade).

Look elsewhere, or plan to layer on top, when:

• Production deployment. Sail is explicitly a local development tool. It is not a production runtime, not a hardened image, and not a substitute for your deploy pipeline. Reject any proposal to ship Sail containers to production.
• Non-Laravel or polyglot monorepos. Sail assumes a PHP-centric app at the repo root. A repo with Go services, a separate SPA build, and a Python worker will fight the defaults.
• Heavy infrastructure customization. Custom PHP builds, proprietary extensions, GPU workloads, or unusual networking will cost more to bend Sail than to write your own compose file.
• Enterprise compliance and hardening requirements. If you need audited base images, FIPS/crypto modules, SBOMs, or a locked-down developer image policy, you need a governed image pipeline, not community default stubs.
• Performance-critical local ergonomics. Bind-mount filesystem performance on macOS/Windows is the long-standing weak point; teams with very large codebases or heavy test suites may need Mutagen-style sync or a different approach.
• You already have a working, owned container setup. Migration cost is real and the benefit is mostly standardization, not capability. Only migrate if the existing setup is a recurring support burden.
• You need a zero-Docker developer experience. If Docker Desktop licensing, corporate policy, or laptop capability rules out containers, Sail is out. (Podman support exists via SAIL_DOCKER_BINARY but treat it as a secondary path.)

How to Pitch It (Stakeholders)

For executives (one paragraph): Laravel Sail is a free, MIT-licensed, first-party Laravel package that gives every engineer an identical, Docker-based development environment with one command. The business case is onboarding velocity and defect reduction: new hires and contractors reach a running application in minutes instead of days, and environment-specific bugs stop consuming engineering time. It costs nothing to license, is maintained upstream by the Laravel team with an active release cadence, and carries no vendor lock-in — it's a require-dev scaffold that can be removed without touching application code. Recommended ask: adopt it as the standard local dev environment for our Laravel services, track time-to-first-run and environment-related bug tickets as the success metrics, and explicitly scope it to development only — it is not a production deployment tool.

For engineering leadership: This removes a category of toil we currently absorb informally. It standardizes PHP version, extensions, DB, cache, queue, and search across macOS, Windows/WSL2, and Linux, and it gives us a shared vocabulary for backing services. It's first-party, so upgrades track the framework rather than our own maintenance. Cost: one engineer-day to standardize the compose file, document the workflow, and wire it into CI service containers. Risks are bounded and known — image tag drift on upgrades, macOS/Windows volume performance, and the temptation to reuse these containers in production, which we should explicitly forbid in the ADR.

For engineering (the practical sell): composer require laravel/sail --dev && php artisan sail:install, pick your services, sail up. Nothing but Docker needed on the host. sail wraps composer, artisan, node, and the test runners so nobody memorizes container flags. Includes Xdebug, Swoole, devcontainer stub, Playwright/Pest browser test support, and Podman compatibility if Docker Desktop is disallowed. Known sharp edges: filesystem performance on macOS/Windows bind mounts, and you should pin Sail's version and review image tag bumps in upgrades rather than floating them.