- Is rebelinblue/deployer a Composer package or a self-hosted Laravel application?
- Despite being catalogued on Packagist, it is a self-hosted Laravel web application rather than a library you require into an existing project. You run it as its own service with a database, queue worker, and web server, and it deploys your other applications over SSH. Nothing in a typical Laravel app would depend on it via Composer, which is why it shows zero dependents.
- How do I install rebelinblue/deployer?
- You install it like a Laravel application: clone the repository, run Composer install against the pinned lockfile, configure an env file with database, queue, and APP_KEY values, then run migrations and build the frontend assets once. A pinned container stack of PHP 7.1 or 7.2, MySQL 5.7, Redis for queues, and Node 8 for the asset build is the practical approach. Front it with an authenticating reverse proxy such as oauth2-proxy rather than exposing it directly.
- Which Laravel and PHP versions does rebelinblue/deployer support?
- It targets the Laravel and Symfony versions current around its final release in June 2018, which means PHP 7.1-era code. It will not run cleanly on PHP 8.x without a fork and upgrade. Both the framework versions and the PHP runtime are end-of-life, so no security patches are available from upstream.
- Does rebelinblue/deployer support zero-downtime deployments and rollbacks?
- Yes, the core model is SSH-and-symlink releases: each deploy writes a new release directory, links the env file and storage directory, runs migrations and queue or config restarts, then flips the symlink. Rollback simply points the symlink back at a previous release and re-runs the relevant steps. That release state machine is the most reusable part of the project and is worth copying even if you never run the app itself.
- Is rebelinblue/deployer still maintained?
- No. The last release was 2018-06-06 and the upstream repository is archived, so there are no security patches, CVE responses, or maintainer support. The MIT license is permissive and removes legal friction for forking, but a fork is effectively mandatory if you want to run it on supported versions. Budget ongoing engineering time for that maintenance.
- How does rebelinblue/deployer store SSH private keys, and is that safe for production?
- It stores the SSH private keys used to reach your target servers, encrypted with the application's APP_KEY. That makes key custody, rotation, and blast radius the central threat model: anyone with the APP_KEY and a database dump has credentials for your fleet. For SOC 2 or similar compliance programs, a 2018-era credential store is unlikely to satisfy requirements without compensating controls such as strict network isolation and restricted egress.
- Can I use rebelinblue/deployer alongside GitHub Actions or GitLab CI?
- You can, but it becomes a parallel, unaudited deployment path, which is exactly the risk the technical assessment flags. If your platform strategy is pipeline-as-code or immutable container deploys, this SSH-and-symlink tool duplicates and can bypass that. The safer pattern is to run it only as an isolated internal service, or to mine its release model and reimplement it inside your existing pipeline.
- What are the best alternatives to rebelinblue/deployer for Laravel deployments?
- Hosted options such as Laravel Forge and Envoyer-style services cover per-environment deploys and rollbacks without you owning a 2018-era credential store. For pipeline-as-code, GitHub Actions or GitLab CI with a symlink-release script covers most teams and keeps deploys auditable. If you only want the recipes rather than a UI, the Deployer PHP task runner is the natural successor.
- Can I fork rebelinblue/deployer and upgrade it to Laravel 10 or 11?
- Yes, and fork-and-modernize is a viable but costly option. Expect non-trivial work across auth scaffolding, the queue API, and the Blade and Vue frontend, plus a security-patch cadence afterward. Budget a multi-week upgrade push plus roughly 20 to 30 percent of one engineer ongoing. The cheaper default is to extract the deployment state machine and symlink strategy and reimplement only the slice you actually need.
- How should I test rebelinblue/deployer before using it in production?
- Stand it up as a pinned container appliance behind an SSO proxy and point it only at disposable staging hosts with throwaway SSH keys. Exercise a full deploy, a rollback, a deliberately failing migration, and a queue restart so you can see how the release state machine behaves under failure. Keep production credentials out of it until key custody, egress restrictions, and the fork ownership question are settled.