Run Laravel Tinker over SSH on a remote server

Direct answer

Connect to the server, change into the Laravel app root, confirm php artisan works, then start Tinker. In LaraBench, save the same host, SSH user, port, app path, and environment once. Run Code then reuses that target for Tinker snippets and Artisan commands.

When to use this

Use SSH for staging or production apps that are not available as a local checkout or Docker container on your machine. You need SSH access, permission to enter the app directory, and a PHP binary that can run the deployed application's Artisan file.

Terminal approach

ssh [email protected]
cd /var/www/demo/current
php artisan about
php artisan tinker

Run php artisan about first. It checks the SSH user, working directory, PHP binary, autoloader, and Laravel bootstrap before you run application code.

LaraBench approach

• Open Connections and choose SSH.
• Add a clear project name and the correct environment.
• Enter the host, SSH user, port, and Laravel app path.
• Choose a private key or use your configured SSH agent.
• Save and test the connection.
• Open Run Code, select the connection, and start with the read-only snippet below.

First snippet

return [
    'app' => config('app.name'),
    'environment' => app()->environment(),
    'laravel' => app()->version(),
    'database' => config('database.default'),
];

This confirms the runtime context without selecting application records. If those values are not the target you expected, stop and fix the connection before running anything else.

Expected result

A successful connection test confirms the remote Laravel app. The first snippet returns the application name, environment, framework version, and default database connection. LaraBench shows the selected environment beside the runner and records completed runs in History.

Troubleshooting

• If SSH authentication fails, test the same host, user, port, and key with your terminal.
• If Artisan is missing, confirm the app path points to the directory that contains artisan.
• If PHP is not found, check the non-interactive SSH user's PATH or use the deployment's expected PHP command.
• If the wrong release opens, update the app path to the current symlink or deployment directory.

Safety notes

Treat every remote run as real application code. Confirm the environment label and app path, begin with configuration reads, and avoid broad model queries. Dry run can roll back supported database writes, but it cannot unsend email, undo an HTTP request, or recall a queued job.

Related workflows

After the connection works, use the remote log workflow or the read-only production check.