Laravel Visits: a visit counter you attach to a model

A counter on the model, not on the page

Laravel Visits is a counter that can be attached to any model to track its visits, using Redis or Eloquent, with tags, IP protection and caching. The homepage is awssat.com/opensource, and the package is installed from Packagist.

The framing in the README is that it is a counter that can be attached to any model. That is a narrower and more specific thing than web analytics, and the distinction shows up in how the documentation is organised. There is a page on increments and decrements, a page on retrieving visits and stats, a page on visits lists, and a page on clearing and resetting values.

So the unit being counted is the model instance. A product, an article, a user profile, a recipe, whatever your application has as an Eloquent model, and the package keeps a tally against it. The visit is the increment, and the questions the documentation answers are what increments it, how to read the number back, how to keep a list of who visited, and how to reset.

The alternative to this is usually a counter column on the table, and the difference is worth naming. A column is one integer per record with no history, no protection against a single visitor inflating it, and no way to answer who visited. A package like this adds those things, and the cost is a dependency and a storage decision.

The project is MIT licensed, the primary language is PHP, and the release history tracks the framework, with 6.3.0 adding Laravel 13 support in April 2026, 6.2.1 adding PostgreSQL support in February 2026 and 6.2.0 adding Laravel 12 support in April 2025. The last push to the master branch was on 2026-04-27.

The documentation is a numbered manual, and the install is one command

The documentation is structured as a numbered set of pages in the docs/ directory, and the order is the reading order.

There is an introduction, then requirements, then installation, then a quick start, then increments and decrements, then retrieving visits and stats, then visits lists, then clear and reset values. That is the whole feature set laid out in the order you would need it, and it is worth noticing that a page is devoted to decrements and a page to clearing and resetting, which tells you the package expects the counter to be adjusted in both directions and occasionally wiped.

The installation is a single Composer command:

composer require awssat/laravel-visits

And the README points to the installation page on the documentation site for more detail, including the installlation note, which is a typo in the original.

The repository layout matches a Laravel package. There is composer.json, src/ for the package code, database/ for the migrations, tests/, a phpunit.xml at the repository root, docs/ for the manual, a CHANGELOG.md, a CONTRIBUTING.md, a CODE_OF_CONDUCT.md, an ISSUE_TEMPLATE.md, a.styleci.yml for code style, and a.travis.yml for the build.

The counters are attached to models, which in Laravel means a trait, and the storage sits behind the model, so the package needs somewhere to put the numbers. The two options named in the description are Redis and Eloquent, and the 6.2.1 release added PostgreSQL support, which tells you the database side is not limited to MySQL.

The Todo section is a single line, an export command to save visits of any periods to a table on the database, which suggests the current scope is counting and reading rather than reporting over time.

IP protection, tags and caching, and what each is for

The three features named in the description are the ones that separate this from a counter column, and each solves a specific problem.

IP protection addresses the most common failure of a naive visit counter, which is that one visitor, or one bot, increments a record thousands of times. With protection in place, the counter reflects distinct visitors rather than raw requests.

Tags let you record something alongside the visit, so a count can be segmented later. A record visited from a campaign, a country, a referrer or a particular feature can be tallied separately, which is the difference between a number and a breakdown.

Caching is the performance half. A visit count is read far more often than it is written, since a product page is served to every visitor and the count is displayed once. Caching the read path is what keeps the counter from turning every page view into a database query.

The features interact in a way that is easy to miss when reading the list. IP protection needs state, because deciding whether a visitor has already counted requires knowing who they are, and that state is what the caching can hold. So the backend choice is not only about where the totals live, it is about where the per-visitor state lives, and that is the thing to read the requirements and installation pages for before you commit to a configuration.

The project also ships a statistics side, since the repository topics include stats and the documentation has a page on retrieving visits and stats. The counter is therefore not only a number on a model, it is a set of figures you can read back for display, which is what the rest of the package is for.

A package with a funding warning

The README carries a request at the top, and it is worth reading as a maintenance signal rather than as an aside.

It asks readers to support the work with a donation so the maintainers can continue to improve the package, and adds that once the funds are raised they will continue working on the package. The wording is a little rough, which fits a project maintained by a small group, but the substance is that this is a package whose maintenance depends on sponsorship.

That matters for an adoption decision in a specific way. A Laravel package that tracks a framework version is on a treadmill, because each new major release needs support work, and the release history shows that treadmill. Version 6.2.0 added Laravel 12 support in April 2025, 6.2.1 added PostgreSQL support in February 2026, and 6.3.0 added Laravel 13 support in April 2026. The framework is moving to a yearly major cadence and the package is keeping pace, with roughly a release per framework generation.

The credits name Bader, with a link to a GitHub profile, and then all the contributors, and the project has an Open Collective contributors badge. The scope of the package has been stable for a while, with one open item on the Todo list, and the CHANGELOG is linked for what changed recently.

So the realistic assessment is that this is a small, focused and actively maintained package with a funding dependency and a yearly release rhythm, which is a perfectly reasonable thing to depend on if the counter semantics it offers are what you were going to build anyway, and a poor foundation if your requirements are still moving.

Editorial conclusion

Adopt Laravel Visits if you need per-record visit counts and the ones you have are coming from a controller rather than an event pipeline, because the package attaches a counter to the model itself. Do not adopt it for page view analytics, since the counter is a model counter and the documentation keeps it separate from a general analytics tool. Before you install, read the requirements page for the Laravel and PHP versions, and decide between Redis and the database, because the storage choice determines how you handle the IP protection and the caching behaviour.

Frequently asked questions

Official sources

1. awssat/laravel-visits on GitHub
2. License: MIT
3. Project website
4. README
5. Releases