Weave Code
Laravel Task Runner Laravel Package
protonemedia/laravel-task-runner
Laravel Task Runner lets you define reusable tasks as classes and run them from Artisan, code, or a schedule. It offers clean task registration, output handling, and cron-like scheduling for maintenance routines and background work.
Write Shell scripts like Blade Components and run them locally or on a remote server
Frequently asked questions about Laravel Task Runner
- How do I install protonemedia/laravel-task-runner in a Laravel app?
- Install it with Composer using composer require protonemedia/laravel-task-runner, then publish the package configuration file with the vendor:publish command so you can declare servers and defaults. No database migrations, daemons, or extra services are involved, so it slots into an existing app and CI pipeline without new infrastructure. Check the package's composer.json constraints to confirm the supported PHP and Laravel versions for the release you install.
- How do I create and register a task with Laravel Task Runner?
- You define a task as a PHP class whose body is a Blade template containing your shell script, so shell logic lives in the same repo, code review flow, and language as the rest of the application. Tasks are registered so they can be resolved through the container and invoked from Artisan, application code via the facade, or a schedule. Because each task is a class, it participates in dependency injection and can be swapped or faked in tests.
- Can Laravel Task Runner execute a task on a remote server over SSH?
- Yes. The runner abstraction targets either localhost or a remote host you declare in the package config, including host, port, user, and key material. That covers the common case of provisioning or deploy scripts that must run on a specific box without standing up Ansible or a full config-management toolchain. Note that SSH credentials become another secret to store, scope, and rotate, and a compromised app server gains the reach of those keys.
- How do I schedule a task to run automatically?
- Tasks can be invoked from a scheduled command, so you register them in your Console Kernel or routes/console.php schedule like any other Laravel scheduled job and let the scheduler trigger them. This is the right place for maintenance routines and background housekeeping rather than firing remote shell work from a web request. Keep in mind the schedule only fires if your scheduler cron entry is running and that long scripts should use withoutOverlapping and appropriate timeouts.
- Is it safe to run a task from a controller or a queued job?
- Running shell work inside an HTTP request is a known failure pattern: PHP max_execution_time, memory consumed by buffered output, and no retry semantics all apply. Prefer dispatching a queued job or a scheduled command so the work has retries, backoff, timeouts, and locking, and confirm what the package gives you for each of those before treating it as a production execution layer. Also verify behavior on Windows or non-POSIX local development machines, where localhost execution can differ from your servers.
- How does Laravel Task Runner handle command output?
- Output handling is a first-class part of the runner: the task result exposes what the script wrote so you can return it from an Artisan command, log it, or assert on it in tests. Be deliberate about volume, since capturing a very chatty script into PHP memory inside a request or job is expensive. For long-running work, confirm whether your version streams output or buffers it fully before you commit to the pattern.
- Is it safe to interpolate variables into a task's shell script?
- Blade's {{ }} escaping model is HTML-oriented, not shell-oriented, so interpolation of user- or environment-supplied values into a command string is a potential quoting bug or injection vector. Adopt an explicit convention: restrict dynamic values to validated scalars, wrap them in a quote-and-escape helper, or pass them as arguments rather than splicing them into the script body. Treat any task that receives external input as security-sensitive during code review.
- How do I test Laravel Task Runner tasks?
- Because tasks are classes resolved from the container, you can instantiate them directly and assert on the rendered script body without touching a real shell, which is the main advantage over a .sh file or an Envoy story. For end-to-end coverage, run tasks against localhost in CI and assert on exit codes and output. Avoid asserting against remote hosts in tests, and never let test suites require production SSH keys.
- What are the alternatives to Laravel Task Runner?
- The closest alternatives are Laravel Envoy for Blade-style task definitions, raw Symfony Process or Artisan calls for one-off commands, and dedicated ops tools such as Ansible, Puppet, or Salt for real configuration management. Task Runner's differentiation is that each script becomes an injectable, testable, reviewable class in the application repo while still supporting remote SSH execution. If your platform team already owns infrastructure-as-code, adding this package may duplicate that responsibility rather than complement it.
- Is protonemedia/laravel-task-runner actively maintained and safe to depend on?
- The maintainer, Protone Media, has a strong track record across many Laravel packages, and the 1.x line is behaving as a stable, additive-only series where releases like 1.7.0 are pure CI and test-matrix maintenance with no API changes. That signals good hygiene but not breadth of adoption: roughly 131 stars and no dependents means you should treat it as a credible solo-maintainer package rather than a platform dependency. Vendor the risk accordingly, keep your tasks small and well covered by tests, and have a fallback to Process or Envoy in mind.
Weaver
How can I help you explore Laravel packages today?