- What is Laradox and what does it include?
- Laradox (adityarizqi/laradox) is a Composer package that gives Laravel a plug-and-play Docker environment built around FrankenPHP, Nginx and Laravel Octane. It ships ready-to-use containers and configuration for PHP, the web server, the database and other common services, so a consistent local stack comes up quickly on any machine. Since v2.1.0 it has grown from a development bootstrap into an operate-and-deploy toolchain by adding Artisan commands for status, benchmark, optimize and deploy.
- How do I install adityarizqi/laradox with Composer?
- Install it with composer require adityarizqi/laradox, adding the --dev flag if you only need the local development containers. Then run the package's documented install or publish step to generate the compose file and container configuration, and start the stack with docker compose. Because v2.1.0 introduces a new CLI surface, pin the exact minor version in composer.json rather than floating on a caret constraint.
- Which Laravel and PHP versions does Laradox support?
- The supported Laravel and PHP versions depend on the Octane and FrankenPHP images the package pins, so check the composer.json constraints and the README's requirements section against your own support matrix before planning. The optimize and deploy commands also assume a host that has access to the Docker CLI and the Docker socket. Confirm both of those assumptions on your build and production hosts before you wire anything into a pipeline.
- Is Laradox only for local development, or can I use it in production?
- Originally it was a local development environment, but v2.1.0 makes it an operate-and-deploy toolchain as well, with laradox:deploy performing maintenance mode toggling, image builds, Composer install, asset builds, migrations and cache warm-up. That fits self-hosted single-VM or small-cluster Laravel well and is a poor fit for managed runtimes. Treat the deploy command as production-mutating software: run it in staging first and keep your manual runbook available as a fallback for at least one production release.
- Can I use laradox:status as a CI gate?
- Yes. laradox:status returns a non-zero exit code when any container is not running or unhealthy, which makes it gateable in CI without parsing output. If you do want structured output, use the --json flag and pin the exact minor version, because the JSON schema and flag names should be treated as a new CLI surface rather than a hardened API. A common sequence is to wire status --json into a non-blocking CI job first and capture a laradox:benchmark --json baseline before you start mutating anything.
- How do I run laradox:deploy safely and non-interactively?
- Use the --dry-run flag first and diff the printed plan against your existing deploy runbook. For unattended CI runs, --force gates the non-interactive execution, and per-step skip flags let you omit individual stages such as asset builds or migrations. If a step fails, the command automatically exits maintenance mode and points you at diagnostics, so a failed run should not leave the app stuck in maintenance.
- Does laradox:deploy roll back migrations if a step fails?
- Migration rollback is not documented as part of the deploy command; the stated failure behaviour is to halt, exit maintenance mode automatically and print a pointer to diagnostics. That means a partially applied migration stays applied, so treat schema changes with their own backwards-compatible, two-phase migration strategy. Verify rollback semantics in staging with laradox:deploy --dry-run and a deliberate failure before relying on it in production.
- Can I use Laradox with Kubernetes, AWS ECS, Cloud Run or Laravel Vapor?
- Not really. The package assumes a compose-file-shaped topology, and laradox:deploy in particular expects a Docker Compose deployment target, typically a single host with the repository checked out. The optimize path also assumes an Octane runtime such as FrankenPHP, Swoole or RoadRunner. Read-only commands like laradox:status and laradox:benchmark stand alone more reasonably, but adopting only those gives you a partial experience.
- Does Laradox work on Windows, WSL, or with a remote Docker host?
- Windows/WSL and remote Docker (DOCKER_HOST) support for the shared container-inspection concern are open questions rather than documented guarantees. Since all the new commands are thin orchestration layers over one container inspection abstraction, behaviour with a remote socket depends entirely on how that concern is implemented. Validate on your actual developer machines and CI runners before standardising the team on it.
- What are the alternatives to Laradox for a Laravel Docker setup?
- Laravel Sail is the official first-party option and DDEV is a popular general-purpose alternative, but both focus on local development rather than deployment. Laradox differentiates itself with FrankenPHP and Octane container configuration plus the status, benchmark, optimize and deploy Artisan commands. If you mainly need reproducible local containers, Sail is the lower-risk choice; if you want one tool that also drives cache warm-up and Octane worker reloads on a self-hosted host, Laradox is the closer fit.