DEV Community: catatsumuri

Localized Out of the Box with `laravel new` — i18n for Laravel Starter Kits (React/Vue/Svelte)

catatsumuri — Thu, 09 Jul 2026 07:57:14 +0000

Laravel's official Starter Kits currently support internationalization (i18n) only in the Livewire version. The Inertia-based kits (React / Vue / Svelte) still have all UI text hardcoded in English. Although support is being discussed upstream (laravel/maestro#168), I created and published localized forks as a temporary solution until official support arrives.

React: https://github.com/catatsumuri/react-starter-kit-i18n
Vue: https://github.com/catatsumuri/vue-starter-kit-i18n
Svelte: https://github.com/catatsumuri/svelte-starter-kit-i18n

These forks differ from the official kits in four ways:

Japanese is available immediately — ja language resources are included. Just change one line in .env
All UI strings go through __() — hardcoded English text has been replaced with translatable strings
Adding languages is easy — just add a JSON file and run a command (see the French example below)
Locale is stored in the session — the selected language persists after page reloads

Only the equivalent of each repository's main branch is provided. teams and WorkOS variants are not available.

For Those Who Just Want to Try It

composer global require laravel/installer # if not installed
laravel new Your_App --using=https://github.com/catatsumuri/react-starter-kit-i18n
cd Your_App
composer dev

Then change APP_LOCALE in .env to ja and restart the development server. Detailed setup instructions are explained later, but first, here is a demo.

Try the Demo First

A demo in a fully localized Japanese state is available on Laravel Cloud.

React: https://react-starter-kit-i18n-production-sbhkku.laravel.cloud/login
Vue: https://vue-starter-kit-i18n-production-bsczpo.laravel.cloud/login
Svelte: https://svelte-starter-kit-i18n-production-dkejy1.laravel.cloud/login

Localized login screen

You can log in using the following account. The database is read-only, so feel free to explore.

Email: test@example.com
Password: password

Actual Setup

Prerequisites

You need the laravel command (Laravel Installer) and npm. If the installer is not installed:

composer global require laravel/installer

% laravel --version
Laravel Installer 5.28.1

(This article does not cover Docker-based setups.)

Specify the Custom Starter Kit with `laravel new`

Simply pass the repository URL to the --using option of laravel new. The example below uses React, but Vue and Svelte follow the same procedure with different URLs.

# Replace Your_App
laravel new Your_App --using=https://github.com/catatsumuri/react-starter-kit-i18n

The repositories again:

React: https://github.com/catatsumuri/react-starter-kit-i18n
Vue: https://github.com/catatsumuri/vue-starter-kit-i18n
Svelte: https://github.com/catatsumuri/svelte-starter-kit-i18n

I primarily use the React version. The Vue and Svelte versions use the same mechanism, but there may be rough edges. If you find any issues, I'd appreciate an issue report.

When you run the command, it enters interactive mode and asks several questions. The defaults are generally fine.

 ┌ Which testing framework do you prefer? ──────────────────────┐
 │ › ● Pest                                                     │
 │   ○ PHPUnit                                                  │
 └──────────────────────────────────────────────────────────────┘

 ┌ Do you want to install Laravel Boost to improve AI assisted coding? ┐
 │ ● Yes / ○ No                                                        │
 └─────────────────────────────────────────────────────────────────────┘

Next, select authentication features.

 ┌ Which authentication features would you like to enable? ─────┐
 │ › ◼ Email verification                                       │
 │   ◼ Registration                                             │
 │   ◼ Two-factor authentication                                │
 │   ◼ Passkeys                                                 │
 │   ◼ Password confirmation                                    │
 └──────────────────────────────────────────────────────────────┘
  Use space to select, enter to confirm.

If you enable Registration, the application will allow anyone to create an account. Make sure this matches your intended behavior before selecting it.

Finally, you'll be asked whether to run npm. Choosing Yes is usually the safest option.

 ┌ Would you like to run npm install --ignore-scripts and npm run build? ┐
 │ ● Yes / ○ No                                                          │
 └───────────────────────────────────────────────────────────────────────┘

If you see the following, setup is complete:

 Application ready in [Your_App]. You can start your local development using:

 ➜ cd Your_App
 ➜ composer run dev

 New to Laravel? Check out our documentation. Build something amazing!

Verify Startup

cd Your_App
composer dev

Start the development server and access http://localhost:8000. On first launch, you'll likely encounter a database connection error.

If SQLite is sufficient, run the following in another terminal:

php artisan migrate:fresh --seed --force

Reload the page and the application should be running.

Switch to Japanese

At this point, the application is still in English. However, this fork already deploys Japanese resources into lang/ during installation (adding other languages is explained later).

% tree lang
lang
├── en
│   ├── actions.php
│   ├── auth.php
│   ├── http-statuses.php
│   ├── pagination.php
│   ├── passwords.php
│   └── validation.php
├── en.json
├── ja
│   ├── actions.php
│   ├── auth.php
│   ├── http-statuses.php
│   ├── pagination.php
│   ├── passwords.php
│   └── validation.php
├── ja.json
└── vendor-patches
    ├── locales
    │   └── ja.json
    └── source
        └── react.json

All you need to do is change .env.

#APP_LOCALE=en
APP_LOCALE=ja
APP_FALLBACK_LOCALE=en
APP_FAKER_LOCALE=en_US

Restart the development server that was running via composer dev, and the application will switch to Japanese.

Localized login screen

You can log in with the seeded account test@example.com / password.

Logged-in screen

Settings page is also localized

Recommended Workflow for Multilingual Development

To preserve internationalization during development, write UI strings using the __() helper. It can be used directly inside React components (translations are provided via Inertia shared props).

import { lang } from '@erag/lang-sync-inertia/react';
// ...
export default function Login({ status, canResetPassword }: Props) {
    const { __ } = lang();
    // ...
    {__('Fallback Language(English)')}

Actual usage example:

https://github.com/catatsumuri/react-starter-kit-i18n/blob/main/resources/js/pages/auth/login.tsx#L116-L121

If no translation exists for a key, the English fallback locale is displayed, so nothing breaks. For projects that do not require multilingual support, it's perfectly acceptable to continue development directly in your localized language.

Adding Another Language — French Example

Japanese is automatically deployed during installation through a Composer script, but adding other languages is also simple. Translation resources consist of two layers:

Base translations (validation messages, authentication errors, etc.) — provided by Laravel Lang for many languages
UI strings specific to this fork (such as the 2FA settings screen) — stored in lang/vendor-patches/locales/{locale}.json

To add French, create fr.json based on lang/vendor-patches/locales/ja.json.

cat lang/vendor-patches/locales/fr.json
{
    "Navigation menu": "Menu de navigation",
    "Once your account is deleted, all of its resources and data will also be permanently deleted. Please enter your password to confirm you would like to permanently delete your account.": "Une fois votre compte supprimé, toutes ses ressources et données seront également supprimées définitivement. Veuillez saisir votre mot de passe pour confirmer la suppression définitive de votre compte.",
    "Please proceed with caution, this cannot be undone.": "Veuillez procéder avec prudence, cette action est irréversible."
}

Reference (an actual implementation exists in the locale-switcher branch):

https://github.com/catatsumuri/react-starter-kit-i18n/blob/feature/locale-switcher/lang/vendor-patches/locales/fr.json

Even if translations are incomplete, missing keys fall back to English. After creating the file, apply the patch and regenerate language files.

composer patch-vendor
php artisan lang:update

% php artisan lang:update

   INFO  Collecting translations...

  LaravelLang\Actions\Plugin ................................. 2.42ms DONE
  LaravelLang\Lang\Plugin ................................... 16.39ms DONE
  LaravelLang\StarterKits\Plugin ............................. 2.52ms DONE

   INFO  Storing changes...

  fr.json ................................................... 10.80ms DONE
  fr/actions.php ............................................. 6.17ms DONE
  fr/auth.php ................................................ 0.29ms DONE
  fr/validation.php ......................................... 14.22ms DONE
  (en / ja are regenerated as well)

This generates lang/fr.json and lang/fr/*.php. Then simply update .env and restart the development server.

#APP_LOCALE=en
#APP_LOCALE=ja
APP_LOCALE=fr
APP_FALLBACK_LOCALE=en
APP_FAKER_LOCALE=en_US

Switched to French

Bonus: Locale Switcher (Language Switching UI)

A UI for switching languages directly from the application is also available in the feature/locale-switcher branch.

Locale switcher demo

To install directly from this branch, append #branch-name to the URL.

laravel new Your_App --using=https://github.com/catatsumuri/react-starter-kit-i18n#feature/locale-switcher

For reference, this is how it's configured on Laravel Cloud.

Closing Thoughts

I plan to keep these starter kits aligned with upstream changes as much as possible. However, if official translation support is added upstream, I may discontinue these repositories.

The issue that motivated this work:

https://github.com/laravel/maestro/issues/168

However, we are already discussing the best implementation for this internally.

About the Translation Adapter

For translation synchronization between Laravel and the frontend, this project uses erag/laravel-lang-sync-inertia.

https://packagist.org/packages/erag/laravel-lang-sync-inertia

Special thanks to Er Amit Gupta for merging PRs related to the Svelte adapter and flat-key support.

Trying Out Laravel Cloud (2) — Quickly Creating Per-Branch Environments in Laravel Cloud

catatsumuri — Fri, 03 Jul 2026 04:57:16 +0000

Introduction

Previously, I had the main branch running as production in a Laravel Cloud environment.

https://dev.to/catatsumuri/trying-out-laravel-cloud-a-hands-on-guide-to-laravel-hosting-starting-at-5-3mda

Continuing from that setup, suppose there is a branch called feature/locale-switcher in the same repository that adds language-switching functionality. In this case, it is possible to quickly add feature/locale-switcher as a separate deployment environment alongside the main branch. Let's walk through this demonstration.

Creating a New Environment

Laravel Cloud supports running multiple branches in parallel. Here, we'll create a New Environment for react-starter-kit-i18n.

You can then select the branch you want to deploy.

An environment independent from main is created as shown below. Before deploying, click Settings to configure it first.

As before, the most important settings will likely be under General and Deployments. We'll focus on configuring those.

You'll probably need to add most of these environment variable settings

After configuring them, deploy the environment.

Deployment starts in a completely separate space from main (production).

Once deployment is complete, use the Commands tab as needed to run artisan commands and finalize the setup.

Issued URL and Verification

After everything is set up, Laravel Cloud issues the URL:

https://react-starter-kit-i18n-feature-locale-switcher-w9x8ho.laravel.cloud/

This URL is different from the production URL.

Japanese version: https://react-starter-kit-i18n-production-sbhkku.laravel.cloud/
Locale Switcher version: https://react-starter-kit-i18n-feature-locale-switcher-w9x8ho.laravel.cloud/

Verification

Let's access https://react-starter-kit-i18n-feature-locale-switcher-w9x8ho.laravel.cloud/ and verify that it is actually running.

This time, the welcome page is in English

This Locale Switcher branch allows users to change the language from the login screen or later in the application. Let's open the login page. You can see a language selector that did not exist in the previous branch.

Example after switching to French

You can log in with:

test@example.com
password

After logging in, I switched the interface to German.

Switching to German

Summary

In this article, we reviewed how to create an additional environment for an existing application in Laravel Cloud and deploy a different branch in parallel.

In this example, we published the feature/locale-switcher branch on its own URL, separate from the main branch, and successfully verified the language-switching functionality.

The primary advantage of this feature is that new functionality can be tested on an actual server before being merged into production. It is useful not only for developers' own verification but also for sharing URLs with clients or team members for review.

Traditionally, a separate server or container would need to be prepared to build a testing environment. With Laravel Cloud, however, an isolated environment can be created in just a few clicks, making it much easier to validate new features or design changes.

For individual developers and small teams in particular, the ability to quickly create an environment simply to "let someone take a look" can be a significant benefit.

Trying Out Laravel Cloud - A Hands-On Guide to Laravel Hosting Starting at $5

catatsumuri — Wed, 01 Jul 2026 22:46:36 +0000

What You'll Need

A credit card
A Git remote repository on GitHub, GitLab, or Bitbucket

Creating an Account — Sign Up

Go to https://laravel.com/cloud and click Sign up.

You can sign up using an email address or authenticate via GitHub or Google. If you choose GitHub, there is an advantage later when integrating with GitHub because you won't need to add an authentication adapter separately.

Once authentication succeeds, your account will be created and you'll see a blank Overview screen. This is where you'll deploy your applications.

About "Organizations" in Laravel Cloud

If you're using Laravel Cloud personally, you don't need to worry much about this section. Currently, the setup uses an organization called catatsumuri, but additional organizations can be created.

This feature may be useful, for example, if you're operating Laravel Cloud within a company and want billing to be handled there. Therefore, if you plan to share usage among multiple accounts under a company billing arrangement, it's recommended that you first explore and establish your organization structure.

It appears that one person creates the organization and then invites other members, and billing can be configured per organization (though the author has not personally used this feature).

Since the hands-on guide below does not use an additional organization, this is only mentioned here. However, before proceeding with billing, it's worth carefully considering how your team should be organized, as restructuring may become more difficult once billing has started.

Your First Subscription

If you haven't subscribed yet, you'll likely see a warning like this:

Clicking the Subscribe button takes you to the billing screen.

You can choose from three plans:

Starter (5 USD)
Growth (20 USD)
Business (200 USD)

For most people, starting with the Starter plan is probably the best way to get familiar with the platform.

Payment

Complete payment on the following screen.

You can choose whether the payment is made as an individual or a company. However, as mentioned earlier, billing is applied at the organization level, so this choice mainly affects how the invoice is presented. Therefore, if you want charges billed to a specific organization, you'll likely need to ensure that organization is selected before subscribing (though this has not been verified).

Checking Usage and Spending Limits

Once payment is complete, open the Usage tab.

The Usage tab shows your available credit and current usage.

Since nothing has been used yet, you'll see a $5 credit balance and $0 usage.

Next, look at the Spending limit settings. You can access them either via Set up spending limit under Usage or through Settings → Billing.

For example, if you want usage to stop exactly at $5, configure it like this:

Stop compute at the limit setting

In practice, production web services usually cannot simply be stopped, so in such cases it may be better to use Notify instead. This depends on your operational requirements. For example, stopping may be acceptable for demo environments.

Whether you choose to stop services or not, enabling at least Notify is advisable. This should be one of the first settings you review.

Deploying an Application

Now let's actually deploy an application. For this demonstration, we'll deploy https://github.com/catatsumuri/react-starter-kit-i18n (a multilingual version of React Starter Kit).

From the Application tab, select New application.

Since this example uses GitHub authentication, the repository is already connected and displayed. If you want to use another provider, you'll need to connect it manually.

GitLab and Bitbucket are supported. Connection instructions are omitted here.

As the author resides in Japan, the Tokyo region was selected.

Select react-starter-kit-i18n and Asia Pacific (Tokyo).

Clicking Create application prepares the application for deployment. Deployment itself has not started yet.

Once setup is complete, you'll see a screen like the following. A default environment named production is provided, but this is merely a default name and does not necessarily indicate a true production environment.

The production environment is created by default.

Be Sure to Visit Settings Before Deploying

Before deployment, review the Settings.

You can freely choose the environment name. As shown earlier, it defaults to production.

An important point: you can choose the deployment branch here. For example, if you maintain both main and dev branches and only want to publish dev via Laravel Cloud, select it here before deployment. In this article, however, main is used.

Specify the deployment branch.

Review the remaining environment settings as well. Ideally, choose the same PHP version as your development environment to reduce the chance of compatibility issues.

Further down, you'll find configuration for .env-based environment variables.

Here, if there are additional environment variables, they should be specified in the box above. In this application, the language is designed to switch according to APP_LOCALE. Since the author wanted a Japanese-language environment, APP_LOCALE=ja was specified. In addition, because data would also be loaded, APP_ENV=local was set.

A dialog appears when editing the box.

After editing, the above dialog appears. Since deployment is not yet desired at this stage, Save only was selected.

Be Sure to Check the Deployments Menu

The Deployments tab contains configuration for Build commands, which determine how composer and npm are executed.

For this particular project, there is no composer.lock file, so composer update was used. Since database seeding was also desired, --no-dev was removed.

In general practice, however, the lock file should be committed and composer install should be used.

Using composer update --no-interaction --prefer-dist --optimize-autoloader

At this point, deployment can finally be started with Save and deploy.

Deployment

After deployment starts, you'll automatically be taken to the Deployments tab where you can monitor progress.

Once deployment is complete, a URL will be provided from the Environment. You can also configure a database via Add Resource (however, this article does not cover that).

The URL is displayed.

For this application, access is already possible at this point. You're also welcome to visit the author's deployed environment directly (arguably one of the strengths of this approach). https://react-starter-kit-i18n-production-sbhkku.laravel.cloud/

Japanese-localized login screen

Configuring SQLite (Unofficial)

Laravel Cloud does not officially support SQLite because the application's local disk is ephemeral and is lost on every deployment. However, by taking advantage of that characteristic, SQLite can still be used in environments where persistence is not critical, at least until the next deployment occurs.

From the Commands tab, arbitrary commands can be executed within the environment. Here, run:

php artisan migrate:fresh --seed --force

Executing php artisan migrate:fresh --seed --force

If execution succeeds, you'll see output like this:

Additionally, since updates are unnecessary (and undesirable) in this case:

chmod 444 database/database.sqlite

was also executed.

However, because the database becomes completely read-only, cache and session data must be stored in files instead.

CACHE_STORE=file
SESSION_DRIVER=file

Final Verification

The assigned URL is:

https://react-starter-kit-i18n-production-sbhkku.laravel.cloud/

Visit it and log in using:

test@example.com
password

Successfully logged in

Updating the profile results in an error

This is intentional. To see the specific error, open Logs.

The write operation fails with attempt to write a readonly database.

Conclusion

This walkthrough covered the entire process of creating a Laravel Cloud account, subscribing, configuring usage limits, and deploying an application.

My overall impression is that Laravel Cloud is extremely approachable for developers who simply want to publish Laravel applications without worrying about infrastructure management. On the other hand, it does not provide the same level of flexibility as traditional VPS hosting or AWS, so some trade-offs are necessary.

That said, with plans starting at just $5 per month, easy branch-based environment creation, and automatic URL provisioning, it feels like a very viable option for personal projects, testing environments, and small-scale services.

A good approach would be to start with the Starter plan, deploy a small application, and see whether it fits your own operational style.

Laravel Maestro Contributor Tutorial

catatsumuri — Tue, 23 Jun 2026 14:27:41 +0000

Introduction

Laravel officially uses Laravel Maestro to streamline Starter Kit development. However, there is currently not much information available on how to actually contribute to Starter Kits using Maestro.

When I first started, I was confused about things such as:

The difference between the build/, kits/, and orchestrator/ directories
The role of the watcher
Which directories should be included in a git commit

In this article, using a real example of modifying text in a Starter Kit, we will cover:

The basic structure of Maestro
The relationship between build / kits / orchestrator
How to run tests
The workflow up to creating a PR

This article is intended less for Laravel users in general and more for developers considering contributing to Starter Kits or Maestro itself. If you are thinking about adding features or fixing functionality in a Starter Kit upstream, I encourage you to read through this hands-on tutorial and get a feel for the contribution workflow up to the PR stage (note that we will not actually submit a PR).

Clone the Repository and Get the Source Tree Locally

First, clone the repository:

git clone https://github.com/laravel/maestro.git

This creates a local copy of the laravel/maestro source tree.

Running a Starter Kit Through Laravel Maestro

At present, containers are not officially supported, and execution is always native. (If you want to run it inside a container, you will likely need to first understand the native workflow and then build your own setup.) Internally, it essentially runs something similar to artisan serve.

In other words, because everything runs natively, your system must have:

php-cli
composer

installed locally. Otherwise, you will not be able to follow the steps below.

Start from orchestrator/

Before launching a Starter Kit through Maestro, let's first check the current directory structure.

% tree -L1 -D
.
├── browser_tests
├── kits
└── orchestrator

Currently, these three directories exist. To get started, change into orchestrator/ and install the Composer and npm dependencies.

cd orchestrator
composer install
npm install

Next, build the project with php artisan build. If you run it without options, it starts in interactive mode:

% php artisan build

 ┌ Which starter kit would you like to build? ──────────────────┐
 │ › ● Livewire                                                 │
 │   ○ React                                                    │
 │   ○ Svelte                                                   │
 │   ○ Vue                                                      │
 └──────────────────────────────────────────────────────────────┘

For example, selecting Livewire gives:

 ┌ Which starter kit would you like to build? ──────────────────┐
 │ Livewire                                                     │
 └──────────────────────────────────────────────────────────────┘

 ┌ Which variant would you like to use? ────────────────────────┐
 │   ○ Blank (no authentication)                                │
 │ › ● Fortify (authentication using Fortify)                   │
 │   ○ WorkOS (authentication using WorkOS)                     │
 └──────────────────────────────────────────────────────────────┘

The final selection is whether to enable Teams:

 ┌ Would you like to enable the Teams feature? ─────────────────┐
 │ ○ Yes / ● No                                                 │
 └──────────────────────────────────────────────────────────────┘

However, Livewire has one additional option:

 ┌ Which Livewire variant would you like to use? ───────────────┐
 │ › ● Single File Components                                   │
 │   ○ Multiple File Components                                 │
 └──────────────────────────────────────────────────────────────┘

These branches make it possible to represent the following 21 variants:

Framework	Blank	Fortify	Fortify + Teams	WorkOS	WorkOS + Teams	Components
Livewire	✓	✓	✓	✓	✓	✓
React	✓	✓	✓	✓	✓	—
Svelte	✓	✓	✓	✓	✓	—
Vue	✓	✓	✓	✓	✓	—

React: 5
Vue: 5
Svelte: 5
Livewire: 6
Total: 21

When submitting modifications as contributions, you should always keep this matrix in mind.

If you already know which matrix combination you want, you can pass options to php artisan build and avoid interactive mode altogether (this approach will also be introduced later).

The build/ Directory

Looking at the directory tree again:

% tree -L1 -D
.
├── browser_tests
├── build # <------------- This was added
├── kits
└── orchestrator

A build/ directory has been generated. This directory is created by orchestrator/ and serves as a working directory. Essentially, it is a copy of the Laravel Starter Kit corresponding to the variant selected in orchestrator/.

However, the Actual Kit Is Started from orchestrator/

Now let's run it. The application is not launched from build/; instead, from orchestrator/ run:

composer kit:run

This runs things such as composer setup, injects a .env file, and starts the selected variant.

The selected variant has started

Note that kit:run occupies the terminal while running, so plan your workflow accordingly. Also, the port is fixed at 8000, so if that port is unavailable, development may become inconvenient. Changing the port is not particularly difficult, but requires a somewhat hacky approach, so it is best to start in an environment where port 8000 is available.

Started via kit:run

Practicing Contributions with Maestro

Next, let's practice making modifications using Maestro. The example used here is not intended to be an actual contribution candidate.

Case 1: Change "Log in" to "Log on" on the Login Page

Change Log in to Log on

There is also a Log in link on the Welcome page, but for this tutorial we will focus only on the login page.

Other occurrences of Log in, such as on the Welcome page, are out of scope for this tutorial

Looking at the matrix:

Framework	Fortify	Fortify + Teams	Components
Livewire	✓	✓
React	✓	✓	—
Svelte	✓	✓	—
Vue	✓	✓	—

These variants will need to be updated. WorkOS variants do not have a login page, so they are not affected. (Again, this tutorial focuses only on the login page, and WorkOS variants delegate authentication externally.)

Change the File in ../build

Work is performed in build/.

First, move into the build directory.

Maestro is launched from orchestrator/, but development work is done in build/

Since build/ is the actual Laravel application, search for the target string using rg or a similar tool.

Searching with rg "Log in"

We find that the relevant file is resources/views/pages/auth/login.blade.php, so edit it as follows:

             <div class="flex items-center justify-end">
                 <flux:button variant="primary" type="submit" class="w-full" data-test="login-button">
-                     {{ __('Log in') }}
+                     {{ __('Log on') }}
                 </flux:button>
             </div>

Changed to Log on

Commit & PRs Are Made from kits/

Although the modification was made in build/, this directory is temporary and is not tracked directly in Git. When you modify build/, a watcher automatically updates the corresponding files in kits/. You can verify this by running git status inside build/.

The watcher automatically updates the corresponding files in ../kits

Testing

Everything looks good, so let's run tests. Testing is done from orchestrator using commands such as composer kits:pint and composer kits:check -- --livewire.

cd ../orchestrator

# Source formatting
composer kits:pint

# PHP tests (Livewire variants only)
composer kits:check -- --livewire

Running kit:check while kit:run is still active results in an error

While kits:pint is fine, due to Maestro's design, you must stop kit:run before running kits:check. Therefore, terminate the terminal session where composer kit:run is running.

The tests take quite a while, but eventually complete

That completes the Livewire modification. As shown earlier, Git now reports:

% git status
On branch main
Your branch is up to date with 'origin/main'.

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   ../kits/Livewire/Fortify/resources/views/pages/auth/login.blade.php

no changes added to commit (use "git add" and/or "git commit -a")

Since the changes have been propagated into kits/, that is the directory whose contents should be committed, pushed, and submitted in a PR.

Rewriting the Remaining 7 Variants

At this point, only Livewire/Fortify has been rewritten. The remaining 7 variants must also be updated, otherwise the PR is unlikely to be accepted.

Of course, you could build them one by one, rewrite them one by one, and let the changes be reflected in kits/. However, since that requires considerable effort, it is also acceptable to modify kits/ directly. For example, you could ask an AI to rewrite them like this:

# Prompt for AI
Check the git diff for the changes made to:

kits/Livewire/Fortify/resources/views/pages/auth/login.blade.php

Based on those changes, update the remaining Fortify and Fortify + Teams variants for:

- Livewire
- React
- Svelte
- Vue

so that the `Log in` button is changed to `Log on` throughout the `kits/` directory.

Even when modifying kits/ directly, it is safer to stop kit:run. Use it only when working inside build/.

The following files were edited:

kits/Inertia/Fortify/React/resources/js/pages/auth/login.tsx
kits/Inertia/Fortify/Svelte/resources/js/pages/auth/Login.svelte
kits/Inertia/Fortify/Vue/resources/js/pages/auth/Login.vue
kits/Inertia/Teams/Fortify/React/resources/js/pages/auth/login.tsx
kits/Inertia/Teams/Fortify/Svelte/resources/js/pages/auth/Login.svelte
kits/Inertia/Teams/Fortify/Vue/resources/js/pages/auth/Login.vue
kits/Livewire/Fortify/resources/views/pages/auth/login.blade.php
kits/Livewire/Teams/Fortify/resources/views/pages/auth/login.blade.php

Rewritten by AI

Actually Run One Variant and Test It in the Browser

Here, we will verify React + Fortify + No Teams. In reality, after changing all eight files, you should manually test all eight variants in a browser. However, due to space constraints, only this one is shown.

Since changes made directly in kits/ require rebuilding, move to orchestrator/ and run:

php artisan build --kit=react

Providing --kit disables interactive mode.

After that, run composer kit:run, and the application will be accessible at localhost:8000. Let's take a look.

The React version has also been updated.

Proceed with testing the variants one by one in this manner.

Final Testing

Again, stop kit:run. Then move to ./orchestrator and run:

composer kits:pint
composer kits:check
composer kits:lint

This executes all tests and linting. Note that linting is for JavaScript.

Since it runs 21 combinations, the testing process takes quite a while.

kits:check shows 21 passed. It takes an extremely long time.

Additionally, kits:lint runs 15 checks, which also takes a very long time.

kits:lint shows 15 passed. This is also lengthy.

In any case, only after reaching this point are you ready to commit.

Preparing the Commit and PR

In this example, the changes involve these eight files. As mentioned earlier, only kits/ should ever be included in the commit. Nothing else should be touched.

git add kits/
git commit

Commit

The username shown here is arbitrary, but in practice you should create commits appropriately for the project. After that, simply follow the project's OSS contribution process and submit the PR.

Example: Making a Shared Backend Change

Previously, we modified eight frontend files. As a final example, let's learn how to make a backend change. This time, we'll build with React + Fortify.

cd orchestrator
php artisan build --kit=react
composer kit:run

Then work inside the build/ directory.

First, Set Up the Authentication Database

Inside build/, run:

php artisan migrate:fresh --seed --force

The database was recreated and seeded.

You can now log in using test@example.com / password. Log in, navigate to Settings, click the profile update button, and observe the toast message.

It displays Profile updated.

Let's change that text. Search for it using rg.

Searching with rg

It turns out that simply modifying app/Http/Controllers/Settings/ProfileController.php is sufficient. For example, change it to Profile changed.

Then:

% git status
On branch main
Your branch is ahead of 'origin/main' by 1 commit.
  (use "git push" to publish your local commits)

Changes not staged for commit:
  (use "git add <file>..." to update what will be committed)
  (use "git restore <file>..." to discard changes in working directory)
        modified:   ../kits/Inertia/Base/app/Http/Controllers/Settings/ProfileController.php

As shown above, the watcher detects the change and updates kits/Inertia/Base/app/Http/Controllers/Settings/ProfileController.php.

Updating Livewire

Notice the focus on kits/Inertia. At this stage, all Inertia backend changes have been completed. However, the Livewire side has not yet been updated, so we must make the corresponding Livewire changes.

Stop kit:run, then in orchestrator/ run:

php artisan build --kit=livewire
composer kit:run

Once it starts, move to build/ and run:

php artisan migrate:fresh --seed --force

Then log in and navigate to the relevant page.

The style is actually a little different from React and the others, but functionally it's equivalent.

Livewire Does Not Handle This Through a Controller

Searching with rg reveals that this is handled in resources/views/pages/settings/profile.blade.php.

Handled in a view file rather than a controller.

This can be confusing if you're not familiar with Livewire (the author isn't particularly experienced with it either), but since it is just a simple text replacement, let's make the change.

Then:

As shown, kits/Livewire/Fortify/resources/views/pages/settings/profile.blade.php is now modified as well.

For this change, these two files will be committed. The remaining steps are the same: stop kit:run, then run:

composer kits:pint
composer kits:check
# composer kits:lint # Not necessary this time

Since this is not a frontend change, kits:lint is unnecessary. If the tests pass, proceed with the same commit, push, and PR workflow.

Laravel in 2026: Starter Kits, AI SDK, and the End of the Breeze Era

catatsumuri — Sun, 24 May 2026 22:57:40 +0000

Why Laravel? That is not the topic here.

This article assumes you already decided to build with Laravel, and instead focuses on a more practical question:

What does the Laravel ecosystem actually look like in 2026, and what should you choose today?

The original draft was based on material gathered through ChatGPT Deep Research, then heavily revised with additional analysis and commentary from actual ecosystem observation. The goal is not neutrality for its own sake, but a realistic reading of where Laravel is heading.

The State of Laravel in April 2026

Executive Summary

As of April 2026, the situation around Laravel starter kits has become fairly clear:

Breeze and Jetstream are not “dead,” but they are no longer the strategic center of the ecosystem.

Laravel officially shifted its public onboarding flow toward the new Starter Kits in 2025. Breeze and Jetstream still receive maintenance updates even in 2026, but their READMEs explicitly position them as belonging to the Laravel 11 era and earlier.

The practical conclusion is:

Breeze should no longer be considered the default choice for new production systems
Jetstream remains acceptable for existing systems, but is difficult to justify for new adoption
The modern default is now Starter Kit + Inertia, especially React
Livewire is still highly relevant and should not be dismissed as “legacy inertia”

That last point matters more than many people realize.

A surprisingly large portion of the discourse around Laravel UI strategy focuses only on GitHub stars of the public starter repositories. That produces a misleading picture.

Yes, React Starter Kit currently has stronger momentum as the public-facing “entry point.” But the broader Laravel UI ecosystem still shows enormous Livewire adoption.

The ecosystem split is becoming increasingly visible:

React + Inertia dominates external AI-oriented products and modern SaaS UX
Vue remains a pragmatic choice for teams with existing Vue investment
Livewire continues to excel in internal systems, admin panels, and PHP-centric organizations
Svelte is promising, but still lacks ecosystem gravity for default adoption

The larger story, however, is not merely frontend selection.

The real shift is that Laravel’s AI SDK is beginning to change Laravel’s architectural assumptions themselves.

This is not just “another package.”

Laravel is increasingly treating AI capabilities as part of the framework’s default application model:

AI SDK
MCP integration
Boost
Cloud APIs
Agent Skills
Maestro-managed starter kits

These are not isolated experiments anymore.

They are converging into a coherent platform direction.

Research Assumptions

This analysis prioritizes primary sources:

Laravel 13 release notes
Official AI SDK documentation
Starter Kit documentation
Laravel blog posts
Public statements by Taylor Otwell
Official GitHub repositories, issues, and pull requests

Community discussions in both English and Japanese were used mainly to identify practical pain points rather than as authoritative sources.

One important complication is that the new Starter Kits are distributed as cloneable repositories rather than Packagist packages.

That means install counts cannot be measured in the same way as Breeze or Jetstream.

As a result, public GitHub signals such as:

stars
forks
issue activity
ecosystem discussion volume

must be treated as imperfect adoption proxies.

This is actually a structural weakness of repository-template distribution models in general.

Comparing the Starter Kit Options

Let’s state the conclusion first.

Breeze is no longer the default recommendation for new production applications.

Jetstream is difficult to justify outside existing systems.

The primary battlefield is now Starter Kit + Inertia or Starter Kit + Livewire.

The strongest default choice today is React + Inertia.

However, dismissing Livewire as merely “legacy momentum” is a serious misunderstanding.

Breeze

Breeze still has real advantages:

minimal structure
easy-to-read authentication flow
relatively small codebase
useful for backend/API-oriented systems
easier onboarding for traditional Laravel developers

There is also a practical reality many people understate:

A large number of teams still adopt Breeze successfully even in Laravel 12 and 13.

Why?

Because the modern Starter Kits are heavy.

Not only technically heavy, but operationally heavy:

rapidly changing upstream conventions
evolving frontend architecture
weak documentation stability
limited Japanese-language ecosystem support
frontend discipline requirements many Laravel teams historically never needed

In practice, many teams still choose Breeze simply because they can fully understand it.

That matters.

Still, from Laravel’s strategic direction, Breeze is no longer where the framework’s future investment is concentrated.

Laravel increasingly treats the application starting point not as:

“authentication scaffolding”

but rather as:

“AI-ready frontend + auth + DX platform foundation”

That is a major philosophical shift.

Breeze still has value.

But increasingly, that value resembles:

learning material
minimal proof-of-concept foundation
compatibility layer
reference implementation

rather than “the modern standard.”

Jetstream

Jetstream faces a harder problem.

Historically, Jetstream differentiated itself through:

teams support
2FA
session management
more feature-complete authentication workflows

But much of that territory is now being absorbed by the Starter Kit ecosystem itself.

Laravel’s newer Starter Kits increasingly support:

built-in authentication
WorkOS integration
passkeys
social login
magic authentication
SSO flows
team variants

Meanwhile, Maestro now manages large variant matrices internally across:

Fortify
WorkOS
Teams
framework variants

As a result, Jetstream’s unique positioning has weakened significantly.

Existing Jetstream systems are still perfectly reasonable to maintain.

But for greenfield applications, the argument for starting with Jetstream has become increasingly thin.

React Starter Kit + Inertia

This is currently the strongest default recommendation for new external-facing Laravel applications.

The reasons are straightforward:

React ecosystem dominance
strong AI UI ecosystem compatibility
shadcn/ui momentum
Radix primitives
React 19 ecosystem maturity
TypeScript-first workflows
modern component architecture

More importantly, AI-oriented UX increasingly favors rich client-side interaction models.

That naturally aligns with React.

Laravel appears fully aware of this.

The modern Starter Kits are clearly optimized around:

TypeScript
component-driven UI
modern frontend tooling
AI-ready interaction patterns

rather than traditional server-rendered MVC assumptions.

The downside is equally obvious:

This stack requires real frontend engineering discipline.

Teams accustomed to purely backend-centric Laravel workflows often underestimate:

frontend state complexity
TypeScript maintenance
component architecture overhead
npm ecosystem churn
modern frontend build tooling expectations

Still, for customer-facing AI-heavy products, React + Inertia is currently the strongest default choice.

Vue Starter Kit + Inertia

Vue remains the pragmatic choice for organizations already invested in Vue.

The migration cost is lower.

The mental model is stable.

The Composition API ecosystem is mature.

However, React currently has stronger gravity in:

AI-oriented UI libraries
external ecosystem examples
modern component ecosystems
bleeding-edge frontend tooling momentum

Vue is therefore less “future dominant,” but still highly viable.

For many teams, stability may matter more than ecosystem fashion.

Svelte Starter Kit + Inertia

Svelte is interesting.

The developer experience is genuinely attractive.

Svelte 5 is modern and elegant.

Inertia integration is surprisingly clean.

But ecosystem gravity still matters.

Right now:

ecosystem scale remains limited
learning resources are thinner
Laravel-specific operational knowledge is scarce
hiring pools are smaller
official investment signals are weaker

Svelte is viable for teams already committed to it.

But it is still difficult to recommend as the default Laravel frontend strategy.

Livewire Is Not Dead

This point deserves emphasis.

Many discussions incorrectly frame Livewire as a fading legacy option.

The numbers simply do not support that narrative.

Livewire still maintains enormous ecosystem presence:

tens of millions of installs
massive production footprint
strong GitHub activity
official Laravel investment
Flux UI integration
Livewire 4 ecosystem momentum

The important distinction is this:

Public starter kit repository popularity does not equal total ecosystem dominance.

Livewire continues to perform extremely well for:

internal business systems
admin dashboards
operational tooling
PHP-centric organizations
teams minimizing frontend specialization

Where Livewire becomes less comfortable is extremely interaction-heavy AI UX with complex client-side state.

There, React usually provides more architectural flexibility.

But for large classes of real-world business applications, Livewire remains extremely competitive.

Calling it “only inertia” misunderstands the actual Laravel user base.

Laravel’s AI Direction

The most important shift in Laravel right now is not frontend technology.

It is the framework’s AI-native direction.

Laravel increasingly behaves as though AI is not an extension layer, but part of the framework’s core application model.

This matters because many frameworks currently integrate AI as:

external orchestration
generic SDK wrappers
thin API abstractions

Laravel is instead attempting to integrate AI directly into:

queues
events
auth
filesystem
application lifecycle
structured workflows
operational tooling

In other words:

Laravel is trying to remain Laravel while becoming AI-native.

That is strategically important.

And honestly, fairly ambitious.

1-Year Outlook

Over the next year, Laravel’s AI direction will likely continue aggressively.

The signals are already obvious:

AI SDK
MCP support
Boost
Cloud APIs
Agent Skills
Maestro
Starter Kit consolidation

The likely short-term evolution areas are:

conversation state stabilization
tool-loop orchestration
structured output improvements
vector-store integrations
multi-tenant AI architecture support
operational maturity around AI workflows

This is not based on secret roadmap knowledge.

It is simply the logical reading of where official framework investment is concentrated.

3-Year Outlook

Within roughly three years, Laravel’s UI strategy will probably polarize even further.

The ecosystem split may become:

React + Inertia

external-facing products
AI-first experiences
rich interactive UX
modern SaaS platforms

Livewire

internal systems
management interfaces
operational tooling
PHP-centric organizations
productivity-oriented systems

Vue likely survives as the “stable pragmatic middle.”

Svelte may remain niche unless official investment accelerates significantly.

Meanwhile, Breeze and Jetstream increasingly transition into compatibility assets rather than ecosystem centers.

5-Year Outlook

Five years is long enough that predictions become dangerous.

Still, some directional probabilities are visible.

The Laravel components most likely to remain strategically central are:

Eloquent
Queue
Events
Auth
Broadcasting
Filesystem
AI-integrated application primitives
Maestro-managed starter ecosystems

The components most likely to lose strategic importance are:

legacy authentication starter packages
older frontend assumptions
Blade-first public application architecture

This last point deserves nuance.

Blade itself is not dying.

Blade remains deeply embedded inside Laravel:

mail rendering
internal templating
Inertia foundations
server-side workflows
operational tooling

But Blade is increasingly no longer the assumed default public UI architecture.

That distinction matters.

Final Thoughts

Laravel in 2026 feels fundamentally different from Laravel in the Breeze era.

The framework is no longer optimizing primarily for:

simple MVC onboarding
lightweight auth scaffolding
traditional PHP-only workflows

Instead, Laravel is increasingly positioning itself as:

an AI-native application platform
with integrated operational tooling
modern frontend expectations
strong developer experience
full-stack orchestration assumptions

That creates both strengths and risks.

The strength is coherence.

Laravel increasingly feels like a unified application platform rather than a disconnected package collection.

The risk is that complexity rises.

The modern Laravel ecosystem now expects:

frontend literacy
TypeScript familiarity
operational maturity
AI workflow understanding
ecosystem adaptation speed

For some teams, that is exciting.

For others, it is exhausting.

But regardless of preference, the direction itself is becoming difficult to ignore.

And if you are building new Laravel applications in 2026, pretending the ecosystem has not changed is probably the real mistake.

Laravel Starter Kit Localization Is Surprisingly Painful

catatsumuri — Sun, 17 May 2026 10:01:21 +0000

About Laravel Starter Kits Since Laravel 12

These are meant to rapidly deploy functionality that is almost essential during the initial launch of an application, including the following:

Layouts
- A typical sidebar layout
- Or a typical header layout
- Breadcrumbs
Authentication
- Basic session management
- Password reminders
- Self-registration
- TOTP-based 2FA
User settings
- Profile
- Light mode / dark mode switching
- Account deletion
Simple dashboard

Provided authentication screen

Part of the user settings

As you can see, this is extremely convenient for getting a project off the ground. However, especially in Japanese-speaking regions, adoption does not seem to be progressing very well. One reason is probably that the functionality is somewhat difficult to understand, but another major factor is likely the effort required for Japanese localization. Nowadays, with AI programming, identifying and rewriting English interfaces is not especially difficult, but not everyone has access to AI development agents, repeatedly translating everything with AI is exhausting, and if you are making an ambitious attempt to support multilingualization as OSS, then Laravel Starter Kits will inevitably run into localization issues.

Laravel Starter Kits Actually Come in About Four Flavors

Even when we say “Laravel Starter Kit,” there are currently about four flavors. First, I want to organize them.

Livewire-based
Inertia.js-based
- React
- Vue
- Svelte

At a broad level, things first split into Livewire and Inertia.js, and under Inertia.js there are three more flavors, each with branches beneath them... This huge number of variations is itself one of the characteristics of this project. Since the localization situation differs between Livewire and Inertia.js, you first need to understand that distinction.

To give the conclusion up front: if you intend to complete your project with Livewire, multilingualization is not especially difficult, and there is already some infrastructure in place. However, if you try to localize Inertia.js, there is no translation mechanism in the Starter Kit’s default state.

Projects for i18n in Laravel

Laravel’s Built-in Translation Mechanism

On the backend side, Laravel itself already has localization functionality, which is reinforced through additional resources provided by Laravel Lang.

Laravel 13 Localization Documentation:

https://laravel.com/docs/13.x/localization

About Laravel-Lang

There has actually been a project called Laravel-Lang for quite a while, and it already provides some multilingualization mechanisms.

https://laravel-lang.com/basic-usage.html

Following the documentation:

composer require laravel-lang/common

This resolves and installs the following dependencies:

laravel-lang/publisher
laravel-lang/lang
laravel-lang/attributes
laravel-lang/http-statuses
laravel-lang/starter-kits

At first glance, it seems like this package might somehow magically handle Starter Kit localization, but reality is not so simple. We’ll look at that later. Simply installing the package only expands files under vendor/, so at this stage, nothing is actually usable yet.

Deploying Into the Actual Project With the lang:add Command

You execute it like this. Here, we’ll only deploy ja.

php artisan lang:add ja

The actual implementation of this command comes from the previously resolved dependency laravel-lang/publisher, which performs the following tasks:

Determine the target locale
Select only enabled plugins from the plugin list
Read the key list from source/...
Read values from locales/{locale}/...
Write them into lang/{locale}.json or lang/{locale}/*.php

In any case, once this command is executed, things should expand like this:

   INFO  Collecting translations...

  LaravelLang\Actions\Plugin ............................................................................. 2.37ms DONE
  LaravelLang\Attributes\Plugin .......................................................................... 0.83ms DONE
  LaravelLang\HttpStatuses\Plugin ........................................................................ 1.28ms DONE
  LaravelLang\Lang\Plugin ................................................................................ 5.90ms DONE
  LaravelLang\StarterKits\Plugin ......................................................................... 1.37ms DONE

   INFO  Storing changes...

  ja.json ................................................................................................ 5.04ms DONE
  ja/actions.php ......................................................................................... 4.65ms DONE
  ja/auth.php ............................................................................................ 0.45ms DONE
  ja/http-statuses.php ................................................................................... 2.02ms DONE
  ja/pagination.php ...................................................................................... 0.55ms DONE
  ja/passwords.php ....................................................................................... 0.52ms DONE
  ja/validation.php

Locale Configuration

As described in the official documentation, this is determined by the APP_LOCALE environment variable, and falls back to APP_FALLBACK_LOCALE if unavailable. Therefore, for Japanese localization, the configuration would typically look like this:

#APP_LOCALE=en
APP_LOCALE=ja
APP_FALLBACK_LOCALE=en
APP_FAKER_LOCALE=en_US

This localizes the backend.

For example, after installing the package and configuring the locale, even 404 pages are immediately translated into Japanese. But this is backend functionality.

Frontend Support

This is where the problem begins.

As mentioned earlier, the situation differs between Livewire and Inertia.js. To say it first: the only thing functioning relatively properly at the moment is Livewire. So let’s start with the Livewire side.

Roughly How Laravel-Lang Builds Translation Files

There are actually two major types of translation files: .json and .php types. Since the frontend mainly uses .json files, I’ll focus on those here.

At this point, the dependency resolution from laravel-lang/common should have expanded the following four files:

vendor/laravel-lang/starter-kits/locales/ja/json.json
vendor/laravel-lang/lang/locales/ja/json.json
vendor/laravel-lang/http-statuses/locales/ja/json.json
vendor/laravel-lang/actions/locales/ja/json.json

These are merged together to ultimately form the file lang/ja.json. However, not everything is blindly copied over; there is actually a filtering stage called source defined beforehand. For example, let’s look at the Livewire one.

https://github.com/Laravel-Lang/starter-kits/blob/main/source/livewire/main/livewire.json

Only the keys listed here are picked up and internally expanded, so this mechanism seems intended to filter out unnecessary keys.

Meanwhile, the current React situation looks like this:

https://github.com/Laravel-Lang/starter-kits/blob/main/source/react/main/react.json

…Yeah.

So let’s look at how the Livewire Starter Kit is actually translated by examining the login screen.

Translating the Livewire Starter Kit Login Screen

https://github.com/laravel/livewire-starter-kit/blob/main/resources/views/pages/auth/login.blade.php

In this case, translation hooks are already embedded throughout the UI from the beginning. For example:

<!-- Remember Me -->
<flux:checkbox name="remember" :label="__('Remember me')" :checked="old('remember')" />

<div class="flex items-center justify-end">
  <flux:button variant="primary" type="submit" class="w-full" data-test="login-button">
    {{ __('Log in') }}
  </flux:button>
</div>

As shown, it passes things through PHP’s translation system using __(). Since Livewire is tightly integrated with the backend (essentially operating in a pure Blade-like manner), this approach is possible.

The Quality of Livewire’s Japanese Resources

So does installing the language pack solve everything? Unfortunately, no. At present, the translation quality is extremely poor, or rather, most of it is untranslated.

https://github.com/Laravel-Lang/starter-kits/blob/main/locales/ja/json.json

Since translation files are generated based on this, there’s honestly no way around fixing it. I’ve been sending PRs and discussing things, so maybe it’ll improve somewhat, but who knows...

https://github.com/Laravel-Lang/starter-kits/pull/1902

https://livewire-starter-kit-ja.catatsumuri.org/login

You can view the current proposal using test@example.com / password

As for Inertia.js UIs Like React

Let’s look at the login screen again. Since we compared the Remember me section earlier, here’s just the corresponding part.

https://github.com/laravel/react-starter-kit/blob/main/resources/js/pages/auth/login.tsx#L76-L94

The strings are written directly into the source code, meaning that whether it’s Japanese or any other language, nothing gets translated as-is (naturally).

Conclusion

That is the current state of localization (i18n) in Laravel Starter Kits. Outside of Livewire, things are honestly pretty rough. For English-speaking users, this tends not to become a major issue, but outside that environment... the problems become extremely apparent. I suspect everyone is just aggressively rewriting UIs using AI or similar tools, but I really wish things were handled a little better. For now, I’ve at least tried contributing Japanese resources through PRs, but in the end, what’s actually going to happen here?

DEV Community: catatsumuri

Localized Out of the Box with `laravel new` — i18n for Laravel Starter Kits (React/Vue/Svelte)

For Those Who Just Want to Try It

Try the Demo First

Actual Setup

Prerequisites

Specify the Custom Starter Kit with laravel new

Verify Startup

Switch to Japanese

Recommended Workflow for Multilingual Development

Adding Another Language — French Example

Bonus: Locale Switcher (Language Switching UI)

Closing Thoughts

About the Translation Adapter

Trying Out Laravel Cloud (2) — Quickly Creating Per-Branch Environments in Laravel Cloud

Introduction

Creating a New Environment

Issued URL and Verification

Verification

Summary

Trying Out Laravel Cloud - A Hands-On Guide to Laravel Hosting Starting at $5

What You'll Need

Creating an Account — Sign Up

About "Organizations" in Laravel Cloud

Your First Subscription

Payment

Checking Usage and Spending Limits

Deploying an Application

Be Sure to Visit Settings Before Deploying

Be Sure to Check the Deployments Menu

Deployment

Configuring SQLite (Unofficial)

Final Verification

Conclusion

Laravel Maestro Contributor Tutorial

Introduction

Clone the Repository and Get the Source Tree Locally

Running a Starter Kit Through Laravel Maestro

Start from orchestrator/

The build/ Directory

However, the Actual Kit Is Started from orchestrator/

Practicing Contributions with Maestro

Case 1: Change "Log in" to "Log on" on the Login Page

Change the File in ../build

Commit & PRs Are Made from kits/

Testing

Rewriting the Remaining 7 Variants

Actually Run One Variant and Test It in the Browser

Final Testing

Preparing the Commit and PR

Example: Making a Shared Backend Change

First, Set Up the Authentication Database

Updating Livewire

Livewire Does Not Handle This Through a Controller

Laravel in 2026: Starter Kits, AI SDK, and the End of the Breeze Era

The State of Laravel in April 2026

Executive Summary

Research Assumptions

Comparing the Starter Kit Options

Breeze

Jetstream

React Starter Kit + Inertia

Vue Starter Kit + Inertia

Svelte Starter Kit + Inertia

Livewire Is Not Dead

Laravel’s AI Direction

1-Year Outlook

3-Year Outlook

React + Inertia

Livewire

5-Year Outlook

Final Thoughts

Laravel Starter Kit Localization Is Surprisingly Painful

About Laravel Starter Kits Since Laravel 12

Laravel Starter Kits Actually Come in About Four Flavors

Projects for i18n in Laravel

Laravel’s Built-in Translation Mechanism

About Laravel-Lang

Deploying Into the Actual Project With the lang:add Command

Locale Configuration

Specify the Custom Starter Kit with `laravel new`