Dockerize a Laravel App

The agent clones the repository into its own sandbox and reads what the image has to carry before it writes a line of the Dockerfile. In a Laravel app like laravelio/laravel.io, composer.json pins "php": "8.4.*" with laravel/framework ^11.5, Livewire 3, Filament 4 and intervention/image 3, and package.json builds the front end with Vite 6 and Tailwind 4 ("build": "vite build"). The test workflow in .github/workflows/tests.yml is the most honest list of what the app needs to run: PHP 8.4 with the dom, curl, mbstring, zip, pcntl, pdo and gd extensions, Node 22.x for npm run build, and a mysql:5.7 service with a laravel database. There is no Dockerfile or compose file in the repository today.

From that it writes a three-stage Dockerfile. A Node 22 stage runs npm ci and npm run build so the hashed assets land in public/build; a Composer stage runs composer install --no-dev --prefer-dist --optimize-autoloader against composer.lock; and the runtime stage starts from a PHP 8.4 image, installs the extensions the workflow lists plus pdo_mysql, copies in vendor/ and public/build from the earlier stages, and never ships Node, Composer or the dev dependencies. Two details come from reading the app rather than a template. database/schema/mysql-schema.sql is a schema dump, and Laravel loads a dump with the mysql command-line client, so the runtime image needs that client or php artisan migrate fails on an empty database. And .env.example sets CACHE_STORE=file and SESSION_DRIVER=file, so storage/ and bootstrap/cache have to be writable by the user the container runs as.

Then compose.yaml: an app service built from that Dockerfile, a mysql service on the same 5.7 image CI uses with a health check, DB_HOST, DB_DATABASE, DB_USERNAME and DB_PASSWORD passed from the environment rather than baked in, and a named volume for the database. Because routes/console.php schedules commands such as lio:generate-sitemap and lio:update-article-view-counts, the agent adds a scheduler service running php artisan schedule:work from the same image, or says in the PR why it left one out. It also writes a .dockerignore so vendor/, node_modules/, .env and storage/logs stay out of the build context.

Last, it proves the thing boots. In the sandbox it runs docker compose build, starts the stack, generates an APP_KEY, runs php artisan migrate --force and php artisan db:seed inside the app container (the repository ships UserSeeder, TagSeeder, ReplySeeder and others), and opens the home page, served by HomeController::show, in the sandbox's browser. It records docker image ls for the image size, takes a screenshot of the page, and fixes and rebuilds until the page loads with seeded threads and articles instead of a 500.

What comes back is a pull request on its own branch with four new files: Dockerfile, compose.yaml, .dockerignore, and a short section in the README or a docker/ note with the commands to build, migrate and run. The description lists what the agent read and why each choice follows from it (the PHP 8.4 runtime, the extensions, the MySQL version matched to CI, the database client for the schema dump), the final image size from docker image ls, and the screenshot of the home page served by the container.

The proof is in the session's transcript, which keeps every command with its output: each docker compose build, the container logs, the migrate and db:seed runs, and the browser load of the home page, including any attempt that failed before a fix. Your repository's own workflows run on the pull request too; for an app like laravel.io the Tests workflow runs Pest against MySQL on every pull request, which shows that adding the Docker files changed nothing the suite covers.

Before merging, a reviewer checks that no secret or .env is copied into the image, that the runtime stage carries no Node, Composer or dev packages, that the container runs as a non-root user, and that the MySQL version in compose.yaml matches production, not only CI. If production runs a newer MySQL than 5.7, one follow-up message to the same session changes it and boots the stack again.

A team moving several Laravel apps to containers can start one run per repository, each a POST /o/{org}/sessions with that repository in resources and the same prompt. Send an Idempotency-Key per repository so a retried request returns the run it already started rather than a second one.

A key runs up to its max_concurrent sessions at once (4 by default), each in its own sandbox, so four apps build and boot in parallel without sharing a Docker daemon. A webhook on the key posts run.completed or run.failed when each turn finishes, with the session_url that holds the result and the pull request.

Proving a Dockerfile works means building it, starting a database next to it, migrating and seeding, and loading a page, several times over while the image is wrong. On a laptop that fills the local Docker cache with half-built layers and can collide with a MySQL already on port 3306. In a Rush sandbox the agent has its own Docker, its own database container and its own browser, so the build loop runs where it cannot touch anything else, and the sandbox parks with its disk and memory when the turn ends.

The pull request comes with what makes it trustworthy: the build logs, the migrate output, the screenshot of the page served from the container and the image size, all in the transcript next to the commands that produced them. A reviewer can see that the stack booted from a clean checkout, not on a machine that already had PHP 8.4 and the right extensions installed.

Will it use Laravel Sail?

Which PHP and MySQL versions does it pick?

Does it run the queue worker and the scheduler?

Does it need my production secrets?