Integrate LiteSpeed Cache with Laravel

Laravel can use LiteSpeed to store HTTP responses for compatible routes. It is useful when a page can be reused without running the whole application. It does not replace query optimisation or Laravel's cache store, which can use Redis or another driver.

Prepare the integration

Check that your PHP and Laravel versions are compatible with litespeed/lscache-laravel. Test on staging and keep the previous code, lock file and configuration.

From the project root:

composer require litespeed/lscache-laravel
php artisan vendor:publish --provider='Litespeed\LSCache\LSCacheServiceProvider'

Run each command only if the previous one finishes successfully. Review the published configuration file without blindly overwriting an existing configuration. The package uses Laravel's auto-discovery; do not copy provider registration or Kernel.php instructions from an old branch into a current project.

For LiteSpeed to look up stored responses, the package documentation specifies this rule in the application's public .htaccess, keeping Laravel's rules:

<IfModule LiteSpeed>
    CacheLookup on
</IfModule>

Choose routes and a purge policy

Start with a read route that returns exactly the same content to every visitor. The package's middleware lets you define a lifetime and whether the response is public, private or not cacheable. Keep the global values without caching while you work out which routes can use it.

Do not turn the whole web group or the admin area into a public cache. A page that looks informational may include a username, CSRF token, currency, language or session data in its template. Those elements need exclusions or a specific design.

Also define when to invalidate responses: publishing a news item or changing a price must remove the related pages. The package provides tags and purge functions; use the ones that match your version and the project's content model.

Check before deploying

Request a public route several times and review its HTTP headers: sending a control header does not prove that the server has stored the response. Look for a cache hit on a later request.

Check two independent sessions, languages and any relevant variant. Update the test content and verify that the purge makes it visible. Login, logout, forms and operations with side effects must keep their behaviour.

If content from another session appears, disable the affected cache policy and purge its responses immediately. To remove the integration, revert the middleware and configuration, purge the cache and then remove the dependency with your deployment procedure. Removing the package is not enough while stored responses remain.