- How do I install tomatophp/filament-browser in a Laravel app?
- Install the package with Composer using composer require tomatophp/filament-browser, then run php artisan filament-browser:install to publish its assets and configuration. Finally, register FilamentBrowserPlugin::make() in your Filament panel provider, for example inside AdminPanelProvider, and configure hidden folders, files, and extensions as needed.
- Which Filament and Laravel versions does filament-browser support?
- The current release targets Filament v5 on Laravel 12 and 13. Projects still on Filament v3 must stay on the package's v3 branch, which is a maintenance branch rather than an upgrade path. Filament v4 support is not addressed in the release notes, so confirm compatibility before planning an upgrade.
- Can I upgrade filament-browser from Filament v3 or v4?
- If you are on Filament v3, treat the v3 branch as your supported line and do not assume the v5 release is a drop-in replacement. Upgrading also changes the authorization contract because the developer gate and authorize() callback now run on every Livewire request, not just at page load. Any published views that referenced the old third-party code field must be reworked for Filament's CodeEditor, and you should run your own regression tests around file operations and access control.
- Is filament-browser safe to use in production?
- The package is explicitly intended for super-admins only because it grants access to files and folders on your server. It now includes root confinement with realpath checks, default .env hiding, server-side enforcement of allow options, and per-request authorization, which addresses the main earlier risks. Safety still depends on configuration: use a narrow root, keep hideEnvFiles enabled, and write a strict authorize() policy.
- How do I restrict which folders and files the browser can access?
- Configure the browser root and use the hiddenFolders, hiddenFiles, and hiddenExtensions options to exclude sensitive paths and file types. The package enforces confinement server-side with realpath checks and rejects parent-directory traversal, absolute paths, null bytes, and symlinks that escape the root. Set the root as narrowly as possible rather than pointing it at your project base path.
- What does hideEnvFiles do in filament-browser?
- hideEnvFiles hides .env files from the browser and is enabled by default. Setting it to false reopens the risk of exposing environment secrets, so it should remain enabled in production unless you have a very specific and controlled reason. Pair it with hiddenFiles entries for other sensitive configuration files.
- How does the authorize() callback work in filament-browser?
- The authorize() callback is checked on every Livewire request, along with the developer gate, instead of being evaluated only when the page loads. This is architecturally stronger because a stale UI cannot bypass the current policy, but it is only as reliable as the callback you write. Return true only for the specific super-admin users or roles who should manage server files.
- Does filament-browser work with S3 or FTP storage disks?
- Path confinement is realpath-based, which is a local filesystem concept, so non-local disks such as S3 or FTP will not receive equivalent enforcement from realpath alone. If you use custom adapters, validate how paths are resolved and assume confinement is weaker until proven otherwise. Most users should keep this package pointed at a local filesystem root.
- Do I need creagia/filament-code-field or Monaco with filament-browser?
- No. The package now uses Filament's built-in CodeEditor instead of creagia/filament-code-field, removing that transitive dependency and aligning with Filament's asset pipeline. If your project previously imported a Monaco bundle manually for this package, clean up that asset pipeline to avoid double-loading or stale bundles. Custom views that referenced the old code field must be updated.
- How do file previews work and do they affect performance?
- Previews are embedded through the application rather than copied into public storage, which removes a public-exposure vector. The tradeoff is that preview bytes pass through your app, so large files, including supported htm content, can increase memory use and response size. Sanitize rendered htm output and test with realistic large media files before relying on previews in production.