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 (
5USD) - Growth (
20USD) - Business (
200USD)
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 installshould 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.compassword
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.
Top comments (0)