Skip to main content

Documentation Index

Fetch the complete documentation index at: https://cloud.laravel.com/docs/llms.txt

Use this file to discover all available pages before exploring further.

Introduction

Laravel Private Cloud provides your organization with a fully isolated environment operated end-to-end by Laravel. You get the control, security, and compliance posture of enterprise-ready infrastructure without diverting engineering resources to deploy your applications and scale on demand.

Why Private Cloud

Private Cloud delivers dedicated infrastructure designed for organizations with strict security, compliance, or performance requirements.
  • Dedicated infrastructure: Your own compute, networking, and scaling are fully isolated. No noisy neighbors. Predictable performance.
  • Private networking: Connect to your existing AWS services over private networking for reduced latency and no public internet exposure.
  • Dedicated outbound IPs: Customer-specific IP addresses for easy whitelisting, traceability, and compliance.
  • Built for compliance: Private networking, isolated compute, and reduced attack surface without custom infrastructure.
  • High availability with automatic failover: Three always-on nodes across availability zones enable automatic failover.
  • Fully managed by Laravel: We operate the platform. Your team builds the product.

How it works

Your Private Cloud is provisioned in a dedicated AWS account and VPC maintained by Laravel. This includes:
  • Private Kubernetes cluster
  • Dedicated compute nodes
  • Private networking via VPC Peering, PrivateLink, VPC Lattice, or Transit Gateway
  • Dedicated NAT gateways with static outbound IPs
  • Optional managed RDS databases inside your private environment
Your applications deploy into this environment using Laravel Cloud, but everything runs inside infrastructure that belongs only to you.

Dedicated edge network

A dedicated edge network gives your Private Cloud its own isolated edge zone with full control over caching, custom rules, and traffic visibility. This feature appears as the “Private network” card on your environment’s canvas. A dedicated edge network includes everything in the shared Cloud Edge Network, plus:
  • Rule builder: Create cache rules and custom rules with execution ordering inside each rule type.
  • Custom rules: Match requests on conditions like path, IP, country, or headers, and apply a challenge, block, or IP access action.
  • Cache rules: Override default caching with per-path control over cache eligibility, edge TTL, browser TTL, stale-while-revalidate, and ETag handling.
  • Traffic visibility: Review the top IP addresses and paths hitting your edge over the last 24 hours, 7 days, or 30 days.
  • Rule event counts: See how many requests matched each custom rule and rate limit rule in the last 24 hours.
Dedicated edge networks are available to Private Cloud customers. Contact Sales to request one.

Custom rules

Custom rules let you define request-matching conditions and apply an action to anything that matches. They are useful for blocking known-bad traffic, allowing specific clients, presenting challenges to suspicious requests, or restricting access by IP. Each custom rule has:
  • Conditions: Request properties to match against, including path, hostname, IP, country, user agent, headers, and query parameters.
  • Action: What happens to a matching request. Available actions are challenge, block, and IP access (allow or block specific addresses or ranges).
  • Name: A human-readable label for the rule.
Rules execute in order within the custom rules section, and the first matching rule wins. You can reorder rules by dragging them. To create a custom rule, click on the “Private network” card from your environment’s canvas, then add a new rule under “Custom rules”.

Cache rules

Cache rules give you per-path control over how content is cached at the edge and override the default extension-based caching behavior described in the Cloud Edge Network documentation. Each cache rule applies to requests matching its conditions and lets you configure:
  • Cache eligibility: Whether matching responses are eligible for caching at all.
  • Edge TTL: How long the response stays in the edge cache.
  • Browser TTL: The cache lifetime served to the client browser.
  • Serve stale while revalidating: Serve a stale response while a fresh copy is fetched in the background.
  • Respect strong ETags: Honor strong ETag validators on origin responses.
Cache rules execute in order within the cache rules section, independent of custom rules, and can be reordered by dragging.
Cache rules do not display per-rule hit counts. Use the traffic cards on the network overview to understand cache performance instead.

Traffic visibility

The network overview displays cards showing the top IP addresses and top paths hitting your dedicated edge network. Use the time filter to switch between the last 24 hours (the default), 7 days, or 30 days. Clicking a row in the traffic cards opens a new custom rule pre-filled with that IP or path as a condition, allowing you to act on anomalous traffic immediately.

Rule event counts

Custom rules and rate limit rules display an inline event count for the last 24 hours next to each rule, showing how many requests matched. Cache rules do not display this count.

Private connections

Private connections let your Private Cloud reach AWS resources in your own accounts without exposing traffic to the public internet. VPC Peering is available as a self-service flow in the Cloud dashboard. PrivateLink, VPC Lattice, and Transit Gateway are also supported, but require coordination with the Laravel Cloud team to set up.

Connection types

When you create a private connection, you choose a connection type. The right choice depends on what you are connecting to and how your network is structured.
  • VPC Peering: A direct network link between two VPCs, allowing connections to route internally using private IPs. Simple to set up and best for simple networks.
  • VPC Lattice: A managed service mesh for connecting services across VPCs. Useful for strict security environments with heightened observability.
  • PrivateLink: Expose an individual service in one VPC to another over a private endpoint. Common for connecting to vendor-managed databases or APIs privately.
  • Transit Gateway: A regional hub that connects multiple VPCs or other gateways together. Best for complex, multi-VPC architectures.

Setting up a VPC peering connection

To establish a VPC peering connection from the Cloud dashboard:
1

Open network settings

Click the “Private network” card from your environment’s canvas and select “Request private connection”.
2

Choose a Private Cloud

Select the Private Cloud the connection will be established with.
3

Select the connection type

Select “VPC Peering” as the connection type.
4

Provide connection details

Enter the following details:
  • AWS account ID: The 12-digit account ID of the AWS account that owns the VPC or resources you want to connect to.
  • VPC ID: The ID of the VPC you want to peer with. You can find this in your AWS VPC dashboard.
  • CIDR range: The IPv4 CIDR block of the target VPC. This must not overlap with your Private Cloud’s CIDR range.
5

Submit the request

Submit the request. Laravel Cloud will provision the peering connection and update the connection’s status as it progresses.
6

Accept the peering request in AWS

Once the connection reaches a state requiring your action, accept the peering request from your AWS account and update your VPC’s route tables to direct traffic to the peering connection.
The connection card on the Private connections page shows both sides of the peering. The values you provided are listed under Target, and the corresponding values on the Laravel Cloud side are listed under Ours. Use the Ours IP information when configuring resources in your account that need to talk to your Private Cloud, and use the Target IPs when your Private Cloud needs to reach resources in your account. If a connection fails or expires, click “Renew request” to restart the workflow without re-entering the details. These connection types are supported but are not yet available as a self-service flow in the dashboard. To set one up, contact the Laravel Cloud team with:
  • The connection type you need.
  • The AWS account and VPC details for the target side.
  • For PrivateLink: the service name or endpoint you need to connect to.
  • For VPC Lattice: the resources or services you want to make available.
  • For Transit Gateway: the existing Transit Gateway ID and routing details.
The Laravel Cloud team will provision the connection, and it will appear in your Private connections list once it is live.

Common use cases

Private Cloud is ideal for organizations with specific infrastructure requirements:
  • Security and compliance: Finance, healthcare, and regulated industries requiring isolated infrastructure.
  • Private system access: Connect Laravel Cloud applications directly to internal APIs, services, and private databases.
  • Performance-sensitive workloads: Predictable performance without noisy neighbors.
  • Enterprise architecture: Laravel Cloud as part of a broader AWS ecosystem.
  • Dedicated IP requirements: Outbound traffic must originate from known, customer-specific IP addresses.

Requirements

To provision your Private Cloud, you will need to provide:
  • AWS account IDs
  • VPC CIDR ranges (to avoid conflicts)
  • Any required private connectivity details
The typical lead time for provisioning is four to six weeks.

Pricing

Private Cloud pricing is based on a custom quote tailored to your organization’s requirements. Private Cloud is typically cost-effective for workloads spending $2,000 or more per month on infrastructure. Every Private Cloud includes:
  • Private networking
  • Dedicated infrastructure

Getting started

To get started with Private Cloud:
  1. Schedule a Private Cloud consultation
  2. Review architecture and security needs with our team
  3. Receive a custom quote
  4. Begin provisioning
Contact Sales to learn more.