Filament Log Manager Laravel Package

Getting Started

filament-log-manager gives a Filament panel a UI for browsing, reading, downloading and clearing the files in storage/logs. It removes the "SSH in and tail -f" step from everyday triage, which is where most of its day-to-day value sits.

Minimal setup:

1. composer require filipfonal/filament-log-manager
2. Publish the config (and translations, if you want to override any strings): php artisan vendor:publish --tag="filament-log-manager-config" php artisan vendor:publish --tag="filament-log-manager-translations"
3. Register the plugin on the panel you actually want it on — not necessarily the default one:

// app/Providers/Filament/AdminPanelProvider.php
use FilipFonal\FilamentLogManager\FilamentLogManagerPlugin;

public function panel(Panel $panel): Panel
{
    return $panel
        // ...
        ->plugin(FilamentLogManagerPlugin::make());
}

Where to look first: the published config/filament-log-manager.php. That is the single place that controls the navigation entry (group, label, icon, sort order, whether it registers at all), the resource label, the accepted file extensions, and the locale list used for the date picker. Read it before touching anything else — most "why is this page in the wrong place" questions are answered there.

First real use case: a report of a 500 on staging. Open the Logs page, pick laravel.log (or the relevant laravel-YYYY-MM-DD.log if the daily channel is in use), search for the exception class or request ID, and download the file if you need to correlate it with Sentry. If the log is stale, clear it from the same screen, reproduce, and re-read — that loop is the whole point of the package.

Implementation Patterns

Register on a restricted panel. The common production pattern is to add the plugin only to an internal/admin panel that already has tighter middleware and authorization, rather than to a customer-facing panel. Keep it out of any panel whose ->authGuard() is shared with end users.

Gate access explicitly. Navigation visibility is not authorization. If your panel doesn't already restrict by role, add a policy check or scope the panel's ->authMiddleware() / user canAccessPanel() so operators can view logs but support agents can't clear them. Treat the clear/delete action as a write operation, because it is.

Lean on the config for environment-shaped behaviour. If you keep log filenames in non-standard shapes, restrict which files are listed rather than relying on the operator to pick the right one. If you don't want the page at all in certain environments, publish the config and disable the navigation registration there — cheaper than conditionally registering the plugin.

Pair it with log channels, not instead of them. The page reflects whatever your config/logging.php writes to storage/logs. Single-file (single), daily (daily) and any custom path-based channels all appear; JSON/stack drivers writing elsewhere won't. If you need structured search, keep shipping logs to an external aggregator and use this package for the fast, low-friction look-at-the-raw-file case.

Localization (new in 3.0.1). Portuguese translations were added. Day-to-day, this means a panel with ->locale('pt_BR') or an app locale of pt / pt_BR gets translated UI strings out of the box. If you had previously published translations to hand-translate those strings, re-publish or diff against the new file so you don't shadow the upstream additions with an outdated copy.

Workflow to standardize on your team. Triage → read → download if needed → fix → clear → verify the fix produces no new entries. Document the clear step as destructive; it permanently deletes the file from the log directory.

Gotchas and Tips

• Permissions are the number one failure. The PHP-FPM user must be able to read (and, for delete, write) the files in storage/logs. A page that lists nothing is usually a permissions or path problem, not a plugin bug.
• Clearing is destructive and unrecoverable. There is no trash. On production, prefer rotating or archiving over clearing, and keep the log shipped off-box first.
• Large files are slow. A multi-hundred-megabyte laravel.log will be painful to open in a browser tab and can hit memory limits. daily channel plus sane retention (days in config/logging.php) keeps this manageable; truncate or download-and-delete when it's already out of hand.
• Ephemeral containers. On containerized/read-only-filesystem deploys the logs may live on the container, not a shared volume — the page will show a different (or empty) set of files per replica. Point the log path at a mounted volume, or accept that this tool is for long-lived VMs and local dev.
• Config caching. After publishing or editing the config, run php artisan optimize:clear (or at minimum config:clear). Stale cached config is the classic reason a navigation change "didn't apply".
• Missing translations look like bugs. 3.0.1 adds pt only; other locales fall back to English. If a string is untranslated, publish the translations and add it rather than assuming the package is broken — and clear the cache afterwards.
• Extension point: if you need different rendering (e.g. a custom filter bar or a link out to your log aggregator), publish and override the package views rather than forking. Combined with a small custom Filament page wrapping the same model, this covers most "I wish it also did X" requests without pinning yourself to a package version.
• Version pinning. This is a 3.x line targeting Filament v3. Upgrade this package alongside Filament, not independently, and skim the changelog for the Filament major you're on — 3.0.1 itself is a purely additive translation patch with no breaking changes or deprecations, so it's a safe minor bump.