Skip to main content
This guide is for Laravel applications that use Statamic.
Statamic is a content management system built on Laravel, so it deploys to Laravel Cloud like any other Laravel application. However, Statamic stores its content as flat files by default, and Cloud environments have an ephemeral filesystem. This guide walks through the choices you should make before going live so your content, assets, and cache behave as expected.

​
Decide where your content lives

Each deployment resets your environment’s filesystem, and each replica of your App cluster has its own filesystem. Any entry, global, navigation, or user that is saved to disk through the Statamic control panel in production will be lost on the next deployment and will not be visible to other replicas. You have two options:
  • Edit content locally. Treat production as read-only. Your team edits content on their local machines, commits the flat files to your repository, and pushes to deploy. This keeps your content in version control and works well for sites that change infrequently.
  • Store content in a database. If your team edits content through the control panel in production, store it in a Laravel MySQL or Postgres database using Statamic’s Eloquent driver.
To use the Eloquent driver, install it locally and follow the prompts to choose which repositories (such as entries, globals, and navigation) should move to the database:
Commit the generated migrations and configuration, attach a database to your environment, and add php artisan migrate --force to your environment’s deploy commands.
Statamic users are stored as files by default as well. If anyone signs in to the control panel in production, store your users in the database so accounts and password changes persist.

​
Store assets in object storage

Files uploaded to a Statamic asset container are written to the container’s filesystem disk. To keep uploads across deployments and replicas, create a Laravel Object Storage bucket and attach it to your environment. Cloud injects the S3-compatible connection variables for the bucket’s disk automatically. Next, point your asset container at the bucket’s disk name. For example, if you named the disk assets, update your container’s YAML file:
content/assets/assets.yaml
If you use a public bucket, copy its AWS_URL from the bucket settings page into your environment variables so Statamic can generate public URLs for your assets.

​
Refresh the Stache on deploy

Statamic indexes your content in a cache called the Stache. If your content lives in your repository, refresh the Stache after each deployment so new and changed files are picked up:
Add this to your environment’s deploy commands. Deploy commands don’t persist filesystem changes, so attach a cache to your environment and use it as your application’s cache store. The Stache is then stored in the cache, where every replica can read it.

​
Enable static caching

Statamic’s static caching serves pre-rendered pages instead of building each page on every request. Statamic offers two strategies, and the right one depends on how you scale your App cluster.

​
Half measure

The half measure strategy stores rendered pages in your application’s cache store. Requests still reach PHP, but Statamic returns the cached response without rendering the page. When your cache store is a Cloud cache, every replica shares the same cached pages, so this strategy works with autoscaling. Set the following environment variable and deploy:

​
Full measure

The full measure strategy writes each page as an HTML file to public/static. When your application requires statamic/cms, Cloud detects it at deploy time and configures NGINX to serve those files directly, so cached pages are returned without reaching PHP. Form submissions and live previews continue to route to your application. You don’t need to write any custom NGINX configuration. Set the following environment variable and deploy:
The full measure cache lives on each instance’s local filesystem and is cleared on each deployment. Statamic only invalidates the cache on the instance that handled a content change, so additional replicas would keep serving stale pages. When using the full measure strategy, set your App cluster’s autoscaling strategy to None and scale vertically by choosing a larger instance size instead of adding replicas.
If your site needs to scale horizontally, use the half measure strategy instead.

​
Monitor your site

Once your site is live, Laravel Nightwatch gives you visibility into slow requests, exceptions, queued jobs, and cache hit rates, which is useful for confirming that static caching is doing its job. You can connect Nightwatch to your environment directly from the Cloud dashboard.

​
Frequently asked questions

Do I need Statamic Pro to deploy on Cloud? No. Statamic Solo and Pro both run on Cloud. Check Statamic’s pricing page for features, such as multiple control panel users, that require a Pro license. Why did my control panel changes disappear after a deployment? Content saved as flat files in production is written to the ephemeral filesystem and reset on each deployment. Edit content locally and commit it, or store content in a database. Why are some visitors seeing outdated pages? If you use the full measure strategy with more than one replica, only the instance that handled a content change clears its cache. Set your App cluster’s autoscaling strategy to None, or switch to the half measure strategy. Does static caching affect applications that don’t use Statamic? No. Cloud only configures NGINX for static caching when your application requires statamic/cms.