Laravel Actions Laravel Package

Product Decisions This Supports

• Build vs. buy for deployment glue: Decides whether to hand-roll a deploy.sh plus a chain of artisan calls in CI, or adopt a small MIT-licensed package that expresses deploy steps declaratively (config-driven operations run via a single artisan command). The build side is cheap to start and expensive to keep consistent across environments; this package is the "buy" (well, free) option for the boring middle.
• Roadmap scoping for release reliability: If post-deploy steps (config/route/view caching, migrations, queue restarts, storage linking, cache warmup) are currently tribal knowledge in a wiki or baked into a Forge/Envoyer script, this is a candidate work item for "make deploys reproducible" — a small, low-risk slice of a larger platform-engineering epic.
• Synchronous vs. asynchronous post-deploy work (new in 7.3.0): Queued operation jobs now have a configurable uniqueness lock duration and an overridable job class (queue.job). That turns a real product question into a config decision: which deploy steps must block the release (migrations, cache clears) and which can be handed to a worker (search reindex, image regeneration, warmup crawls) without holding the deploy open. The lock duration also bounds duplicate execution when two deploys or a retry overlap.
• Extensibility / lock-in check: The queue.job override means a team can subclass the dispatched job to add retries, timeouts, onQueue, or middleware without forking the package. For an org wary of adopting a low-adoption dependency, that's the escape hatch that makes the risk tolerable — worth citing explicitly in the decision record.
• Standardizing across projects: For a team or agency shipping multiple Laravel apps, a shared operations list becomes a reusable convention: same command, same ordering, same output, every repo. That's a product decision about internal platform consistency, not just code.
• Incident prevention: Most "works locally, broken in prod" incidents in Laravel come from a skipped cache clear or an unrun migration. Framing deploy steps as an explicit, reviewable list is a decision to trade a little abstraction for fewer 2 a.m. pages.
• Due diligence flags: The package name in the ticket (laravel-actions) still does not match the repository (laravel-deploy-operations) — confirm which artifact is being evaluated. Separately, 7.3.0's queue features are only useful if you actually run a queue worker in the deploy window; if you don't, they're inert config surface.

When to Consider This Package

Adopt when:

• You deploy Laravel to a single host or small fleet (Forge, Ploi, a VPS, or a simple container) and your post-deploy steps fit in a linear, idempotent list.
• You want the deploy sequence versioned in the repo and reviewable in PRs, rather than living in a dashboard's deploy script field.
• Your team is small and Laravel-native; a config array plus an artisan command is legible to everyone without new tooling.
• You need per-environment variation in deploy steps (e.g., seed only on staging) and want that expressed in config, not shell conditionals.
• Some steps are slow and safe to defer. With 7.3.0 you can queue operations, set a uniqueness lock window appropriate to your deploy cadence, and override the job class for queue/connection/timeout specifics — without leaving the config file.
• Your pipeline depends on --isolated semantics matching Laravel core; 7.3.0 aligns the package's presence handling with the framework, so behavior shouldn't diverge between your own commands and these operations.
• You accept the maintenance profile: low adoption (zero dependents reported) and a single-maintainer project. Recent releases are authored by a second contributor, which is a mild positive signal on bus factor, but verify the changelog and commit cadence rather than trusting stars.

Look elsewhere when:

• You already run Envoyer, Deployer, GitHub Actions with composed steps, or Kubernetes Jobs — you'd be adding a second, competing source of truth for deploy ordering. Pick one owner for the pipeline. Note that the queued mode is still step execution, not orchestration — it does not make this a replacement for those tools.
• You need zero-downtime orchestration, rollbacks, health checks, or canary/blue-green — that belongs to Envoyer, Deployer, or your container platform.
• You need parallelism, retry policies, timeouts, or conditional rollback out of the box. The queue.job override lets you build retries/timeouts, but that logic becomes your code to own and test; the uniqueness lock is a duplicate-run guard, not a distributed lock manager.
• Your org requires a commercial support contract or a maintainer with a bus factor above one.
• You're on a Laravel version outside the package's tested matrix — check composer.json constraints explicitly, and re-check after a 7.3.x bump.

How to Pitch It (Stakeholders)

For executives (one paragraph): Deployment failures in Laravel apps are disproportionately caused by forgotten post-deploy steps — cached config that no longer matches the environment, migrations that never ran, stale route caches. Today that knowledge lives in someone's head or in a dashboard script nobody reviews. This package moves those steps into the codebase as a plain, versioned list, so deploys are repeatable and auditable and onboarding doesn't depend on tribal knowledge. The latest release extends that to slow steps: expensive work like search reindexing or cache warmup can run as a tracked job instead of stretching the deploy window, with a guard against running twice. It's MIT-licensed, adoptable in an afternoon, and the maintenance signal is fine — recent releases add capability and fix framework-parity issues rather than just bumping versions.

For engineering (one paragraph): dragon-code/laravel-deploy-operations gives you a config-driven operation list executed by a single artisan command with console output, so your cache/migrate/seed/queue-restart sequence is code-reviewed and identical across environments. 7.3.0 adds a configurable uniqueness lock duration for queued operation jobs, a queue.job override so you can supply your own job class (queues, connections, timeout, middleware) without forking, and corrects --isolated presence semantics to match Laravel core. It remains deliberately thin — no process supervision, no rollback, no orchestration — and complements rather than replaces Forge/Envoyer/GitHub Actions; queued operations assume a live worker and don't give you retry/rollback policy for free. Caveats: low adoption, single-maintainer project, and a repo name that doesn't match the ticket. Recommend a timeboxed spike: port one non-critical app's deploy steps, exercise both the synchronous and queued paths in staging for two release cycles, and only then standardize.