- How do I install Laravel Totem?
- Run composer require always-open/laravel-totem, then php artisan totem:install. Publish the config, assets, and migrations, run migrations, and add the scheduler cron entry on one node. Review the generated route prefix, middleware, and auth gate before merging.
- What is Laravel Totem used for?
- Laravel Totem gives a Laravel app a Blade-rendered web dashboard to view, create, edit, enable, disable, and run scheduled tasks. It also records run history and output, and it executes due tasks through an Artisan command. It is not a standalone ops console or an external scheduler monitor.
- Does Laravel Totem support Laravel 10 and 11?
- The evaluation context specifically calls out Laravel 10 and 11 monoliths or modular monoliths as a good fit for v13.x, and v13.4.0 is the release discussed. Exact PHP and Laravel constraints are defined in the package composer.json, so verify those against your upgrade horizon before adopting it.
- How should I secure the Totem dashboard in production?
- The dashboard can trigger scheduled tasks on demand, so leaving the default route middleware in production creates a remote task-execution surface. Put the Totem route behind an explicit auth gate or policy, restrict who can run tasks manually, and test both unauthenticated and low-privilege requests before rollout.
- Do I still need a cron entry after installing Laravel Totem?
- Yes. Totem is an in-app dashboard and history layer, so you still need a single scheduler cron entry on one node that invokes the documented Artisan command to execute due tasks. Totem does not replace the need for a trigger, and multi-node deployments need onOneServer or overlap locks to avoid duplicate runs.
- Does Totem store scheduled tasks in the database or in code?
- Totem stores task definitions and execution history in your application database, which is what allows the dashboard to create, edit, enable, and disable entries. Laravel schedule definitions in code remain the other possible source of truth, and drift between the two is the main long-term risk. Decide explicitly which one owns scheduling before rollout.
- How do I manage Laravel Totem execution history retention?
- The evaluation notes flag retention as an open question and do not describe automated pruning, so treat history growth as something you must manage. Check expected row growth after migrations, define a retention window, and add a scheduled pruning job or query if Totem does not provide one. Monitor table size in staging before production.
- Will upgrading Laravel Totem break customized Blade views?
- If you override layout.blade.php or partials/sidebar.blade.php, the 13.4.0 release notes require you to hand-merge new lines. That is direct evidence that UI-level overrides create recurring upgrade tax. Either avoid overriding Totem views or assign clear ownership for the merge on every release.
- Why is Totem dark mode not styled after upgrading to 13.4.0?
- Version 13.4.0 adds a dark mode switcher and a new published asset, css/dark.css. If your deploy pipeline assumes a fixed asset list, rerun php artisan totem:assets so the file is published. Missing dark.css is cosmetic and does not affect scheduling behavior.
- Can Laravel Totem monitor non-Laravel cron jobs or queue workers?
- No. Totem is an operational dashboard for Laravel's own task scheduler; it does not observe external cron jobs, queue workers, or non-PHP services. If your scheduling spans other runtimes, pair Totem with an external scheduler-monitoring service rather than treating it as a complete ops console.