- How do I install Takeout in a Laravel project and enable a service?
- Add it to your project as a Composer dev dependency, then run ./vendor/bin/takeout list to see the available commands. Enable what you need with something like ./vendor/bin/takeout enable mysql, and Takeout writes a docker-compose.yml for that service and prints the host port it assigned. Copy that port into your .env, run php artisan config:clear, then migrate. Verify Docker Engine and Compose v2 with docker compose version before installing, because Takeout shells out to docker compose and inherits every failure of that layer.
- Which services can Takeout run for local Laravel development?
- Takeout ships definitions for the usual Laravel backing services: MySQL and MariaDB, PostgreSQL, Redis, Memcached, Mailhog or Mailpit, MinIO, and search such as Meilisearch. You enable only what a given project needs, and each service gets its own container, host port, and named volume for that project. PHP itself and web serving are out of scope, so you still use Herd, Valet, or your own runtime for the app.
- Does Takeout replace Laravel Sail, and can I run both in the same project?
- Takeout and Sail both own docker-compose.yml and both bind host ports, so running them against the same project is a known and confusing failure mode rather than a preference. Takeout is deliberately narrower: it manages backing services only and never touches your app runtime, .env, or config/database.php. If you want one tool that also runs PHP, look at Sail, DDEV, or a platform-provided environment instead, and record the default orchestrator per project.
- Does Takeout update my .env or config/database.php automatically?
- No. Takeout deliberately stays out of the application runtime, so it does not rewrite .env and does not touch config/database.php. After enabling a service it prints the host port to use, and you paste that into your .env yourself before running php artisan config:clear. That keeps behavior predictable, but it means the copy step must be documented for new developers and for CI.
- Why do I get connection refused after re-enabling a Takeout service?
- Enable assigns a free host port, and it may assign a different one after a disable and re-enable, but it never updates your .env. The symptom is a connection refused error that is routinely misdiagnosed as a credentials or auth-plugin problem. Inspect the running container or takeout list output, update the port in DB_HOST, DB_PORT, or REDIS_PORT, and clear config. Teams that want determinism pin ports with --default-port or edit the generated YAML and commit it.
- Does takeout disable delete my database data?
- No. takeout disable stops and removes the containers but preserves the named volumes, so your data is still there when you enable the service again. The destructive command is docker compose down -v, which removes volumes irrecoverably. Engineers routinely expect the opposite of whichever one they ran, so put this distinction in your README.
- How do I customize the generated docker-compose.yml without losing my changes?
- Hand-editing the generated docker-compose.yml works until Takeout regenerates it and overwrites your edits. The supported extension point is a docker-compose.override.yml in the same directory, which Compose merges automatically. Use the override file for extra environment variables, fixed port mappings, or platform pins rather than editing the generated artifact.
- Does Takeout work on Apple Silicon, Linux, and Windows with WSL2?
- It runs anywhere Docker Engine plus Compose v2 are available: Docker Desktop, OrbStack, or Colima on macOS, native Docker on Linux, and Docker Desktop with WSL2 on Windows. On Apple Silicon, amd64-only images may need platform: linux/amd64 in your override file. On Linux your user must be in the docker group, and because localhost often resolves to ::1, documenting 127.0.0.1 as the default for DB_HOST and Redis avoids a whole class of connection failures.
- How do I stop image updates from breaking my Takeout containers?
- Takeout generates a compose file with service images, so an unpinned postgres:latest will move under you; Takeout 3.2.1 itself was a fix for PostgreSQL 18's volume path change, and anyone tracking latest hit initdb errors. Pin image tags in the committed YAML for every service, and treat tag bumps as reviewable pull requests with an owner. That gives you a reproducible local environment instead of one that changes when upstream pushes.
- Is Takeout safe for production and how is the project maintained?
- Takeout is a require-dev Composer package for local development only; it should never be part of a production deployment and it does not ship Docker or run your application. It is MIT-licensed and maintained by Tighten with a narrow scope, which means low coupling and low blast radius, but also very few external dependents and little validation beyond its own star count. Evaluate it against your team's default orchestrator, image-tag ownership, and the maintainer's release cadence before standardizing on it.