> ## Documentation Index
> Fetch the complete documentation index at: https://cloud.laravel.com/docs/llms.txt
> Use this file to discover all available pages before exploring further.

# Monorepos

> Deploy a Laravel application from a monorepo on Laravel Cloud.

## Introduction

Laravel Cloud includes first-class monorepo support. When you create a new application, Cloud analyzes your repository and automatically detects whether it contains a single or multiple applications.

### How it works

If Cloud does not detect a monorepo structure, you proceed through the standard application creation flow without any additional steps.

If Cloud detects a monorepo, it presents the top-level directories in your repository, allowing you to select the one containing your application. Cloud uses that directory as the root for all build and runtime operations such as commands and background processes.

All directories in your repository are accessible during the build, so your application can reference shared packages or sibling directories if needed. Only the selected application directory is deployed, which is why all commands and processes are scoped to it at runtime.

### Deploying multiple applications from the same monorepo

If your monorepo contains more than one application, such as a frontend and a backend, you'll need to create a separate application in Laravel Cloud for each one. Attach the same repository to each application, then select a different root directory during setup so Cloud knows which part of the repository to deploy.

Each application you create is a fully independent Cloud resource with its own environment variables, instances, scaling settings, domains, and attached services, even though they share a single repository. Because Cloud is framework-aware, it may expose different configuration options depending on each application's runtime.

Deploying each application separately allows them to be sized and scaled independently. Your frontend, backend, and other applications often have very different traffic patterns and resource needs, and keeping them as separate applications means you can size, scale, and deploy each one according to its own demands rather than treating them as a single unit.