Sail Ssl Laravel Package

Product Decisions This Supports

• Local/production parity for anything that touches HTTPS. Adopting this moves local Sail environments from http://localhost to trusted https://*.localhost, which is what unblocks testing of secure-only cookies, SameSite/Secure flags, service workers, WebAuthn/passkeys, OAuth callback URLs that providers require to be HTTPS, mixed-content behavior, and HSTS assumptions. That directly reduces the class of "works locally, breaks in staging" bugs that cost sprint time late in a release.
• Third-party integration readiness. Any roadmap item involving an external identity provider, payment SDK, push notifications, or a PWA has an HTTPS precondition locally. This is a cheap enabler for those epics rather than a feature in itself.
• Build vs buy: buy (adopt). The alternative is an engineer hand-rolling mkcert + openssl + docker-compose overrides — a recurring, undocumented tax that breaks whenever Sail bumps its compose template. This release specifically addresses that churn (Sail v1.46.0 compatibility, YAML-aware compose editing).
• Roadmap weighting: low. This is developer-experience infrastructure, not customer-facing. Treat it as a team-standard tooling decision owned by engineering, not a roadmap line item. It should not consume product review cycles beyond initial adoption.
• Not a production dependency. Nothing here ships to production; it is a local dev convenience with no runtime footprint. That keeps the risk/benefit calculation simple and reversible.

When to Consider This Package

Adopt when all of the following hold:

• The team standardizes on Laravel Sail + Docker Compose for local development. The package's core function is rewriting compose.yaml and generating certs for the Sail container — it is tightly coupled to that workflow.
• There is a concrete near-term need for HTTPS locally — an OAuth/SSO integration, secure-cookie behavior, PWA/service-worker work, or WebAuthn. Without a driver, plain HTTP is fine and this is unnecessary complexity.
• The team can accept trusting a locally generated CA on developer machines. The v1.5.0 two-tier CA model produces browser-trustable certificates, which is the right UX but is a machine-level trust decision that may conflict with corporate device policy or require a documented opt-in/out step for contractors and new hires.
• Someone owns keeping it current. This release exists largely because Sail changed its compose template; the package needs a version bump whenever Sail moves. Pin the version and assign an owner for quarterly checks.

Look elsewhere when:

• The team is not on Sail — Herd, Valet, DDEV, and Lando each ship their own TLS story, and stacking this on top adds conflict surface for no gain.
• You need HTTPS in CI or shared/staging environments. This is a localhost-scoped tool; use real certificates or a managed proxy instead.
• Your developers are on Windows or locked-down managed laptops where installing a root CA is a support ticket. Budget for that friction or pick a solution your IT team already blesses.
• You want a guaranteed-maintained, vendor-backed component. This is a single-maintainer project with recent contributions from an automated agent; the code is small and auditable, but pinning and having a fallback (mkcert + hand-written compose override) documented in the runbook is prudent.

Release-specific notes for v1.5.0:

• Adds a new Composer dependency (symfony/yaml) and replaces regex/stub rewriting with structured YAML manipulation. Behavior should be more reliable, but it may reformat or reorder a hand-edited compose.yaml — verify on a branch before rolling out team-wide, and review any comments in existing compose files.
• Sail v1.46.0 compatibility is explicitly targeted; confirm the team's Sail version before assuming older or newer versions behave identically.
• The empty-SSL_ALT_NAME fix removes a setup failure that would otherwise surface as a confusing onboarding blocker — a meaningful DX win for new-environment bootstrapping.
• No breaking changes or deprecations announced, so upgrading from v1.4.0 is low risk.

How to Pitch It (Stakeholders)

For executives (one paragraph): This is a small, free, open-source developer-tooling package that gives every engineer a trusted https:// address on their local Laravel environment in one step. It doesn't ship to production and costs nothing, but it removes a recurring source of late-stage defects — login flows, cookies, and browser APIs that behave differently over HTTP than HTTPS — and eliminates the ad-hoc certificate scripts engineers currently maintain by hand. Recommendation: approve it as a team standard, pinned to a version, with a named owner, and revisit only if we move off Sail or need HTTPS in CI.

For engineering leads: Approve a time-boxed trial on one service. v1.5.0 is a maintenance-and-reliability release — structured YAML handling instead of regex, fixed cert generation when no SAN is supplied, and a two-tier CA so browsers stop showing warnings. The practical wins are faster onboarding (no more "why is my cert broken" threads) and a trustworthy local environment for OAuth, secure cookies, and service workers. Two things to plan for: developers will need to trust a local CA on their machines, which may need an IT exception for managed laptops, and the new symfony/yaml dependency means existing compose.yaml files should be diffed on a branch before a team-wide rollout. Risk is low and fully reversible: it's a dev-only dependency, we pin it, and we document the manual fallback.