Laravel Deployer Laravel Package

Product Decisions This Supports

• Multi-host / horizontally-scaled deployments. The v0.3.5 change makes migrations run once across all target hosts by default, which removes the most common footgun in multi-node deploy pipelines: N hosts each racing to run the same migration. This directly supports a roadmap decision to scale app tier horizontally without redesigning the release process.
• Build vs. buy on deploy tooling. If our pipeline currently relies on hand-rolled ssh loops or CI scripts to decide which host runs php artisan migrate, this package absorbs that logic. That is a credible reason to retire bespoke deploy scripts rather than maintain them.
• Release-safety and rollback policy. Because the default is now "migrate once," the PM can commit to a simpler release checklist for multi-host environments (one migration runner, no per-host coordination step) — but must also sponsor an explicit decision on the opt-out path for teams that genuinely need per-host execution (sharded or per-tenant databases).
• Upgrade sequencing across products. Any product still on a pre-0.3.5 version will silently change migration behavior on upgrade. That is a cross-team coordination item, not a per-team one — it belongs in the platform/release-train backlog.
• Not a decision driver for: feature velocity, user-facing capability, or data model changes. This release is infrastructure hygiene; treat it as risk reduction, not a value-add to sell.

When to Consider This Package

Consider it when:

• We deploy the same Laravel codebase to more than one application host behind a load balancer, and migrations are part of the deploy.
• We are currently solving "which host migrates?" with ad-hoc scripting, deploy-time flags, or documentation, and that logic is a recurring source of incidents or review friction.
• The team is comfortable operating a 0.x dependency — v0.3.5 signals an actively maintained but pre-1.0 project, so minor bumps may still carry behavior changes (this release is one).
• The surface area we'd depend on is narrow (a deploy-time command/flag), so a later swap-out is cheap.

Look elsewhere when:

• We run a single app host, or migrations are already gated by a dedicated release job / one-off task runner — the default change is a no-op and adds a dependency for nothing.
• We rely on per-host or per-shard migration execution (multi-tenant, sharded, or per-region databases). The new default inverts that behavior; adopting means immediately pinning to the opt-out path and re-testing every environment.
• We require semantic-versioning stability, long support windows, or vendor SLAs. Nothing in a 0.x release supports that commitment.
• The package would become load-bearing for compliance-relevant release controls (audit trail, approval gates) that it does not itself provide.

How to Pitch It (Stakeholders)

For executives (30 seconds): A small change in a Laravel deployment package we're evaluating makes database migrations run once per release instead of once per server — by default. That removes a whole class of deploy failures that show up exactly when we scale to more servers, and it lets us delete some custom deploy glue. It's a pre-1.0 dependency, so the recommendation is to pilot it on one multi-host service, not standardize on it yet. No user-facing impact; cost is a few days of a platform engineer's time plus a migration-behavior review.

For engineering (the substance):

• What changed: migrate now de-duplicates across hosts by default (once() behavior), rather than requiring per-invocation opt-in. Anyone upgrading gets the new behavior silently.
• Why it matters: it eliminates concurrent-migration races on multi-host deploys, which is the failure mode that produces half-applied schemas and out-of-band manual fixes.
• What we must verify before rollout: (1) the explicit opt-out and what it's called; (2) whether "once" is keyed per-release, per-batch, or per-command-invocation; (3) behavior when the target host set changes mid-deploy; (4) behavior under zero-downtime / rolling deploy strategies where old and new code coexist.
• What we ask for: one sprint of a platform engineer to pilot on a single multi-host service, a documented opt-out for any sharded/tenant database, and a version pin (exact 0.3.5) so an unreviewed minor bump can't change deploy semantics underneath us.
• Ask of product: confirm no team is depending on per-host migration execution today. If any are, they need to be identified before this becomes a default in our templates.