Tinker is the smallest repository in the Laravel ecosystem and the hardest one to replace
Powerful REPL for the Laravel framework.
At a glance
- What is it?
- Seven and a half thousand stars, one open issue and a 1,542 character README, because the package is not the REPL. The REPL is PsySH, and the interesting work is making an interactive shell trust your application's container.
- Who is it for?
- Tinker's profile makes sense once you understand that it is a bridge rather than a program. With 7,445 stars, 139 forks and a single open issue, the numbers describe something people depend on daily and file issues about almost never, which is exactly the shape of a package whose job is to hand you a booted application and get out of the way.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 17 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 7, 2026, and from our analysis. They are not legal advice.
Editorial analysis
The README is a single sentence about the product
The introduction paragraph is one line: Laravel Tinker is a powerful REPL for the Laravel framework. The description field repeats it exactly. Then come links to documentation on laravel.com at the artisan#tinker anchor, a contribution guide, a code of conduct, a security policy and the MIT licence.
That is the whole README, 1,542 characters. For a package with 7,445 stars it is the thinnest README in the Laravel organisation, and the reason is structural rather than a failure of documentation effort. Tinker is not a REPL. It is the layer that puts PsySH inside a booted Laravel application, and PsySH is documented by its own maintainers.
The topic tags confirm the layering: `laravel`, `psysh`, `repl`, `tinker`. PsySH appears as its own tag because it is the independent dependency that does the actual line editing, history, tab completion and evaluation, and it is maintained on its own schedule outside this repository. Everything Laravel-specific is the small part, and that is why the interesting engineering is all in the boundary.
The tree shows a package with almost nothing in it
The repository contains `.styleci.yml`, `CHANGELOG.md`, `art/`, `composer.json`, `config/`, `phpstan.neon.dist`, `phpunit.xml.dist`, `src/` and `tests/`. There is no `bin/`, no vendored dependency, no bundled binary and no frontend build.
Compare that to a framework-adjacent package that does real work and you see how small this is. Tinker ships a `config/` directory, which is the part users actually interact with, and an `src/` directory holding the command that boots PsySH and hands it the application. That is the product.
The maintenance numbers are the strongest evidence for that reading. 7,445 stars and 139 forks is a fork ratio under two percent, which is unusual for a Laravel package and normal for one that people use rather than modify. One open issue is extraordinary by comparison, and it is the number that tells you what kind of project this is: there is very little to complain about because there is very little behaviour to own. Every bug you would want to report is either a PsySH bug or a Laravel framework bug.
Version 3 dropped old PHP and added Laravel 13
The v3.0.0 release on 2026-03-17 is the substantive entry in this project's history and it contains four changes.
It returns the correct exit code when an exception is thrown, which sounds trivial and is not. If you script Tinker, throw inside it and get a success status, every wrapper around it silently misbehaves. It removed support for PHP 8.0 and 7.x, a hard version cut rather than a deprecation. It added support for Laravel 13. And it stopped trusting PsySH's project trust prompts.
That last one deserves a sentence, because it is the kind of change that gets backported. v2.11.1 on 2026-02-10, on the older 2.x line, contains the same PsySH trust prompt fix from the same pull request number, 198. The same change landing on both the 2.x and 3.x lines in the same month is a deliberate maintenance decision by the Laravel team, and it tells you something about how they treat this package: a security-adjacent change gets backported to every supported line rather than held for the next major.
v3.0.2 on 2026-04-14 carries only a generated comparison link, which is the pattern you would expect for a package that mostly absorbs upstream changes.
There is one timing detail worth flagging. The default branch is `3.x` and the last push was 2026-09-20, five months after the v3.0.2 release. Work is landing on the branch that has not yet been cut into a tagged release, which is normal for a stable package and means the version you install today may be behind the tip of the branch.
Why the PsySH trust prompt mattered enough to disable
PsySH can ask whether it should trust a project directory before it will read files from it. That prompt exists because a REPL that evaluates code has no natural boundary around what it will execute, and a project-local config file is executable code by definition.
Tinker disabling those prompts is a decision that trades one risk for another. PsySH's prompt protects you from a project that tries to get your REPL to run something on load. Removing it removes that friction on every single invocation, which for a tool people use dozens of times a day is a real cost saved, and which also means the protection now lives entirely in how your team decides which working directories are safe to open a shell in.
That framing is the honest way to think about Tinker generally. It gives you a process with your application's container booted, your configuration loaded, your service providers registered and your database credentials available as resolved instances. That is precisely why it is invaluable for exploring a production-shaped application and precisely why it is not something to run against production without thought.
The config directory is where that decision gets expressed, since the homepage points at the artisan#tinker documentation anchor rather than at a page of its own, which suggests the configuration surface is documented as part of the artisan command documentation.
Where this fits among the tools you already run
Tinker overlaps with things you probably have: a database client, an application log, and any number of one-off scripts you write to check a question about the data. What it replaces is the need to bootstrap the framework to ask a question that needs the framework. Eloquent relationships, model casts, container bindings, service provider logic and config defaults are all live in the shell, which is a different thing from querying the database directly.
That is the whole value proposition, and it explains why a package this thin has this many stars. It is not competing with a REPL; it is competing with `php artisan tinker`-shaped friction, which before Laravel shipped it was a lot of writing a console command just to check one thing.
The right way to evaluate it is therefore not feature comparison. It is operational. What does your team do with a shell that can write to your database? Is it in your local development container, or reachable from a production shell? What is the review story for a change somebody validated by mutating rows in Tinker rather than in a migration? Those questions have nothing to do with PsySH and everything to do with why this package is worth 7,445 stars and one open issue.
Editorial conclusion
Tinker's profile makes sense once you understand that it is a bridge rather than a program. With 7,445 stars, 139 forks and a single open issue, the numbers describe something people depend on daily and file issues about almost never, which is exactly the shape of a package whose job is to hand you a booted application and get out of the way. The 3.x line is where the real decisions live: dropping PHP 8.0 and 7.x, adding Laravel 13, fixing exit codes so a thrown exception can fail your script, and suppressing PsySH's trust prompt after a credential leak showed why it existed. If you evaluate one thing, evaluate what your team is allowed to paste into a shell that has production credentials loaded, because that is the question this tool's design has been answering for a decade.
Frequently asked questions
What is Laravel Tinker?
Tinker is a REPL for the Laravel framework. It wraps the PsySH interactive shell inside a booted application so your container, service providers, configuration and Eloquent models are available at the prompt, rather than only a raw PHP interpreter.
Which PHP versions does Tinker 3 support?
Version 3.0.0, published 2026-03-17, explicitly removed support for PHP 8.0 and 7.x and added support for Laravel 13. The 2.x line remains available if you are still on an older PHP or Laravel version.
Does Tinker need PsySH?
Yes, and PsySH does most of the work. The topic tags list `psysh` alongside `laravel`, `repl` and `tinker`, and the repository is a thin bridge that boots Laravel and hands it to PsySH. PsySH is developed and released independently of this repository.
Can I use Tinker in a shell script?
Yes, and 3.0.0 fixed exactly that case by returning the correct exit code when an exception is thrown. Before that fix a thrown exception could still produce a success status, which would break any wrapper checking the process result.
Is Laravel Tinker actively maintained?
Yes. The default branch is `3.x`, the last push was 2026-09-20, and v3.0.0 shipped on 2026-03-17 with v3.0.2 following in April. There is 1 open issue on 7,445 stars, which reflects how little behaviour the package owns.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/laravel-tinker)