Weave Code
Laravel Web Tinker Laravel Package
luminarix/laravel-web-tinker
A web-based tinker for Laravel that lets you run PHP code in the browser without the CLI. Quickly test snippets, inspect models, and debug queries through a simple interface, making it handy for local development and experimentation.
Small Laravel package to use Tinker in your browser
Frequently asked questions about Laravel Web Tinker
- How do I install laravel-web-tinker in a Laravel application?
- Install it with a single Composer require for luminarix/laravel-web-tinker; the package supports Laravel auto-discovery, so its service provider is registered without manual edits to config/app.php. From there you can optionally publish the configuration and route files if you want to customize the console path or middleware. Time to a first working console is typically measured in minutes to hours, not days. After installing, load the console route in the browser and run a simple expression to confirm it works.
- Which Laravel and PHP versions does laravel-web-tinker support?
- The package targets modern Laravel applications, with Laravel 11 and 12 on PHP 8.2 or newer being the practical baseline implied by its test suite and Testbench 10.x dev dependency. It is built on spatie/laravel-package-tools and hooks into the framework through a standard service provider, so it fits conventional Laravel app structure. Because minimum constraints can shift between releases, check the composer.json of the version you install and confirm it matches your app's PHP and Laravel constraints before merging. Consuming ^1.1 is the recommended approach for new installs.
- Is laravel-web-tinker safe to use in production?
- The package executes arbitrary PHP inside your application process, with the app's database connections, credentials, and filesystem access, so exposure is a serious concern. Its production warning badge is an advisory UI cue only and does not gate, block, or restrict access to the endpoint. Real protection comes from controls the package does not own: route middleware, authorization gates, IP allowlisting, and disabling the route outside local or staging environments. Treat it as an internal tool for trusted operators, not something to expose on a multi-tenant or public surface.
- Does the production warning badge block access to the web console?
- No. The badge added in v1.1.0 is a visual warning rendered when the environment is production; it changes what the operator sees, not who can reach the route. It reduces the chance of mistaking a production app for local, but it does nothing to stop an attacker who finds the endpoint. Verify the actual behavior in a sandbox by toggling APP_ENV and checking route registration and enablement, then rely on middleware and gates for enforcement.
- How do I add authorization or IP allowlisting to the web tinker route?
- Authorization is delegated to your host application, so the package does not ship a built-in gate or ability hook you can simply toggle. Publish the route and config files, then attach middleware you already trust, such as auth, a custom gate-backed middleware, or an IP allowlist middleware scoped to your office or VPN ranges. Apply these before the route is reachable outside your local environment. A defensive setup is to register the console route only in non-production environments and add authentication on top for staging.
- What is the difference between laravel-web-tinker and php artisan tinker?
- Both are backed by Tinker and PsySH, so the code you can run and the objects you can inspect are broadly the same. The difference is the delivery channel: this package exposes an in-application HTTP route that renders a browser console, so you do not need shell access or a terminal session. That makes it convenient for sandboxed environments, containers, or quick model inspection while you are already in the browser. The tradeoff is that the console now lives behind your web server and inherits the security obligations of any HTTP route.
- What runtime dependencies does laravel-web-tinker add to my application?
- In the current release the shipped runtime dependency delta is limited to spatie/laravel-package-tools. Everything else in the dependency bump is dev-only tooling such as Pest, PHPStan/Larastan, Collision, Pint, and Testbench, which does not ship to consumers. The package adds no queue, no external service, and no database schema, so there is nothing to provision. It only adds an additional HTTP route surface to your existing app, which is worth reviewing before merging a lockfile diff.
- Can a long-running tinker command hang a PHP-FPM worker?
- The package docs do not describe a bounded request lifecycle for console execution, so treat arbitrary code as unbounded unless you verify otherwise. Because execution happens inside the normal web request, a long-running query or infinite loop can occupy a PHP-FPM worker until your max_execution_time or web server timeout kills it. If you need hard limits, enforce them at the PHP or web server level and keep the console restricted to trusted environments. Test with a deliberately slow snippet in staging to see how your specific configuration behaves.
- How do I upgrade laravel-web-tinker from v1.0.4 to v1.1.0?
- It is a patch-level Composer bump: run composer update luminarix/laravel-web-tinker and regress-test the console route. The changelog shows no breaking changes, removals, or deprecations, so v1.1.0 reads as additive plus routine dependency hygiene. One caveat is the spatie/laravel-package-tools version jump from 1.19.0 to 1.91.1, which is an unusually large single hop, so validate the resolved dependency tree in a branch and inspect the lockfile diff. Confirm that provider registration and config publishing still behave the same after upgrading.
- What are good alternatives to laravel-web-tinker?
- If you already have shell access, the built-in php artisan tinker command is the lowest-risk option because it never exposes an HTTP route. Desktop and editor-integrated tinker clients are another route for developers who want a GUI without opening a web endpoint inside the app. This package is the right choice when you specifically need browser access from within the application, for example on a laptop, sandbox, or internal admin panel. Whichever you pick, the deciding factor is usually exposure and authorization rather than the execution engine, since most options sit on top of Tinker and PsySH.
Weaver
How can I help you explore Laravel packages today?