Weave Code
Tomato Admin Laravel Package
tomatophp/tomato-admin
Tomato Admin is a Laravel admin panel built on Splade that gives you a ready-made dashboard with authentication, roles and permissions, a CRUD generator, menus, notifications, and translation tools, so you can scaffold complete backend interfaces quickly with minimal code.
Tomato Admin is a ready-to-use Laravel admin panel that provides a clean, extensible back office for managing users, roles, permissions, settings, and content. Built for rapid development, it fits into the TomatoPHP ecosystem and offers a consistent UI for common administrative tasks.
- Role-based access control with users, roles, and permissions
- CRUD generator for scaffolding resources, forms, and tables
- Media and file management with upload and storage integration
- Settings, menus, and translations for configurable multilingual admin
- Responsive, RTL-ready UI for modern dashboards
Frequently asked questions about Tomato Admin
- What is Tomato Admin and what does it include out of the box?
- Tomato Admin is a ready-to-use Laravel admin panel that ships authentication, users, roles and permissions, settings, menus, media and file management, translations, and a CRUD generator. It is built on Splade (Laravel with Livewire and Alpine, plus Vue 3) and uses a FilamentPHP-derived theme, so the UI is consistent and RTL-ready. It is designed for internal back-office surfaces such as ops consoles, support tooling, and CMS-lite applications rather than public-facing products. Treat it as a scaffold that removes weeks of plumbing, not as a finished product you will never touch.
- How do I install Tomato Admin in a Laravel application?
- Install it with Composer using tomatophp/tomato-admin into a Laravel app that already runs Splade, since the package views and assets depend on it. Then publish the package config and assets, run the migrations, and point your admin route prefix at the shipped dashboard. The exact publish tags, guard, and route prefix are defined in the package config, so read it before wiring your own auth flow. Because the admin ships its own user and role assumptions, align those with your existing user model early rather than after go-live.
- Which Laravel and PHP versions does Tomato Admin support?
- Support is defined by the constraints in the package composer.json, so check that file against your app Laravel and PHP versions before committing. The last release was mid-2024, which typically lines up with Laravel 10 and 11 era projects, and you should assume Filament v3-era theming unless the manifest says otherwise. Test installation in a throwaway branch first, because a silent incompatibility with your Laravel minor is easier to catch there than in a running admin.
- Is Tomato Admin built on Filament or Splade?
- Both, in a sense: it is a FilamentPHP-derived theme layered on Laravel Splade, with Livewire and Alpine for interactivity and Vue 3 underneath Splade SPA routing. The important question to answer before adopting it is whether composer.json requires filament/filament outright or only vendors the theme, because that decides whether you inherit the full Filament resource engine or just a UI shell. Either way, adoption is a stack bet on Livewire, Alpine, and Splade rather than a single-package pick, so record it as an architecture decision.
- Can I use Tomato Admin for a customer-facing admin panel or a multi-tenant SaaS?
- It is a poor fit for customer-visible surfaces and heavily multi-tenant deployments. Tomato Admin is an opinionated monolith-side back-office accelerator built for internal, low-blast-radius tools where the admin is not part of the product experience. If regulated data or customers touch the surface, a vanilla Filament install or Laravel Nova gives you a dependency profile you can actually own and audit. Use Tomato Admin where the worst-case failure is a broken internal dashboard, not a customer incident.
- How does the Tomato Admin CRUD generator work?
- The generator scaffolds resources into forms and tables so you can stand up a complete backend interface for a model with minimal hand-written code. It is the main reason the package can remove three to six weeks of plumbing from a first release. Keep your domain logic in your own classes and migrations rather than in generated or package-owned code, so a future swap to vanilla Filament stays a UI migration rather than a rewrite. Generated scaffolding is a starting point, not a place to bury business rules.
- How do roles and permissions work in Tomato Admin, and which guard does it use?
- It ships role-based access control with users, roles, and permissions wired into the dashboard, and sibling TomatoPHP packages are designed to compose with it. The shipped routes, config, and user model assume a specific guard and route prefix, so confirm those values from the published config before connecting your own auth. Align the package user model with your application early, because retrofitting a different guard after the admin is live is more disruptive than it looks. Prefer deep adoption of the roles package over shallow adoption of every sibling package.
- What are the biggest technical risks with Tomato Admin in production?
- Risk concentrates in the front end, not in PHP. A Tailwind preset collision between Filament and Splade routinely passes in dev and fails only in minified production builds, and Splade SPA routing with Livewire can leave stale component state after navigation. Asset publish drift is another quiet failure mode: if your pipeline rebuilds Filament theme assets instead of shipping the published ones, staging serves stale CSS with no error surfaced anywhere. A Filament major bump degrades styling and a Splade bump can blank the dashboard, and neither is caught by unit tests.
- Is Tomato Admin actively maintained and safe to depend on?
- The project has roughly 56 GitHub stars, zero dependents, a last release from mid-2024, and a single-maintainer ecosystem with no evident security policy or CVE channel. Practically, that means every dependency in the chain is yours to patch, and you should budget fork-and-own from day one rather than treating it as a fallback. For internal tooling with a small blast radius that is a reasonable trade, but for anything touching regulated data or customers it is the wrong dependency profile. Check composer.json and open issues for the Filament major and Splade version the views were written against before you commit.
- What are the alternatives to Tomato Admin, and how hard is it to migrate off?
- Vanilla Filament and Laravel Nova are the natural alternatives, and a React-based admin is the better call if your team is React or Next-native rather than Blade and Livewire comfortable. The exit cost depends almost entirely on discipline: keep domain logic out of package-owned and generated code, and a swap in twelve months is a UI migration rather than a rewrite. Because the two likeliest regressions, styling breakage and blank dashboards, are invisible to automated tests, budget a visual smoke test or screenshot diff so you notice problems during the migration. Decide who owns the fork before approval, not after the first silent upgrade failure.
Weaver
How can I help you explore Laravel packages today?