- How do I install tomatophp/tomato-saas-module in a Laravel app?
- Install it with composer require tomatophp/tomato-saas-module, and Laravel package auto-discovery registers the service provider. Publish the config and migrations with vendor:publish, review them, then run php artisan migrate. Because the release notes do not describe the schema, read the published migrations and config before migrating anything.
- Which Laravel and PHP versions does tomato-saas-module support?
- The package is a Laravel package in the TomatoPHP family and expects PHP 8.2+ alongside a Filament-aligned admin stack, but the repository does not publish an explicit support matrix. Check composer.json for the exact Laravel, PHP, Filament, and Livewire constraints before installing. Given the thin version history, pin an exact version and treat the composer constraints as authoritative.
- Does tomato-saas-module require Filament or the TomatoPHP admin panel?
- Most of the module's value sits in its Filament-based admin resources, typically layered on tomato-admin, so it assumes a Filament admin surface. If you ship an Inertia/Vue or bespoke admin, you would adopt the migrations and models while discarding the UI, which is usually a poor ratio of dependency cost to benefit. Verify the required Filament major in composer.json matches yours.
- What tenancy strategy does tomato-saas-module use: shared database, schema per tenant, or database per tenant?
- The repository does not document whether it uses a shared database with a tenant discriminator, schema-per-tenant, or database-per-tenant. You have to read the published migrations and the tenant-resolution middleware to determine this, and it is unclear whether the strategy is configurable. Treat this as a blocking question, because tenancy is a security boundary rather than a feature toggle.
- What does tomato-saas-module actually own versus what do I still have to build?
- Expect it to own tenant records, a plan catalog, subscriptions, seat or feature limits, and admin CRUD screens, with billing hooks at the edges. It is not documented where enforcement stops or whether it calls a billing provider directly. Map the models, policies, and service provider bindings before integrating so you do not end up with a dual source of truth.
- Is tomato-saas-module production ready, and is v1.0.0 stable?
- Version 1.0.0 is published with only an auto-generated commit link and no human-authored changelog, so treat the major version as a label rather than proof of stability. There is no published test suite or CI signal in the repository. Since multi-tenancy is a security boundary, a code review of global scopes, withoutGlobalScopes usage, and cache key namespacing is required before production use.
- How does billing work in tomato-saas-module, and which payment providers are supported?
- Billing is described only as billing hooks, with no documented provider integration, so which providers, webhook handling, idempotency, and dunning behavior are covered is unknown. Verify this by reading the code rather than assuming Stripe or Paddle support. If your provider is not supported, plan to write the adapter and the webhook handling yourself.
- How do I enforce plan limits and feature entitlements with tomato-saas-module?
- Plans, subscriptions, and seat or feature limits are part of the module's domain, but it is not documented whether enforcement is centralized in a single gate or policy or scattered across admin resources. Audit where limits are checked so you can also enforce them outside the Filament UI, for example in APIs, jobs, and console commands. If enforcement lives only in resources, add your own policy layer on top.
- What are the alternatives to tomato-saas-module for SaaS scaffolding in Laravel?
- Alternatives include building on stancl/tenancy or spatie/laravel-multitenancy for tenancy plus Laravel Cashier or a billing SDK, with your own Filament resources. tomato-saas-module makes the most sense if you are already inside the TomatoPHP and Filament ecosystem and want tenants, plans, and admin screens from one package. If you already own a tenancy model, adopting it risks maintaining two competing implementations.
- Is tomato-saas-module actively maintained, and how do I handle upgrades and security fixes?
- It is a single-maintainer project with a thin version history, so there is no evidence yet of a patch-release rhythm or a published security disclosure process. There is also no public CI status or test coverage to rely on, which means budgeting for your own tenant-isolation smoke tests. Pin an exact version, commit the lockfile, and mirror the repository internally so you can ship a fix if upstream stalls.