Laravel Enso: a Laravel and Vue admin boilerplate

An application you clone, not a package you install

The positioning is the classic boilerplate pitch. Hit the ground running when building your new Laravel SPA project with boilerplate and extra functionality out of the box.

The stack is stated plainly at the bottom of the readme: it was crafted on Laravel 5.6, Bulma 0.6 and Vue 2.5, with Vue Router, Vuex and Axios in the front end, plus Font Awesome 5, Animate.css, Bulma Extensions, Driver.js, Chart.js and Flatpickr. The project credits Taylor Otwell, Jeffrey Way, Evan You and Jeremy Thomas, which is a way of saying that the pieces are familiar ones assembled by someone else.

What makes this different from a bare Laravel install is the amount of admin scaffolding that arrives with it. The topic list gives the hint: admin, boilerplate, SPA, Vue, Vue Router, Vuex. There is an entities layer, a users and roles layer, and a front end that already knows how to talk to it.

The documentation is split into backend and frontend, hosted on a separate documentation site, and the readme notes that most sections have short demo clips. The live demo installation is at the project's own site, and the readme gives the credentials for it, which is an unusual thing to publish and a useful thing to try before you commit an afternoon to setting the project up locally.

Ten steps from clone to login

The installation instructions are numbered and specific, which is what you want from a boilerplate.

git clone https://github.com/laravel-enso/enso.git --depth 1
composer install
php artisan key:generate
php artisan migrate --seed

The clone is shallow, which is a sensible choice for a repository you are about to fork rather than contribute to. The database step comes from the Laravel documentation, and the instruction is to create a database, copy or rename the environment example file to the environment file, edit the database configuration information, and generate the application key.

The API is served with the standard Laravel local development server, and the readme points at that section of the Laravel documentation and suggests considering Valet for a better experience.

Then the front end, which is a separate application with its own environment file:

yarn && yarn build

The client folder has its own environment example, which you copy to an environment file and set the back end API URL in. Step eight is to launch the site and log in with the published demo user, and step nine is to run the serve command for live reload and hot module replacement:

yarn serve

Step ten is the one that separates this from a tutorial. The configuration files live in a directory of PHP configuration files under the config directory, named for the project, and you set them up as needed. That directory is the extension point, and the fact that the configuration is a set of PHP files rather than a pile of environment variables means it can hold logic.

The seeding step is what creates the admin user, the roles and the sample entities, so the migrate with seed command is doing a lot of the work here.

The demo credentials are a warning, not a convenience

The demo login is published in the repository description, in the installation steps and in the take it for a spin section, and it is the same account everywhere: the admin address at the project domain, with the password.

That is entirely reasonable for a demo instance, and it is a very common source of trouble in derived projects, because the seeded admin account often survives into production. The readme's own step eight tells you to log in with those same credentials in your own local install, which means a fresh clone has a known admin password before you have written a line of code.

The environment file gives you the tools to fix that, and they are worth reading before you deploy. There is a login attempts per minute setting, set to 5 by default, which is a rate limit on the login endpoint and a sensible default that a lot of hand-rolled admin panels lack.

There is also a password policy expressed as environment variables: a password lifetime, currently 0, a minimum length set to 6, and three switches for mixed case, numeric and special characters, all of which default to 0, meaning off. A minimum length of 6 with no complexity rules is a weak default for an admin panel, and those four variables are where you tighten it.

If your deployment is a single tenant application, changing the seeded admin credentials and raising that minimum length are the two changes to make before the first login in production.

Docker for local development, and what it wires together

There is a compose file at the root, and it describes a three service development environment.

    container_name: enso
    restart: unless-stopped
    working_dir: /var/www/html

The PHP service builds from a Dockerfile in the docker directory, runs Apache, exposes port 80 as port 8000 on the host, mounts the project into the container, and mounts a virtual host configuration file into the Apache sites directory so the local domain resolves properly. The database host and the Redis host are set as environment variables, and the environment file is loaded into the container.

The MySQL service uses the version 8 image, takes the database name, user and password from the environment file, and has a health check that pings the server as the root user with an interval of 10 seconds, a 5 second timeout and 10 retries. The PHP service depends on MySQL with the condition that it is healthy, and on Redis with the condition that it has started, which is the difference between waiting for a database to accept connections and waiting for it to be ready to serve queries.

The Redis service is the simplest of the three, and the data volume for MySQL is a named volume so the database survives a compose down.

There is also a commented-out phpMyAdmin service in the file, which is the sort of thing that gets left in place for convenience. It is worth noticing that it is there at all, since the pattern of a web database client on a development port is a common one to copy into a production compose file by accident.

The environment file is bigger than a Laravel default

The environment example is where the framework's assumptions show, and it is a longer file than a stock Laravel one.

Beyond the usual application name, environment, key, debug flag, URL and locale settings, there is an owner company identifier, set to 1, which tells you that the entities are partitioned by company. That is the multi-tenant shape of the data model, and it is the single most important thing to understand before you start writing your own entities, because everything else inherits from it.

The password and login settings we have already covered. The mail configuration covers a generic SMTP mailer with a Mailtrap host as the default, plus Mailgun and S3 credential variables, and a Sentry DSN for error reporting.

The session and cache configuration is mostly stock, with the file driver for sessions and a 120 minute lifetime, and the broadcast connection set to log rather than to a real broadcaster, which is the right default for a project you have just cloned.

The Redis client is the phpredis extension rather than a pure PHP client, so the extension has to be installed in your PHP runtime, and the port and password are set here. The queue connection is the database driver, so queued jobs go into the database rather than needing a separate worker queue at the start, and Telescope, the Laravel debug panel, is disabled by default.

Two entries are worth a second look. There is an API token variable, empty by default, which is presumably the shared secret the front end uses to talk to the API. And the Sanctum stateful domains list already contains the local development hostnames including the port 8000 that the Docker setup exposes, which tells you the authentication is Sanctum based, with a token for the front end and cookie based stateful domains for the browser.

Paid support, sponsorship and the release cadence

This is a project with commercial ambitions around it, and the readme is upfront about that.

While developing Enso, the maintainers say they constantly received private inquiries from developers and teams asking about paid support, some of which led to fruitful collaborations, so they launched a support option. The packages start at 480 euro per month with 8 hours included. The list of what you get is specific: a private repository on their self hosted GitLab instance, priority on issues, help with understanding the environment, help becoming proficient, mentoring, code reviews, general advice on Laravel and Vue, assistance on version upgrades, up to 4 hours a month of remote desktop sessions and calls, and direct communication over Slack during office hours. The support is provided by a team of four.

The project is also backed by Earthlink, and there are Open Collective badges for backers, sponsors and contributors, so the funding model is mixed between a corporate sponsor, individual backers and paid support.

The release history follows the Laravel majors closely, with version 7 in January 2025, version 8 in March 2026 and version 9 in April 2026, which is the pattern of a boilerplate that tracks the framework it is built on.

That is why the readme puts a changelog link near the top with the instruction to consult it on every update if you are using the project. A boilerplate that jumps major versions with the framework will have breaking changes in the scaffolding, the entities and the front end, and the changelog is where they are written down. The last push was on 2026-08-11 and the repository is not archived, and the licence is MIT.

Editorial conclusion

Laravel Enso suits a team that wants an admin panel with the usual entities, menus and access control already built, and that is happy to take the front end as it comes rather than design their own. It is a poor fit if you need a modern front end stack, since the shipped client is on Vue 2 and the project itself is candid that a major upgrade means checking the changelog first. Before you build on it, read the changelog for the version you are moving to, replace the demo credentials and the default password policy before the first deploy, and confirm that the Laravel and PHP versions in your environment match the one the boilerplate was crafted on.

Frequently asked questions

Official sources

1. laravel-enso/enso on GitHub
2. License: MIT
3. Project website
4. README
5. Releases