Laravel Cloud launched in February 2025 as a hosting platform built for one framework. Nineteen months later it is quietly becoming something bigger: a general-purpose platform that still happens to be best at Laravel.
Also Read: Get a LinkedIn OAuth PHP Access Token in Laravel (2026)
The Laravel Cloud docs now describe the product as the deployment platform for Laravel "with support for Symfony, Next.js, Nuxt, Go, Python, and more". On 24 September 2026, Taylor Otwell went further in a live session and deployed five backends in five stacks (Rails, Go, Node, Python and Laravel) to the same platform in about 30 minutes.
Here is what is actually supported today, what is still coming, and what it means if you run a mixed stack.
What Laravel Cloud supports right now
According to the official runtimes documentation, Laravel Cloud now has four runtimes:
| Runtime | Frameworks detected | Versions |
|---|---|---|
| PHP | Laravel, Symfony | 8.2, 8.3, 8.4, 8.5 (8.5 default) |
| JavaScript | Next.js, Nuxt, TanStack Start, Express, Hono, generic Node | Node.js 20/22/24 (24 default), Bun 1.2, Deno 2.2.6 |
| Go | Any Go app with a go.mod | Go 1.24, 1.25, 1.26 (1.26 default) |
| Python | Django, FastAPI, Flask, generic Python | Python 3.10 to 3.14 (3.12 default) |
Cloud detects the framework from your repository when you create an application. A go.mod means Go. A pyproject.toml, requirements.txt, Pipfile or setup.py means Python, with Django, FastAPI or Flask picked out from your dependencies. For JavaScript, the lockfile decides the runtime: bun.lock means Bun, deno.json means Deno, and package-lock.json means Node.js.
What is still on the way
Two stacks are not in the runtimes docs yet:
- Ruby on Rails. Taylor deployed a Rails app in the September live session, and Laravel's own deployment guide lists Rails as supported, but the version is still marked "TBD" and there is no Rails quickstart yet. Treat it as imminent rather than generally available.
- Java (Spring Boot). Laravel says this support is "in progress".
According to the event page, Laravel is working with Rails and Python specialists so each framework gets its own polished setup rather than a generic container.
Which features work outside Laravel
This is the part to read before you move anything. Most of the platform works for every runtime, but two Laravel-flavoured features do not:
| Feature | Laravel / Symfony | Next, Nuxt, Node, Go, Python |
|---|---|---|
| Scale to zero | Yes | Yes |
| Preview environments | Yes | Yes |
| Custom domains | Yes | Yes |
| Object storage | Yes | Yes |
| Worker clusters | Yes | Yes |
| Managed queues | Yes | No |
| Scheduled tasks | Yes | No |
So a FastAPI service can sleep when idle, get a preview environment per pull request and read from an R2 bucket. It cannot use Cloud's managed queues or scheduler. For background work in Python or Go, you would run your own worker process on a worker cluster.
Why Laravel is doing this
The Laracon US 2026 announcement post put it plainly: most Laravel APIs are paired with a JavaScript frontend that lived on a separate host with its own pipeline and bill. Next.js and Nuxt support fixed that first. Python and Go are the logical next step for teams that have a Django admin, a Go microservice or a FastAPI machine-learning endpoint sitting next to their Laravel app.
In the September session, Taylor also argued that AI coding tools make it more practical to pick the right language for each job, even one your team has not used before. If that is how teams now work, a Laravel-only host becomes a limitation. A host that runs everything, with Laravel as the first-class citizen, does not.
Also Read: Renew LinkedIn Access Tokens in Laravel (60-Day Fix)
How it compares with other PaaS options
Multi-language platforms are not new. Upsun, Render, Railway, Fly.io and Heroku have run mixed stacks for years. What Laravel Cloud brings is its existing bundle: scale-to-zero compute that wakes in under 500 milliseconds, managed MySQL and Postgres, Valkey caches, Reverb WebSockets, and one bill and one permission model across every app in an organisation.
The trade-off is breadth. Laravel Cloud deliberately supports a curated list of frameworks rather than "anything in a Dockerfile", so niche stacks are not covered.
Should you move your non-Laravel apps?
It makes sense if:
- you already run Laravel on Cloud and pay a second provider for a Python or Go service,
- your non-Laravel services are HTTP apps that don't need Cloud's managed queues or scheduler,
- you want preview environments across your whole stack from one pull request.
Wait if you depend on Rails today (until it reaches the docs) or need Java.
FAQ
Does Laravel Cloud support Python? Yes. Django, FastAPI and Flask are detected automatically, and other Python apps run as generic Python apps. Python 3.10 to 3.14 are supported.
Does Laravel Cloud support Ruby on Rails? Rails has been demonstrated live and is listed on Laravel's site, but it is not in the runtimes documentation yet and the version is marked TBD.
Can I run Go on Laravel Cloud? Yes. Cloud detects a go.mod, builds a static binary and runs it. Go 1.24, 1.25 and 1.26 are supported.
Do managed queues work with Python or Go? No. Managed queues and scheduled tasks currently work only for Laravel and Symfony.
Related on The Web Tier
- How to deploy Django, FastAPI or Flask on Laravel Cloud
- How to deploy Go and Node.js apps on Laravel Cloud
- Laravel Cloud updates in 2026: every change so far
Sources: Laravel Cloud runtimes docs · Laravel Cloud quickstart · Deploying Rails, Laravel, Go, Node and Python to Laravel Cloud (live session) · How to deploy a Laravel app to Cloud
