# Report Abuse Source: https://cloud.laravel.com/docs/abuse Report abuse and violations of Laravel Cloud terms of service and policies. Please email us at [security@laravel.com](mailto:security@laravel.com) ## Our commitment Your security and safety are our top priorities. All abuse reports are handled with your confidentiality and security guaranteed. All abuse reports are handled sensitively and we follow best practices for disclosing issues responsibly. Laravel adheres to a zero tolerance policy when it comes to abuse and we take immediate action to ensure the security of our platform. # Create application Source: https://cloud.laravel.com/docs/api/applications/create-application https://cloud.laravel.com/api-docs/api.json post /applications Create a new application. # Delete application Source: https://cloud.laravel.com/docs/api/applications/delete-application https://cloud.laravel.com/api-docs/api.json delete /applications/{application} Delete an application and all of its environments. # Delete application avatar Source: https://cloud.laravel.com/docs/api/applications/delete-application-avatar https://cloud.laravel.com/api-docs/api.json delete /applications/{application}/avatar Remove the avatar from an application. # Get application Source: https://cloud.laravel.com/docs/api/applications/get-application https://cloud.laravel.com/api-docs/api.json get /applications/{application} Get a specific application. # List applications Source: https://cloud.laravel.com/docs/api/applications/list-applications https://cloud.laravel.com/api-docs/api.json get /applications Get a list of all applications for the authenticated organization. # Update application Source: https://cloud.laravel.com/docs/api/applications/update-application https://cloud.laravel.com/api-docs/api.json patch /applications/{application} Update an application. # Upload application avatar Source: https://cloud.laravel.com/docs/api/applications/upload-application-avatar https://cloud.laravel.com/api-docs/api.json post /applications/{application}/avatar Upload or replace the avatar for an application. # API authentication for Laravel Cloud Source: https://cloud.laravel.com/docs/api/authentication Authenticate and access the Laravel Cloud API using tokens and credentials. The Laravel Cloud API uses token-based authentication. You can generate an API token from your Laravel Cloud organization settings. Once you have your token, include it in the `Authorization` header of your API requests as follows: ```http theme={null} Authorization: Bearer YOUR_API_TOKEN ``` ### Managing API tokens You can manage your API tokens from your Laravel Cloud organization settings. Navigate to the API tokens section to create, view, and revoke your tokens. API Tokens management interface in Laravel Cloud settings #### Create an API token To create a new API token, follow these steps: 1. Navigate to your Laravel Cloud organization settings 2. Click on the "API tokens" section in the sidebar 3. Click the "Create API Token" button 4. Enter a descriptive name for your token to help you identify its purpose 5. Select an expiration period for the token 6. Click "Create" to generate your new API token Make sure to copy your API token immediately after creation, as it will only be displayed once for security reasons. Store it securely and never share it publicly. #### Revoke an API token To revoke an API token that you no longer need or that may have been compromised, follow these steps: 1. Navigate to your Laravel Cloud organization settings 2. Click on the "API tokens" section in the sidebar 3. Find the API token you want to revoke in the list 4. Click the "Revoke" button next to the token 5. Confirm your password when prompted 6. Click "Revoke API token" to permanently delete the token Once an API token is revoked, it cannot be restored. Any applications using this token will immediately lose access to the API. Make sure to update your applications with a new token before revoking the old one if you need continued access. #### API token expiration API tokens have configurable expiration periods to help maintain security. When creating a new token, you can choose from the following expiration options: * **1 month** - Recommended for short-term projects or testing * **6 months** - Good balance between security and convenience * **1 year** - Suitable for long-term integrations Once a token expires, it will no longer be valid for API requests and you'll need to generate a new one. Make sure to update your applications with the new token before the old one expires. # Create background process Source: https://cloud.laravel.com/docs/api/background-processes/create-background-process https://cloud.laravel.com/api-docs/api.json post /instances/{instance}/background-processes Create a new background process for an instance. # Delete background process Source: https://cloud.laravel.com/docs/api/background-processes/delete-background-process https://cloud.laravel.com/api-docs/api.json delete /background-processes/{backgroundProcess} Delete a background process. # Get background process Source: https://cloud.laravel.com/docs/api/background-processes/get-background-process https://cloud.laravel.com/api-docs/api.json get /background-processes/{backgroundProcess} Get the details of a specific background process. # List background processes Source: https://cloud.laravel.com/docs/api/background-processes/list-background-processes https://cloud.laravel.com/api-docs/api.json get /instances/{instance}/background-processes Get a list of all background processes for the given instance. # Update background process Source: https://cloud.laravel.com/docs/api/background-processes/update-background-process https://cloud.laravel.com/api-docs/api.json patch /background-processes/{backgroundProcess} Update a background process. # Create object storage key Source: https://cloud.laravel.com/docs/api/bucket-keys/create-object-storage-key https://cloud.laravel.com/api-docs/api.json post /buckets/{filesystem}/keys Create a new key for an object storage bucket. # Delete object storage key Source: https://cloud.laravel.com/docs/api/bucket-keys/delete-object-storage-key https://cloud.laravel.com/api-docs/api.json delete /bucket-keys/{filesystemKey} Delete an object storage key. # Get object storage key Source: https://cloud.laravel.com/docs/api/bucket-keys/get-object-storage-key https://cloud.laravel.com/api-docs/api.json get /bucket-keys/{filesystemKey} Get a specific object storage key. # List object storage keys Source: https://cloud.laravel.com/docs/api/bucket-keys/list-object-storage-keys https://cloud.laravel.com/api-docs/api.json get /buckets/{filesystem}/keys Get a list of all keys for a specific object storage bucket. # Update object storage key Source: https://cloud.laravel.com/docs/api/bucket-keys/update-object-storage-key https://cloud.laravel.com/api-docs/api.json patch /bucket-keys/{filesystemKey} Update an object storage key. # Create cache Source: https://cloud.laravel.com/docs/api/caches/create-cache https://cloud.laravel.com/api-docs/api.json post /caches Create a new cache. # Delete cache Source: https://cloud.laravel.com/docs/api/caches/delete-cache https://cloud.laravel.com/api-docs/api.json delete /caches/{cache} Delete a cache. # Get cache Source: https://cloud.laravel.com/docs/api/caches/get-cache https://cloud.laravel.com/api-docs/api.json get /caches/{cache} Get a specific cache. # Get cache metrics Source: https://cloud.laravel.com/docs/api/caches/get-cache-metrics https://cloud.laravel.com/api-docs/api.json get /caches/{cache}/metrics Get metrics for a specific cache. # List all available cache types with their configuration options Source: https://cloud.laravel.com/docs/api/caches/list-all-available-cache-types-with-their-configuration-options https://cloud.laravel.com/api-docs/api.json get /caches/types # List caches Source: https://cloud.laravel.com/docs/api/caches/list-caches https://cloud.laravel.com/api-docs/api.json get /caches Get a list of all caches for the authenticated organization. # Update cache Source: https://cloud.laravel.com/docs/api/caches/update-cache https://cloud.laravel.com/api-docs/api.json patch /caches/{cache} Update a cache. # Laravel Cloud CLI Source: https://cloud.laravel.com/docs/api/cli Deploy and manage your Laravel Cloud applications from the command line. The Laravel Cloud CLI provides a powerful command-line interface for managing your applications, environments, and resources on Laravel Cloud. Whether you are deploying from your terminal or integrating with a CI/CD pipeline, the CLI gives you full control over your Laravel Cloud account. ## Requirements * PHP 8.2 or higher * Composer * Git The [GitHub CLI](https://cli.github.com/) (`gh`) is optional but recommended. It is used by the `ship` command to create a GitHub repository if your project doesn't already have one. ## Installation Install the CLI globally: ```bash theme={null} composer global require laravel/cloud-cli ``` *Note:* Make sure your global vendor binaries directory is in your `$PATH` environment variable, you can read more about this in the [Composer documentation](https://getcomposer.org/doc/03-cli.md#global). ### Shell completions The CLI supports tab completions for Bash, Zsh, and Fish. To generate and install completions for your shell, run: ```bash theme={null} cloud completions ``` You can also target a specific shell directly: ```bash theme={null} cloud completions zsh cloud completions bash cloud completions fish ``` ## Authentication Before using the CLI, you need to authenticate with your Laravel Cloud account. The CLI supports two authentication methods: browser-based OAuth and manual token entry. ### Browser authentication The simplest way to authenticate is through your browser: ```bash theme={null} cloud auth ``` This command opens your default browser, prompts you to authorize the CLI, and stores the resulting API token locally. The token is saved in `~/.config/cloud/config.json`. ### Token authentication You can also manage API tokens directly. This is useful for CI/CD environments or when you prefer to provide tokens manually: ```bash theme={null} # Add a token cloud auth:token --add # List stored tokens cloud auth:token --list # Remove a token cloud auth:token --remove ``` If you have tokens for multiple organizations, the CLI will prompt you to select which organization to use when running commands. ## Quick start The fastest way to get an application running on Laravel Cloud is the `ship` command. From inside your project directory, run: ```bash theme={null} cloud ship ``` This guided flow walks you through creating an application, configuring your environment, and deploying — all in a single command. It detects your repository, prompts for a region and application name, and optionally syncs your `.env` variables, creates databases or caches, and configures features like the scheduler, Octane, or WebSockets. ## Deploying To deploy your application, run the `deploy` command from your project directory: ```bash theme={null} cloud deploy ``` The CLI resolves the target application and environment automatically using your repository configuration. After the deployment starts, the CLI monitors its progress and reports the result in real time. To open your application in the browser after a successful deployment: ```bash theme={null} cloud deploy --open ``` You can also monitor an active deployment separately: ```bash theme={null} cloud deploy:monitor ``` ## Repository configuration To avoid specifying your application and environment on every command, you can save defaults for your repository: ```bash theme={null} cloud repo:config ``` This creates a `.cloud/config.json` file in your project root that stores the `application_id` and `organization_id`. Subsequent commands will use these defaults automatically. ## Managing resources The CLI provides full CRUD operations for Laravel Cloud resources. Command examples below show the most common operations. ### Applications ```bash theme={null} cloud application:list cloud application:get cloud application:create cloud application:update ``` ### Environments ```bash theme={null} cloud environment:list cloud environment:get cloud environment:create cloud environment:update cloud environment:delete ``` To update environment variables interactively or by using command options: ```bash theme={null} cloud environment:variables ``` To view environment logs: ```bash theme={null} cloud environment:logs ``` ### Instances ```bash theme={null} cloud instance:list cloud instance:get cloud instance:create cloud instance:update cloud instance:delete cloud instance:sizes ``` ### Databases ```bash theme={null} cloud database-cluster:list cloud database-cluster:get cloud database-cluster:create cloud database-cluster:update cloud database-cluster:delete ``` You can manage individual databases within a cluster: ```bash theme={null} cloud database:list cloud database:get cloud database:create cloud database:delete ``` To connect to a database locally: ```bash theme={null} cloud database:open ``` Database snapshots and restores are also available: ```bash theme={null} cloud database-snapshot:list cloud database-snapshot:get cloud database-snapshot:create cloud database-snapshot:delete cloud database-restore:create ``` ### Caches ```bash theme={null} cloud cache:list cloud cache:create cloud cache:update cloud cache:delete cloud cache:types ``` ### Object storage ```bash theme={null} cloud bucket:list cloud bucket:get cloud bucket:create cloud bucket:update cloud bucket:delete ``` Bucket keys can be managed separately: ```bash theme={null} cloud bucket-key:list cloud bucket-key:get cloud bucket-key:create cloud bucket-key:update cloud bucket-key:delete ``` ### Domains ```bash theme={null} cloud domain:list cloud domain:create cloud domain:update cloud domain:delete cloud domain:verify ``` ### WebSockets ```bash theme={null} cloud websocket-cluster:list cloud websocket-cluster:get cloud websocket-cluster:create cloud websocket-cluster:update cloud websocket-cluster:delete ``` WebSocket applications within a cluster: ```bash theme={null} cloud websocket-application:list cloud websocket-application:get cloud websocket-application:create cloud websocket-application:update cloud websocket-application:delete ``` ### Background processes ```bash theme={null} cloud background-process:list cloud background-process:get cloud background-process:create cloud background-process:update cloud background-process:delete ``` ### Commands To run a one-off command on an environment: ```bash theme={null} cloud command:run ``` To list previously executed commands: ```bash theme={null} cloud command:list cloud command:get ``` ### Tinker The `tinker` command opens an interactive PHP REPL connected to your Laravel Cloud environment, allowing you to execute PHP code directly against your running application: ```bash theme={null} cloud tinker ``` By default, a multi-line text input is presented in your terminal where you can type and submit PHP code. Each submission is sent to your Cloud environment for execution, and the result is displayed in your terminal. The session remains open so you can continue executing code. #### Editor mode If you prefer to write code in your editor, use the `--editor` option: ```bash theme={null} cloud tinker --editor=code ``` This opens a temporary file in your editor. Every time you save the file, the code is automatically sent to your Cloud environment for execution and the result is displayed in your terminal. The session ends when you close the file. Common editor values include `code`, `subl`, `vim`, and `phpstorm`. If no value is given, the `VISUAL` or `EDITOR` environment variable is used. #### Non-interactive mode To execute a single snippet of PHP code without entering the interactive session, use the `--code` option: ```bash theme={null} cloud tinker --code="echo App\Models\User::count();" ``` This is useful for scripting and CI/CD pipelines. #### Timeout By default, code execution will time out after 60 seconds. You can adjust this with the `--timeout` option: ```bash theme={null} cloud tinker --timeout=120 ``` ## Utility commands Open your application in the Laravel Cloud dashboard: ```bash theme={null} cloud dashboard ``` Open your application in the browser: ```bash theme={null} cloud browser ``` Retrieve Laravel Cloud IP addresses by region: ```bash theme={null} cloud ip:addresses ``` ## Agent skills The CLI can install Laravel Cloud skills for your AI coding agents. Skills are fetched from the `laravel/agent-skills` repository and installed into the appropriate directory for each agent. ```bash theme={null} cloud skills:install ``` The command auto-detects which agents you have configured and prompts you to select which ones to install skills for. Supported agents include Claude, Cursor, Junie, GitHub Copilot, and a generic agent format. ### Global vs. project installation By default, skills are installed globally if you are outside a Laravel Cloud project, or to the current project if the Cloud CLI is detected as a local dependency. You can override this behavior: ```bash theme={null} # Install globally (e.g. ~/.claude/skills) cloud skills:install --global # Install to the current project (e.g. .claude/skills) cloud skills:install --project ``` ### Specifying agents To install skills for specific agents without being prompted: ```bash theme={null} cloud skills:install --agent=claude --agent=cursor ``` ### Overwriting existing skills If skills have already been installed, use the `--force` flag to overwrite them: ```bash theme={null} cloud skills:install --force ``` ## JSON output Many commands support a `--json` flag for machine-readable output, which is useful for automation and CI/CD pipelines: ```bash theme={null} cloud instance:list --json cloud environment:variables --json --action=set --key=APP_ENV --value=production ``` In non-interactive environments (such as GitHub Actions), interactive prompts are disabled automatically. # Get command Source: https://cloud.laravel.com/docs/api/commands/get-command https://cloud.laravel.com/api-docs/api.json get /commands/{command} Get the details of a specific command. # List commands Source: https://cloud.laravel.com/docs/api/commands/list-commands https://cloud.laravel.com/api-docs/api.json get /environments/{environment}/commands Get a list of all commands for the given environment. # Run command Source: https://cloud.laravel.com/docs/api/commands/run-command https://cloud.laravel.com/api-docs/api.json post /environments/{environment}/commands Run a command on the given environment. # Create database cluster Source: https://cloud.laravel.com/docs/api/database-clusters/create-database-cluster https://cloud.laravel.com/api-docs/api.json post /databases/clusters Create a new database cluster. A default database will also be created and returned on the `databases` relationship. `schemas` is deprecated. # Delete database cluster Source: https://cloud.laravel.com/docs/api/database-clusters/delete-database-cluster https://cloud.laravel.com/api-docs/api.json delete /databases/clusters/{database} Delete a database cluster. # Get database cluster Source: https://cloud.laravel.com/docs/api/database-clusters/get-database-cluster https://cloud.laravel.com/api-docs/api.json get /databases/clusters/{database} Get a specific database cluster. The `schemas` relationship is deprecated. # Get database cluster metrics Source: https://cloud.laravel.com/docs/api/database-clusters/get-database-cluster-metrics https://cloud.laravel.com/api-docs/api.json get /databases/clusters/{database}/metrics Get metrics for a specific database cluster. # List database clusters Source: https://cloud.laravel.com/docs/api/database-clusters/list-database-clusters https://cloud.laravel.com/api-docs/api.json get /databases/clusters Get a list of all database clusters for the authenticated organization. The `schemas` relationship is deprecated. # List database types Source: https://cloud.laravel.com/docs/api/database-clusters/list-database-types https://cloud.laravel.com/api-docs/api.json get /databases/types List all available database types with their configuration schemas. # Update database cluster Source: https://cloud.laravel.com/docs/api/database-clusters/update-database-cluster https://cloud.laravel.com/api-docs/api.json patch /databases/clusters/{database} Update a database cluster. # Create a database restore Source: https://cloud.laravel.com/docs/api/database-restores/create-a-database-restore https://cloud.laravel.com/api-docs/api.json post /databases/clusters/{database}/restore Restore a database cluster from a point in time or snapshot. Returns the newly created database. # Create a database snapshot Source: https://cloud.laravel.com/docs/api/database-snapshots/create-a-database-snapshot https://cloud.laravel.com/api-docs/api.json post /databases/clusters/{database}/snapshots Create a new manual snapshot for a database cluster. # Delete a database snapshot Source: https://cloud.laravel.com/docs/api/database-snapshots/delete-a-database-snapshot https://cloud.laravel.com/api-docs/api.json delete /database-snapshots/{databaseSnapshot} # Get a database snapshot Source: https://cloud.laravel.com/docs/api/database-snapshots/get-a-database-snapshot https://cloud.laravel.com/api-docs/api.json get /database-snapshots/{databaseSnapshot} Get a specific database snapshot. # List database snapshots Source: https://cloud.laravel.com/docs/api/database-snapshots/list-database-snapshots https://cloud.laravel.com/api-docs/api.json get /databases/clusters/{database}/snapshots Get a list of all snapshots for a specific database cluster. # Create database Source: https://cloud.laravel.com/docs/api/databases-legacy/create-database https://cloud.laravel.com/api-docs/api.json post /databases Use POST /databases/clusters instead. # Delete database Source: https://cloud.laravel.com/docs/api/databases-legacy/delete-database https://cloud.laravel.com/api-docs/api.json delete /databases/{database} Use DELETE /databases/clusters/{database} instead. # Get database Source: https://cloud.laravel.com/docs/api/databases-legacy/get-database https://cloud.laravel.com/api-docs/api.json get /databases/{database} Use GET /databases/clusters/{database} instead. # List databases Source: https://cloud.laravel.com/docs/api/databases-legacy/list-databases https://cloud.laravel.com/api-docs/api.json get /databases Use GET /databases/clusters instead. # Update database Source: https://cloud.laravel.com/docs/api/databases-legacy/update-database https://cloud.laravel.com/api-docs/api.json patch /databases/{database} Use PATCH /databases/clusters/{database} instead. # Create a database Source: https://cloud.laravel.com/docs/api/databases/create-a-database https://cloud.laravel.com/api-docs/api.json post /databases/clusters/{database}/databases Create a new database in a database cluster. # Delete a database Source: https://cloud.laravel.com/docs/api/databases/delete-a-database https://cloud.laravel.com/api-docs/api.json delete /databases/clusters/{database}/databases/{schema} Delete a database from a database cluster. # Get a database Source: https://cloud.laravel.com/docs/api/databases/get-a-database https://cloud.laravel.com/api-docs/api.json get /databases/clusters/{database}/databases/{schema} Get a specific database. # List databases Source: https://cloud.laravel.com/docs/api/databases/list-databases https://cloud.laravel.com/api-docs/api.json get /databases/clusters/{database}/databases Get a list of all databases for a specific database cluster. # List dedicated clusters Source: https://cloud.laravel.com/docs/api/dedicated-clusters/list-dedicated-clusters https://cloud.laravel.com/api-docs/api.json get /dedicated-clusters Get a list of all dedicated clusters for the authenticated organization. # Get deployment Source: https://cloud.laravel.com/docs/api/deployments/get-deployment https://cloud.laravel.com/api-docs/api.json get /deployments/{deployment} Get the details of a specific deployment. # Get deployment logs Source: https://cloud.laravel.com/docs/api/deployments/get-deployment-logs https://cloud.laravel.com/api-docs/api.json get /deployments/{deployment}/logs Get the build and deploy logs for a specific deployment. # Initiate deployment Source: https://cloud.laravel.com/docs/api/deployments/initiate-deployment https://cloud.laravel.com/api-docs/api.json post /environments/{environment}/deployments Initiate a deployment for the given environment. # List deployments Source: https://cloud.laravel.com/docs/api/deployments/list-deployments https://cloud.laravel.com/api-docs/api.json get /environments/{environment}/deployments Get a list of all deployments for the given environment. # Create domain Source: https://cloud.laravel.com/docs/api/domains/create-domain https://cloud.laravel.com/api-docs/api.json post /environments/{environment}/domains Create a new domain for the given environment. After creating the domain, you'll have to add the required DNS records to your DNS provider. This might be a 2-step process, depending on the verification method used. You can check the required DNS records in the response of this endpoint, and you can verify the domain using the "verify" query parameter in the "Get domain" endpoint. # Delete domain Source: https://cloud.laravel.com/docs/api/domains/delete-domain https://cloud.laravel.com/api-docs/api.json delete /domains/{domain} Delete a specific domain. # Get domain Source: https://cloud.laravel.com/docs/api/domains/get-domain https://cloud.laravel.com/api-docs/api.json get /domains/{domain} Show a specific domain. # List domains Source: https://cloud.laravel.com/docs/api/domains/list-domains https://cloud.laravel.com/api-docs/api.json get /environments/{environment}/domains List all domains for the given environment. # Update domain Source: https://cloud.laravel.com/docs/api/domains/update-domain https://cloud.laravel.com/api-docs/api.json patch /domains/{domain} Update a specific domain. # Verify a domain Source: https://cloud.laravel.com/docs/api/domains/verify-a-domain https://cloud.laravel.com/api-docs/api.json post /domains/{domain}/verify Checks whether the DNS records for a given domain have been properly set up. # Add environment variables Source: https://cloud.laravel.com/docs/api/environments/add-environment-variables https://cloud.laravel.com/api-docs/api.json post /environments/{environment}/variables Add environment variables to an environment. # Create environment Source: https://cloud.laravel.com/docs/api/environments/create-environment https://cloud.laravel.com/api-docs/api.json post /applications/{application}/environments Create a new environment. # Delete environment Source: https://cloud.laravel.com/docs/api/environments/delete-environment https://cloud.laravel.com/api-docs/api.json delete /environments/{environment} Delete an environment. # Delete environment variables Source: https://cloud.laravel.com/docs/api/environments/delete-environment-variables https://cloud.laravel.com/api-docs/api.json post /environments/{environment}/variables/delete Remove specific environment variables by key name. This operation is atomic: if any of the specified keys do not exist, no variables will be deleted and an error will be returned indicating which keys were missing. # Get environment Source: https://cloud.laravel.com/docs/api/environments/get-environment https://cloud.laravel.com/api-docs/api.json get /environments/{environment} Get a specific environment. # Get environment metrics Source: https://cloud.laravel.com/docs/api/environments/get-environment-metrics https://cloud.laravel.com/api-docs/api.json get /environments/{environment}/metrics Get metrics for a specific environment. # List environment logs Source: https://cloud.laravel.com/docs/api/environments/list-environment-logs https://cloud.laravel.com/api-docs/api.json get /environments/{environment}/logs Get a list of logs for the given environment. # List environments Source: https://cloud.laravel.com/docs/api/environments/list-environments https://cloud.laravel.com/api-docs/api.json get /applications/{application}/environments Get a list of all environments for the given application. # Purge edge cache Source: https://cloud.laravel.com/docs/api/environments/purge-edge-cache https://cloud.laravel.com/api-docs/api.json post /environments/{environment}/purge-edge-cache Purge the edge cache for all domains associated with the environment. # Start environment Source: https://cloud.laravel.com/docs/api/environments/start-environment https://cloud.laravel.com/api-docs/api.json post /environments/{environment}/start Start an environment and trigger a deployment. # Stop environment Source: https://cloud.laravel.com/docs/api/environments/stop-environment https://cloud.laravel.com/api-docs/api.json post /environments/{environment}/stop Stop an environment and cancel any in-progress deployment. # Update environment Source: https://cloud.laravel.com/docs/api/environments/update-environment https://cloud.laravel.com/api-docs/api.json patch /environments/{environment} Update an environment. # Create instance Source: https://cloud.laravel.com/docs/api/instances/create-instance https://cloud.laravel.com/api-docs/api.json post /environments/{environment}/instances Create a new instance for an environment. # Delete a managed queue failed job Source: https://cloud.laravel.com/docs/api/instances/delete-a-managed-queue-failed-job https://cloud.laravel.com/api-docs/api.json delete /instances/{instance}/failed-jobs/{jobId} Permanently remove a failed job from the given managed queue. # Delete instance Source: https://cloud.laravel.com/docs/api/instances/delete-instance https://cloud.laravel.com/api-docs/api.json delete /instances/{instance} Delete an instance. # Get instance Source: https://cloud.laravel.com/docs/api/instances/get-instance https://cloud.laravel.com/api-docs/api.json get /instances/{instance} Get the details of a specific instance. # List instance sizes Source: https://cloud.laravel.com/docs/api/instances/list-instance-sizes https://cloud.laravel.com/api-docs/api.json get /instances/sizes List all available instance sizes grouped by category. # List instances Source: https://cloud.laravel.com/docs/api/instances/list-instances https://cloud.laravel.com/api-docs/api.json get /environments/{environment}/instances Get a list of all instances for the given environment. # List managed queue failed jobs Source: https://cloud.laravel.com/docs/api/instances/list-managed-queue-failed-jobs https://cloud.laravel.com/api-docs/api.json get /instances/{instance}/failed-jobs Get a list of the jobs that have failed on the given managed queue. # Pause a managed queue Source: https://cloud.laravel.com/docs/api/instances/pause-a-managed-queue https://cloud.laravel.com/api-docs/api.json post /instances/{instance}/pause Stop dispatching jobs to the queue's workers; queued messages are retained until it is resumed. # Purge a managed queue Source: https://cloud.laravel.com/docs/api/instances/purge-a-managed-queue https://cloud.laravel.com/api-docs/api.json post /instances/{instance}/purge Permanently delete all messages currently in the queue. This cannot be undone. # Resume a managed queue Source: https://cloud.laravel.com/docs/api/instances/resume-a-managed-queue https://cloud.laravel.com/api-docs/api.json post /instances/{instance}/resume Resume dispatching jobs to the queue's workers after it was paused. # Retry a managed queue failed job Source: https://cloud.laravel.com/docs/api/instances/retry-a-managed-queue-failed-job https://cloud.laravel.com/api-docs/api.json post /instances/{instance}/failed-jobs/{jobId}/retry Re-queue a failed job so it is processed again. # Set the default managed queue Source: https://cloud.laravel.com/docs/api/instances/set-the-default-managed-queue https://cloud.laravel.com/api-docs/api.json post /instances/{instance}/default Make this queue the environment's default, used when a job does not specify a queue. # Update instance Source: https://cloud.laravel.com/docs/api/instances/update-instance https://cloud.laravel.com/api-docs/api.json patch /instances/{instance} Update an instance. # Laravel Cloud API Source: https://cloud.laravel.com/docs/api/introduction Use the Laravel Cloud API to manage applications, environments, and resources programmatically. The Laravel Cloud API lets you manage your Laravel Cloud organization, applications, environments, and resources programmatically. If you prefer a terminal workflow, the [Laravel Cloud CLI](/docs/api/cli) is built on top of this API and provides an interactive command-line experience. ## Base URL The base URL for the Laravel Cloud API is: ``` https://cloud.laravel.com/api ``` ## Authentication All API requests require a bearer token in the `Authorization` header. See [API authentication](/docs/api/authentication) for setup instructions. ## Make your first request Once you have a token, you can make requests directly to the API. The following example returns a JSON:API list of your applications: ```bash theme={null} curl https://cloud.laravel.com/api/applications \ -H "Authorization: Bearer YOUR_API_TOKEN" \ -H "Accept: application/json" ``` ## Next steps * Review [API authentication](/docs/api/authentication) for token setup and security guidance. * Explore [Laravel Cloud CLI](/docs/api/cli) if you want to work from the terminal. * Browse the endpoint reference in the API sidebar to see available resources and request schemas. # Get organization Source: https://cloud.laravel.com/docs/api/meta/get-organization https://cloud.laravel.com/api-docs/api.json get /meta/organization Get details about the currently authenticated organization. # List regions Source: https://cloud.laravel.com/docs/api/meta/list-regions https://cloud.laravel.com/api-docs/api.json get /meta/regions List all available cloud regions. # Create object storage bucket Source: https://cloud.laravel.com/docs/api/object-storage-buckets/create-object-storage-bucket https://cloud.laravel.com/api-docs/api.json post /buckets Create a new object storage bucket with an initial key. # Delete object storage bucket Source: https://cloud.laravel.com/docs/api/object-storage-buckets/delete-object-storage-bucket https://cloud.laravel.com/api-docs/api.json delete /buckets/{filesystem} Delete an object storage bucket. # Get object storage bucket Source: https://cloud.laravel.com/docs/api/object-storage-buckets/get-object-storage-bucket https://cloud.laravel.com/api-docs/api.json get /buckets/{filesystem} Get a specific object storage bucket. # List object storage buckets Source: https://cloud.laravel.com/docs/api/object-storage-buckets/list-object-storage-buckets https://cloud.laravel.com/api-docs/api.json get /buckets Get a list of all object storage buckets for the authenticated organization. # Update object storage bucket Source: https://cloud.laravel.com/docs/api/object-storage-buckets/update-object-storage-bucket https://cloud.laravel.com/api-docs/api.json patch /buckets/{filesystem} Update an object storage bucket. # Get usage Source: https://cloud.laravel.com/docs/api/usage/get-usage https://cloud.laravel.com/api-docs/api.json get /usage Get billing and usage data for the authenticated organization. # Create WebSocket application Source: https://cloud.laravel.com/docs/api/websocket-applications/create-websocket-application https://cloud.laravel.com/api-docs/api.json post /websocket-servers/{websocketServer}/applications Create a new application for a WebSocket cluster. # Delete WebSocket application Source: https://cloud.laravel.com/docs/api/websocket-applications/delete-websocket-application https://cloud.laravel.com/api-docs/api.json delete /websocket-applications/{websocketApplication} Delete a WebSocket application. # Get WebSocket application Source: https://cloud.laravel.com/docs/api/websocket-applications/get-websocket-application https://cloud.laravel.com/api-docs/api.json get /websocket-applications/{websocketApplication} Get a specific WebSocket application including credentials. # Get WebSocket application metrics Source: https://cloud.laravel.com/docs/api/websocket-applications/get-websocket-application-metrics https://cloud.laravel.com/api-docs/api.json get /websocket-applications/{websocketApplication}/metrics Get metrics for a specific WebSocket application. # List WebSocket applications Source: https://cloud.laravel.com/docs/api/websocket-applications/list-websocket-applications https://cloud.laravel.com/api-docs/api.json get /websocket-servers/{websocketServer}/applications Get a list of all applications for a specific WebSocket cluster. # Update WebSocket application Source: https://cloud.laravel.com/docs/api/websocket-applications/update-websocket-application https://cloud.laravel.com/api-docs/api.json patch /websocket-applications/{websocketApplication} Update a WebSocket application. # Create WebSocket cluster Source: https://cloud.laravel.com/docs/api/websocket-clusters/create-websocket-cluster https://cloud.laravel.com/api-docs/api.json post /websocket-servers Create a new WebSocket cluster with a default application. # Delete WebSocket cluster Source: https://cloud.laravel.com/docs/api/websocket-clusters/delete-websocket-cluster https://cloud.laravel.com/api-docs/api.json delete /websocket-servers/{websocketServer} Delete a WebSocket cluster and all its applications. # Get WebSocket cluster Source: https://cloud.laravel.com/docs/api/websocket-clusters/get-websocket-cluster https://cloud.laravel.com/api-docs/api.json get /websocket-servers/{websocketServer} Get a specific WebSocket cluster. # Get WebSocket cluster metrics Source: https://cloud.laravel.com/docs/api/websocket-clusters/get-websocket-cluster-metrics https://cloud.laravel.com/api-docs/api.json get /websocket-servers/{websocketServer}/metrics Get metrics for a specific WebSocket cluster. # List WebSocket clusters Source: https://cloud.laravel.com/docs/api/websocket-clusters/list-websocket-clusters https://cloud.laravel.com/api-docs/api.json get /websocket-servers Get a list of all WebSocket clusters for the authenticated organization. # Update WebSocket cluster Source: https://cloud.laravel.com/docs/api/websocket-clusters/update-websocket-cluster https://cloud.laravel.com/api-docs/api.json patch /websocket-servers/{websocketServer} Update a WebSocket cluster. # Applications Source: https://cloud.laravel.com/docs/applications ## Introduction Applications represent a Laravel application that is deployed to Laravel Cloud. Applications can be created from official [Laravel starter kits](https://laravel.com/starter-kits) or from existing GitHub, Bitbucket, or GitLab repositories. Applications can contain many environments and resources. ## Creating applications Laravel Cloud offers two ways to create applications: 1. **From Starter Kits** - Bootstrap a new application using official Laravel starter kits 2. **From Existing Repository** - Import and deploy from your existing Git repository Both methods require selecting a region where your application will be deployed. Currently, an application can only be deployed to a single region at a time. Laravel Cloud will automatically create a default [environment](/docs/environments) for your application regardless of the creation method you choose. Applications cannot be transferred between organizations once created. Applications are permanently associated with the organization they are created in. ### Creating from starter kits Laravel Cloud supports creating applications from official [Laravel starter kits](https://laravel.com/starter-kits), allowing you to deploy a production-ready Laravel application in minutes without needing an existing repository. #### Available starter kits Laravel Cloud provides the following official starter kit templates: * **Laravel** - A new, empty Laravel application * **[React Starter Kit](https://laravel.com/docs/12.x/starter-kits#react)** - React, TypeScript, Inertia, shadcn/ui * **[Vue Starter Kit](https://laravel.com/docs/12.x/starter-kits#vue-customization)** - Vue, TypeScript, Inertia, shadcn-vue * **[Livewire Starter Kit](https://laravel.com/docs/12.x/starter-kits#livewire-customization)** - Livewire, Laravel Volt, Flux UI #### Creating from a starter kit When creating an application from a starter kit: 1. Select "Use a template" from the application creation page 2. Choose your desired starter kit template 3. Configure your Git provider account (if not already connected) 4. Set your repository name and choose visibility (private or public) 5. Assign an application name 6. Select your deployment region The starter kit will automatically create a new repository in your connected Git provider account, clone the official Laravel starter kit code, and set up your application for deployment. Starter kit applications work exactly like any other Laravel application on Laravel Cloud. Once deployed, you can customize, extend, and deploy changes just like applications created from existing repositories. ### Creating from existing repository When creating an application from an existing repository, you will need to select a source control repository that the application should be deployed from, assign the application a name, and select a region. If you have not already linked a source control provider account to your organization, you will be prompted to do so when you create your application. Typically, your Laravel Cloud organization structure should mirror your source control provider organization structure. After a source control provider has been authenticated, the repository (or repositories) selected become available for all users in the organization to view and create applications from. ### Regions Laravel Cloud currently supports the following application regions: * US East (Virginia) / `us-east-1` * US East (Ohio) / `us-east-2` * CA Central (Central) / `ca-central-1` * EU Central (Frankfurt) / `eu-central-1` * EU West (Ireland) / `eu-west-1` * EU West (London) / `eu-west-2` * Asia Pacific (Singapore) / `ap-southeast-1` * Asia Pacific (Sydney) / `ap-southeast-2` * Asia Pacific (Tokyo) / `ap-northeast-1` For minimal latency, you should ensure that your application and its associated resources exist within the same region. ## Deleting applications When deleting applications, all environments within that application will be deleted; however, resources such as databases, key-value stores ,and object storage buckets are not deleted, since they may be used by other applications within the environment. To delete these resources, navigate to your organization's "Resources" tab. ## Troubleshooting ### Reconnect Git repository Applications can lose their connection to a Git repository if Laravel Cloud's API access is revoked from within the source control provider. When this happens, your application's environments can no longer deploy your latest changes. Follow these steps to restore your Git connection: 1. Navigate to your applications "Settings" page. 2. Click the "Not connected" button next to "Git repository". 3. Click the "Source control provider" dropdown to select an existing source control provider or connect a new one by clicking "Add account". 4. Select the right repository, click "Set repository", then click "Save". Your application's Git repository is now restored and you can resume deploying fresh code to your environments. In most cases environment branches will be restored automatically; however, there may be some cases where environment branches need to be manually selected and saved via the environment "Settings" tab. # Changelog Source: https://cloud.laravel.com/docs/changelog See the latest Laravel Cloud updates, improvements, and platform changes. ## Scale to Zero and New Pricing Scale to Zero Laravel Cloud now offers a new generation of Flex compute that can scale to zero, sleeping when your application is idle and waking in under 500 milliseconds when a request arrives. Your scheduled tasks continue running and queued jobs keep processing while the environment sleeps. Flex compute, Serverless Postgres, and Laravel Valkey can sleep and wake together so you only pay for what you use. Alongside Scale to Zero, we've refreshed our plans: * The new **Starter plan** is \$5/mo with \$5 in monthly usage credits and a free first month. * Every paid plan now includes \$5 in monthly usage credits. * **Spending limits** let you set a hard monthly cap so your bill never exceeds your budget. * **Custom domains** are now counted per organization, with additional domains billed at \$0.25 per domain per month. [Read the compute documentation](/docs/compute#scale-to-zero) to learn more. ## Managed Queues Managed queues Managed queues are now generally available. Laravel Cloud provisions the queue, runs workers on dedicated instances, and automatically scales them based on the work waiting to be processed — including scaling to zero when your queue is idle, so you only pay for compute when jobs are actually running. Each managed queue is independent, with its own pool of workers, instance size, and scaling configuration. You also get a built-in failed jobs dashboard with retry tooling, so background work is isolated from your web traffic and easy to operate. [Read the queues documentation](/docs/queues#managed-queues) to learn more. ## HTTP Basic Authentication HTTP basic authentication Protect staging environments, preview environments, private demo environments, etc with HTTP basic authentication. When enabled, visitors must enter the username `admin` and the environment password before traffic reaches your application. This feature is available on the Growth plan or higher, and can help prevent unauthorized visitors or automated bots from waking hibernating environments. [Read the environment documentation](/docs/environments#http-basic-authentication) to learn more. ## Roles & Permissions Roles and permissions Give every member of your organization the right level of access with role-based access control. Basic RBAC is available on every plan with a set of predefined team roles designed to match how most teams already work. On the Business and Enterprise plans, Advanced RBAC unlocks custom roles, application and environment-level access, and the new Restricted role — perfect for contractors, auditors, or teammates who should only see a specific slice of your organization. [Read the roles and permissions documentation](/docs/rbac) to learn more. ## Dedicated Edge Network Enhancements Dedicated Edge Network rules Catch the traffic costing you money or causing problems. Surface top IPs and paths at your edge, turn them into firewall or cache rules in a click, and watch each rule take effect in real time. ## Mobile Cloud is Here Laravel Cloud on a phone: environment overview with project, repository, and Deploy The Laravel Cloud experience is now fine-tuned for any screen. Move between environments, manage resources, watch deployments, and ship releases from wherever you are. Perfect for on-the-go deployments and AI workflows. ## Redesigned Usage Page Redesigned Usage Page The Usage page has been redesigned to make it easier to understand what your organization is spending and where that spend is coming from. You can now review a cleaner summary of your current spend, bandwidth usage, credits, and billing alerts, then drill down into resource costs and application-level compute usage by environment. The new layout also makes it easier to spot the clusters, resources, and add-ons contributing to your bill during the selected billing period. [Read the usage documentation](/docs/usage) to learn more. ## Scheduled Autoscaling Scheduled autoscaling Scheduled autoscaling is now available on the Business and Enterprise plans. You can create one-time or recurring schedules that temporarily adjust your minimum and maximum replicas, as well as your CPU and memory thresholds, before predictable traffic arrives. This makes it easy to prepare for launches, promotions, business hours, and other recurring traffic patterns without manually changing your baseline scaling settings. Each schedule uses its own timezone, and Laravel Cloud automatically applies the one that matches the current time. [Read the compute documentation](/docs/compute#scheduled-autoscaling) to learn how to configure scheduled autoscaling. ## Sign In with GitHub Github SSO GitHub SSO is here. Sign in or create your account with GitHub, and since we already use that connection for source control, your repos come with you. Go from sign-up to first deploy faster than ever. ## Try Laravel Cloud for Free Try Laravel Cloud for Free Start shipping on Laravel Cloud with \$5 in free usage credits, automatically applied to your account the moment you sign up. Deploy your first applications, spin up databases, caches, and more, on us. Want a completely free trial? Our Starter plan has no subscription fee. Your \$5 in credits is all you need to get started, no questions asked. Credits are valid for 14 days. When they run out or expire, you'll simply be billed for what you use. [Sign up](https://cloud.laravel.com/sign-up) or [read the docs](/docs/free-trial) to learn more. ## Same Git Account, Multiple Organizations and Users Try Laravel Cloud for Free Git connections are now stored per user instead of per organization. The same Git account can be connected to multiple Cloud users and organizations at once. * **One user, many orgs.** Connect once and use your Git account across every organization you belong to. * **One git account, many Cloud users.** Connect the same git provider (e.g. your personal GitHub) to multiple Cloud user accounts. Each Cloud account and org stays separate, but they can all use the same git source. To use the new model, reconnect from your organization's git provider settings. [Learn more about source control connections](/docs/source-control). ## Laravel Cloud API: Programmable Infra for Teams and AI Agents Laravel Cloud API You can now manage your entire Laravel Cloud infrastructure programmatically with the Laravel Cloud API. Our API covers deployments, environments, databases, caches, object storage, and scaling for CI/CD integration, infrastructure-as-code workflows, and AI agents that provision resources or query status on your behalf. [Explore the API documentation](https://cloud.laravel.com/docs/api/introduction). ## New CLI: Deploy and Manage from Your Terminal Laravel Cloud CLI You can now run and script Laravel Cloud operations directly from the command line. The CLI provides smart defaults for quick setup and full control when you need it. [Learn more in the CLI documentation](https://cloud.laravel.com/docs/api/cli). ## MySQL 8.0 End of Life: Upgrade to 8.4 MySQL 8.4 Upgrade If your application is currently running on Laravel MySQL 8.0, please be aware that our MySQL 8.0 database version will reach end of life in April 2026 and will no longer receive security updates. To keep your database and application safe, we recommend upgrading to MySQL 8.4. MySQL 8.4 is the current long-term support release and ensures continued security updates, performance improvements, and long-term stability for your workloads on Laravel Cloud. Before upgrading, be sure to create a backup of your database. For complete upgrade instructions and guidance, please [visit the documentation](https://cloud.laravel.com/docs/knowledge-base/upgrade-mysql-to-84). For additional context and walkthroughs, you can also watch this [Laravel Cloud Office Hours](https://www.youtube.com/live/S0DQmy8sBkY?si=JRmOqIHOSaRBAjpY) session. To avoid thinking about this in the future, we also recommend [setting up a maintenance window](https://cloud.laravel.com/docs/resources/databases/laravel-mysql#maintenance-window) for your database. This allows Laravel Cloud to apply updates automatically at a time that works for you, so you can concentrate on shipping. * Sign in with Google SSO * Redesigned navigation * RDS Replicas, Postgres, Mysql now available for Private Cloud * File explorer for bucket storage ## Cloud API Expanded: Databases, Caches, Buckets, and WebSockets Cloud API Expanded The Laravel Cloud API now supports additional resources, including database clusters, caches, object storage buckets (and keys), and WebSocket clusters and applications. This expansion gives you programmatic access to more of your infrastructure, enabling you to automate provisioning, integrate Cloud into your CI/CD pipelines, and build custom tooling around your deployment workflows. Check out the [API documentation](https://cloud.laravel.com/docs/api/introduction) to explore the available endpoints and learn how to get started. ## Valkey Now Generally Available Laravel Valkey Generally Available Laravel Valkey is now generally available on Laravel Cloud. With Valkey, you can provision fully managed, scalable cache instances for your Laravel applications with the same reliability and performance you expect from Cloud’s managed services. Its full compatibility with Redis protocols and commands allows for a seamless transition for existing Redis users. Building Laravel Valkey in-house has enabled us to tune every dial to ensure our solution outperforms standard Redis-compatible offerings: * Our benchmarks show Laravel Valkey delivers 20-50% lower latency than similar competitor offerings. * We’ve included a generous request size limit that is 5x to 20x larger than industry standards for the same price point as other providers. Get started by creating a new Valkey cache in Laravel Cloud. [Read the docs to learn more](https://cloud.laravel.com/docs/resources/caches#laravel-valkey). ## Private Cloud Now Available Laravel Private Cloud [Laravel Private Cloud](https://cloud.laravel.com/enterprise) offers fully isolated, enterprise-grade infrastructure operated by Laravel. Get your own dedicated Kubernetes cluster in a private AWS account with dedicated compute, private networking, static outbound IPs, and optional managed RDS databases. **Key benefits:** * **Dedicated infrastructure:** Isolated compute and networking with predictable performance. * **Private Networking:** Connect to AWS services privately with reduced latency. * **Dedicated outbound IPs:** Customer-specific IPs for whitelisting and compliance. * **High availability:** Three nodes across availability zones with automatic failover. * **Built for compliance:** SOC 2 Type II certified, designed for HIPAA and PCI-DSS. * **Fully managed:** Laravel handles operations so you can focus on your product. Ideal for regulated industries and organizations with strict security or performance requirements. Includes Business Plan, 24/7 Artisan Support, and dedicated infrastructure. Custom pricing, typically cost-effective for \$2,000+/month workloads. [Check out the docs](https://cloud.laravel.com/docs/private-cloud) or [contact sales](https://cloud.laravel.com/enterprise) to learn more. * Start/stop environments now in the Cloud API * Cloud API supports token expiration * Accessibility updates * Domain verification improvements * Fixed validation error on billing alerts ## New: Billing Alerts Billing Alerts Stay in control of your cloud spending with billing alerts. You can now configure notifications to alert you when you cross spending thresholds, helping you manage your budget proactively and avoid unexpected costs. Learn more in the [Billing Alerts documentation](/docs/billing-alerts). * Added cache details and metrics pages, with more consistent canvas actions * Renamed "filesystems" to "buckets" across the UI and API, and added a bucket details page * Valkey now supports configuring an eviction policy * Improved Valkey auto-upgrade * Improved billing alerts * Multiple small deployment and UI polish improvements * Require password to delete resources * Fixed WebSocket application "Edit settings" button * Fixed cache upgrade notification labelling ## Laravel Reverb-Powered WebSocket Is Now Generally Available Laravel Reverb WebSocket GA We're excited to announce that [WebSockets for Laravel Cloud](https://cloud.laravel.com/docs/resources/websockets) is now generally available! Powered by Reverb, Laravel's first-party WebSocket server, you can now bring blazing-fast, scalable real-time communication to your applications. Deploying Reverb on Laravel Cloud is effortless. Just enable it in your project settings, and Cloud handles the rest, including providing you with a handy dashboard so you can keep an eye on your WebSocket connections. With Reverb, you can build real-time features like live notifications, chat systems, and collaborative tools with the simplicity and elegance you expect from Laravel. It integrates seamlessly with Laravel's broadcasting system and provides a drop-in replacement for services like Pusher and Ably. Check out the [Reverb documentation](/docs/resources/websockets) to get started. ## Valkey Now Available in Developer Preview Laravel Valkey Developer Preview Laravel Valkey is now available in developer preview on Laravel Cloud! Valkey is a high-performance, open-source key-value data store that serves as a powerful alternative to Redis, offering the same performance speed and rich feature set you rely on. As a community-driven fork of Redis, Valkey maintains full compatibility with Redis commands and protocols, making it a seamless drop-in replacement for your existing Redis workloads. From caching and session management to queues and real-time analytics, it delivers the performance and reliability your applications demand. During the developer preview, you can experiment with Valkey on Laravel Cloud and experience its benefits firsthand. We're committed to supporting open-source infrastructure, and Valkey represents our investment in providing you with the best tools for building modern web applications. [Enable Laravel Valkey in your project settings](https://cloud.laravel.com/sign-in) and let us know what you think, or [check out the docs](https://cloud.laravel.com/docs/resources/caches#laravel-valkey) to learn more. ## Introducing the Canada Region Canada Region We're pleased to announce that Laravel Cloud is now available in the Canada region (ca-central)! Located in Central Canada, this new region brings Laravel Cloud's powerful deployment platform closer to our Canadian users and anyone serving customers in Canada. With the Canada region, you can deploy your Laravel applications with reduced latency for Canadian users while ensuring compliance with data residency requirements. Deploying to Canada is simple: just select the ca-central region when creating a new project or provisioning new servers. All of Laravel Cloud's features are fully available in this new region, including automatic scaling, zero-downtime deployments, and managed databases. [See all the regions available in Laravel Cloud](https://cloud.laravel.com/docs/applications#regions). ## gRPC Extension Now Available gRPC Extension Available By popular demand, Laravel Cloud now supports the gRPC PHP extension, our most requested addition. The gRPC extension enables high-performance, low-latency communication with services like Firebase, Google Cloud APIs, and other gRPC-based backends directly from your Laravel applications. To enable gRPC in your app, simply redeploy. No additional configuration required. Check out all [available PHP extensions on Cloud](https://cloud.laravel.com/docs/environments#php-extensions). * Business plan now available with increased domain limits * PHP 8.5 available (pdo\_sqlsrv support coming soon) * Serverless Postgres lower pricing * Redesigned build & deploy * Node 24 available * 25GB Laravel Redis cache option * Improved cache usage page * Fixed domains missing on Cloudflare not being marked as failed * Fixed cache errors on Redis by Upstash * Fixed dropdowns not closing properly * Fixed logs scroll bug * Fixed MySQL storage sync ## Laravel Cloud API Is Now Early Access Laravel Cloud API Early Access The Laravel Cloud API is now available in early access, giving you programmatic control over your Laravel Cloud infrastructure. This powerful API allows you to automate deployments, manage environments, configure domains, and much more—all from your own applications or scripts. With the early access release, you can manage key aspects of your Laravel Cloud setup, including applications, environments, deployments, domains, commands, instances, and background processes. [Contact our support team for EA](https://cloud.laravel.com/docs/support) ## New Region: Hello, Ireland Ireland Region We're excited to announce that Laravel Cloud is now available in the Europe (Ireland) region. This expansion brings improved performance and reduced latency for applications serving users across Europe and the UK. Ireland joins our growing global infrastructure, offering you more flexibility to deploy your Laravel applications closer to your European audience. This strategic location provides excellent connectivity throughout the region and seamless integration with other services. To deploy to Ireland, simply select "Europe (Ireland)" when creating a new environment or server. Existing applications can be migrated to take advantage of this new region's benefits. [See all regions](https://cloud.laravel.com/docs/applications#regions) ## Laravel Reverb-Powered WebSocket Clusters Laravel Reverb WebSocket Clusters We're excited to announce that [WebSockets for Laravel Cloud](https://cloud.laravel.com/docs/resources/websockets), powered by Laravel Reverb, is now available in developer preview. This marks our first managed WebSocket offering, allowing you to easily add Reverb's real-time capabilities to your Laravel application without the complexities of managing your own infrastructure. All it takes is a few clicks in Cloud: select the desired number of concurrent connections, attach the resource to your environment, and you're off. [Learn more](https://cloud.laravel.com/docs/resources/websockets) ## Advanced Rate Limit Rules Now Available For Business Plan Advanced Rate Limiting Customers on our [Business plan](https://cloud.laravel.com/pricing) now have access to advanced rate-limiting rules within their Web Application Firewall (WAF). These enhanced features provide more granular control over rate limiting, allowing you to customize triggers, actions, and bot protection settings to better secure your applications. With advanced rate limiting, you can define thresholds for request rates, set custom responses for rate-limited requests, and fine-tune bot protection mechanisms to distinguish between legitimate traffic and malicious bots. This level of control helps you protect your applications from abuse while ensuring a smooth experience for genuine users. [Contact our support team to upgrade](https://cloud.laravel.com/docs/support) ## Set Up Email Notifications in Laravel Cloud Email Notifications You can now configure email notifications in Laravel Cloud to stay informed about important events across your organization and applications. Access notification preferences by clicking on Account under your profile and navigating to Notifications. Email notifications are available for a wide range of events, including organization changes, team member updates, API token activity, application and environment management, resource alerts, deployment status, and payment notifications. By default, you'll receive notifications for resource alerts, failed deployments, and failed payments. You can easily customize which notifications you receive by toggling your preferences on or off at any time. [Manage email notification preferences](https://cloud.laravel.com/profile/notifications) * Improved loading speed of source control repository selection * Laravel Valkey cache improvements * Updated pricing calculator * Add cache credentials to canvas * Fixed Slack channel names in notifications * UI fix for queue configurators * Fixed redirect on logout ## New Region: Welcome, Virginia New Virginia Region We're excited to announce that Laravel Cloud is now available in the US East (Virginia) region! This expansion means reduced latency and improved performance for applications deployed in the eastern United States. Virginia joins our growing list of regions, providing you with more options to deploy your Laravel applications closer to your users. This strategic location offers excellent connectivity across the eastern seaboard, enabling seamless integration with other AWS services in the region. To deploy to Virginia, simply select "US East (Virginia)" when creating a new environment or server. Existing applications can be migrated to take advantage of this new region. [See all regions](https://cloud.laravel.com/docs/applications#regions) ## Laravel Valkey is now Early Access Laravel Valkey Early Access Laravel Valkey is our new managed Redis offering that gives you a high-performance, fully managed key-value database right out of the box. With different sizes available, you can easily find the right fit for your application's needs, whether you're handling a small project or a large-scale, enterprise-level workload. Laravel Valkey is available in early access. To request access, [contact our support team](https://cloud.laravel.com/docs/support). ## Coming Soon to Laravel Cloud The Laravel Cloud team has a number of features launching this fall. Keep an eye out for Reverb, the Cloud API, a new region in Ireland (eu-west-1), and an Advanced Web Application Firewall. * Updated pricing for serverless Postgres * App performance improvements * [Laravel Cloud IPs now available in docs](https://cloud.laravel.com/docs/network#ip-addresses) * App UI improvements: links in deployments, automation autofill * Slack channel renames * Typos in environment network settings and Bitbucket error message ## New Pricing New Pricing We’ve updated Laravel Cloud’s pricing plans. Starting on August 13, the Starter (formerly Sandbox), Growth (formerly Production), and Business plans now offer smarter usage-based billing and richer defaults like custom domains on Starter and Pro-class compute on Growth and Business. Bandwidth now scales with compute usage and is shared across environments, making billing more transparent and aligned with actual value. [Learn more about the new pricing](https://blog.laravel.com/laravel-cloud-more-features-smarter-pricing) ## Smart Autoscaling with Queue Clusters Queue clusters have been deprecated. Please see [Managed queues](/docs/queues#managed-queues). Smart Autoscaling with Queue Clusters Laravel Cloud now supports a third cluster type (in addition to [App and Worker clusters](https://cloud.laravel.com/docs/compute)) built specifically for queue workloads. Available for testing in developer preview, these Queue clusters fully manage and autoscale Laravel queue workers, tracking CPU, memory, job throughput, and backlog in real time to determine how many workers and replicas your application needs. Autoscaling is latency‑driven: when queue wait time exceeds your threshold, capacity is automatically added, and once latency improves, the cluster scales back to reduce cost. This removes the guesswork of sizing queue workers manually while optimizing for both performance and savings. [Read the docs](https://cloud.laravel.com/docs/queues) ## Laravel Cloud Is Now SOC2 Compliant SOC2 Compliance SOC 2 Type 2 is a compliance framework created by the American Institute of Certified Public Accountants (AICPA) that evaluates how organizations secure and protect customer data. The framework consists of five Trust Services Categories (TSCs) with specific criteria for assessing an organization's controls and service commitments. Laravel Cloud has achieved SOC 2 Type 2 attestation for Security, Confidentiality, and Availability. More information is available at [trust.laravel.com](http://trust.laravel.com/). ## New Region: Welcome, Sydney! New Sydney Region We're thrilled to announce that Laravel Cloud is now available in the Sydney (ap-southeast-2) region, expanding our global coverage to better serve customers in Australia and the broader Asia-Pacific area. This new region offers lower latency and improved performance for applications serving users in this part of the world. Deploying to Sydney is as simple as selecting "Asia Pacific (Sydney)" when creating a new app. Existing customers can continue using their current regions, while new projects targeting Australian and APAC users can benefit from this regional deployment option. [Learn more](https://cloud.laravel.com/docs/applications#regions) * Enabled Slack notifications in private channels * Delete MySQL scheduled snapshots * Warnings when deleting environments with attached resources * Adds 6-hour option to logs * Slack channel pagination * Disable database upgrade button during upgrade ## MySQL is Production Ready MySQL is Generally Available You can now provision production‑ready MySQL instances with compute ranging from 1 CPU/512 MB RAM up to 8 CPU/32 GB RAM, and storage tiers from 5 GB to 1 TB. Automated daily backups are included, with retention configurable up to 30 days for standard plans and extended retention available on Enterprise plans. [Read the docs](https://cloud.laravel.com/docs/resources/databases/laravel-mysql) ## Automated preview environments Automated preview environments Preview environments are now available on [Growth, Business, and Enterprise plans](https://cloud.laravel.com/pricing). For every pull request, Laravel Cloud automatically spins up a fully isolated production‑like environment. You can mirror your live app using either shared or dedicated databases, configure filters to limit previews by branch or PR, and run custom deploy steps such as migrations or seeders. Auto‑cleanup can be enabled to delete environments when PRs close or merge, so you only pay for active environments. These features help you catch bugs early, collaborate across teams, demo confidently, and ship with certainty. [Read the docs](https://cloud.laravel.com/docs/environments#preview-environments) ## Ship Faster With the New Starter Kits Ship with Starter Kits You can now deploy production‑ready Laravel applications in under five minutes using the new official [Laravel Starter Kits](https://laravel.com/starter-kits) for Laravel, Livewire, React, and Vue. Select a stack, choose a region, customize repository name and visibility, and Laravel Cloud handles the repo creation, deployment configuration, and infrastructure setup. All templates come directly from Laravel’s [official GitHub](https://github.com/laravel/laravel). No existing repository is required. This greatly simplifies launching demos, prototypes, or new apps without setup friction. Learn more about the [Laravel Starter Kits](https://youtu.be/y2FfKwcK_iU) * Improved repo searching when creating new apps * Added 6-hour period option for metrics viewing * Improved MySQL charts * Better validation running commands during deployments * Fix 404s in app for hibernation and page reloads * Log fixes * Responsive layout fixes ## One-Click Nightwatch Integration Laravel Cloud Nightwatch Integration You can now quickly [enable Laravel Nightwatch monitoring](https://cloud.laravel.com/docs/environments#nightwatch-integration) in your Cloud environment canvas with a single click. This new integration runs Nightwatch across all your App and Worker clusters and automatically injects the correct `.env` settings so you can get up and running (or edit your sampling threshold) faster. [Start monitoring with Nightwatch](https://nightwatch.laravel.com/sign-up) ## Under Attack Mode Laravel Cloud Under Attack Mode We’ve enhanced DDoS protection with an optional Under Attack Mode you can enable during periods of unusual traffic. While DDoS attacks are automatically detected and mitigated, this mode provides an additional layer of protection when you want to safeguard your app proactively. When active, access to your app is restricted, and visitors are presented with a JavaScript challenge before they can reach your app. The feature automatically expires after 24 hours to help prevent unintentional enablement. To enable Under Attack Mode, head to your environment, click on Network, and then Web Application Firewall settings. [Learn how to set up Under Attack Mode](/docs/network#under-attack-mode) ## Improved Metrics and Charts Laravel Cloud Improved Metrics and Charts We’ve updated our metrics to offer a more detailed and granular view of resource usage. CPU and memory charts have been refined to highlight trends and spikes, enabling more informed decisions about scaling and optimization. For example, memory charts now display total cache storage usage instead of average cache usage, meaning that if you have one or more replicas, you will now see each replica’s memory usage instead of the average memory. [Check your app's performance](https://cloud.laravel.com/sign-in) ## MySQL Metrics Land as GA Nears You can now view real-time CPU, memory, and storage metrics for your MySQL databases. Navigate to your environment, click Resources, and then hit the Cluster card to see all metrics. This addition gives you a fuller picture of database performance and is one of several steps we’re taking as we move closer to MySQL's general availability. If you're using MySQL in Laravel Cloud, this brings deeper visibility and greater operational confidence. [Check your MySQL database performance](https://cloud.laravel.com/sign-in) * New 500gb cache type * Added notifications to command palette * Archive MySQL databases * Improved Slack notifications adding MySQL and Cache alerts * Improved speed on environments page * Cache and Database dialog minor fixes * Fix HTTP timeout validation message ## Visualize Replica Count You can now view a replica count chart in your environment’s Metrics tab that shows exactly when autoscaling occurs in your Laravel Cloud applications. The step chart visualizes how each of your App and Worker clusters scale from one to multiple replicas. You can also see when your application was scaled to zero and not incurring compute usage costs due to being stopped manually or hibernating automatically (requires Hibernation to be toggled on). This update helps provide clearer performance and billing insights for each of your Cloud environments. Laravel Cloud Replica Count [View your replica metrics](https://cloud.laravel.com/to/org/applications) ## More Flexible Caching Laravel Cloud’s Redis-compatible key-value stores can now be configured to scale up automatically when usage limits are met. Instead of hard limits that could lead to downtime and require manual intervention, caches can now upsize with zero downtime as they approach monthly data transfer or usage thresholds such as simultaneous connections, commands per second, record size, and request size. Opt in to auto-upsizing by toggling on the “Automatically Upgrade” option of your new or existing Laravel Cloud caches. Laravel Cloud Flexible Cloud Cache Sizing [Learn more about Laravel Cloud caches](/docs/resources/caches#auto-upgrade) ## Slack Alerts [Slack notifications](/docs/notifications) now include a new “Resource Alerts” category for critical runtime issues. You’ll receive real-time alerts anytime CPU, RAM, or disk usage nears its limit or when your compute crashes, making it easier to identify and respond to issues quickly. Set up Slack notifications in Laravel Cloud and opt in to Resource Alerts to make sure you are the first to know when your applications are at risk of downtime or performance degradation. Laravel Cloud Slack Alerts [Connect Slack to Laravel Cloud](https://cloud.laravel.com/to/org/settings/notifications) * Show total cache storage usage instead of average cache usage * Tooltips for identifiers in usage section * Added source control disconnected notification * Updated usage to include resource identifiers * Users can now configure WWW domains as root domains * Save and Deploy now deploys with latest commit * Configure backup setings for Laravel Serverless Postgres * Fixed average calculation on replica count chart * Fixed network settings blank screen ## Slack Notifications Connect Laravel Cloud to your Slack workspace to receive notifications about your organization and application. Organization settings include notifications about resources (new database, new application, etc.) and membership requests. Application settings include notifications about deployment success, environment settings, domain verification and more. You can configure application and organization notification to go to specific channels. [Connect your Slack workspace to Laravel Cloud](https://cloud.laravel.com/to/org/settings/notifications) ## Improved Usage Page The Usage page now includes an Allowances tab that shows your overall utilization of your plan's included usage. The Applications tab now also includes bandwidth usage (requests & data transfer) for each application. Paired with Invoice Previews, you can now deeply understand usage across your applications. [View Your Usage](https://cloud.laravel.com/to/org/usage/applications) ## Pricing Calculator Our pricing calculator allows you to estimate your costs on Laravel Cloud, before you even start deploying. Choose from our preset options (personal blog, SaaS app, etc) or customize everything and choose the compute and resources that work best for your application. [Try the pricing calculator](https://cloud.laravel.com/pricing/calculator) ## Greater Cache & Response Header Control You now have greater control of over your cache and response headers. All `Cache-Control` and `Expires` headers set by your application now be fully respected. In addition, you can choose when to purge your Edge Network cache - either manually or automatically on each new deploy. You can also choose to bypass the cache entirely. Finally, you can also override certain response headers like `X-Frame-Options`, `X-Content-Type-Options`, and `Strict-Transport-Security` directly in the Cloud environment canvas. [Learn more](/docs/network#cache-control) ## Flexible Backup Retention Window Laravel Serverless Postgres now allows setting a backup retention window between 0 to 30 days. Previously it was a fixed 7-day window with no flexibility to change the window or opt-out. Choose a backup window that works for your application and save money on storage if your application doesn’t require backups at all. [Learn more](/docs/resources/databases/postgres) * Hibernation is now enabled by default for all new environments on the Sandbox plan. * Add infinite scrolling for Logs. * Introduced full page layout for database UI. * Added organization restricted, suspended, and terminated billing states. * Improved Invoice Preview UI. * Individual chart lines on Metrics pages can now be enabled / disabled. * Various logs UI fixes. * Various source control provider fixes. ## Replicate Environments Create copies of existing environments with all configuration intact. This is an important step towards the team shipping automatic preview environments. This allows you to quickly spin up testing environments, create staging replicas of production, or set up identical workspaces for team members. Replication saves time and ensures consistency across your development workflow. [Learn more](/docs/environments#replicate) ## Stop and Restart Environments Take manual control of your environment states with our new stop and restart functionality. Unlike hibernation (which happens automatically), this feature lets you explicitly pause environments when you don't need them and restart them when you do. Perfect for managing costs, scheduling maintenance, or controlling resources during your development cycles. [Learn more](/docs/environments#stop-and-restart) ## Invoice Previews Better predict your spend by viewing a preview of your current month’s invoice (to date). Previews include plan subscription, additional usage (after allowances), and discounts. [View Invoice Preview](https://cloud.laravel.com/to/org/usage/invoices) ## Inertia SSR We now support the ability to serve [Inertia](https://inertiajs.com/) based pages via [server-side rendering](https://inertiajs.com/server-side-rendering). Inertia SSR pre-renders your HTML server-side before sending it to the client, which can improve your application’s SEO. [Learn more](/docs/compute#inertia-ssr) ## Repository Connection Management A disconnected repo no longer leaves you hanging. You can now edit which repository is connected to your application. This enables recovery from disconnections that occur when repositories are deleted or access is revoked. After updating your repository, you can easily reconnect each environment to the appropriate branch, preserving all your settings and attached resources. [Learn more](/docs/applications#reconnect-git-repository) *** * Improved GitHub integration for enhanced reliability. * Added applications usage to the usage screen. * Improved domain verification workflow. * Improved error messages for running commands. * Enhanced tooltips and copy button usability. * Allow re-running commands * Added support for enabling "EU jurisdiction" when creating a bucket. * Improved validation to check if Octane is installed before enabling it. * Environments can now be "woken" from the hibernation state. * Fixed an issue where “Build Logs” and “Deploy Logs” were sometimes truncated prematurely, preventing error messages from being displayed. * Resolved an issue where deployment output was sometimes missing when a deployment failed. * Fixed issue with the "Create Application" modal when a repository was not selected during branch refresh. * Fixed Bitbucket link issue. * Resolved an issue where the deployment output might incorrectly display as "complete". * Fix the issue where changing the application’s avatar also disconnects its source control. * Prevent commands from being executed on stopped environments. * Resolved timeout issue when creating applications with source controllers managing thousands of repositories. Launched Laravel Cloud! # Compliance & Security Source: https://cloud.laravel.com/docs/compliance Learn about Laravel Cloud security practices, compliance controls, and protections for production apps. We're committed to providing a secure and compliant platform for your Laravel applications. We understand that security and compliance are critical for your business, and we're proud to have achieved industry-leading certifications. This page outlines our current compliance status and provides transparency into our security measures. ## Current compliance status ### SOC 2 Type 2 System and Organization Control 2 Type 2 (SOC 2) is a compliance framework developed by the American Institute of Certified Public Accountants (AICPA) that focuses on how an organization's services remain secure and protect customer data. The framework contains 5 Trust Services Categories (TSCs), which contain criteria to evaluate the controls and service commitments of an organization. Laravel Cloud has achieved SOC 2 Type 2 attestation for Security, Confidentiality, and Availability. More information is available at [trust.laravel.com](https://trust.laravel.com/?product=cloud). ## Future compliance roadmap ### ISO 27001 Following the completion of SOC 2, our next major compliance initiative will be achieving ISO 27001 certification. This internationally recognized standard for information management systems (ISMS) will further solidify our dedication to protecting your data and ensuring the confidentiality, integrity, and availability of our platform. We aim to deliver full ISO 27001 compliance in H1 of 2026. ## What this means for you Our commitment to these compliance standards means you can trust Laravel Cloud to handle your sensitive data with the highest level of security and care. These certifications demonstrate our dedication to: * **Data Security:** Protecting your data from unauthorized access, use, disclosure, disruption, modification, or destruction. * **OWASP Top 10 coverage:** Any domain served through Laravel Cloud's edge network, default or custom proxied through Cloudflare, is protected by Cloudflare's [OWASP Core Ruleset](https://developers.cloudflare.com/waf/managed-rules/reference/owasp-core-ruleset/), filtering common injection, authentication, and data exposure attacks before they reach your application. * **Availability:** Ensuring the continuous operation of our platform and minimizing downtime. * **Confidentiality:** Maintaining the privacy of your data and preventing unauthorized access. * **Compliance:** Adhering to industry best practices and regulatory requirements. ## Stay updated We will continue to update this page with the latest information on our compliance progress. We encourage you to check back regularly for updates. If you have any questions regarding our compliance status, please don't hesitate to contact our support team at [cloud@laravel.com](mailto:cloud@laravel.com). We appreciate your trust in Laravel Cloud and are committed to providing you with a secure and compliant platform. # Compute Source: https://cloud.laravel.com/docs/compute ## Introduction Each environment deployed to Laravel Cloud runs on at least one App compute instance, which is assigned a specified amount of CPU processing power and available RAM. Your environment's App compute instance is responsible for handling incoming HTTP traffic to the environment. In addition, you may add dedicated worker compute instances to your environment to process queued jobs or execute other background processes. Compute resources assigned to an environment may be managed from the environment's infrastructure canvas dashboard. ## App compute cluster Your environment's App compute cluster represents the primary compute and infrastructure that will run your Laravel application. This compute cluster can serve web traffic, scale to zero, manage long-running processes like [queue workers](/docs/queues), and even run scheduled tasks. To scale or customize your environment's App compute cluster, simply click the cluster in your environment's infrastructure canvas dashboard. ### Laravel Octane Laravel Cloud makes it easy to run your application using [Laravel Octane](https://laravel.com/docs/octane), which boots your application once and keeps it in memory for each request. When editing your App compute cluster, simply toggle on the “Use Octane as runtime” option. Then, save and deploy your environment and Laravel Cloud will build, configure, and serve your Laravel application using Laravel Octane and [FrankenPHP](https://frankenphp.dev/). Please review the [Laravel Octane documentation](https://laravel.com/docs/octane) to learn about the caveats you should keep in mind when building your application to run on Octane. Before enabling the Laravel Octane runtime, make sure Laravel Octane has been [added to your application](https://laravel.com/docs/octane#installation) via the Composer package manager. ### Inertia SSR Laravel Cloud also allows you to serve your [Inertia](https://inertiajs.com) based pages via [server-side rendering](https://inertiajs.com/server-side-rendering). Inertia SSR pre-renders your HTML server-side before sending it to the client, which can improve your application's SEO. When editing your App compute cluster, simply toggle on the "Use Inertia SSR" option. Then, save and deploy your environment and Laravel Cloud will render your Laravel application's templates using Inertia's SSR engine. In addition, if you are using one of Laravel's official [starter kits](https://laravel.com/docs/starter-kits), you should update your environment's build commands to use the `npm run build:ssr` command instead of `npm run build`: ```bash theme={null} npm run build:ssr ``` ## Worker clusters Worker clusters are optional compute resources that can be added to your environment. They are a mirror copy of your environment's App compute in the sense that they use the same repository, branch, PHP version, environment variables, deployment commands, database, and other resources. However, each Worker cluster can be independently sized and can run a custom set of [queue workers](/docs/queues) or custom background processes. Dedicated worker clusters can be useful for larger applications where you want to use the primary App cluster to serve web traffic, but send background workloads to separate compute resources. To add a worker cluster to an environment, click "Add worker cluster" on the environment's infrastructure canvas dashboard. Workers do not serve web traffic. If your application needs more HTTP throughput capacity, modify your environment's App compute cluster's size, replica count, or autoscaling settings and re-deploy your application. ## Autoscaling Laravel Cloud can automatically scale the compute resources attached to your environment based on the CPU and memory being used by the environment. To configure your environment's autoscaling strategy, click on your environment's App or Worker compute cluster on the infrastructure canvas dashboard, and select the autoscaling strategy that is appropriate for your environment. For maximum flexibility, Laravel Cloud currently supports three different autoscaling strategies: * **None:** run your App / Worker compute on a single instance without autoscaling. * **Custom:** automatically scale your App / Worker compute clusters up and down horizontally within a specified minimum and maximum replica range. * **Unlimited:** automatically scale your App / Worker compute clusters up and down indefinitely based on demand. After adjusting your environment's autoscaling strategy, re-deploy the environment in order for the changes to take effect. ### Scheduled autoscaling Scheduled autoscaling is available on the **Business** and **Enterprise** plans. It allows you to define time-based overrides for clusters that scale between a minimum and maximum number of replicas. This is useful for predictable traffic patterns like product launches, marketing campaigns, or business hours. Each scheduled override temporarily changes your cluster's: * minimum replicas * maximum replicas * CPU threshold * memory threshold Overrides may be configured as one-time or recurring schedules. Recurring schedules support daily, weekday, weekend, or weekly patterns, and each schedule uses its own timezone so the configured start and end times match the hours that matter to your team. If multiple schedules overlap, Laravel Cloud applies the most specific matching override. One-time schedules take precedence over recurring schedules. Among recurring schedules, schedules for specific days of the week take precedence over weekday or weekend schedules, and weekday or weekend schedules take precedence over daily schedules. Scheduled autoscaling changes are applied automatically around the configured boundary times, typically within about one minute. ### Scheduled autoscaling limitations * Scheduled autoscaling is only available for clusters that scale between a defined minimum and maximum replica count. * Recurring schedules must start and end on the same day. If you need an overnight window, create two schedules. * One-time schedules run once, then automatically stop applying after their scheduled window ends. ## Compute classes Laravel Cloud applications run on the latest generation of AWS Graviton EC2 servers with an optimized cost to performance ratio, allowing us to pass on best-in-class compute performance and pricing. Laravel Cloud offers two classes of compute: Lightweight and cost-efficient. Perfect for dev environments or applications that need the flexibility to support periodic traffic bursts. Larger compute sizes designed for sustained, heavy utilization. Best for large-scale, mission-critical production applications. Within each class, there are multiple sizes of CPU and RAM available. Prices vary by region - see [Plans and Pricing](/docs/pricing) for more information. ## Compute metrics Your environment's compute metrics may be viewed by navigating to the "Metrics" tab of your environment. When graphed, CPU and memory usage for your environment's App and Worker clusters will be averaged across all replicas. ## Scale to Zero Your environment can scale to zero when it does not receive an inbound network request to your application (port 8080) within a specified time limit, known as the sleep timeout. While an environment is sleeping, you will not be charged for its compute until it is woken up again. New Flex compute sizes wake in under 500 milliseconds when the environment receives a new inbound request, which is fast enough that your application's users will not notice. Legacy Flex sizes use the previous wake behavior and typically take 5-20 seconds to wake. You can enable Scale to Zero by clicking on your environment's App compute cluster on the infrastructure canvas dashboard, enabling the Scale to Zero toggle, saving the compute cluster settings, and re-deploying the environment. ### Scheduled tasks and queues A sleeping environment now wakes automatically to run [scheduled tasks](/docs/scheduled-tasks) and process [queued jobs](/docs/queues), so nothing falls behind while your environment sleeps. When your environment wakes for a scheduled task or a manual wake interval, it stays awake for the duration of the sleep timeout. Any inbound request resets this timer. Make sure your scheduled tasks and background processes can complete within that window. If a queued job is still running when the sleep timeout elapses, the App cluster will stop and the job may be interrupted. We recommend [Managed Queues](/docs/queues#managed-queues) for queued jobs so that background processing is never interrupted by Scale to Zero. ### Manual wake interval You may configure a manual wake interval to wake an environment on a fixed schedule, which is useful for background processes like self-managed `queue:work` processes that must run periodically. As with scheduled tasks, a wake interval shorter than your sleep timeout can keep the environment awake continuously. ### Worker clusters Each Worker cluster can either stay awake at all times or follow the App cluster and sleep alongside it. You may configure this behavior within the Worker cluster's settings. ### Limitations * Only Flex compute sizes can scale to zero. * Sub-500 millisecond wake times apply to new Flex sizes only. Legacy Flex sizes keep their previous wake behavior. ## Maintenance mode By default, Laravel uses the `file` driver for maintenance mode. If you run `php artisan down` from the "Commands" tab, the maintenance mode state will not persist across deployments or apply to multiple replicas. To ensure a consistent maintenance mode state across your application and its replicas, set the maintenance mode driver to `cache` and use either a [database](/docs/resources/databases/laravel-mysql) or [Laravel Valkey (Redis-compatible)](/docs/resources/caches) as the maintenance mode state backend in your environment variables. ```ini theme={null} APP_MAINTENANCE_DRIVER=cache APP_MAINTENANCE_STORE=database ``` # Deployments Source: https://cloud.laravel.com/docs/deployments ## Introduction Deployments in Laravel Cloud happen whenever you have new code to release, new resources to attach, or environment settings that you want to update. When a new deployment is triggered, Laravel Cloud will take your code and environment settings, build a Docker image with the applicable PHP version, extensions, and other configurations fine-tuned for Laravel, and then run your build and deploy commands. Once your build completes successfully, the existing deployment will be gracefully terminated (allowing any running processes to complete) and the new deployment will be brought online with zero downtime. ## Deploy options ### Push to deploy Every time you push new code to your remote Git branch, a new deploy is automatically triggered. Push to deploy is enabled by default on all environments. To change this setting, go to Settings > Deployments. ### Deploy hooks If you prefer to trigger a deployment via an HTTP endpoint, you can enable the "Deploy hook" option in Settings > Deployments. When enabled, you will be provided a URL that you can make a POST request to as part of your CI/CD flow. You can refresh your URL anytime from the Deployments settings. You can also deploy a specific commit by passing a `commit_hash` query parameter to the deploy hook URL. The commit hash should belong to the branch configured for the environment. ```shell theme={null} curl -X POST "https://your-deploy-hook-url?commit_hash=abc123def456" ``` If no commit hash is provided, the latest commit from the environment's branch will be deployed. #### Example using GitHub Actions Deploy hooks are perfect for integrating Laravel Cloud with your CI / CD pipeline. Here's a complete example using GitHub Actions: 1. First, add your deploy hook URL as a secret in your GitHub repository: * Go to your GitHub repository settings * Navigate to Secrets and variables → Actions * Add a new secret named `LARAVEL_CLOUD_DEPLOY_HOOK` with your deploy hook URL 2. Create a `.github/workflows/deploy.yml` file in your repository: ```yaml theme={null} name: Deploy to Laravel Cloud on: push: branches: [ main ] jobs: deploy: runs-on: ubuntu-latest steps: - name: Deploy to Laravel Cloud run: | curl -X POST "${{ secrets.LARAVEL_CLOUD_DEPLOY_HOOK }}?commit_hash=${{ github.sha }}" ``` 3. Commit and push the workflow file to trigger your first deployment. Unlike traditional deployment processes that require installing dependencies and running build commands in CI, Laravel Cloud handles all of this for you. The deploy hook simply triggers Laravel Cloud to: * Pull your code from the specified commit * Run your configured build commands * Run your configured deploy commands * Deploy your application with zero downtime ### Manual You can trigger a deployment from the Laravel Cloud dashboard anytime by clicking the "Deploy" button from the Environment overview page or Deployments page. After updating environment settings, you can also click "Save & Deploy" to manually trigger a deployment. ## Troubleshooting ### Laravel framework version not supported Laravel Cloud requires Laravel 9 or greater. In addition, you should be using the latest minor version of the `laravel/framework` Composer package. The minimum minor versions required are: * Laravel 11: `v11.41.3` * Laravel 10: `v10.48.28` * Laravel 9: `v9.52.20` Watch [this video](https://youtu.be/95iC9L-3CxY) to learn more about fixing this framework error. If you receive an error during a deployment that *"The \[laravel/framework] package was found in the \[composer.lock] file, but the version is not supported. Upgrade Laravel to the latest minor version"* then you can update by running the following command: ```shell theme={null} composer update laravel/framework ``` # Domains Source: https://cloud.laravel.com/docs/domains Configure Laravel Cloud domains, connect custom domains, set up DNS, and troubleshoot verification. Laravel Cloud provides two types of domains for each environment: an automatically assigned `laravel.cloud` domain and any custom domains you connect. Domain stuck verifying? Read our docs on [verifying domains](/docs/knowledge-base/domain-verification). ## Cloud domains Each environment is assigned a free `laravel.cloud` domain after its first successful deployment. This is ideal for testing and staging before switching to your own domain. Cloud domains are constructed from your application and environment name. If you rename either, the Cloud domain will change and you will need to redeploy for the change to take effect. Since Cloud domains are frequently used for non-production environments, an `X-Robots-Tag: noindex, nofollow` header is automatically set on all `*.laravel.cloud` domains so they are not indexed by search engines. This header is not set for custom domains. ## Custom domains A custom domain lets visitors reach your application at your own address (e.g., `example.com`) instead of the default `laravel.cloud` domain. Laravel Cloud automatically provisions and renews SSL certificates for each custom domain so your site is served over HTTPS. ### Add a custom domain In the dashboard, open your environment's Network settings and select "Add domain". You'll be asked to choose: * **Wildcard support**: Whether to accept traffic on all subdomains (for example, `*.example.com`). * **Redirect behavior**: Whether Cloud should redirect `www.example.com` to `example.com` (or the reverse). * **Downtime preference**: Whether brief downtime is acceptable during setup, or whether you need an uninterrupted transition with no gaps in service. * **Cloudflare DNS settings**: Whether your DNS is managed by Cloudflare and whether the hostname is already proxied (routed through Cloudflare's network). These choices determine which DNS records Laravel Cloud will ask you to add and in what order. Enter the domain and choose your options. If you selected the uninterrupted path or enabled wildcard support, add the ownership and SSL validation records first. These records let Laravel Cloud confirm you own the domain and issue an SSL certificate before any traffic is switched over. This option is only available if the hostname is not already proxied through Cloudflare's network. Add the origin record(s) shown in the UI. Origin records are the DNS entries that direct your domain's traffic to Laravel Cloud's servers. Use the Refresh action in the dashboard until the domain status shows as connected. Most domains connect within 15 minutes, but DNS propagation can occasionally take longer. ### Verification paths Laravel Cloud supports two verification approaches. The right choice depends on whether you can tolerate a brief gap in service while DNS changes take effect: * **Real-time verification (flexible)**: Point the domain to Laravel Cloud first, then Laravel Cloud will verify ownership and issue an SSL certificate. This is the simplest path, but there may be a short window where the domain is not yet serving over HTTPS. * **Pre-verification (uninterrupted)**: Prove ownership and issue the SSL certificate before switching traffic. This avoids any downtime or insecure window, but requires additional DNS records up front. Required for wildcard domains. This approach is only available if the hostname is not already proxied through Cloudflare's network. ## DNS records you will see in Cloud When you open a domain's configuration, Laravel Cloud will show the exact DNS records required for your setup. You do not need to figure out which records to create on your own — simply copy the record type, name, and value exactly as shown and add them to your DNS provider. ### Origin records Origin records are the primary DNS entries that tell the internet to send traffic for your domain to Laravel Cloud: * An **A** record maps your domain to an IP address and is common when you are not using Cloudflare DNS. * A **CNAME** record maps your domain to another hostname and is common when you are using Cloudflare DNS (Cloudflare supports CNAME flattening at the apex, which allows a CNAME on the root domain). ### Ownership verification record During pre-verification, Laravel Cloud may require a temporary TXT record to confirm that you control the domain. This record looks like: `TXT _cf-custom-hostname. -> ` Once ownership is confirmed, this record is no longer needed, though leaving it in place will not cause any issues. ### SSL validation records To issue an SSL certificate for your domain (so it can be served over HTTPS), Laravel Cloud may require one or more validation records: `TXT _acme-challenge. -> ` `CNAME _acme-challenge. -> ` (common for wildcard / DCV delegation) If you are using wildcard support, keep the DCV delegation CNAME record in place permanently. This record allows Laravel Cloud to automatically renew your wildcard SSL certificate — removing it will prevent future renewals. ## Understanding verification status A domain is fully connected once three components are verified: * **Hostname**: Ownership of the domain is confirmed. * **SSL**: An SSL certificate has been issued and is active, enabling HTTPS. * **Origin**: DNS is correctly routing traffic to Laravel Cloud. As verification progresses, the dashboard will show one of the following statuses: * **Verifying ownership**: Laravel Cloud is waiting for your ownership and SSL validation DNS records to become visible. This is the propagation stage. * **Verifying**: Ownership and SSL are confirmed, but origin routing has not been detected yet. Your origin DNS record may still be propagating. * **Connected**: All three components are verified and your domain is live. * **Timed out**: Verification did not complete within the allowed window. Review your DNS records for errors and retry. Laravel Cloud retries verification checks for approximately 12 hours before timing out, so there is no need to manually re-trigger during this period. If you are using real-time verification, visiting your domain in a browser can help Laravel Cloud detect traffic flowing through the network and speed up the final verification step. ## Wildcard domains A wildcard domain (e.g., `*.example.com`) allows any subdomain — such as `app.example.com`, `api.example.com`, etc. — to route to your environment without configuring each one individually. Wildcard domains require pre-verification unless the hostname is already being proxied through Cloudflare's network. When configuring a wildcard domain: * Also configure the root domain `example.com`, so both `example.com` and its subdomains are covered. * Add the DCV delegation record shown in the UI. This record allows Laravel Cloud to continue issuing and renewing wildcard SSL certificates on your behalf. If your DNS is managed by Cloudflare, ensure DCV delegation records under `_acme-challenge` are configured as **DNS only** (grey cloud, not proxied). Proxying these records will block certificate issuance. ## Managing domains From your environment's domain settings, you can detach and reassign domains between environments in the same organization. You can also set a verified root domain as the primary domain for an environment. Primary domains cannot be moved or removed until they are unset as the primary domain. ## Limitations There are no limitations on the number of Cloud environments that can have a custom domain assigned to them. Each plan includes a number of custom domains across your entire organization: * **Starter**: 10 custom domains per organization * **Growth**: 50 custom domains per organization * **Business**: 250 custom domains per organization * **Enterprise**: Custom Additional custom domains beyond your plan's included amount are billed at \$0.25 per domain per month. If you have a special use case that requires many domains (for example, multi-tenant applications), please [contact us](/docs/support) to discuss raising your limits. ## Troubleshooting For guided troubleshooting and provider-specific DNS instructions, see the [Domain Verification](/docs/knowledge-base/domain-verification) guide. If you're diagnosing an issue in production, Laravel Nightwatch can help you confirm whether traffic is reaching your application and whether requests are being served successfully. ### Verify DNS from the terminal You can confirm your records are publicly visible by running the following commands in your terminal. Replace `example.com` with your actual domain. Both `dig` and `nslookup` are shown — use whichever is available on your system: ```bash theme={null} # Which DNS provider is responsible for your domain? dig NS example.com +short nslookup -type=NS example.com # Are your origin records resolving? (use the record type you configured — A or CNAME) dig A example.com +short dig CNAME example.com +short nslookup -type=A example.com nslookup -type=CNAME example.com # Is the ownership verification record visible? dig TXT _cf-custom-hostname.example.com +short nslookup -type=TXT _cf-custom-hostname.example.com # Are the SSL validation records visible? (may be TXT or CNAME depending on your setup) dig TXT _acme-challenge.example.com +short dig CNAME _acme-challenge.example.com +short nslookup -type=TXT _acme-challenge.example.com nslookup -type=CNAME _acme-challenge.example.com ``` If a command returns no output, the record is either missing or has not finished propagating. # Environments Source: https://cloud.laravel.com/docs/environments ## Introduction Laravel Cloud applications can be made up of many environments, such as "production", "staging", or even short-lived environments used for trialing new features you're developing for your application. Compute infrastructure, resources, and deployment settings are unique to each environment, allowing you to fine-tune each environment based on its purpose. For example, you might wish to assign small Flex compute instances that scale to zero to your staging environment, while larger, always-on compute instances are assigned to your production environment. ## Build and deploy commands You may define how both the frontend and backend of your application are built during deployment from the "Deployments" section of your environment settings. ### Build commands Build commands allow you to customize the build process for your application. Typically, this will involve customizing how you want Composer and NPM dependencies to be installed. In addition, you may add any custom build scripts or commands that are specific to your Laravel application. Running `php artisan optimize` or `php artisan config:cache` should be done during the build process, not during the deploy process. #### Private Composer packages To allow the installation of private Composer packages, you will need to configure your application's Composer HTTP authentication credentials for each package using the `composer config` command. You should add this command to your build commands prior to invoking `composer install`: ```shell theme={null} composer config http-basic.composer.fluxui.dev your-username your-license-key composer install --no-dev ``` Build commands must complete within 15 minutes or they will time out. #### Dynamic environment variables ```shell theme={null} # Adding a dynamic environment variable echo "MY_DYNAMIC_VAR=value" >> .env ``` ### Deploy commands Your environment's "Deploy Commands" are run on your Laravel Cloud infrastructure just before a new deployment goes "live". Typically, these commands will be used to migrate your environment's database. Unlike build commands, changes made to the filesystem by deploy commands will not be persisted to your application. Deploy commands must complete within 15 minutes or they will time out. #### Unnecessary build and deploy commands The following commands are either automatically handled by Laravel Cloud or should not be run during deployment: * **`php artisan queue:restart`** - Queue workers are automatically restarted after each deployment * **`php artisan horizon:terminate`** - Horizon processes are automatically managed during deployments * **`php artisan optimize:clear`** - This clears the cache and can cause unexpected behavior, especially related to the queue * **`php artisan storage:link`** - The symbolic link won't persist as changes made during deploy commands are not saved. Use [Laravel Object Storage](/docs/resources/object-storage) for persistent file storage instead. Typically, your deploy commands should only include database migrations and other essential post-deployment tasks. ## Environment settings ### Environment variables Within your environment's settings, the environment variables section allows you to customize the `.env` variables available to your environment. In addition to injecting your custom environment variables, Laravel Cloud will automatically inject a variety of environment variables into your environment on your behalf, including any credentials necessary to connect to Laravel Cloud resources like databases, key-value storage, or object storage. Custom environment variables take priority and will override any automatically injected environment variables. After changing an environment's variables, a re-deployment is required in order for the changes to take effect. ### HTTP basic authentication HTTP basic authentication allows you to protect an environment with a username and password before traffic reaches your application. This is useful for staging environments, private demos, preview environments, or sleeping environments that should not wake up because of unauthorized requests or automated bot traffic. You may enable HTTP basic authentication from your environment's General Settings page in the Security section. When enabled, users can access the environment using the username `admin` and the password you set. Passwords must be between 5 and 32 characters and cannot contain the `:` character. HTTP basic authentication is available on the [Growth plan](/docs/pricing) or higher. After enabling, disabling, or changing the password, a re-deployment is required in order for the changes to take effect. ### PHP version Laravel Cloud supports PHP 8.2, 8.3, 8.4, and 8.5. PHP 8.5 is the default selection for new environments. You may select the PHP version that should be used by an environment on the environment's General Settings page. After changing the PHP version, a re-deployment is required in order for the changes to take effect. PHP 8.5 is generally available, but the pdo\_sqlsrv extension is temporarily unavailable until the upstream project adds 8.5 support. Use PHP 8.2, 8.3, or 8.4 if you need those extensions today. ### PHP extensions Laravel Cloud currently supports the following PHP extensions: ``` apcu, bcmath, calendar, Core, ctype, curl, date, dom, ev, excimer, exif, fileinfo, filter, ftp, gd, gettext, gmp, grpc, hash, iconv, igbinary, imagick, imap, intl, json, ldap, libxml, mbstring, mongodb, msgpack, mysqli, mysqlnd, openssl, pcntl, pcre, PDO, pdo_mysql, pdo_pgsql, pdo_sqlite, pdo_sqlsrv, Phar, posix, pspell, random, readline, redis, Reflection, session, shmop, SimpleXML, soap, sockets, sodium, SPL, sqlite3, sqlsrv, standard, tokenizer, xml, xmlreader, xmlwriter, xsl, Zend OPcache, zip, zlib. ``` You can also list the currently loaded extensions by running `php -m` using Laravel Cloud's "Command" feature in your environment dashboard. ### PHP memory limit Laravel Cloud allocates PHP memory dynamically based on a percentage of your instance's total memory. If your application requires a specific amount, you can override this by defining a new `memory_limit`. You can override the default memory limit by adding configuration directly in your application code. The most common method is to update your `public/index.php` and your `artisan` file: ```php theme={null} ## Cloud domains Each Laravel Cloud environment is assigned a free `laravel.cloud` domain the first time it is deployed successfully. This makes it easy to test and build your application before attaching a custom domain. Laravel Cloud domains are constructed using a combination of your application and environment name. If either of these names are changed, the Laravel Cloud domain will be updated to reflect the changes. A redeployment is required for this change to take effect. ## Custom domains Of course, before shipping your application to the world, you will likely want to assign your own custom domain name to your production environment. Laravel Cloud will guide you through DNS configuration, verify domain ownership, and issue an SSL certificate automatically. For comprehensive documentation (DNS records, verification paths, wildcards, provider-specific guides, and plan limits), see [Domains](/docs/domains). If your domain verification is taking longer than expected, check out our docs on [verifying domains](/docs/knowledge-base/domain-verification). ## Stop and restart To stop an environment, click the "..." button next to the environment's "Deploy" button. Then, click "Stop". When you stop an environment, all App and Worker clusters within the environment will be shutdown. This means all web traffic, background processes, and scheduled tasks will stop processing. You will not be charged for the environment's compute, but you will still be charged for any attached resources. You can restart the environment using the same dropdown menu. A full deployment is required to restart an environment. ## Replicate It is common for environments in the same application to have similar or identical resource and settings configurations. Therefore, when creating new environments, it is often more convenient to clone an existing environment and make changes rather than creating a new environment from scratch. To replicate an environment, click the "..." button next to the environment's "Deploy" button. Then, click "Replicate". Confirm you are replicating the correct environment and Git branch, then enter a name for your new environment. By default, all General, Environment, and Deployment settings will be duplicated. You can optionally edit the default replication settings for compute and resources. The default replication behavior is: * Compute: duplicate all clusters (including size, autoscaling, scale to zero, scheduler, Octane, Inertia, and background process settings) * Database: use the same database compute / storage cluster, but create a new logical database schema * Cache: use the same KV Store instance, but add a unique `CACHE_PREFIX` environment variable to your application * Object storage: no replication Review and edit the "Replication options" as needed before deploying your new environment. The defaults provided are a sensible balance between cost and performance, but may not be right for your application's specific use case. Use extra care when replicating a production environment to avoid reusing resources in a way that will impact performance or interfere with queued jobs, sessions, or other application data. ## Commands Laravel Cloud allows you to execute commands directly in your environment. Navigate to your environment's "Commands" tab to run one-time commands such as `php artisan cache:clear`. Commands should be non-interactive and may not run for more than 30 minutes. Commands will be executed on any available instance in your environment. ## Filesystem Environment filesystems are **ephemeral**, meaning files may not persist across requests or jobs. New deployments or re-deployments will reset the filesystem. In addition, each replica of your compute cluster has its own filesystem. Thus, you should treat the filesystem as temporary, unshared disk space that is only consistent during a single request or job. The total disk space available on each replica is proportional to the compute / RAM of the cluster. Every 1GB of RAM is equal to 512MB of disk space. For example, a cluster with 2GB of RAM will have 1GB of ephemeral disk space available to it. If you exceed the available disk space, your application may crash and the deployment may need to restart. We recommend using `redis` or `database` drivers for a persistent cache and session via a [KV Store](./resources/caches) or [database](./resources/databases/laravel-mysql) resource. For persistent file storage, use the `s3` driver via [Laravel Object Storage](./resources/object-storage). ## Nightwatch integration Laravel Cloud environments have built-in support for [Laravel Nightwatch](https://nightwatch.laravel.com) monitoring. Nightwatch provides deep insights into your application environment's performance, exceptions, logs, and overall health. Install the Laravel Nightwatch package in your application locally using [Composer](https://packagist.org/packages/laravel/nightwatch): ```bash theme={null} composer require laravel/nightwatch ``` Run composer require laravel/nightwatch on your local machine to update your composer.json and composer.lock files before deploying. Click the Connect Nightwatch button in your environment dashboard. Toggle Enable monitoring to activate Nightwatch for your environment. Enter your Nightwatch token, which you can find in your Nightwatch application settings. Enabling Nightwatch will automatically run the agent across all the App compute and Worker clusters in the environment. You can [setup Nightwatch manually](/docs/knowledge-base/nightwatch-on-cloud) if you want the agent to run on specific instances. When enabled, Laravel Cloud will automatically inject the following environment variables into your environment: ``` NIGHTWATCH_TOKEN= NIGHTWATCH_REQUEST_SAMPLE_RATE=0.1 LOG_CHANNEL=stack LOG_STACK=laravel-cloud-socket,nightwatch ``` You can override these variables in your environment variable settings if needed. If you have previously [configured Nightwatch manually](/docs/knowledge-base/nightwatch-on-cloud) with a background process, you must remove that process from every cluster before enabling the built-in integration to avoid issues with your environment. # Free trial Source: https://cloud.laravel.com/docs/free-trial Start on the Starter plan with your first 30 days free and $5 in usage credits. ## Introduction New Starter subscriptions get their **first 30 days free**: the \$5 monthly fee is waived and you receive **\$5 in usage credits**. Use them to ship your first application on Laravel Cloud—on us. ## Getting started Sign up at [cloud.laravel.com](https://cloud.laravel.com/sign-up), select the Starter plan, and add your payment details. Your first 30 days free and \$5 in usage credits are applied automatically. Laravel Cloud promotion showing $5 in free usage credits for the Starter plan with a Get started button. Credits are consumed as you provision and run resources. How far they go depends on what you deploy and for how long. Because [Scale to Zero](/docs/compute#scale-to-zero) is on by default, your compute and resources stop consuming credits while your application is idle, which makes your trial go further. ## How far does \$5 go? Laravel Cloud compute and many resources can [scale to zero](/docs/compute#scale-to-zero) when your application is idle, which means they stop consuming credits until traffic returns. For many users, that makes the \$5 go surprisingly far. Here are a few realistic examples: | Scenario | What is running | Estimated runtime | | ------------------------- | ------------------------------------------------------------------------- | ----------------- | | Weekend tinkerer | Compute + Serverless Postgres, awake about 1 hour per day | About 4 months | | Active side project | Compute + Serverless Postgres, awake about 4 hours per day | About 5 weeks | | Full-stack app with cache | Compute + Serverless Postgres + Valkey | About 3 weeks | | Everything always on | Compute, Serverless Postgres, Valkey, and WebSockets active and always on | About 7 days | These are estimates, not guarantees. Actual usage depends on the resources you provision, how long they stay active, and whether Scale to Zero is enabled. ## After your first 30 days If your usage stays under \$5 during your first 30 days, you pay nothing. You are only charged during this period for usage above your \$5 in credits. After your first 30 days, standard Starter billing begins at \$5/mo plus any usage beyond your monthly \$5 in credits. Your app stays online; nothing turns off. [View plans and pricing](/docs/pricing) # Welcome to Laravel Cloud Source: https://cloud.laravel.com/docs/intro The official infrastructure and deployment platform for Laravel applications. Laravel Cloud is a fully managed infrastructure platform for deploying and scaling Laravel applications, with built-in solutions for web and worker compute, relational databases, key-value storage, managed queues, file and object storage, and more. ## Unmatched developer experience Laravel Cloud is the only fully managed platform-as-a-service (PaaS) obsessively optimized for shipping and scaling Laravel applications. * **No application or server configuration necessary.** Most Laravel applications can be [deployed to Laravel Cloud](/docs/deployments) without any additional changes to your application's architecture. Additionally, no server management experience is required when deploying applications to Laravel Cloud. * **Fully managed MySQL / Postgres databases and Redis-compatible key-value storage.** You can provision and manage [MySQL](/docs/resources/databases/laravel-mysql) and [Postgres](/docs/resources/databases/postgres) databases directly from the Laravel Cloud dashboard. [Redis-compatible key-value storage](/docs/resources/caches/valkey) may also be provisioned in seconds. * **Managed queues.** Laravel Cloud can provision [fully managed queues](/docs/queues#managed-queues) with dedicated workers that automatically scale based on the work waiting to be processed, including scaling to zero when idle, with a built-in dashboard for retrying failed jobs. * **Zero downtime deployments and scaling.** Laravel Cloud automatically rolls out [changes to your application](/docs/deployments) without downtime. In addition, [scaling your application's infrastructure](/docs/compute#autoscaling) can be done at any time without interrupting your users. * **Scale to Zero.** Laravel Cloud can [put your environment to sleep](/docs/compute#scale-to-zero) when it is idle so you are not charged for compute, then wake it in under 500 milliseconds when a request arrives. Your scheduled tasks and queued jobs continue to run while your environment sleeps. * **Preview environments.** Automatically provision a [fully isolated environment for every pull request](/docs/preview-environments), then tear it down when the pull request is merged or closed, so your team can review changes in a production-like environment before they ship. * **Automatic TLS and load balancing.** All applications running on Laravel Cloud automatically receive [TLS certificates](/docs/domains), which are also automatically updated. Incoming traffic to your application is also automatically [distributed across your available application replicas](/docs/network#cloud-compute-network). * **Cloud Edge Network.** Laravel Cloud partners with Cloudflare to offer a [globally distributed caching and security network at the edge](/docs/network#cloud-edge-network). This edge network provides DDoS protection and edge asset caching to all applications running on Laravel Cloud. * **Monitoring and logs.** Basic [infrastructure metrics](/docs/compute#compute-metrics), such as CPU and memory usage, are available via the Laravel Cloud dashboard. You may also easily [view and search your application's logs](/docs/logs). ## Next steps We can't wait to see what you ship on Laravel Cloud. When you're ready to dive in, check out our [quickstart documentation](/docs/quickstart). ## Prerequisites Laravel Cloud supports Laravel applications on PHP 8.2 through PHP 8.5 and Laravel 9.x or greater. # Fix 502 Bad Gateway Or Internal Server Errors Source: https://cloud.laravel.com/docs/knowledge-base/502-error Troubleshoot and fix 502 bad gateway errors in Laravel apps running on Laravel Cloud. When trying to access your Laravel Cloud-deployed website, a `502 Gateway Error` means that Cloudflare, which is used in the networking layer of Laravel Cloud, was unable to reach your application. This can happen when the instance serving your application becomes unresponsive. Common issues include: ### Your environment may be under-provisioned Depending on the complexity and functionality of your Laravel application, your app may consume more memory than is available in your compute instance. When your application attempts to over-allocate memory than is available, the pod in which your application is deployed temporarily crashes and needs to reboot. Small compute instances, such as those with 256MB or 512MB RAM are often common culprits for becoming over-allocated. Common places of high RAM utilization include: * **Unoptimized queries.** Consider using eager loading or chunking when necessary to reduce data stored in memory. * **High number of active jobs.** A large number of jobs, particularly those with large payloads, may consume an excess of memory. * **Too many queue workers.** As each worker consumes memory, requesting many workers may consume more memory than anticipated. * **Excessive logging / debugging.** If your application has `APP_DEBUG=true`, you should expect higher memory usage through more verbose logging. * **Inefficient Blade templates.** Large, deeply nested Blade templates, and looping Blade directives can increase memory consumption. Consider using a local development aid like [Laravel Telescope](https://laravel.com/docs/telescope), or 3rd party packages such as [Laravel Debugbar](https://laraveldebugbar.com/), to help diagnose memory utilization for your application. *** ### Laravel Horizon may be configured improperly If you are using Laravel Horizon to manage your Redis-backed queues, be mindful of how Horizon spawns workers which can directly impact memory usage in your application. First, ensure that within your Laravel Cloud application, you configure Horizon to run with a single process (`1 process`). This is important as Horizon will automatically spawn workers based on the settings within your application's `config/horizon.php` file. Be mindful of how many workers you have defined in your `config/horizon.php` file via the `maxProcesses` key. When Horizon starts, it will automatically spawn processes based on this value for each supervisor you define. In some cases, too many workers may cause an overallocation of memory. ```php {4} theme={null} 'environments' => [ 'production' => [ 'supervisor-1' => [ 'maxProcesses' => 10, // ... ], ], ], ``` Other considerations: * If no jobs are being processed, ensure your `config/horizon.php` file has a key under `environments` that matches your `APP_ENV` value, or includes an `*` key as a fallback for when no matching environment is found. For more information, refer to the [Horizon documentation](https://laravel.com/docs/horizon#environments). * Upgrade to Laravel Horizon >=`v5.31`. Older version of Horizon can be more aggressive in spawning workers on startup. Keep in mind that even if Horizon starts successfully, your application may still crash if spawning the maximum number of workers causes an overallocation of memory. * Considering moving your Horizon, or `queue:work` workers, onto worker clusters separate from your app cluster. This ensures that your application is still reachable, even if your job queues become stressed. # Fix Production Command Failures Source: https://cloud.laravel.com/docs/knowledge-base/command-failed-prod-app Resolve Laravel Cloud production command failures including migrate force errors. Some migration operations are destructive, which means they may cause you to lose data. As all Laravel Cloud environments default to `APP_ENV=production`, you may run into issues running migrations in an ad-hoc manner using the "Commands" tab from your environment panel. Since these commands do not support interactivity, the command will fail if it attempts to prompt you for input. This happens most commonly when attempting to run migrations in a production environment. This is a safety feature of Laravel to prevent unexpected data loss. ```shell theme={null} APPLICATION IN PRODUCTION. WARN Command cancelled. ``` If you are comfortable with the risks associated with running migrations in a production environment, you may append the `--force` flag on your command to bypass the production environment warning. ```bash theme={null} php artisan migrate --force ``` *** Related commands which may also require the `--force` flag include: ```php theme={null} php artisan migrate:fresh php artisan migrate:refresh php artisan db:seed ``` ### Customizing your `APP_ENV` If you are working on non-production environment, you may consider overwriting your `APP_ENV` environment variable in your environment's [Custom Environment Variables](https://cloud.laravel.com/docs/environments#environment-variables) to better match your environment's purpose. Non-production environments will not trigger the same warnings as described above. ``` APP_ENV=development ``` # Domain Verification Source: https://cloud.laravel.com/docs/knowledge-base/domain-verification Learn how to add, validate, and verify custom domains on Laravel Cloud. When you add a custom domain to Laravel Cloud, it needs to confirm that you own the domain and that your DNS records are set up correctly. This process is called verification. Occasionally, verification may appear stuck or time out entirely — usually because a DNS record is misconfigured or has not finished propagating (the process by which DNS changes spread across the internet). ## Quick checklist * Confirm you are updating DNS at the provider that is actually responsible for your domain. This is not always your registrar — for example, if you moved your nameservers to Cloudflare, your records need to be added in Cloudflare, not at your registrar. * Confirm you added **all** records Laravel Cloud shows, including `www` and wildcard records if they are enabled. * Confirm record **names** and **values** match exactly what Laravel Cloud shows — even small differences (extra dots, missing prefixes) will cause verification to fail. * If you are using Cloudflare DNS, review the proxy status (orange cloud vs. grey cloud) for each record. Some records, such as SSL validation records, must not be proxied. ## Before you start Before adding any records, confirm which provider is actually serving DNS for your domain — this is not always where you purchased it. For example, if you registered at GoDaddy but pointed your nameservers to Cloudflare, you must add records in Cloudflare. Run the following command to check: ```bash theme={null} dig NS example.com +short ``` The output will list nameserver hostnames (e.g., `anna.ns.cloudflare.com`). Add your Laravel Cloud records at the provider that owns those nameservers. ## Add your DNS records ### General rule of thumb Most DNS providers have a "host" or "name" field that expects only the subdomain portion of a record name — not the full domain. Your provider appends the domain automatically: * For `www.example.com`, enter `www` * For `_cf-custom-hostname.example.com`, enter `_cf-custom-hostname` * For `_acme-challenge.example.com`, enter `_acme-challenge` * For `example.com` itself, most providers use `@` or leave the host blank After saving a record, always re-open it in your provider's dashboard and confirm the assembled name matches exactly what Laravel Cloud shows. This is the most effective way to catch formatting mistakes early. ### Provider-specific instructions If the `dig NS` output lists Cloudflare nameservers (e.g., `anna.ns.cloudflare.com`), add your records in Cloudflare's DNS dashboard. In Cloudflare, select your website and open **DNS**. In Laravel Cloud, open your domain's configuration and copy the **origin** record(s). These records tell Cloudflare where to send traffic for your domain. For the record name in Cloudflare: * Use `@` for the root domain (e.g., `example.com`) * Use `www` for `www.example.com` * Use `*` for `*.example.com` (wildcards), if shown For proxy status (the orange / grey cloud icon in Cloudflare): * Origin records are typically safe to proxy (orange cloud) if you selected a Cloudflare proxy option in Laravel Cloud. * If you are unsure, start with the proxy status Laravel Cloud recommends in the UI. If Laravel Cloud shows an ownership verification record like `_cf-custom-hostname.example.com`, add it as a **TXT** record. Set the record name to `_cf-custom-hostname` — Cloudflare appends the domain automatically. Laravel Cloud may show `_acme-challenge` records used to issue your domain's SSL certificate. Copy them exactly as shown. If the `_acme-challenge` record is a **CNAME**, ensure it is set to **DNS only** (grey cloud) in Cloudflare. Proxying this record will prevent the SSL certificate from being issued. **Wildcard domains and DCV delegation** Wildcard domains (e.g., `*.example.com`) require a special `_acme-challenge` CNAME called a DCV delegation record. This allows Laravel Cloud to automatically issue and renew SSL certificates for your wildcard domain. Keep this record in place and ensure it remains **DNS only** (grey cloud) at all times — removing or proxying it will prevent certificate renewals. **Troubleshooting Cloudflare records** * Confirm you are editing DNS records in the correct Cloudflare account and zone. * Confirm record names are not duplicated. A common mistake is entering the full name including the domain, which causes Cloudflare to append it again (e.g., `_cf-custom-hostname.example.com.example.com`). * If you are pre-verifying your domain and see Cloudflare-related verification errors, temporarily setting the record to **DNS only** may be required until verification completes. You can re-enable the proxy afterward. Unlike most providers, Route 53 accepts fully qualified record names — you can paste the complete name from Laravel Cloud (e.g., `_cf-custom-hostname.example.com`) directly into the name field. Route 53 may add a trailing dot (e.g., `_cf-custom-hostname.example.com.`), which is standard DNS formatting and is expected. If you are not sure you are editing the correct hosted zone, confirm which nameservers are authoritative for your domain: ```bash theme={null} dig NS example.com +short ``` The output should match the nameservers listed in your Route 53 hosted zone. GoDaddy's DNS editor uses a "Host" field that expects only the subdomain portion. For example, if Laravel Cloud shows `_cf-custom-hostname.example.com`, enter `_cf-custom-hostname` — GoDaddy adds `.example.com` for you. After saving, GoDaddy displays the full record name. Confirm it matches the record name shown in Laravel Cloud exactly, with no repeated or missing parts. Namecheap's DNS editor uses a "Host" field that expects only the subdomain portion. For example, if Laravel Cloud shows `_acme-challenge.example.com`, enter `_acme-challenge` — Namecheap adds the domain automatically. For root-domain records (i.e., records for `example.com` itself), use `@` as the host value. Squarespace (which acquired Google Domains) has its own naming conventions. In any name or host field, omit the `.example.com` suffix — Squarespace appends it for you: * If Laravel Cloud shows `_cf-custom-hostname.example.com`, enter `_cf-custom-hostname` * For `www.example.com`, enter `www` * For a wildcard `*.example.com`, enter `*` ## Verification timeline Most domains verify within 15 minutes once the correct DNS records are publicly visible. However, propagation can take longer depending on your DNS provider and the record's TTL (time-to-live) — a value that controls how long DNS results are cached before being refreshed. Laravel Cloud will automatically retry verification checks for approximately 12 hours. If verification still cannot complete after that period, the domain will time out and you may need to correct your DNS records and retry. ## Check your records in the terminal You can verify that your DNS records are publicly visible by running `dig` commands in your terminal. Replace `example.com` with your actual domain: ```bash theme={null} # Which DNS provider is responsible for your domain? dig NS example.com +short # Are your origin records (the records that point traffic to Laravel Cloud) resolving? dig A example.com +short dig CNAME example.com +short # Is the ownership verification record visible? dig TXT _cf-custom-hostname.example.com +short # Are the SSL validation records visible? (may be TXT or CNAME depending on your setup) dig TXT _acme-challenge.example.com +short dig CNAME _acme-challenge.example.com +short ``` If any command returns no output, that record is either missing or has not finished propagating. ## Common verification issues ### Records added in the wrong place If your domain is managed in multiple places (for example, you registered at GoDaddy but pointed your nameservers to Cloudflare), it is easy to add records in the wrong place. Records must be added at the provider that is actually serving your DNS — not necessarily where you purchased the domain. Run `dig NS example.com +short` to confirm which provider is authoritative. ### Missing `www` records when redirects are enabled Laravel Cloud's `Redirect from www.` setting is enabled by default and is the recommended configuration. When enabled, Laravel Cloud will validate both `example.com` and `www.example.com`, which means DNS records are required for both hostnames. If you only added records for `example.com` and skipped `www`, verification can fail. Make sure you added records for both hostnames exactly as shown in the domain configuration screen. ### DNS provider formatting issues (host vs. full name) Most DNS providers have a "host" or "name" field that expects only the subdomain portion of a record name. The provider then appends your domain automatically. If you paste the full name from Laravel Cloud into this field, the domain gets added twice. For example: * `_cf-custom-hostname.example.com.example.com` — incorrect, domain appended twice * `_cf-custom-hostname.example.com` — correct To avoid this, enter only the part before your domain (e.g., `_cf-custom-hostname`). After saving, re-open the record to confirm the assembled name matches what Laravel Cloud shows. See the [provider-specific instructions](#provider-specific-instructions) above for details. ### Cloudflare proxy and DNS-only records Cloudflare has a proxy feature (shown as an orange cloud icon) that routes traffic through its network. While this is useful for your site's origin records, certain verification and SSL records must bypass the proxy and be set to **DNS only** (grey cloud). In particular, `_acme-challenge` records used for SSL certificate issuance and DCV delegation must always be DNS only — proxying them will prevent certificates from being issued or renewed. If you are pre-verifying your domain and see Cloudflare-related verification errors, temporarily setting the hostname's record to **DNS only** may be required until verification completes. You can re-enable the proxy afterward. ### Verification appears propagated but Laravel Cloud still shows "Validating" If your records look correct when checked with `dig` or an external DNS tool, but the domain is still showing as "Validating" or "Timed Out" in Laravel Cloud, this may indicate that our network provider (Cloudflare) has flagged the domain for manual review. This can happen even if your domain is not hosted on Cloudflare, because Laravel Cloud uses Cloudflare's infrastructure behind the scenes to manage SSL certificates and routing. Cloudflare's automated systems occasionally flag domains due to potential abuse concerns. This is sometimes a false positive and requires intervention on the Cloudflare side to resolve. If you believe this is affecting your domain, please raise a ticket through the **Help** portal in your Laravel Cloud dashboard so the team can assist. ## When to contact support If your domain is still stuck after working through the steps above, contact support through the **Help** portal in your Laravel Cloud dashboard. To help the team diagnose the issue quickly, include: * Your domain name * Screenshots of the DNS records as they appear in your DNS provider's dashboard * The output from the `dig` commands listed in the [Check your records in the terminal](#check-your-records-in-the-terminal) section above # Fix Environment Not Sleeping Issues Source: https://cloud.laravel.com/docs/knowledge-base/environment-not-sleeping Troubleshoot and fix Laravel Cloud environments that won't scale to zero. [Scale to Zero](/docs/compute#scale-to-zero) is enabled by default on Flex compute instances. If you change this setting, you will need to **Save and Redeploy** your environment for it to take effect. Even when you aren't actively using your application, it can still receive requests that wake it from sleep: * Simple vanity domains can occasionally be found by bots scanning for active web pages to index. Consider using the auto-generated domain or choosing a more complex vanity domain to reduce stray bot traffic. * Custom domains may have existing traffic patterns, such as being regularly crawled or indexed by bots. Laravel Cloud blocks many such instances, but it is not always possible to differentiate regular requests from automated ones. * Links posted into common messaging applications, like Slack, can automatically "visit" your site in order to access thumbnails and other metadata about your site. * Applications that use WebSockets may delay the sleep timer. Because your environment also wakes automatically to run [scheduled tasks](/docs/scheduled-tasks) and process [queued jobs](/docs/queues), a wake interval at or below your sleep timeout can keep the environment awake continuously: * A scheduled task or manual wake interval that runs more frequently than the sleep timeout will wake the environment before it can sleep. For example, a task that runs every 5 minutes with a 5-minute sleep timeout means the environment never reaches the timeout and never sleeps. * To resolve this, set your sleep timeout shorter than your most frequent wake interval, or space out your scheduled tasks. Databases that support Scale to Zero, such as Serverless Postgres, are configured separately. As with your app cluster, changing these settings requires **Save and Redeploy** to take effect. # Generating PDFs Source: https://cloud.laravel.com/docs/knowledge-base/generating-pdfs Learn how to generate PDFs with Laravel in Laravel Cloud. You may generate PDFs in Laravel Cloud by leveraging [Cloudflare's Browser Rendering API](https://developers.cloudflare.com/browser-rendering/rest-api/pdf-endpoint/#convert-custom-html-to-pdf). To get started, generate a Cloudflare API token that has the `Account.Browser Rendering` permission and locate your Account ID from your Cloudflare dashboard URL. ## Using Laravel PDF [Spatie's Laravel PDF](https://spatie.be/docs/laravel-pdf) package provides a convenient wrapper around Cloudflare's Browser Rendering API via its built-in Cloudflare driver. No Node.js or Chrome binary is required on your instances. First, install the package via Composer: ```bash theme={null} composer require spatie/laravel-pdf ``` Then, add the following environment variables to your Cloud environment's environment variable settings: ```env theme={null} LARAVEL_PDF_DRIVER=cloudflare CLOUDFLARE_API_TOKEN=your-api-token CLOUDFLARE_ACCOUNT_ID=your-account-id ``` Once configured, you may generate PDFs using the `Pdf` facade. For example, the following controller method renders a view as a PDF and streams it as a download to the browser: ```php theme={null} use Spatie\LaravelPdf\Facades\Pdf; public function download() { return Pdf::view('pdfs.invoice', ['invoice' => $invoice]) ->format('a4') ->download('invoice.pdf'); } ``` For more information on available options such as custom paper sizes, margins, headers, and footers, please refer to the [Laravel PDF documentation](https://spatie.be/docs/laravel-pdf). ## Using Laravel Cashier with Laravel PDF Cashier's default invoice PDF renderer uses Dompdf, which does not work in Laravel Cloud. To generate Cashier invoices on Cloud, install Spatie's Laravel PDF package and configure the Cloudflare environment variables as described [above](#using-laravel-pdf): ```bash theme={null} composer require spatie/laravel-pdf ``` Then, set Cashier to use its built-in Laravel PDF invoice renderer by adding the following environment variable to your Cloud environment's environment variable settings: ```env theme={null} CASHIER_INVOICE_RENDERER=Laravel\Cashier\Invoices\LaravelPdfInvoiceRenderer ``` Cashier will automatically resolve this renderer at runtime and use Spatie Laravel PDF when generating invoice downloads. ## Manual Usage If you prefer to call the Cloudflare API directly without an additional dependency, add a `cloudflare` entry to your `services.php` config file: ```php theme={null} 'cloudflare' => [ 'api_token' => env('CLOUDFLARE_API_TOKEN'), 'account_id' => env('CLOUDFLARE_ACCOUNT_ID'), ], ``` Next, set these environment variables in your Cloud environment's environment variable settings. Now you may call the Cloudflare PDF API using Laravel's built-in `Http` facade. The following example demonstrates how to generate HTML from a view and stream the response as a downloadable PDF to the browser from a controller method: ```php theme={null} use Illuminate\Support\Facades\Http; public function download() { return response()->streamDownload(function () { $token = config('services.cloudflare.api_token'); $accountId = config('services.cloudflare.account_id'); echo Http::withToken($token) ->post('https://api.cloudflare.com/client/v4/accounts/'.$accountId.'/browser-rendering/pdf', [ 'html' => view('view-to-render')->render(), ]) ->body(); }, 'file.pdf', [ 'Content-Type' => 'application/pdf', ]); } ``` # Knowledge Base Source: https://cloud.laravel.com/docs/knowledge-base/intro Browse helpful guides and articles for Laravel Cloud setup, deployment, and troubleshooting. Welcome to Laravel Cloud's knowledge base. Here you will find guides and troubleshooting articles tailored to common questions or issues you may face when using Cloud. Use the sidebar navigation (or navbar menu on mobile) to see the available articles. If you need further assistance or would like to suggest a new KB topic, please contact support by clicking the "chat" button in the bottom/right of your screen. # Understanding Logs Source: https://cloud.laravel.com/docs/knowledge-base/logs Learn about common application logs when using Laravel Cloud. ## \[error] Access forbidden by rule As is common for many websites on the internet, bots may often scan trying to find vulnerabilities on your website. When a bot tries to request access to a page that does not exist, or is explicitly blocked by Laravel Cloud for security purposes, you may see related `[error]` logs. These can be safely ignored. ```shell theme={null} Example logs: 2025-03-26 17:26:05 UTC 2025/03/26 17:26:05 [error] 148#148: *35409 access forbidden by rule, client: 2600:1f16:e0:8506:ea9f::8, server: _, request: "GET /config/php.ini HTTP/1.1", host: "yourWebsite.com" 2025-03-26 17:26:18 UTC 2025/03/26 17:26:18 [error] 150#150: *35439 access forbidden by rule, client: 2600:1f16:e0:8506:b40f::6, server: _, request: "GET /.aws/credentials HTTP/1.1", host: "yourWebsite.com" 2025-03-26 17:26:24 UTC 2025/03/26 17:26:24 [error] 150#150: *35455 access forbidden by rule, client: 2600:1f16:e0:8506:ea9f::8, server: _, request: "GET /config.ini HTTP/1.1", host: "yourWebsite.com" ``` *** ## fatal: not a git repository Some packages may attempt to access your `.git` directory during runtime in your application. When using Laravel Cloud, the `.git` folder is removed during the deploy process, meaning this directory is unavailable at runtime, which can trigger this error for packages that depend on this. For example, having Sentry installed will allow you the option to run Git to grab the current commit hash, thus triggering these errors. If a package depends on your deployment's Git hash being available, you can inject it as an environment variable by adding the following to your build commands: ```bash theme={null} # Install production dependencies... composer install --no-dev # Add the Git commit hash to an environment variable... echo -e "\nSENTRY_RELEASE=`git log --pretty="%h" -n1 HEAD`" >> .env # Cache the configuration to make SENTRY_RELEASE available at runtime... php artisan config:cache ``` *** ## \[truncated due size] The message `[truncated due size...]` log is indicating that a log message exceeded a size limit, causing the message to be cut off. This typically happens when logs or error messages are too lengthy. This can be common during your deployment process. To reduce the size of the content printed out for your deploy commands, you can reduce the commands' verbosity through additional flags: ``` composer install --no-dev --quiet npm ci --quiet --no-progress ``` Note that if your application is in `APP_DEBUG=true`, errors will produce a full stack track which can be truncated. # Manage robots.txt Source: https://cloud.laravel.com/docs/knowledge-base/managing-robots The `robots.txt` file is essential for controlling search engine crawlers' access to your site. It provides information on which pages and sections can be visited by web crawlers. If you need to customize the contents of this file when your application is being deployed, you can add a command to the **Build Commands** section of your environment's deployment settings. For example, if you want to disallow crawling any part of your website: 1. Visit your application environment 2. Open its **Settings** page 3. On the **Deployments** section of the Settings page. Under the **Build commands** section, add: ```shell theme={null} echo -e "User-agent: *\nDisallow: /" > public/robots.txt ``` ## Cloudflare reserved paths and SEO Laravel Cloud utilizes Cloudflare's CDN service, which automatically reserves the `/cdn-cgi` path on all hosted domains. This path appears on your domain as `https://www.example.com/cdn-cgi/l/email-protection` and similar endpoints. These `/cdn-cgi` endpoints are: * Automatically generated by Cloudflare's service * Managed entirely by Cloudflare * Cannot be modified or customized For optimal SEO performance, consider adding the following directive to your `robots.txt` file to exclude these paths from search engine crawling: ``` Disallow: /cdn-cgi/ ``` For additional technical details about Cloudflare's CDN endpoints, refer to [Cloudflare's developer documentation](https://developers.cloudflare.com/fundamentals/reference/cdn-cgi-endpoint). # Migrate an Application to a Different Region Source: https://cloud.laravel.com/docs/knowledge-base/migrate-to-different-region Learn how to move your Laravel Cloud application to a different region. To move your application and its resources to a new region, create the new regional infrastructure first, then cut traffic over. This guide walks you through each step. ## Before you start You cannot perform this migration in place. You will run old and new environments in parallel until cutover. Downtime is possible, especially during database cutover, so plan accordingly (for example, schedule a maintenance window and take backups). If you use private database connectivity, your database region must match your application region. ## Step 1: Create the new application Create a new application in the target region using the same repository. Then recreate each environment, matching branch names and settings from the original application. ## Step 2: Migrate the database Laravel Cloud does not provide cross-region database copy or restore. Complete the migration manually: 1. Export data from the current database (for example, `mysqldump`, `pg_dump`, or a Neon export). 2. Create a new database in the target region via the normal create flow. 3. Import your data into the new database. 4. Attach the new database to the new application's environments. Do not detach or delete the original database until you have verified cutover. ## Step 3: Migrate the cache Cache data migration is not handled by the platform. The process depends on whether cache data must be preserved: 1. Create a new cache in the target region. 2. Attach it to your new environments. 3. If data must be preserved, implement dual writes in your application before switching reads to the new cache. 4. Delete the old cache once you've cut over. If your cache is ephemeral (such as sessions or rate-limiting state), you can skip data migration and start with a fresh cache. ## Step 4: Migrate WebSockets (Reverb) 1. Create a new Reverb WebSocket cluster in the target region. 2. Attach it to the new environments. 3. Delete the old cluster after cutover. ## Step 5: Copy environment configuration Manually copy configuration from each old environment to its corresponding new environment: * Environment variables * Build and deploy settings * Vanity domains ## Step 6: Deploy and verify Deploy each environment in the new application, then verify: * Deployments complete successfully * Database connectivity works * Cache is functioning * WebSocket connections are established * Logs are appearing (logs are region specific through OpenSearch) ## Step 7: Migrate domains To move your domains to the new application: 1. Go to the old environment's **Network settings**. 2. Open the **...** dropdown on each domain. 3. Click the **Move** option. 4. Follow the dialog instructions and select the new environment as the target. 5. Redeploy the new application so `APP_URL` is updated. Primary domains cannot be moved between environments. First, choose **Unset as primary** in the domain dropdown. After the move completes, set the domain as primary in the new application. ## Step 8: Clean up Once you've confirmed everything is working in the new region: * Delete or archive the old database, cache, and WebSocket cluster * Delete the old application # Migrate MySQL to PostgreSQL Source: https://cloud.laravel.com/docs/knowledge-base/migrating-mysql-to-postgresql Learn how to convert MySQL to PostgreSQL in Laravel and migrate to hosted Serverless Postgres on Laravel Cloud. If you're moving to Laravel Cloud and want a database that scales to zero today, you can migrate from MySQL to PostgreSQL. Laravel **Serverless Postgres** scales to zero — meaning your database sleeps when idle, and you won’t be billed for unused compute time. In contrast, **Laravel MySQL** databases are currently always-on with fixed compute and storage sizes. Scale to Zero for Laravel MySQL Flex is coming soon. ### Migrating your data To move from MySQL to Postgres, you will need to: * Export your MySQL database (e.g., using `mysqldump`). * Use a tool like [**pgloader**](https://pgloader.io/) to import the data into your Serverless Postgres database. pgloader is specifically designed to convert MySQL databases to Postgres and handles much of the transformation automatically. Some tweaks may be needed depending on your schema, but many Laravel applications migrate cleanly with minimal effort. If you need more guidance, our database partner, **Neon**, has a helpful step-by-step guide: [Migrate from MySQL to Neon Postgres](https://neon.tech/docs/import/migrate-mysql). ### Application implementation considerations Keep in mind that although Postgres is very similar to MySQL, it is generally more strict in certain field definitions and usage. Below are common considerations which may be relevant to your application.
MySQL Postgres Considerations
Boolean Values Stores as `TINYINT` Stores as `BOOLEAN` Boolean casting works in Laravel, but avoid direct 0/1 comparisons in raw queries.
Auto-Increment IDs Uses AUTO\_INCREMENT Uses SERIAL Laravel handles this with \$table->id() or increments(), but raw SQL may need to be adjusted.
Unsigned Integers Supports unsignedInteger and unsignedBigInteger Must use signed bigInteger / foreignId() Although Laravel will silently handle conversions in your migration files, executing raw imports may reference UNSIGNED BIGINT columns. You will need to cast or redefine types on import.
UUIDs Stores as strings Has native UUID support If you have a custom UUID definition that does not match the specification, it will fail in Postgres. Use Laravel’s Str::uuid() helper to stay compatible.
Zero Dates Allows '0000-00-00' Invalid Date Use nullable() and avoid "zero dates"; Postgres will throw an error.
JSON Column Supported, but is not validated. Validates JSON on save. Ensure the JSON you store is valid, else Postgres save will fail.
Timestamp with Timezone `timestamp` does not store timezone detail Supports `timestamp` with and without timezone Laravel defaults to timestamp, so you must explicitly use \$table->timestampTz() if you want time zone-aware behavior.
Implicit Foreign Key Indexes Foreign key columns automatically receive corresponding index Indexes are not automatically created Explicitly add ->index() to any foreignId() columns to ensure indexes are created.
# Monorepo Support Source: https://cloud.laravel.com/docs/knowledge-base/monorepo-support Deploy a Laravel application from a monorepo on Laravel Cloud, with or without building and hosting a separate frontend on the same service. Laravel Cloud does not officially support monorepos yet, but you can work around this limitation with a custom build script. How you configure that script depends on what you are deploying: **only the Laravel application** from the monorepo, or **Laravel plus a built frontend** (for example, a static Nuxt site served from Laravel's `public/` directory). Monorepo support is not officially available yet, but we are actively working on it. In the meantime, some users have had success with the workarounds below. Use them at your own risk — Laravel Cloud Support may be unable to assist with debugging custom monorepo configurations. ### Choose your deployment path * **Laravel only.** Your monorepo includes a Laravel app in a subdirectory, and you want Cloud to run that app after promoting it to the repository root. Any frontend assets built with Laravel's own tooling (for example, Vite or Laravel Mix) are compiled as part of that app after promotion; you are not copying in a separate SPA package from another directory. * **Laravel and a separate frontend.** Your monorepo has a Laravel API (or full backend) and a frontend in another directory (for example, `frontend/` with Nuxt). The build script promotes Laravel to the root, builds the frontend, and copies the generated static files into Laravel's `public/` directory so one service serves both. Both approaches use the same prerequisites in the next section. ### Shared prerequisites You need a *fake* `composer.lock` in your repository root. Copy the `composer.lock` file from the Laravel application subdirectory you deploy and commit it at the monorepo root. That file tells Laravel Cloud that the repository contains a Laravel application. It does not need to be kept up to date. Customize your environment's build script in Laravel Cloud so it runs **after** checkout and performs the moves, installs, and builds required by your chosen path. If you add commands that use a different JavaScript toolchain than the defaults, remove or comment out the default `npm` steps in your build configuration so they do not conflict. ### Deploying only the Laravel application Use this approach when the only application you are shipping is the Laravel project in a subdirectory. After that directory becomes the repository root, run `composer install` and your usual steps (for example, `npm install` and `npm run build` for Vite or Mix assets defined in that Laravel app). If the monorepo also contains other top-level directories you are not deploying (for example, a separate `frontend/` package), list only the directories you need to relocate in the script below. You can leave unused directories in the temporary folder so they are not copied into the deployment root. ```bash theme={null} # --------------------------------- # Deploying the "laravel_app" directory # --------------------------------- # Step 1: Create a temporary directory mkdir /tmp/monorepo_tmp # Step 2: Create an array with all subdirectories repos=("laravel_app" "go_app") # Step 3: Move all subdirectories to the temporary directory for item in "${repos[@]}"; do mv $item /tmp/monorepo_tmp/ done # Step 4: Copy the Laravel app into the deployment root cp -Rf /tmp/monorepo_tmp/laravel_app/. . # Step 5: Remove the temporary directory rm -rf /tmp/monorepo_tmp # Step 6: Proceed with build steps composer install --no-dev npm install npm run build ``` **Notes:** * Replace `laravel_app` with the name of the Laravel app directory you want to deploy. * If your app depends on sibling directories (such as shared packages or configuration), you will need to adjust paths manually or restructure accordingly. ### Deploying Laravel and a static frontend (Nuxt) Use this approach when you build a client-rendered frontend at deploy time and serve it from Laravel. Laravel Cloud expects a single application at the repository root; the script stashes your `backend/` and `frontend/` directories, promotes the Laravel app to the root, installs PHP dependencies, generates static Nuxt output, and copies that output into `public/`. At runtime, PHP serves the API and the static files; you do not need a Node.js server for the SPA. The directory names `backend` and `frontend` are examples. Replace them with your actual paths. The script below also removes monorepo-level files from the build working directory (for example, `composer.json` and `composer.lock` that belong to the monorepo root, not the promoted Laravel app). Some teams additionally remove `.git` or other files; adjust the `rm` list for your repository and security practices. Move both application directories to a temporary path, then remove files at the repository root that would conflict with copying the Laravel app into place. Copy the Laravel application into the deployment root and run `composer install` for production. Install your JavaScript tooling (this example uses Bun), install frontend dependencies, run static generation, and copy the generated files into Laravel's `public/` directory on the instance. ```bash theme={null} # --------------------------------- # Deploying backend + frontend (Nuxt static) # --------------------------------- # Step 1: Create a temporary directory mkdir /tmp/monorepo # Step 2: Move backend and frontend to the temporary directory repos=("backend" "frontend") for item in "${repos[@]}"; do mv $item /tmp/monorepo/ done # Step 3: Remove monorepo-level files at the repository root rm -rf composer.lock rm -rf composer.json rm -rf README.md rm -rf .gitignore rm -rf .git rm -rf solo.yml # Step 4: Copy the backend into the deployment root cp -Rf /tmp/monorepo/backend/. . # Step 5: Install Composer dependencies composer install --no-dev --no-interaction --prefer-dist --optimize-autoloader # Step 6: Install Bun npm i -g bun # Step 7: Install frontend dependencies and generate static assets cd /tmp/monorepo/frontend bun install bun run generate # Step 8: Copy generated files into Laravel public cp -Rf .output/public/* /var/www/html/public/ # Step 9: Remove the temporary directory rm -rf /tmp/monorepo ``` The copy target `/var/www/html/public/` is in the application root Laravel Cloud uses during the build. The generated `index.html` and assets must end up there so the web server can serve them. To install Bun (or another package manager) inside the build, see [Using Yarn, PNPM, or Bun](/docs/knowledge-base/using-yarn-bun-pnpm). If your environment runs default `npm install` and `npm run build` steps, align those with this script or remove them so they do not run against the wrong directory. ### Application configuration for a static frontend These details assume a statically generated Nuxt app served by Laravel, not server-side rendering in Node. **Nuxt.** Configure the frontend as a client-side SPA (for example, `ssr: false` in `nuxt.config.ts`) so `nuxt generate` (or `bun run generate`) produces static files. When the API and SPA share a domain in production, you can use relative URLs for API calls (for example, `/api/...`) instead of a separate API host in runtime config. During local development, proxy `/api` and `/sanctum` from the Nuxt dev server to your Laravel URL so routing matches production. **Laravel.** Add a catch-all route so unknown paths return the SPA shell while API and Sanctum routes continue to be handled by Laravel: ```php theme={null} Route::get('/{any?}', function () { return response(file_get_contents(public_path('index.html'))) ->header('Content-Type', 'text/html'); })->where('any', '^(?!api|sanctum).*$'); ``` **Authentication and CORS.** [Laravel Sanctum](https://laravel.com/docs/sanctum) works well when the SPA and API share a domain. [Configure CORS](https://laravel.com/docs/routing#cors) for local development (for example, your Nuxt dev origin); in production, same-origin requests avoid cross-origin issues. This pattern serves a **pre-built** Nuxt site from Laravel. **Nuxt SSR** or a dedicated Node process for rendering is a different architecture and is not covered by this workaround. # Manually Configure Laravel Nightwatch on Cloud Source: https://cloud.laravel.com/docs/knowledge-base/nightwatch-on-cloud Follow these steps to manually configure [Laravel Nightwatch](https://nightwatch.laravel.com) in your Laravel application and run the agent as a background process in your Cloud environment. For more details, see the [Nightwatch Getting Started Guide](https://nightwatch.laravel.com/docs/getting-started/start-guide). You can easily connect all your App compute and Worker clusters by [automatically integrating Nightwatch with your app environment](/docs/environments#nightwatch-integration). ## Configure Nightwatch on Cloud Install the Laravel Nightwatch package in your application locally using [Composer](https://packagist.org/packages/laravel/nightwatch): ```bash theme={null} composer require laravel/nightwatch ``` Run `composer require laravel/nightwatch` on your local machine to update your composer.json and composer.lock files before deploying. Add your Nightwatch environment's `NIGHTWATCH_TOKEN` to your `.env` file: ``` NIGHTWATCH_TOKEN=your-api-token ``` You will find this value in your Nightwatch dashboard when you create an application. To ensure the Nightwatch agent is always running and sending data, configure it as a background process in your Cloud environment: 1. Go to your **App cluster** in the Cloud dashboard. Select the app cluster 2. Click **New background process**. Select “New Background Process” 3. Choose **Custom worker**. Add a custom worker that runs the `nightwatch:agent` command 4. Enter the following command: ```bash theme={null} php artisan nightwatch:agent ``` 5. Save your changes and redeploy your application. If you're using a dedicated [worker cluster](/docs/compute#worker-clusters), repeat these steps for the worker cluster so it also runs the agent. To check the health of the running agent, use the following command: ```bash theme={null} php artisan nightwatch:status ``` The `nightwatch:status` command will exit with a non-zero status code if there is an error. This command will ensure the agent is able to accept connections and send data to Nightwatch. ## Use Cloud and Nightwatch logs To send your logs to both [Laravel Cloud Logs](/docs/logs) and [Nightwatch](https://nightwatch.laravel.com/docs/agent/logging), use Laravel's [log stacks](https://laravel.com/docs/12.x/logging#building-log-stacks) feature. Update your `.env` file as shown below to enable logging to both services: ```bash theme={null} LOG_CHANNEL=stack LOG_STACK=laravel-cloud-socket,nightwatch ``` ## Frequently asked questions **Why would I want to run Nightwatch manually?** If you only want the Nightwatch agent to run on specific instances, you can manually set up the background process for each one. **Can I log to both Nightwatch and Cloud Logs?** Yes, you can use [Laravel Cloud Logs](/docs/logs) simultaneously with [Nightwatch Logging](https://nightwatch.laravel.com/docs/agent/logging) by [setting a log stack in your .env in your Cloud environment settings](#use-cloud-and-nightwatch-logs). **Do you need a background process running for each worker cluster?** Yes, you should configure a background process for each worker cluster that needs to run the Nightwatch agent. **Can you run the command from the Commands dashboard of Laravel Cloud?** No, the Nightwatch agent must run as a background process to continuously collect and send data. Running it from the Commands dashboard will not keep the agent running. # SQLite Support Source: https://cloud.laravel.com/docs/knowledge-base/sqlite Learn why SQLite is not supported on Laravel Cloud, which databases we recommend, and how to migrate from SQLite to PostgreSQL or MySQL. While SQLite is a popular option for development and lightweight applications, **it is not supported in Laravel Cloud production environments**. This is because Laravel Cloud environments are [ephemeral](../environments#filesystem), meaning the filesystem resets across deployments, reboots, and infrastructure migrations. Since SQLite stores data in a single file on disk (often `*.sqlite`, `*.db`, or a path you configure in `DB_DATABASE`), any changes are lost whenever your application is redeployed, sleeps and wakes, or is moved between hosts. We recommend [**Laravel Serverless Postgres**](/docs/resources/databases/postgres) for most apps: it scales to zero when idle, scales with usage, and keeps persistent storage across deployments. [**Laravel MySQL**](/docs/resources/databases/laravel-mysql) is available if you prefer it. ## Migrating from SQLite to PostgreSQL or MySQL When you deploy to Laravel Cloud, you need a hosted database such as [Laravel Serverless Postgres](/docs/resources/databases/postgres) (Neon) or [Laravel MySQL](/docs/resources/databases/laravel-mysql). If your app currently uses SQLite, migrate your schema and data using one of the paths below. ### SQLite to PostgreSQL (Neon) If you plan to load the `.db` file with pgloader in the import step below, skip this step and the cleanup step. Otherwise, from your project directory, dump the database to SQL: ```bash theme={null} sqlite3 your_database.db .dump > dump.sql ``` PostgreSQL uses different syntax than SQLite. You only need this step if you import with `psql` using a hand-edited `dump.sql` (if you use pgloader with the `.db` file directly, skip this step). Edit `dump.sql` as needed: * Remove or replace `BEGIN TRANSACTION` and `COMMIT`. * Replace `INTEGER PRIMARY KEY AUTOINCREMENT` with `SERIAL PRIMARY KEY` or `BIGSERIAL PRIMARY KEY`. * Replace `BLOB` with `BYTEA`. * Remove all `PRAGMA` statements. * Replace `TEXT` columns that store dates with `TIMESTAMP` if you want PostgreSQL-native date handling. * Strip any `OWNER TO` or `GRANT` statements that reference system roles; Neon does not support superuser operations. [**pgloader**](https://pgloader.io/) can load a SQLite file directly into Postgres. Check pgloader’s release notes for PostgreSQL 18 compatibility before you proceed. If it supports your target version, run (substitute the full path to your SQLite file; see [pgloader’s SQLite reference](https://pgloader.readthedocs.io/en/latest/ref/sqlite.html) for URI forms): ```bash theme={null} pgloader sqlite:///absolute/path/to/your_database.db "postgresql://user:password@ep-xxx.region.aws.neon.tech/dbname?sslmode=require" ``` `sslmode=require` is mandatory for Neon. If pgloader does not yet support PostgreSQL 18, finish cleaning `dump.sql` manually and import with `psql`: ```bash theme={null} psql "postgresql://user:password@ep-xxx.region.aws.neon.tech/dbname?sslmode=require" < dump.sql ``` Confirm that row counts match across all tables, foreign keys and unique constraints behave as expected, and your application runs against the new database without query errors. ### SQLite to MySQL 8.4 ```bash theme={null} sqlite3 your_database.db .dump > dump.sql ``` Edit `dump.sql` for MySQL compatibility: * Translate SQLite’s `INTEGER PRIMARY KEY AUTOINCREMENT` pattern into a MySQL integer primary key column that uses `AUTO_INCREMENT`. * Replace `TEXT` with `LONGTEXT` or `VARCHAR(n)` as appropriate for your columns. * Remove all `PRAGMA` statements. * Change double-quoted identifiers (for example, `"column"`) to backticks (for example, `` `column` ``). * Replace `BEGIN TRANSACTION` with `START TRANSACTION`. * Keep `BLOB` as `BLOB`. * Booleans: SQLite stores booleans as `0`/`1` integers; MySQL’s `TINYINT(1)` behaves the same way. * `utf8mb4` is the default character set for new databases on MySQL 8.4 in most configurations, so you often do not need to set it explicitly. ```bash theme={null} mysql -u user -p target_db < dump.sql ``` Confirm that row counts match across all tables, foreign keys and unique constraints behave as expected, and your application runs against the new database without query errors. ### Before you go live * Run through the migration on a **staging** environment first. * For MySQL, the [`sqlite3-to-mysql`](https://pypi.org/project/sqlite3-to-mysql/) package (`pip install sqlite3-to-mysql`) can automate dialect conversion instead of editing `dump.sql` by hand. * SQLite is permissive about types; PostgreSQL and MySQL are stricter, so invalid data may only surface after you migrate. * Foreign keys are not always enforced in SQLite (for example, when `PRAGMA foreign_keys` is off). Your target database will enforce them, which can reveal existing data integrity problems. # Upgrading from MySQL 8.0 to MySQL 8.4 Source: https://cloud.laravel.com/docs/knowledge-base/upgrade-mysql-to-84 Learn how to prepare for and perform the upgrade from MySQL 8.0 to MySQL 8.4 on Laravel Cloud. MySQL 8.0 is entering end-of-life in April 2026. We recommend upgrading all Laravel MySQL 8.0 databases to 8.4 as soon as possible. Although Laravel Cloud makes this incredibly easy, **the upgrade is irreversible**, so take a few minutes to prepare before starting. ## Before you upgrade ### 1. Back up your database Before you do anything, create a manual backup of your database. If something goes wrong, this is your only way to recover. 1. Go to "Org > Resources > Databases" 2. Click on your Laravel MySQL 8.0 database 3. Go to "Backups" 4. Click "New backup" 5. Give your backup a name and a description Learn more about [Laravel MySQL backups](/docs/resources/databases/laravel-mysql#database-backups). ### 2. Review core changes between 8.0 and 8.4 Most applications will upgrade without issues, but check the following: **Foreign key strictness.** Foreign key constraints now require a unique key on the parent table's referenced column, not just any index. If your schema has foreign keys referencing non-unique indexes, the upgrade will fail. Check your schema and ensure all referenced columns have a unique key or primary key. **New reserved keywords.** MySQL 8.4 reserves several new words, including `MANUAL`, `PARALLEL`, `QUALIFY`, and `TABLESAMPLE`. If you use any of these as unquoted table or column names, queries will break. Either quote or rename those identifiers. **`FLOAT`/`DOUBLE` with `AUTO_INCREMENT`.** This was deprecated in 8.0 and is fully removed in 8.4. If any of your tables have a column matching this combination, the upgrade will fail. Check with: ```sql theme={null} SELECT table_schema, table_name, column_name, data_type FROM information_schema.columns WHERE extra LIKE '%auto_increment%' AND data_type IN ('float', 'double'); ``` If you get results, convert those columns to an integer type (e.g. `BIGINT`) before proceeding. For the complete list of changes, see the [MySQL 8.4 upgrade documentation](https://dev.mysql.com/doc/refman/8.4/en/upgrading-from-previous-series.html). ## Performing the upgrade ### 3. Run the upgrade Upgrading to MySQL 8.4 is irreversible. Laravel Cloud makes upgrading your database easy. 1. Go to "Org > Resources > Databases" 2. Find your Laravel MySQL 8.0 database 3. Click "Upgrade" on the yellow banner below the database 4. Confirm your upgrade The process takes up to a few minutes. **Your database will be briefly unavailable during this time**. We recommend doing this during a low-traffic window. ### 4. Verify your application Once the upgrade completes, confirm that your application is connecting and behaving normally. ## After the upgrade ### 5. Delete your backup (optional) Once you're confident everything is working, you can delete the backup from step 1 to free up storage. 1. Go to "Org > Resources > Databases" 2. Click on your database (now on 8.4) 3. Go to "Backups" 4. Click "..." and delete the backup # Using Yarn, PNPM, or Bun Source: https://cloud.laravel.com/docs/knowledge-base/using-yarn-bun-pnpm Learn how to use PNPM, Yarn, or Bun with Laravel Cloud and compare package managers. Laravel Cloud installs and runs `npm` by default during deployments. However, if you prefer to use an alternative JavaScript package manager like **Yarn**, **Bun**, or **PNPM**, you can do so by customizing your build commands. These tools are not officially supported by Laravel Cloud, but you can install them manually within your build steps. If you plan to use a different JavaScript package manager via the examples below, be sure to remove or comment out the default `npm` commands in your build commands before adding the custom commands. #### Example: Using Bun If you would like to use Bun instead of npm, you can override the default build command in your site’s settings with the following: ```bash theme={null} npm install -g bun bun install bun run build ``` #### Example: Using Yarn To use Yarn instead of npm: ```bash theme={null} npm install -g yarn yarn install yarn run build ``` #### Example: Using PNPM To use PNPM instead of npm: ```bash theme={null} npm install -g pnpm pnpm install pnpm run build ``` # Logs Source: https://cloud.laravel.com/docs/logs Learn how to view, search, and filter Laravel Cloud application and access logs. ## Introduction Laravel Cloud allows you to view and search your Laravel application's logs for a given environment via the "Logs" tab. When viewing your logs, you may filter logs based on type: * **Application logs:** log entries written by your Laravel application, either manually or when the application encounters an unhandled exception. * **Access logs:** log entries automatically generated by Laravel Cloud when a request is received by your Laravel application. ## Log retention Laravel Cloud prioritizes your most recent logs and will eventually delete older logs when they exceed your plan's retention period or storage quota allowance (whichever comes first). See "Log retention" in our [pricing and plan documentation](/docs/pricing#plans) for more details. # Migrating from Vapor Source: https://cloud.laravel.com/docs/migrating-from-vapor Learn how to migrate your application from Laravel Vapor to Laravel Cloud While Vapor and Cloud serve similar use cases, Laravel Cloud provides a simpler operational model and a more predictable runtime environment. Many teams migrate from Vapor to Cloud to reduce infrastructure complexity while keeping the same Laravel application. ## How to migrate If you’re running applications on Laravel Vapor, the migration process focuses on mapping your existing configuration and deployment workflows to Laravel Cloud equivalents. The [migration guide](https://cloud.laravel.com/migration-vapor-cloud) explains the benefits of migrating and walks through the required changes. # Laravel Cloud Network Source: https://cloud.laravel.com/docs/network ## Introduction Laravel Cloud manages all aspects of networking in order to bring enterprise-grade speed, security, and scalability to any Laravel application. There are two main layers to the Cloud's networking infrastructure: the Cloud Edge Network and the Cloud Compute Network. Private Cloud customers with a dedicated edge network have access to additional networking features including custom rules, cache rules, and private connections to AWS resources. See [Dedicated edge network](/docs/private-cloud#dedicated-edge-network) and [Private connections](/docs/private-cloud#private-connections) in the Private Cloud documentation. ## Cloud edge network Laravel Cloud has partnered with [Cloudflare](https://cloudflare.com) to offer every application globally distributed caching and network security at the edge. Incoming HTTP requests are first routed to the nearest edge region (335 cities around the world), pass through DDoS mitigation and Web Application Firewall (WAF) security layers, and are either returned from the cache (if available) or passed on to the Cloud Compute Network to be routed to your application's compute cluster. ### Cache control An important function of the Cloud Edge Network is caching your application's static assets. This has two key benefits: it reduces the number of requests that your application's compute needs to handle and it decreases latency for your users. Laravel Cloud optimizes your CDN cache through a two-step approach. First, Cloud uses a long cache lifespan to ensure your static assets are served at the edge as much as possible. Second, Cloud clears the CDN cache automatically on every deployment to ensure that no stale files accidentally remain in the cache. Combined, these two steps offer an efficient and safe approach to CDN caching. By default, Laravel Cloud caches files with the following extensions: `7Z`, `APK`, `AVI`, `AVIF`, `BIN`, `BMP`, `BZ2`, `CLASS`, `CSS`, `CSV`, `DMG`, `DOC`, `DOCX`, `EJS`, `EOT`, `EPS`, `EXE`, `FLAC`, `GIF`, `GZ`, `ICO`, `ISO`, `JAR`, `JPEG`, `JPG`, `JS`, `MID`, `MIDI`, `MKV`, `MP3`, `MP4`, `OGG`, `OTF`, `PDF`, `PICT`, `PLS`, `PNG`, `PPT`, `PPTX`, `PS`, `RAR`, `SVG`, `SVGZ`, `SWF`, `TAR`, `TIF`, `TIFF`, `TTF`, `WEBM`, `WEBP`, `WOFF`, `WOFF2`, `XLS`, `XLSX`, `ZIP`, `ZST` When a `Cache-Control` directive or `Expires` header is not explicitly set, Laravel Cloud will use the HTTP status code to determine the cache duration. | HTTP Status Code | Default TTL | | ---------------- | ----------- | | 200, 206, 301 | 120m | | 302, 303 | 20m | | 404, 410 | 3m | All other status codes are not cached by default. You are free to override the default cache rules by setting your own `Cache-Control` and `Expires` headers in your application code. Laravel Cloud will respect these headers and cache your assets according to the rules you set. Certain headers set by your application can prevent Laravel Cloud from caching a response. * The `Set-Cookie` header will prevent caching. * The `Authorization` header will prevent caching (unless a `must-revalidate`, `public`, or `s-maxage` header is also present). To reduce the risk of stale files being served from the cache, Laravel Cloud enables the "Purge edge cache on deploy" setting for your environment by default. You can disable this setting by clicking on the "Edge network" card from your environment's canvas. From there, you can also manually purge the cache or even bypass the cache entirely. Bypassing the cache will result in all requests being sent to your application, which may increase latency and load on your compute cluster. This is not recommended unless you are debugging a specific issue. ### Response rules Laravel Cloud allows you to easily configure a number of security headers that will be set on every response. You can modify the defaults by clicking on the "Edge network" card from your environment's canvas and selecting the desired option. You can also override the default headers by setting them directly in your application code. #### X-Frame-Options By default, Laravel Cloud will set an `X-Frame-Options: DENY` header. This prevents certain types of attacks that can occur if an application is loaded from an iframe. If your application has a use case for allowing iframes, you can change the header value to `SAMEORIGIN` or you can unset it entirely by clicking "Edge network" from the environment's canvas. #### X-Content-Type-Options By default, Laravel Cloud will set an `X-Content-Type-Options: nosniff` header. This prevents browsers from interpreting files as a different MIME type than what is specified in the `Content-Type` header. This is a security measure to prevent attacks based on MIME-type confusion. If your application has a use case for allowing browsers to interpret files as a different MIME type, you can unset the header entirely by clicking "Edge network" from the environment's canvas and selecting "None". If you select the "None" option for the `X-Content-Type-Options` header, your application can override the default and set a `nosniff` value at the route level. However, the the opposite is not true: if you select the `nosniff` option, your application cannot unset the value. #### Strict-Transport-Security HSTS is disabled by default but can be enabled with a simple toggle. When enabled, Laravel Cloud will set a `Strict-Transport-Security` header with a max-age of 31536000 seconds (1 year - customizable). This header is used to enforce secure (HTTPS) connections to the server. You can also optionally enable the `includeSubDomains` and `preload` directives. The `includeSubDomains` directive applies the HSTS policy to all subdomains of your application, while the `preload` directive allows your domain to be included in browsers' HSTS preload lists. This means that browsers will automatically enforce HTTPS for your domain and its subdomains, even before the first request is made. Make sure you understand the implications of these directives before enabling them, as it can be difficult to remove once set due to browser caching. #### Markdown for Agents Markdown for Agents enables real-time HTML to Markdown conversion at the edge for AI agents and crawlers. When enabled, AI systems can request your application's pages in Markdown format by including `Accept: text/markdown` in their request headers. Cloudflare's network will automatically convert the HTML response to Markdown before serving it to the client. Markdown's explicit structure is ideal for AI processing, resulting in better comprehension while significantly reducing token usage compared to raw HTML. When a response is converted, the following headers are included: * **`x-markdown-tokens`**: An estimated token count of the Markdown document, useful for calculating context window sizes or chunking strategies. * **`content-signal`**: Indicates AI usage permissions following the [Content Signals](https://contentsignals.org/) framework. By default, this is set to `ai-train=yes, search=yes, ai-input=yes`. You can enable or disable Markdown for Agents by clicking on the "Edge network" card from your environment's canvas and toggling the setting in the "Response" section. The origin response must not exceed 2 MB, and only HTML content is eligible for conversion. For more information, refer to [Cloudflare's Markdown for Agents documentation](https://developers.cloudflare.com/fundamentals/reference/markdown-for-agents/). ### X-Robots-Tag Since Laravel Cloud domains are often used for testing and staging purposes, a `X-Robots-Tag: noindex, nofollow` header is automatically set on all `*.laravel.cloud` domains so that they are not indexed by search engines. To remove this header, you should configure a custom domain for your application. The header will not be set for custom domains. ## Cloud compute network Requests that need to be processed by your application will be routed to the Compute Network in the AWS region assigned to your Laravel Cloud application. The Cloud Compute Network is built for security and scale. Your applications run in private networks and are only made publicly accessible via the Cloud Edge Network. Compute clusters are distributed across multiple availability zones (AZs) to ensure regions remain stable and recover quickly from any interruptions in a single zone. Compute Network traffic is also intelligently load balanced across all instances in your compute cluster as you horizontally scale up or down. ## Web application firewall The Web Application Firewall (WAF) provides advanced protection for your Laravel Cloud applications by filtering and monitoring HTTP traffic between your application and the Internet. All traffic routed through Laravel Cloud's edge network, via the default `app.laravel.cloud` hostname or a custom domain proxied through Cloudflare, runs behind Cloudflare's [OWASP Core Ruleset](https://developers.cloudflare.com/waf/managed-rules/reference/owasp-core-ruleset/), giving every environment managed protection that maps to the OWASP Top 10 before traffic ever reaches your app. ### Bot categories Bot categories allow you to present a JavaScript challenge to clients identified as specific types of automated traffic. Visitors matching your selected bot categories will see a challenge before they can access your application. Categories include, but are not limited to, AI crawlers, AI assistants, advertising and marketing bots, aggregators, search engine optimization bots, social media marketing bots, and monitoring tools. You can configure bot categories by clicking on the "Edge network" card from your environment's canvas and selecting the "Web Application Firewall" tab. Bot categories are available for [Business plan](/docs/pricing) customers. ### Rate limiting Rate limiting protects your application from abuse by controlling how many requests a client can make within a given time period. #### Basic rate limiting When enabled, Laravel Cloud will intercept requests from any IP address that exceeds 100 requests per minute. You can choose from three actions: * **Challenge**: Present a challenge (CAPTCHA or Turnstile) to the IP address. The challenge will be shown for 5 minutes. * **Throttle**: Block new requests from the IP address for 5 minutes. * **Ban**: Block all requests from the IP address for 5 minutes. To configure basic rate limiting, click on the "Edge network" card from your environment's canvas and select the "Web Application Firewall" tab. Basic rate limiting is available for [Growth and Business plan](/docs/pricing) customers. #### Advanced rate limiting Advanced rate limiting includes all basic rate limiting features plus additional customization: * **Customizable threshold**: Set your own requests per minute threshold instead of the default 100 rpm. * **Block repeated 4xx responses**: Block clients that send more than 30 unauthorized / error requests per minute (401, 403, 404) for 10 minutes. * **Block excess 429 responses**: Block clients that continue sending traffic after receiving more than 5 rate limit responses from your application. The block will last for 10 minutes. Advanced rate limiting is available for [Business plan](/docs/pricing) customers. ### Under attack mode If your application is experiencing a large-scale attack or suspicious traffic spikes, you can enable "Under Attack Mode" in the Edge network settings for your environment. When activated: * All incoming traffic to your environment is filtered through additional Cloudflare security checks designed to mitigate layer 7 DDoS attacks. * Visitors will see an interstitial "Checking your browser before accessing..." page and must pass a JavaScript challenge, which typically takes no more than 5 seconds. * Validated users are allowed through, while suspicious or automated traffic is blocked. * Under Attack Mode is intended as a last resort during active threats and may temporarily pause access to your site and impact your site analytics. * This mode will automatically expire after 24 hours to ensure normal access is restored. * Browsers must support JavaScript to pass the challenge; some third-party analytics tools may be affected. Enabling Under Attack Mode may temporarily impact the user experience for legitimate visitors due to the additional security checks. Use this mode only when necessary. ## IP addresses Laravel Cloud applications may make outbound requests from any of the following IP addresses. This information is useful when configuring firewalls, security groups, or allowlists for external services that your application needs to access. If your organization has dedicated compute available from [Private Cloud](/docs/private-cloud), make sure to use the dedicated IP addresses provided during your onboarding instead of the ranges provided below. ### Programmatic access The IP addresses are also available via API for programmatic access: ```bash theme={null} curl https://cloud.laravel.com/api/ip ``` This endpoint returns a JSON object with IP addresses organized by region: ```json theme={null} { "us-east-2": { "ipv4": ["3.140.62.214", "3.139.253.68", ...], "ipv6": ["2600:1f16:e0:8500::/56"] }, "eu-west-2": { "ipv4": ["35.178.113.65", ...], "ipv6": ["2a05:d01c:243:e500::/56"] } } ``` These IP addresses are subject to change. We recommend checking this endpoint regularly or subscribing to our changelog for updates. # Notifications Source: https://cloud.laravel.com/docs/notifications Configure notifications and alerts for Laravel Cloud events. ## Introduction Laravel Cloud makes it easy to stay informed about important events through email and Slack notifications. You can configure personal email notifications and team-wide Slack notifications for organization and application events, ensuring you never miss a critical update. ## Notification categories Laravel Cloud supports notifications for the following types of events: * **Organization** – Changes to your organization's settings * **Members** – New and removed members of your organization * **API tokens** – API tokens issued and revoked from your organization * **Applications** – Creation, deletion, and changes to applications * **Environments** – Creation, deletion, and changes to environments and domains * **Resources** – Creation, deletion, and changes to resources * **Resource alerts** – Notifications for application and database resource issues, including: * App cluster CPU usage * App cluster crashing * App cluster disk usage * App cluster out-of-memory (OOM) * App cluster RAM usage * Database cluster CPU usage * Database cluster crashing * Database cluster disk usage * Database out-of-memory (OOM) * Database RAM usage * Worker cluster CPU usage * Worker cluster crashing * Worker cluster disk usage * Worker cluster out-of-memory (OOM) * Worker cluster RAM usage * Cache max size / bandwidth (pending) * Cache upgraded due to max size * Cache upgraded due to bandwidth * **Deployments** – Deployment successes, failures, and cancellations * **Commands** – Command successes and failures * **Payments** – Successful and failed invoice payments ## Email notifications You can configure email notifications in Laravel Cloud to receive updates about important events directly in your inbox. Email notifications are configured at the user level, allowing each team member to customize their own notification preferences. ### Configuring email notifications To manage your email notification preferences, click on your profile picture in the top right corner, select **Account**, and navigate to **Notifications**. ### Supported categories Email notifications support the following categories: * Organization * Members * API tokens * Applications * Environments * Resources * Resource alerts * Deployments (all deployments or only failed deployments) * Payments (all payments or only failed payments) By default, you'll receive notifications for resource alerts, failed deployments, and failed payments. You can easily customize which notifications you receive by toggling your preferences on or off at any time. ## Slack notifications Laravel Cloud can send notifications to your Slack workspace to keep your team informed about important events and changes. You can configure Slack notifications at both the organization and application levels. ### Connecting to Slack To get started, navigate to your organization's Integrations settings and click **Connect Slack workspace**. A new window will open where you can complete the integration setup with your Slack workspace. Once your Slack workspace is connected, navigate to your organization's Notifications settings. Toggle **Enable Slack notifications** on and select the channel where you want to receive notifications. ### Organization-level notifications Organization-level Slack notifications support the following categories: * Organization * Members * Applications * Resources * Resource alerts * Payments (all payments or only failed payments) ### Application-level notifications Individual applications have their own Slack notification settings that can be configured independently from your organization-level notifications. Navigate to your application's Notifications settings to configure these options. Application-level Slack notifications support the following categories: * Environments * Alerts (resource alerts for this application's compute clusters) * Deployments (all deployments or only failed deployments) * Commands (all commands or only failed commands) All Slack notification categories are enabled by default. You may customize which notifications you receive by toggling categories on or off in your organization or application notification settings. # Organizations Source: https://cloud.laravel.com/docs/organizations ## Introduction After registering with Laravel Cloud, you will be assigned to an organization. For new registrations, this will be a brand new organization created just for you; however, if you are invited by another Laravel Cloud user, you will be added to the existing organization you were invited to. In Laravel Cloud, the organization is the top-level entity that owns all applications, environments, and resources such as databases and custom domains. Each organization's member and billing plan configuration is unique, so each organization may configure its own payment method details and preferred pricing plan. ## Organization members You can manage users in your organization via the Access tab in your organization's settings. Users can have two roles: Admin or Developer. The Admin role grants full access to view and manage an organization's applications, resources, members, and billing settings. The Developer role grants full access to view and manage an organization's applications and resources, but not its members or billing settings. ### Inviting new members To invite someone to an organization, navigate to the organization's dashboard and click Settings > Access. Then, enter the email of the new user and click "Invite". The invited user will receive an email that will allow them to accept the invitation to join the organization. #### Revoking invitations To revoke an invite, an admin can navigate to your Organization dashboard and click Settings > Access. On any rows that show the "Invite Pending" status, click the more "…" button and select "Revoke Invite." ### Removing members To remove a member from an organization, navigate to your Organization dashboard and click Settings > Access. On a member row, click the more “…” button and select “Remove Member.” ## Organization billing Each organization's billing plan configuration is unique, so each organization may configure its own payment method details and preferred pricing plan. ### Changing plans Every Laravel Cloud organization must have an active subscription. To upgrade or downgrade your plan, an Admin can navigate to your Organization dashboard and click Settings > Billing. Then, click "Change plan," select a new plan, and then click "Update plan." For upgrades, we will issue a one-off invoice immediately for any usage accrued in the current cycle plus the new subscription fee (pro-rated based on days remaining in the current billing cycle). We will then continue to issue monthly invoices on the regular anniversary billing date. For downgrades, you will continue to have access to the higher plan and its features for the rest of the billing cycle. Downgrading plans will result in the loss of access to some features like custom domains and autoscaling. Make sure your applications do not depend on these features before downgrading. ### Canceling subscriptions If you wish to stop using Laravel Cloud, you can cancel an organization's subscription at any time. To cancel an organization's subscription, an Admin can navigate to the organization's dashboard, click Settings > Billing, and click "Cancel subscription." Your subscription will continue on the current plan for the rest of your current billing cycle. At the end of the billing cycle, any remaining environment compute, resources, or custom domains that are still active will be terminated. Two days later, your final invoice will be processed. After subscription plan termination, you will still have access to your organization's basic data such as invoices and members, but you will need to resubscribe to a billing plan before deploying or managing additional applications for that organization. ### Billing details To change an organization's billing details, an Admin can navigate to the organization's dashboard and click Settings > Billing. Scroll to the "Billing details" section, and make any changes necessary to your "Bill as" type (Individual or Company), "Billing name", "Billing email", "Billing address", or "Payment method". ### Usage and invoices To view information about your organization's current compute, bandwidth, or other resource usage, navigate to your Organization's dashboard and click "Usage" in the navigation bar. From the usage dashboard, you can review your current spend, your plan allowances, usage by application and environment, and resource usage across your organization. ## General settings ### Renaming organizations To rename an organization, navigate to the organization's dashboard and click Settings. On the General tab, edit the Organization Name field. After updating the name, click Save. ### Deleting organizations To delete an organization, navigate to the organization's dashboard and click Settings. Then, on the General tab, click the Delete Organization button. Deleting an organization requires the organization to be current on all outstanding invoices and have no additional usage charges for the current billing period. Deleting an organization is permanently destructive and cannot be undone. All organization member, application, and resource data will be terminated immediately. ## Notifications Connect Laravel Cloud to your Slack workspace to receive notifications about your organization, applications, resources, and more. See [Notifications](/docs/notifications) for detailed setup of Organization notifications. # Preview Environments Source: https://cloud.laravel.com/docs/preview-environments Automatically spin up fully isolated environments for every pull request to safely test changes, share previews, and catch issues before merging.