# tighten/takeout: Docker Dependencies for Local Development

> Takeout is a PHP CLI that starts disposable Docker containers for development dependencies such as MySQL, Redis, PostgreSQL and MongoDB. It fits macOS, Linux, Windows 10 and WSL2 users who want a simpler way to manage local service containers, but it is not a general Docker replacement.

**tighten/takeout** — Docker-based development-only dependency manager. macOS, Linux, and WSL2-only and installs via PHP's Composer... for now.

- Repository: https://github.com/tighten/takeout
- Stars: 1,655 · Forks: 82
- Language: PHP
- License: MIT
- Published: 2026-10-16 · Updated: 2026-10-16 · Language: en
- Canonical page: https://hysenlabs.com/projects/tighten-takeout

## What Takeout Manages in a Development Machine

Takeout addresses a specific local-development problem: a project may need several database, cache, search or messaging services at the same time, and installing each one through a host package manager can create version conflicts and cleanup work. Takeout wraps those dependencies in Docker containers and exposes a small command line for starting and stopping them. The intended audience is developers who already use Docker and want to keep service management separate from the host system. The README explicitly positions Takeout alongside Laravel Valet.

The supported service examples include MySQL, Redis, PostgreSQL, MSSQL, MongoDB and ElasticSearch. The repository also mentions Meilisearch and pgvector in shell examples. The exact available list is not fixed in the usage section: the README directs readers to the service classes in app/Services. That distinction matters because the command names shown in examples are not necessarily a complete service catalog.

Takeout's central behavior is intentionally narrow. `enable` creates a service container, while `disable` removes the container without deleting the associated Docker volume. The README states that Docker persistent volumes preserve data after a container is deleted, so a developer can stop using a service and bring it back later. That makes the tool convenient for temporary local work, but it also means that disabling a service is not the same as erasing its data.

## How the Containerized CLI Executes

The recommended installation does not install a long-running Takeout service. It defines an alias that starts the Takeout image as a temporary Docker container. The command mounts the host Docker socket, adds `host.docker.internal`, uses an interactive terminal and runs the `tighten/takeout:latest` image. The Dockerfile sets `TAKEOUT_CONTAINER=1`, copies a built Takeout executable into `/usr/local/bin/takeout`, and declares that executable as the container entrypoint.

Inside the image, the base is `php:8.2-cli-alpine`. The build installs the Docker client, OpenRC and ncurses, installs the PHP sockets extension, and copies Docker Buildx into the Docker CLI plugin path. The resulting architecture is therefore a CLI image that talks to the host Docker daemon through `/var/run/docker.sock`. The host daemon remains responsible for creating and managing the dependency containers.

When a service is enabled, Takeout generates a `docker run` command. Service-specific parameters are selected by Takeout, and additional Docker options can be supplied with `--run=`. Arguments placed after `--` are passed to the container entrypoint, not to `docker run`. This separation is important when a service needs both host-level configuration, such as an environment variable or volume, and service-level arguments, such as a database user or host.

## Installing Takeout Through the Docker Alias

For Linux or macOS, add the documented alias to `~/.bashrc`, `~/.zshrc` or an equivalent shell configuration file. This is the README's recommended installation route. The first invocation pulls the Takeout image from Docker Hub, so Docker must already be installed and usable.

```bash
alias takeout="docker run --rm -v /var/run/docker.sock:/var/run/docker.sock --add-host=host.docker.internal:host-gateway -it tighten/takeout:latest"
```

Reload the shell configuration after adding the alias, or open a new shell. The README does not provide a verification command for the alias, so the first documented real use is the service listing:

```bash
takeout enable
```

That command should display the services Takeout can enable. To update the image, the README gives this command:

```bash
docker pull tighten/takeout
```

The update command pulls the image, but the README does not document a pinned production release or an automated upgrade policy. For repeatable local setups, the Docker alias and the selected service definitions should be treated as project configuration that deserves review.

## Enabling and Disabling Development Services

Takeout accepts one or more short service names after `enable`. The following command starts MySQL:

```bash
takeout enable mysql
```

Several services can be started in one invocation:

```bash
takeout enable redis meilisearch
```

Without `--default`, Takeout may ask for parameters. If the defaults are appropriate for the current project, the documented shortcut avoids that prompt:

```bash
takeout enable mysql --default
```

The same option works with multiple services. When a database image needs its own command-line settings, pass them after the separator:

```bash
takeout enable mysql -- -hsome.mysql.host -usome-user
```

For options that belong to the generated `docker run` invocation, use `--run=`:

```bash
takeout enable mysql --run="{docker-run-options}"
```

The README explains that the resulting command has the general shape below. The placeholders are examples, not literal values to paste into a shell:

```bash
docker run {docker-run-options} {service-options} mysql/mysql-server
```

Disabling removes the managed container while retaining the Docker volume according to the README:

```bash
takeout disable mysql
```

Use `takeout disable` to list enabled services and `takeout disable --all` to disable all of them. If data must be removed, the README does not document a Takeout cleanup command, so Docker volume management would need separate verification.

## Starting, Stopping and Entering Containers

Takeout separates container lifecycle from creation. A stopped container can be listed with `takeout start`, then started by its container ID:

```bash
takeout start {container_id}
```

Multiple stopped containers can be started together:

```bash
takeout start {container_id1} {container_id2}
```

The README also documents `takeout start --all`, which starts every enabled container that is currently stopped. For running containers, `takeout stop` lists candidates, and specific IDs can be supplied:

```bash
takeout stop {container_id1} {container_id2}
```

For direct inspection, Takeout can open a shell in a running service container:

```bash
takeout shell mysql
```

The README states that Takeout starts either `bash` or `sh`, depending on what the container supports. Examples include `mysql`, `neo4j` and `pgvector`. This is useful for examining a running dependency, but it also means the available shell depends on the selected image. The README does not explain behavior for a service that is disabled, stopped, or missing a shell binary.

## Composer Installation and Version Constraints

Takeout can also be installed globally through PHP's Composer. The README calls this route not recommended and requires PHP on the latest major version plus Composer. Its documented command is:

```bash
composer global require "tightenco/takeout:~2.9"
```

That version constraint is worth noticing. The repository information lists recent releases v3.1.0, v3.2.0 and v3.2.1, while the README's Composer example explicitly requests `~2.9`. The documentation does not explain whether the Composer installation route is intended to remain on that line or whether the example is outdated. A team choosing Composer should resolve and review the installed version instead of assuming it matches the Docker image tag.

The Dockerfile uses PHP 8.2 for the containerized build, while the README says the Composer route supports only the current major version of PHP. That creates another version decision for developers: the Docker route is isolated from the host PHP installation, whereas Composer adds a PHP and Composer dependency to the workstation. Neither route makes Takeout a production dependency manager. Its documented scope is local development services, and the README does not describe deployment, replication, access control or production persistence.

## Maintenance, Licensing and Operational Limits

The repository is not archived. Its last push was on 2026-04-09, and recent release entries include v3.2.1 on 2026-01-29. That supports treating the project as receiving repository updates, but it does not establish compatibility with every local environment. The README does not document a support window, release cadence, migration guide or rollback procedure.

Takeout is identified as MIT licensed. That license permits use and modification under its terms, but it does not make Docker, database images, PHP, Composer or the service images themselves part of Takeout's license. Those dependencies have separate licensing and operational requirements. The repository includes a LICENSE.md file, so an organization should read that file and the licenses of every selected service image before distributing a packaged environment.

The main limitation is the boundary between convenience and infrastructure management. Takeout makes local container lifecycle commands short, but the README does not document backups, schema migration, secret management, network policies, resource limits, log retention or production upgrades. A developer who deletes a container should also remember that persistent volume data may remain. Teams that need those controls should treat the Docker volumes and generated `docker run` configuration as part of their operational design.

## Takeout Compared with Direct Docker Commands

Direct Docker commands provide more control because the developer writes the full `docker run` configuration. That is a real advantage when a service needs unusual mounts, environment variables, ports, resource limits or a custom image. It also avoids installing an additional PHP CLI or running Takeout through a Docker alias.

Takeout reduces that work by storing service defaults and offering commands such as `enable mysql`, `disable mysql`, `start`, `stop` and `shell mysql`. It also provides a repeatable way to start several services with short names. The trade-off is that the convenience depends on the service class definitions in `app/Services`, and the README directs users to those definitions for the current catalog. A service that needs behavior outside those defaults may require direct Docker commands or additional `--run` options.

For a single project with a fixed service set, direct Docker can be clearer. For repeated local services across projects, Takeout can reduce repetitive commands. Neither choice, based on the README, provides a documented production control plane.

## Conclusion

Takeout is a reasonable fit for developers who repeatedly need short-lived local MySQL, Redis, PostgreSQL and similar services, especially when paired with Laravel Valet. It is a poor fit for a team that needs production orchestration, explicit backup and retention controls, or a stable installation path across incompatible PHP versions. Before adoption, verify the service definitions in app/Services, confirm how your data is stored, and inspect the Docker alias or Composer installation method you will standardize.

## FAQ

### How do I install Takeout on macOS or Linux?

The README recommends adding a Docker alias to `~/.bashrc`, `~/.zshrc` or an equivalent file. The first use pulls `tighten/takeout:latest` from Docker Hub.

### Which development services does Takeout support?

The README names MySQL, Redis, PostgreSQL, MSSQL, MongoDB and ElasticSearch, with additional examples including Meilisearch, Neo4j and pgvector. It says the current list is represented by the classes in `app/Services`.

### Does disabling a Takeout service delete its data?

The README states that disabling removes the container but does not delete its data because Docker persistent volumes retain it. The README does not describe a Takeout command for deleting those volumes.

## Sources

- [Issues](https://github.com/tighten/takeout/issues)
- [License: MIT](https://github.com/tighten/takeout/blob/main/LICENSE)
- [README](https://github.com/tighten/takeout/blob/main/README.md)
- [Releases](https://github.com/tighten/takeout/releases)
- [tighten/takeout on GitHub](https://github.com/tighten/takeout)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/tighten-takeout