How to run Laravel Tinker in Docker, Sail, or Laradock

Direct answer

To run Laravel Tinker in Docker, first find the container that can execute php artisan. For plain Docker Compose, run docker compose exec app php artisan tinker. For Sail, run ./vendor/bin/sail artisan tinker. For Laradock, run Tinker from the workspace container, usually with docker exec -it -w /var/www laradock-workspace-1 php artisan tinker.

In LaraBench, create a Docker exec connection with that container and app path, then select it in Run Code.

When to use this

Use this workflow when your Laravel app only boots correctly inside a container. That is common when the app expects container DNS names such as mysql, redis, or mailpit, or when PHP extensions are installed inside the Docker image rather than on your host machine.

You need three facts before opening Tinker:

• The container that has PHP and can run php artisan.
• The Laravel app path as it exists inside the container.
• The container user, if the app should not run as the default user.

Terminal approach

Start in the terminal. If these commands fail, LaraBench will fail for the same reason, because Docker connections run through docker exec.

Plain Docker Compose

docker compose ps
docker compose exec app php artisan about
docker compose exec app php artisan tinker --execute="dump(config('app.name'));"

Replace app with the service that has PHP. If the compose service starts outside the Laravel root, add the workdir:

docker compose exec -w /var/www/html app php artisan about
docker compose exec -w /var/www/html app php artisan tinker --execute="dump(config('app.name'));"

Laravel Sail

Sail wraps Docker Compose for Laravel projects. Laravel's docs show Artisan commands running through ./vendor/bin/sail artisan, and Tinker is just another Artisan command.

./vendor/bin/sail artisan about
./vendor/bin/sail artisan tinker --execute="dump(config('app.name'));"

Laradock

For Laradock, use the workspace container. It is normally the container with PHP, Composer, and your mounted application path.

docker ps
docker exec -it -w /var/www laradock-workspace-1 php artisan about
docker exec -it -w /var/www laradock-workspace-1 php artisan tinker --execute="dump(config('app.name'));"

LaraBench approach

Once the terminal command works, save the same target in LaraBench:

• Open Connections and create a new connection.
• Set the connection type to Docker exec.
• Enter the container name, for example app or laradock-workspace-1.
• Set the Laravel app path inside the container, for example /var/www/html or /var/www.
• Set the environment label to local, staging, or production.
• Add a container user only if your terminal command needs one.
• Test the connection, then use it from Run Code.

LaraBench does not install a helper package inside the container. It needs Docker to be running locally, a reachable container, and a Laravel app root that can run Artisan.

Safe snippet

Start with a read-only snippet that proves the Laravel app booted and that the selected connection is the one you intended.

return [
    'app' => config('app.name'),
    'environment' => app()->environment(),
    'database' => config('database.default'),
    'php' => PHP_VERSION,
    'base_path' => base_path(),
];

In LaraBench, paste that into Run Code in Tinker mode, choose the Docker connection, and run it. The same snippet is safe for local and staging checks because it only reads configuration values.

Expected result

A working run should return an array with the app name, environment, database connection name, PHP version, and app path. In LaraBench, the output appears in the result panel and the run is recorded in History with the selected connection.

Keep the terminal command around. When a Docker image changes or a project moves paths, the terminal check is still the fastest way to separate a container problem from a LaraBench connection problem.

Troubleshooting

Safety notes

Tinker runs real application code. A Docker connection can still point at staging or production services if the container's environment does, so read the environment label before each run and begin with inspection snippets.

• Prefer config(), app(), and small read-only queries for the first run.
• Do not paste destructive snippets into a production connection just because the target is Docker.
• Use LaraBench production labels and confirmations for remote or production-like containers.
• Run migrations, queue changes, and destructive maintenance commands as deliberate Artisan commands, not casual Tinker snippets.

Related workflows

For setup details, read the LaraBench Docker connection docs and Sail and Laradock docs. For the broader runner model, start with Run Code.