- How do I install hedii/artisan-log-cleaner in a Laravel app?
- Install it with Composer by running composer require hedii/artisan-log-cleaner. The package ships a service provider that Laravel's package auto-discovery registers automatically, so no manual provider entry is needed in most applications. From there you can optionally publish the config file to pin the log directory and file extension before running the command. There is no migration, no environment variable, and no runtime dependency to configure.
- Which Laravel and PHP versions does this log cleaner support?
- The package is a small service-provider plus command package, so it generally tracks the Laravel majors it declares in its composer.json constraints. Check the require block on Packagist or in the repository for the exact illuminate/support and PHP version bounds of the release you plan to install. Pin the version in composer.json and let the lock file govern so a routine composer update does not silently shift compatibility. Re-validate the package as part of your normal framework-upgrade checklist, because service-provider and command-signature conventions do change between majors.
- How do I schedule the log cleaning command to run automatically?
- Register the command in your scheduler, either in routes/console.php on Laravel 11+ or in the console kernel's schedule method on older versions, using the command's signature and a frequency such as daily or weekly. Because the command only touches local files, it runs happily inside the standard schedule:run cron entry. Enable it in staging for one full retention cycle first and watch the disk-usage trend before rolling it out to production. If your logs are shipped to a central sink, confirm the schedule does not delete buffers before they are collected.
- Can I change which log directory and file extension the command targets?
- Yes. The package lets you publish a config file where you set the target directory and the file extension it should match, which means you can point it at storage/logs or constrain it to a dedicated subdirectory. Set these values explicitly rather than relying on defaults, so the deletion scope is exactly what you intend. Scoping the command to a narrow subdirectory is the simplest way to avoid collateral deletion of anything else living under storage.
- Will it delete the currently active log file while Laravel is still writing to it?
- The command operates on files it finds in the configured log directory, so whether the in-progress file is included depends on your retention settings and file matching. Before enabling it on a schedule, run it manually in staging with a before-and-after directory listing to see exactly which files disappear, including the current daily file. On Linux, deleting a file that a process still holds open does not break writes, but it does mean those buffered entries are lost from disk. If preserving the active log matters, target only rotated files by name pattern or retention age.
- Is there a dry-run mode so I can preview what will be deleted?
- There is no documented dry-run flag, so the safe approach is to validate outside production. Copy a representative set of log files into a staging directory, point the config at it, run the command, and diff the directory listing before and after. Repeat that on a real staging host before you trust it on an unattended schedule. Because deletions are irreversible, that manual inventory step is worth doing once per environment.
- What is the risk of misconfiguring the log cleaner in production?
- The blast radius is small but the consequence is high: the command deletes files permanently, with no recycle bin and no undo. The main hazard is scope, so verify the directory, file pattern, and retention rule explicitly instead of accepting defaults. Keep your configured path as narrow as possible, and never point it at a directory that holds anything other than disposable log files. Filesystem-level snapshots or backups on the log volume are cheap insurance during the first production cycles.
- Does this package replace Laravel's built-in daily log rotation?
- No. Laravel's logging configuration, including the daily driver and its retention days setting, still governs how logs are rotated and how many channel-specific files are kept. This package is a housekeeping utility that sits alongside that, cleaning up files in the log directory on a schedule you control. If the daily channel's own retention setting already handles your needs, the package may be redundant. It becomes useful when you have accumulated files from multiple channels or historical naming schemes that Laravel does not prune.
- How does it behave on multi-server or autoscaled deployments?
- On a multi-host fleet, the scheduled command runs per host and only deletes files on that host's local disk. Whether that is correct depends entirely on your logging architecture: it is fine if each node keeps its own local logs, but redundant if logs are shipped to a central sink such as CloudWatch, Loki, or Papertrail. In container-native setups where applications write to stdout and stderr, the package has nothing to clean and can even be harmful if it deletes files before a sidecar ships them. Confirm your logging topology before enabling it.
- Is the package actively maintained, and what if it gets abandoned?
- It is MIT licensed with a recent release, but the maintainer base is narrow and the star count is modest, so abandonment risk is real and worth pricing in. The upside is that the code surface is tiny, roughly a service provider plus one command, so forking it or reimplementing the behavior with a short custom command using File::delete over storage/logs is a same-day task. Pin the version in composer.json so an unmaintained release does not break unexpectedly on a framework upgrade. Keep the custom-command fallback in mind as your exit path rather than a rewrite.