- What is philo/artisan-remote and how does it work?
- philo/artisan-remote is a Laravel package that exposes your Artisan commands through an HTTP API so a Laravel app can trigger them, including on hosts you configure as remote targets. The package blurb describes it as a secure SSH-based bridge for executing Artisan commands on any configured host, with support for multiple server environments. Architecturally it inverts Laravel's normal model, where Artisan runs in-process via the CLI, the scheduler, or queue workers, so treat it as an exception path rather than a platform component.
- How do I install philo/artisan-remote in a Laravel application?
- Installation is a Composer require plus service provider auto-discovery and a published config file that holds your host definitions. The effort to install is low, but the effort to make it safe is high, so plan for auth middleware, network restriction, and a command allowlist before you enable it anywhere shared. Because the last release was January 2021, expect dependency resolution errors on modern Laravel and PHP versions and budget a compatibility spike first.
- Does philo/artisan-remote work with Laravel 10, 11 or 12 and PHP 8.2+?
- The last release was January 2021, which predates Laravel 9, 10, 11 and 12 as well as PHP 8.2+, and the package has zero dependents and low visibility. Assume incompatibility until you prove otherwise, since it is unlikely to have been tested against current Illuminate Console and Symfony Process internals. The realistic fit is a Laravel 6 to 8 era application on PHP 7.4 or 8.0.
- Is it safe to expose Artisan commands over an HTTP endpoint in production?
- An HTTP-reachable Artisan endpoint is a remote code execution surface, because anyone who can reach the route can potentially invoke privileged commands. It also bypasses the deployment, CI, and SSH or bastion controls that normally gate those operations. If you use it at all, put it behind a VPN or localhost-only binding, wrap it in your own authentication and IP-allowlist middleware, and add structured audit logging rather than relying on the package's own hygiene.
- Can I restrict which Artisan commands the API is allowed to run?
- You must verify in the package source whether an allowlist ships at all, or whether arbitrary command names and arguments are passed straight through. Argument injection via flags such as --env or --force, or shell metacharacters in arguments, is the dominant exploit vector for this kind of endpoint. The recommended approach is to allowlist only three to five benign commands such as cache:clear, config:cache, and queue:restart, and to own changes to that list.
- Can I manage multiple servers or environments with one installation?
- The package advertises support for managing multiple server environments through configured hosts, which is useful for internal ops dashboards spanning staging and production. Before adopting it, confirm how credentials or SSH keys for each host are stored, and whether per-host authorization is enforced or whether one route can target any configured host. Also confirm the execution mode, since synchronous, buffered Artisan calls are fine for cache:clear but dangerous for migrate or queue:work.
- How should I test the Artisan Remote endpoint in my Laravel test suite?
- Use Laravel's HTTP test helpers to assert that the route rejects unauthenticated and non-allowlisted requests, and that non-permitted commands never reach the executor. Bind a fake or stub in the container so Artisan::call is not actually executed against a real host during tests. Cover argument injection cases explicitly, including flags like --force and unusual characters in command arguments.
- Is philo/artisan-remote still actively maintained?
- It has a single maintainer, roughly 82 stars, zero dependents, and no release since January 2021, so there is very little community pressure to patch issues. That combination makes it an unmaintained dependency from the day you add it, and a low bus factor if the maintainer steps away. If the need is real, plan to fork and own the code rather than wait for upstream fixes.
- What are the alternatives to using Artisan Remote?
- The simplest alternative is a small internal controller of 30 to 50 lines calling Artisan::call() behind your existing middleware, which achieves the same outcome with no third-party dependency. For scheduled or long-running work, use the Laravel scheduler, queue workers, or CI/CD deploy hooks instead of HTTP invocation. For remote execution, SSH with a bastion host or a tool like Laravel Envoy is generally a better-controlled path.
- What should I do if I decide I really need remote Artisan execution?
- Start with a throwaway spike: run it locally or behind a VPN, add authentication and IP middleware, allowlist a few benign commands, and evaluate the real operational need for two weeks. If the need holds, vendor the package under an internal namespace, pin Laravel and PHP constraints, and add command allowlisting, audit logging, output size caps, timeouts, and a kill switch. Expect roughly three to five engineer-days to convert an unmaintained dependency into owned code, and avoid it entirely for multi-tenant SaaS or PCI and HIPAA-scoped workloads.