thedevdojo/genesis: A Laravel Folio and Volt Starter Kit

What Genesis assembles for a new Laravel application

thedevdojo/genesis solves the initial assembly problem faced by developers starting a Laravel application around Folio and Volt. Instead of supplying only Laravel's default structure, it presents a starter application that already contains public pages, authentication views, an authenticated dashboard, profile management, shared layouts, and reusable Blade UI components. The intended audience is a Laravel developer who wants to begin with the TALL Stack components already connected rather than selecting and wiring each layer independently.

The stack combines Laravel with Tailwind CSS, AlpineJS, Livewire, Folio, and Volt. Blade remains the primary language for pages and components, while Folio maps files under `resources/views/pages` to routes. The repository also includes `artisan`, `config/`, `database/`, `routes/`, `tests/`, and the usual Laravel application directories, which makes it more than a collection of visual templates.

The starter creates 11 documented routes. They cover `/`, `/about`, `/dashboard`, `/learn`, `/profile/edit`, and six authentication paths. That scope is enough to demonstrate authentication and authenticated application screens, but it is not a full business application scaffold. Billing, teams, roles, API scaffolding, model factories beyond the repository contents, and other domain-specific systems are not documented. Developers expecting those features should treat Genesis as a UI and application foundation that still needs substantial product-specific work.

How Folio turns Blade pages into application routes

Genesis relies on file-based routing rather than defining every screen through a conventional route controller file. The README identifies `resources/views/pages/index.blade.php` as the homepage and states that Folio maps this page to `GET /`. The same mechanism maps the authentication files under `resources/views/pages/auth` to paths such as `/auth/login`, `/auth/register`, and `/auth/password/reset`.

Middleware is attached directly in the relevant page files. The homepage includes the following declaration:

middleware(['redirect-to-dashboard']);

According to the README, this redirects an authenticated visitor from the homepage to the dashboard. Removing that line changes the homepage behavior for signed-in users. The dashboard and profile editor instead use both Laravel's authentication and verification checks:

middleware(['auth', 'verified']);

This page-level arrangement is a central part of the starter's design. A developer can see access behavior beside the Blade page that needs it, although the README does not provide the implementation of the custom `redirect-to-dashboard` middleware. The repository's `app/` directory is the place to inspect that behavior before relying on it.

Route discovery remains available through Laravel's Artisan interface. Folio owns the page mapping, but `php artisan folio:list` gives an inventory of the generated route files. This makes routing visible without requiring the developer to infer every URL only from directory names.

Installing Genesis and launching its first asset build

The README directs users to the Laravel Installer and gives one command for creating a new project from the `devdojo/genesis` package. This is the documented installation path; it does not instruct developers to clone the repository manually.

Use the installer to create `my-app` with the Genesis package:

laravel new my-app --using=devdojo/genesis

The installer command is responsible for obtaining the starter and creating the application. The README does not separately document `composer install`, database migrations, application-key generation, or copying `.env.example` to `.env`, so it would be inaccurate to present undocumented setup commands as part of Genesis's official procedure.

After installation, the README says to run the asset watcher during development:

composer run dev

The corresponding `composer.json` scripts can confirm that this is a long-running development command rather than a production build. `package.json` defines `dev` as `vite` and `build` as `vite build`. Consequently, `composer run dev` is the command associated with watching and developing assets, while the production asset command documented by `package.json` is `npm run build`. The README itself explicitly mentions only `composer run dev`.

A practical first check is route discovery after the new application is created:

php artisan folio:list

The documented output should list 11 GET routes, including `index.blade.php`, `login.blade.php`, `dashboard/index.blade.php`, and `profile/edit.blade.php`. Seeing those entries confirms that Folio has discovered the starter pages. The command does not prove that the pages function, but it provides a concrete first inspection point tied to Genesis's routing model.

Authentication, dashboard behavior, and profile editing

Genesis includes a conventional account flow rather than leaving authentication entirely to the adopter. The documented pages cover login, registration, email verification, password confirmation, password reset, and the password reset token URL. Their files live under `resources/views/pages/auth`, and Folio supplies the corresponding paths.

The `/dashboard` page is intentionally minimal according to the README. Its `auth` and `verified` middleware prevent access until the user is authenticated and verified. The same restriction applies to `/profile/edit`. That page provides three distinct account operations: changing name and email, changing the password, and deleting the profile. Further behavior is delegated to a linked project wiki, so the README alone does not establish validation rules, authorization nuances, or implementation details for those operations.

The `/learn` page is also starter-specific rather than a general application feature. It fetches `README.md` and displays it inside the application. That behavior can be useful while evaluating or demonstrating Genesis, but it is project documentation content, not a reusable documentation system. The README does not claim caching, sanitization policy, versioned content, or support for multiple documents.

Authentication and profile pages use the `main` layout, according to the README. This separates their basic HTML structure from the authenticated `app` layout and the public `marketing` layout. Before production use, a developer still needs to inspect the generated authentication configuration, confirm mail delivery behavior, and understand whether a real deployment uses database sessions and queues. The `.env.example` defaults to SQLite, database-backed sessions, queues, and cache, with mail written to logs, which are development-oriented defaults rather than a production configuration.

Layout inheritance and the bundled Blade component set

Genesis supplies three layouts under `resources/views/components/layouts`. The `app.blade.php` layout is for application pages whose users must be authenticated. The `marketing.blade.php` layout is intended for public pages such as the homepage and blog. The `main.blade.php` layout contains the main HTML structure, and both `app` and `marketing` inherit from it. Authentication pages use `main` directly, which avoids adding either authenticated navigation or public marketing chrome.

The README documents component invocation with Blade syntax:

<x-layouts.app>
    <!-- content here... -->
</x-layouts.app>

The `marketing` and `main` variants follow the same component form. This explicit hierarchy gives developers recognizable boundaries between public presentation, authenticated application presentation, and the underlying page structure. It also creates a customization cost: a change to `main.blade.php` can propagate into multiple page types, while application-specific headers and footers belong in the inheriting layouts.

The repository also places reusable elements under `resources/views/components/ui`. The README names button, checkbox, input, light-dark-switch, and link components, although the visible component list is truncated at the end. The about page demonstrates `ui/marketing/breadcrumbs.blade.php`, showing that components are grouped by use case rather than exposed as one undifferentiated set.

Genesis does not document a complete component catalog or compatibility policy in the visible README. Developers should inspect the actual files before assuming every interface pattern or state behavior exists. The bundled components reduce initial styling work, but they also become code owned by the adopting project once the starter is copied into a new repository.

Maintenance signals, dependency work, and license uncertainty

The repository is not archived, and its last push was on 2026-05-22. That date provides a recent development signal, but it does not by itself establish a release cadence or a long-term support commitment. There are no GitHub releases, so Genesis does not currently provide release notes or a versioned upgrade path through that mechanism.

The frontend dependencies are declared in `package.json`. They include Tailwind CSS 4 through `@tailwindcss/vite`, Vite 6, AlpineJS 3, Laravel's Vite plugin, Tailwind typography and forms plugins, Autoprefixer, and Concurrently. The repository also contains `package-lock.json`, which gives the JavaScript installation a lockfile. `composer.lock` similarly appears in the top-level repository entries, although the visible material does not provide the full Composer dependency versions or PHP requirements.

An adopter will still need ordinary application maintenance after creating a project. Laravel, Livewire, Folio, Volt, PHP packages, and frontend dependencies can change independently. The absence of GitHub releases means there is no documented Genesis release series to consult when deciding whether an older generated application should be replaced or updated. Copying the starter also means reviewing its accumulated files and dependencies rather than applying a simple starter-version upgrade.

The repository information gives no confirmed license. Its Packagist badge and `composer.json` presence do not establish reuse rights, and no legal interpretation should be inferred from the Laravel ecosystem around it. This is a direct adoption blocker for organizations that require an approved license before incorporating source code. The license file or repository metadata must be checked before Genesis is copied into a proprietary codebase. The license implications cannot otherwise be resolved from the available documentation.

Why Folio differs from controller-first Laravel starters

The closest architectural alternative is a conventional Laravel starter that defines routes in PHP and renders Blade through controllers or route closures. That approach keeps the URL and controller relationship explicit in route files. Genesis instead places routing beside Blade pages through Folio, with page files such as `index.blade.php` mapping directly to URLs. Volt and Livewire add the component-oriented interaction layer, while Tailwind CSS and AlpineJS handle presentation and browser behavior.

This difference matters during customization. In a controller-first project, a developer may trace a request from a route declaration to a controller method and then a Blade view. In Genesis, the README's documented path begins with a file under `resources/views/pages`, with middleware declared in that file. That can reduce route boilerplate for page-oriented applications, but it moves a meaningful part of application structure into the view tree. Teams with strict conventions around controllers, service objects, or centralized route policy may need to adapt their expectations.

A controller-first alternative is not automatically better for every project. Genesis makes sense when much of the initial product is a set of authenticated and public screens, because the starter already supplies both categories, layouts for each, and account pages. It offers less as an alternative if the application is primarily an API, a background service, a data-processing package, or a system whose team requires controller and route organization by policy. The visible material presents a web application starter, not a framework-neutral component library.

Editorial conclusion

Genesis fits developers who already work with Laravel and want Folio-based routing, authentication screens, and a TALL Stack UI foundation rather than an empty Laravel installation. It is a poor fit for teams that require a known license, extensive domain features, or a documented release and upgrade process. Before adopting it, inspect the repository license, review all 11 predefined routes and page-level middleware, then run `php artisan folio:list` in the generated application to confirm that the starter structure matches the intended project.

Frequently asked questions

Official sources

1. Issues
2. README
3. thedevdojo/genesis on GitHub