Laravel File Manager: a file browser bolted onto your Laravel app through Flysystem
File manager for Laravel
At a glance
- What is it?
- This package gives a Laravel application a file management interface backed by Laravel Flysystem disks, with ACL, WYSIWYG editor integration and a separate Vue.js frontend. Its scope is fixed at version 3, which supports Laravel 9, 10 and 11 only.
- Who is it for?
- Adopt this package when your Laravel application needs users to manage files through a browser on the disks you already configured, and you want per-path access control plus a picker for CKEditor, TinyMCE or SummerNote. Do not adopt it if you need Laravel 12, a bundled frontend, or storage outside Flysystem.
- Can I use it commercially?
- Yes. MIT is a permissive licence: you can use, modify and sell software built on it, as long as you keep its copyright and licence notices.
- Is it still maintained?
- Yes. The repository last received commits 164 days ago.
- What is it written in?
- Mainly PHP, according to GitHub's language statistics.
Answers come from the project's GitHub data, last synced on October 23, 2026, and from our analysis. They are not legal advice.
Editorial analysis
A file browser for people who are already inside your Laravel app
Laravel File Manager is a package that attaches a file management interface to an existing Laravel application. The problem it addresses is narrow and real: an application that stores uploads through Flysystem has files on disk, but no way for an authenticated user to browse, rename, copy or delete them. This package supplies that interface, along with the pieces that make it usable in a product rather than a demo.
The audience is a Laravel developer who already has an application with a storage layer and wants to add user-facing file management to it. It is not a standalone admin panel, a backup tool, or a sync client. The routing, authentication and Blade layout come from the host application, and the package contributes the file manager behaviour.
The stated set of display options is worth noting because it affects integration. You can run it as a one-panel view, as a one-panel view with a directory tree, or as a two-panel arrangement. The two-panel form is the familiar dual-pane browser, and choosing between them is a configuration decision in the host application rather than a rebuild.
The frontend is not included in this repository. The README points at a separate project, alexusmai/vue-laravel-file-manager, described as a Vue.js frontend, and the version 3 notes specify Vue.js 3 with Bootstrap 5 and Bootstrap Icons. So this repository is the Laravel side: disks, ACL, events, permissions and the API, with the browser application living elsewhere.
Everything runs through Flysystem disks, and only the disks you allow
The mechanism is Laravel Flysystem, the framework's filesystem abstraction. The README says work with the file system is organized by the standard means Laravel Flysystem, listing local, (S)FTP, S3 and Dropbox among the adapters. This is the single most consequential design decision in the package, and it cuts both ways.
On the good side, the package inherits everything your Laravel application already knows about disks. If a disk is configured in the host application, the file manager can work with it, and you do not write storage code twice. Local disk support also matters for a specific reason: the zip and unzip operations are documented as working only for local disks, so the archive feature is unavailable the moment you move to S3 or an SFTP server.
The second half of that design is scoping. The package supports working only with the selected disks, meaning the set of disks the file manager may touch is a configuration choice, not the full set the application happens to have registered. That control matters for a package whose whole job is to expose file access to users, and it pairs with the ACL layer described below.
The practical consequence is that anything the Flysystem abstraction cannot express is out of reach. The README does not describe support for streaming to arbitrary destinations, on-the-fly resizing of stored objects, or lifecycle policies on the underlying storage, and it does not document how the package behaves when an adapter returns an error mid-operation, for example a partial multi-file upload. Those are the areas to probe during evaluation.
The ACL layer decides what a user can even see
Access control is a first-class feature rather than an afterthought bolted on top. The ACL documentation covers delimiting access to files and folders, and offers two work strategies that are worth reading carefully because they are opposites. In blacklist mode, everything is allowed that is not forbidden by the ACL rules list. In whitelist mode, everything is denied that is not explicitly allowed by the rules list. The whitelist mode is the safer default for a multi-tenant application, and the blacklist mode is the one that will surprise you.
Rules can come from more than one place. The README says you can use different repositories for the rules, with an array in the configuration file as one option, a database as another with an example implementation provided, or your own implementation. The database route is the one that scales with a growing user base, and the example implementation in the repository gives you a starting point rather than requiring you to design the schema from scratch.
The ACL also handles visibility. The README states you can hide files and folders that are not accessible, so an unauthorized path is not merely refused on operation but kept out of the listing. That distinction matters for a file browser: a user who cannot see a folder should not learn it exists from a directory listing, and a denial that only fires on the action leaks the structure anyway.
What the ACL does not appear to cover is role modelling. The documentation describes rules and strategies but not a user and role model, and the repository's examples folder contains a wysiwyg example rather than a multi-tenant permission model. If your application already has roles and permissions, expect to write the bridge between them and the ACL rules yourself.
Getting it into a Laravel app: the docs are the install instructions
The installation steps are not written out in the README. The README links to a documentation set in the docs folder, with separate pages for installation, configuration, integration, ACL, events and update. The package itself is distributed through Packagist under the name alexusmai/laravel-file-manager, and the README links to that package page for the current stable version, the latest unstable version, the licence and the required PHP version. That badge link is the place to confirm the PHP constraint for your environment before you start.
Because the README does not give the commands themselves, this section stops short of inventing them. Read docs/installation.md, then docs/configuration.md, then docs/integration.md in that order.
The repository layout tells you what a configuration step is likely to involve. There is a config/ directory at the top level, alongside src/ for the package code, resources/ for views and assets, migrations/ for the database tables, and docs/ for the guides. The presence of migrations means at least some parts of the package, in particular the database-backed ACL example, require schema changes applied through your application's migration flow rather than a one-line setup.
The docs/index.md file is the entry point listed in the README, and it links to each of the six topic pages. Everything you need to run this in production is in that folder, and none of it is in the README, so treat the docs rather than the README as the source of truth during evaluation.
The feature set beyond the file operations themselves
The core operation set is the familiar one: creating files, creating folders, copying and cutting folders and files, renaming, multi-file upload, downloading, and two display modes for elements, table and grid. Image preview, image viewing and a full screen mode round out the browsing experience.
Version 2 added a set of richer operations, and the exact dependencies matter because they determine what you are pulling into your application. Audio playback for mp3, ogg, wav and aac, and video playback for webm and mp4, both use Plyr. The code editor uses CodeMirror. The image cropper uses Cropper.js. Zip and unzip round out the list, and as noted earlier, they are limited to local disks.
The WYSIWYG integration is the feature most likely to be the actual reason you install this package. The README lists CKEditor 4, TinyMCE 4, TinyMCE 5, SummerNote and a standalone button as supported editor targets. In practice this means a browse button in the editor that hands back a URL, which is the piece that is painful to build by hand. If you are on a different editor, the standalone button option is the fallback.
Two smaller items complete the list. Thumbnails load lazily, which matters for large directories, and sixteen locales are supported, including ru, en, ar, sr, cs, de, es, nl, zh-CN, fa, it, tr, fr, pt-BR, zh-TW and pl. Events were added in version 2.2 and dynamic configuration in version 2.4, both of which let the host application react to file operations and change behaviour at runtime, though the README does not list the event names.
Version 3 narrows the Laravel range and moves the frontend out
The version boundary is the most consequential fact for anyone considering this package today. The README states plainly that version 3 only works with Laravel 9, 10 and 11. That is a three-major-version window, and a Laravel application that has moved past 11 is outside the supported range.
The release history shows how the package has tracked the framework. Release 3.2.0 added Laravel 11 support and was published on 2024-05-11. Before it, v3.0.5 carried Laravel 10 support and was published on 2023-02-26, and v3.0.1 was published on 2022-02-20. Each framework generation appears to have been met with a release, which is a pattern of a maintainer who responds to framework upgrades rather than a fixed release schedule.
The repository is not archived, and the last push was on 2026-05-12, which is more recent than the 3.2.0 tag. The most recent tagged release in the list is still 3.2.0 from 2024-05-11, so there is work in the tree that sits outside a published tag, and the docs include a dedicated update page that you should read before running an upgrade in an environment you care about. The README does not document a rollback procedure for either the package version or the framework version.
The licence is MIT, and the repository carries a LICENSE.md alongside a CONTRIBUTING.md, so the terms are the permissive ones and there is a stated contribution process. Version 3 also brought Vue.js 3, Bootstrap 5 and Bootstrap Icons, so the frontend has its own upgrade surface that is versioned separately from the Laravel package.
Editorial conclusion
Adopt this package when your Laravel application needs users to manage files through a browser on the disks you already configured, and you want per-path access control plus a picker for CKEditor, TinyMCE or SummerNote. Do not adopt it if you need Laravel 12, a bundled frontend, or storage outside Flysystem. Verify first that your Laravel version falls inside 9, 10 or 11, that the ACL rules match the permission model of the underlying disk, and that the separate vue-laravel-file-manager frontend can be deployed alongside your application.
Frequently asked questions
Which Laravel versions does Laravel File Manager support?
The README states that version 3 only works with Laravel 9, 10 and 11. Release 3.2.0, published on 2024-05-11, added Laravel 11 support, and the release before it carried Laravel 10 support.
Where do I get the frontend for Laravel File Manager?
The frontend lives in a separate repository, alexusmai/vue-laravel-file-manager, and the Laravel package here is the backend side. Version 3 uses Vue.js 3 with Bootstrap 5 and Bootstrap Icons.
Can Laravel File Manager manage files on S3 or FTP?
File access goes through Laravel Flysystem, with local, (S)FTP, S3 and Dropbox listed among the adapters, and you can restrict the file manager to selected disks. The zip and unzip operations are documented as working only for local disks.
How does the ACL block unauthorized access?
The ACL supports a blacklist strategy that allows everything not forbidden, and a whitelist strategy that denies everything not explicitly allowed, with rules held in an array, in a database with an example implementation, or in your own repository. You can also hide files and folders that are not accessible rather than only refusing the operation.
Official sources
Add this badge to your README
If you maintain this project, the badge below links readers to this analysis and shows its maintenance status from the daily GitHub snapshot. Paste the markdown into your README; add ?metric=license or ?metric=stars to the image URL for a different field.
[](https://hysenlabs.com/projects/alexusmai-laravel-file-manager)Was this useful?