adityarizqi/laradox
Laradox provides a streamlined Docker-based development environment for Laravel, with ready-to-use containers and configuration for PHP, web, database, and common services. It speeds up local setup and keeps development environments consistent across machines.
Architecture fit. laradox has moved from a development-environment bootstrapper to an operate-and-deploy toolchain. v2.1.0 is entirely additive (four new Artisan commands plus a shared InspectsContainers concern), which is the architecturally significant piece: the concern centralises container inspection, resource sampling, health polling and in-container execution, so every new command is a thin orchestration layer over one tested abstraction. That is the right shape and it means the marginal cost of the next five commands is low. The trade-off is that the package is now opinionated about runtime: laradox:optimize knows about Octane worker reloads and bootstrapped config/config cache ordering, and laradox:deploy assumes a compose-file-shaped topology. That is a good fit for self-hosted, single-VM or small-cluster Laravel, and a poor fit for managed runtimes (ECS, Cloud Run, Kubernetes, Vapor).
Integration feasibility. High for existing laradox users — no breaking changes are signalled, and the commands slot into existing composer/artisan habits. For teams not already on laradox, adopting individual commands without adopting the compose workflow is possible but partial; laradox:status and laradox:benchmark stand alone reasonably well, laradox:deploy does not.
Technical risk. Concentrated in laradox:deploy, which performs mutating operations on production: maintenance mode toggling, image build, Composer install, asset build, migrations, cache warm-up. A bug here is measured in downtime, not developer friction. Mitigations present in the release are sound — --dry-run, --force gating for non-interactive runs, per-step skip flags, and automatic removal from maintenance mode on failure with a pointer to diagnostics. laradox:status returning non-zero when anything is not running or unhealthy is the highest-leverage detail in the release: it makes the package CI-gateable without parsing output. Residual risks worth probing: correctness of the environment-conditional --no-dev Composer flag; ordering of cache warm-up versus Octane reload (a classic stale-code window); and laradox:benchmark generating host-side load that could be aimed at a production URL with no built-in guardrail.
Key questions.
laradox:deploy roll back migrations, or only halt and exit maintenance mode?laradox:status treat intentionally-scaled-to-zero or one-shot services as failures, which would break CI gates?--json schema of status and benchmark considered stable, or will we be pinned to exact flags?DOCKER_HOST) support for the inspection concern?Stack fit. Requires a compose-based deployment and, for the optimize path, an Octane runtime (Swoole, RoadRunner or FrankenPHP). Confirm Laravel and PHP version support against our supported matrix before planning; the commands also assume host access to the Docker CLI and socket.
Migration path. Adopt read-only before mutating. Sequence: (1) pin and upgrade in local/dev, (2) wire laradox:status --json into a non-blocking CI job and capture a laradox:benchmark --json baseline, (3) run laradox:optimize then --clear in staging to confirm the autoloader/cache/Octane reload cycle behaves, (4) run laradox:deploy --dry-run and diff the printed plan against our existing deploy runbook, (5) execute laradox:deploy in staging, (6) cut over in production behind a manual approval step in CI.
Compatibility. Treat this as a new CLI surface rather than a hardened API: pin the exact minor version in composer.json, and review each subsequent changelog for flag renames before composer update. No deprecations are introduced in this release.
Sequencing. Keep the manual runbook live as a fallback for at least one production release cycle, and gate the first real deploy on a completed dry-run diff. Defer enabling --stats and --watch in any always-on monitoring until we have measured their polling overhead against our service count.
Maintenance. We inherit the package's release cadence for a component that now owns deploy semantics and health definitions. New surface area (four commands, a shared concern, and a matrix of skip flags) increases upgrade review cost. Pin minor versions and read changelogs; do not float.
Support. On-call needs the status exit-code contract and --json shape documented internally, plus a failure-mode table for deploy. The release's failure behaviour — leave maintenance mode, report where to look — is the right default, but we should verify the surfaced message is actionable to a first responder and never reaches end users.
Scaling. status probes every service in the compose file, including ones with no container; --stats samples CPU, memory and network per container. Cost scales linearly with service count and is fine at our size but should be measured before polling on a short interval. deploy is single-host oriented; multi-node or rolling deploys are not addressed and would need to be built around it. benchmark measures from the host, so results are sensitive to host resources and network position — useful for release-to-release comparison, not a substitute for external load testing.
Failure modes. Docker daemon or socket unavailable fails all four commands; a mid-sequence deploy failure (e.g. migration after successful build) leaves a built-but-unmigrated state that needs a documented recovery; Octane reload can race in-flight requests; benchmark pointed at a production endpoint is an unguarded footgun; a health gate that mis-classifies scaled-to-zero services will block deploys and CI. Each of these needs an explicit "what we do next" line in the runbook.
Ramp-up. Low for developers already using laradox — a few hours to read --help and try dry-runs. Moderate for operations: roughly a day to read the deploy command's step order and side effects before trusting it in production, plus the time to rewrite the runbook and wire the CI gate.
How can I help you explore Laravel packages today?