- Is tiben/crontab-manager a Laravel package?
- No. It is a framework-agnostic PHP wrapper around the Linux crontab binary and ships no service provider, facade, config file, or container bindings. If you adopt it in a Laravel app you will own a thin adapter layer consisting of a service class, a facade, and config of your own. Treat it as a vendored utility rather than a first-class Laravel dependency.
- How do I install and wire up crontab-manager in a Laravel application?
- Install it with Composer, then encapsulate it behind your own interface bound in a service provider so nothing outside that boundary imports the vendor namespace. The executing PHP/FPM user must be permitted to edit its own crontab, and you need a stable absolute path to the PHP binary. The library itself reads, parses, adds, and removes cron lines by identifier or comment, so keep entry namespacing consistent.
- Can I run crontab-manager in Docker, on Heroku or Lambda, or on a Windows dev machine?
- No, not without writing your own abstraction. The library shells out to the crontab binary, so it requires a POSIX host with cron installed. Containers, PaaS platforms such as Heroku and Lambda, and Windows development machines are non-starters as-is. The usual fix is a CronManager interface with a CrontabDriver for the one real host and a NullDriver or DatabaseDriver everywhere else.
- Why not just use Laravel's built-in task scheduler instead of this package?
- Laravel's native scheduler collapses to a single system cron entry running schedule:run and is the idiomatic answer for most scheduling needs. The crontab library is only justified in narrow cases such as per-tenant or per-user generated cron entries, or an admin UI where operators manage raw crontab lines. Ask first whether a database-driven schedule() loop can satisfy the requirement before adding this dependency.
- What are the security risks of letting users manage cron entries from a web UI?
- Every managed job becomes a shell command executed as the PHP/FPM user, so any user-supplied input that reaches a cron line is a command injection vector. A tenant able to write a cron entry could potentially read environment variables, hit internal endpoints, or persist on the box. Restrict who can create jobs, validate and escape all input, and run the scheduler under a dedicated unix user with minimal privileges.
- Does crontab-manager handle concurrent writes or locking?
- No. The crontab is a mutable shared resource and the library's model provides no locking, so two concurrent writes, such as two web requests or a request racing a deploy, can lose updates. You must serialize writes yourself with a mutex or flock. Also decide whether you have a single scheduler host or every app node, since that determines whether crontab is even the right substrate.
- What license does tiben/crontab-manager use?
- The license is reported as NOASSERTION, which is a hard procurement gate until legal confirms the LICENSE file against the declared terms. Do not merge or ship it until that review is cleared. Treat license confirmation as a prerequisite, not a follow-up task.
- Is tiben/crontab-manager actively maintained and safe for production?
- It has roughly 138 stars, zero dependents, and its last release was May 2023, with effectively a single maintainer behind it. That is a bus factor of one on a component that mutates production scheduling, so plan to vendor or fork it if you depend on it long term. Its low score reflects exactly that: a bounded utility, not a strategic dependency.
- How should I test and run local development with crontab-manager?
- Do not touch a real crontab in local dev or CI. Put the library behind your own CronManager interface and swap in a NullDriver or DatabaseDriver implementation for those environments. Only the single host that genuinely needs crontab writes should use the CrontabDriver wrapping this library. This also keeps the vendor namespace out of your application code.
- How do I migrate existing cron jobs to crontab-manager without breaking production?
- Baseline first: capture crontab -l from every target host and version it before any code writes to it, because automated writes onto an un-baselined crontab cause outages. Reserve a marker block such as BEGIN/END app-managed comments, refuse to touch anything outside it, and adopt a stable job-key convention in the comment field so removals are deterministic. Then parallel-run the manager alongside the static entries until parity is proven, cut over by removing the static ones, and enforce a reconcile at boot. Remember the crontab lives on the box, is invisible to infrastructure-as-code, and will not survive a rebuild.