husam-tariq/filament-database-schedule
A Filament plugin for managing Laravel scheduled tasks stored in the database. Create, edit, pause, and delete cron jobs from a visual panel interface, with run history and task logs, without touching code or redeploying.
Architecture fit. The package targets Laravel applications that already run Filament as their admin surface. It shifts task scheduling from statically declared code (Kernel.php / routes/console.php) to a database-backed model exposed through a Filament resource. That is a governance-relevant architectural change, not merely a UI convenience: schedule definitions move from a version-controlled, code-reviewed artifact into mutable runtime data. It fits well where operations or admin staff genuinely need to adjust cadence without a deploy (content sync, report generation, cache warming, notification digests). It fits poorly where schedules are treated as infrastructure-as-code, where change control requires peer review and diffable history, or where an auditor must reconstruct "what ran and who changed it" from source control. Treat the adoption decision as "do we want scheduling to be a data-driven capability with an admin surface," not "do we want a nicer UI."
Integration feasibility. Mechanically low-friction: Composer install, register the plugin on a Filament panel provider, publish and run the migration, then define schedules through the UI. The real feasibility question is coexistence. Any application already defining schedules in code must establish whether this package augments the existing scheduler or supersedes it; if both paths remain active, the same logical job can be registered twice and run twice. Confirm how the package hooks into the scheduler (service provider boot, Schedule facade extension, or a replacement schedule:run entry point) before assuming a clean swap. The host application's server-level cron entry invoking schedule:run remains mandatory — the package does not remove that dependency, and teams frequently misread a UI-driven scheduler as eliminating operational cron setup.
Technical risk. The dominant risk is maturity and bus factor. At roughly 104 stars with a narrow maintainer base, this is a single-maintainer dependency sitting directly on the critical path of all background processing. A regression, an abandoned release, or an incompatibility with a new Filament or Laravel major version can silently stop scheduled work — a failure class that is notoriously slow to detect because nothing throws; jobs simply do not run. Secondary risks: framework version compatibility across the Filament v3/v4 and Laravel 10/11/12 matrix, cron-expression validation quality (a malformed expression entered via UI may be accepted and never fire), timezone semantics between the DB-stored schedule, the app config, and the server, and authorization on the Filament resource — schedule editing is effectively privileged execution control and must not inherit permissive default panel access.
Key questions.
withoutOverlapping, mutexes, and onOneServer semantics for multi-node deployments?Stack fit. Appropriate only for Laravel + Filament hosts. For a TALL-stack product where Filament is already the operational console, this is a natural adjacency: the same audience that manages content and users gains schedule control. For headless APIs, non-Filament admin surfaces, or polyglot estates, the value proposition collapses to "a DB-backed scheduler," which is better served by a lighter, more established library or a thin in-house model plus a console command.
Migration path. Do not cut over in one step. (1) Inventory every existing schedule entry — command signature, cadence, constraints (withoutOverlapping, onOneServer, runInBackground), and business criticality. (2) Classify: safely admin-editable (low blast radius, tolerant of cadence drift) versus must-remain-in-code (billing, compliance exports, anything with downstream SLAs). (3) Install and publish in a non-production environment and observe one full scheduling cycle. (4) Migrate the low-risk tier first, with the code-defined entry removed in the same commit that adds the DB record — never leave both live. (5) Keep critical schedules in code indefinitely unless there is a demonstrated operational need. Maintain a documented list of "DB-managed schedules" as a controlled artifact so the team retains an inventory that source control no longer provides.
Compatibility. Verify against the exact pinned versions in the host: PHP minor, Laravel major, Filament major, and the production database engine (MySQL/Postgres/SQLite behave differently around timezone-aware columns and JSON payloads). Filament plugins are especially sensitive to major-version drift because panel registration APIs have changed across releases; a Filament upgrade is a re-validation event, not a routine bump.
Sequencing. Foundation first (composer, plugin registration, migration, CI green) → governance second (authorization policies, audit expectations, naming conventions for schedule records) → pilot third (two or three low-risk schedules in a staging environment across several days) → cutover fourth (remove corresponding code entries) → observability last but before broad rollout (alerting on missed expected runs, since the package is unlikely to provide it). Budget explicit time for the observability work; it is the step most often skipped and the one that determines whether failures are caught in minutes or weeks.
Maintenance. Pin to an exact version and treat upgrades as reviewed changes, not automatic. Assume you may need to fork or vendor the package if the maintainer goes dormant; the mitigation is a small surface area (one resource, one model, one service provider) and a documented exit plan: drop the plugin, retain the table, and read schedules into code. Assign clear ownership — a package on the scheduling critical path without a named owner is an unmanaged single point of failure.
Support. Community-only, MIT, no SLA, no vendor escalation. Internal teams must be capable of reading the source and patching it. That is a reasonable trade for a UI convenience layer and an unreasonable one if the team cannot dedicate Laravel engineers to it.
Scaling. The per-run overhead is a single database read plus schedule registration, which is negligible at hundreds of schedule records and irrelevant at tens. The genuine scaling concerns are elsewhere: schedule:run is invoked once per minute, so cadence granularity is capped at one minute; multi-node deployments require onOneServer semantics or the schedules execute on every node; and long-running jobs entered with a tight cadence will overlap unless the package surfaces Laravel's overlap and mutex controls. Confirm which of those constraints the package preserves before relying on it for anything with a runtime approaching its interval.
Failure modes. Enumerate and pre-mitigate: database unavailable at schedule:run time means no schedules register and all work silently halts; malformed cron expressions accepted by the UI produce jobs that never fire; an unauthorized or accidental edit changes a production cadence with no diff to review; removal or rollback of the package leaves the table intact while schedules stop executing, with no error surfaced; timezone drift between stored schedule, app config, and server shifts execution windows in ways that are invisible until a downstream consumer notices stale data. The unifying characteristic is silence — every one of these fails without an exception. Instrument for it: alert when an expected job has not produced its observable side effect within its cadence window, independent of what the package reports.
Ramp-up. Low for engineers already fluent in Filament, who will read the resource and service provider in under an hour. Higher for the operations audience actually using it: they need a runbook covering what a schedule record means, which fields are safe to change, what "cron expression" means in practice, and who to contact when a job stops producing output. Allocate a short training session and a written "how to verify your schedule is running" procedure — the operational cost of this package is concentrated not in installation but in teaching non-engineers to change production execution behavior responsibly.
How can I help you explore Laravel packages today?