For Statamic

Statamic, served
without the surprises

Flat-file Laravel CMS on real VMs, asset containers backed by S3-compatible Edge Storage, global CDN with zero egress fees. Or generate static, push, serve — origin-less.

Start your trial Read the deploy guide

# config/filesystems.php — asset disk

'edge' => [

'driver' => 's3',

'endpoint' => env('EDGE_ENDPOINT'),

'bucket' => env('EDGE_BUCKET'),

# Generate the static site

$ php please ssg:generate

# Sync to Edge Storage

$ aws s3 sync storage/app/static s3://my-site \

--endpoint https://storage.edge.run --delete

# Front it with the CDN

$ edge cdn create example.com \

--origin s3://my-site

Why Statamic teams pick Edge

Flat-file content meets a flat-fee infrastructure stack. No DB to babysit, no per-visit caps, no egress fees on the way to your readers.

Flat-file by default, no DB drama

Statamic's flat-file content lives in the repo. No MySQL to provision, snapshot or scale — your VM does one thing and does it well.

Assets straight to Edge Storage

Wire Statamic asset containers to the S3 driver and point them at Edge Storage. Uploads, thumbnails and downloads all live in one durable bucket.

Image transforms at the CDN

Use Statamic's native Glide tags for build-time work, or hand off to Edge Image Optimization for on-the-fly resize, AVIF/WebP and smart cropping.

Global CDN, zero egress

Front the control panel and the front-end through the Edge CDN. Public pages cached globally, control panel falls through to your VM.

Static Site Generator out the box

Run `php please ssg:generate`, push the output straight to Edge Storage, serve from the CDN. Origin-less hosting for content sites that change daily, not hourly.

Laravel inside, agent-deployable

It's Laravel under the hood — Forge, Envoyer, Kamal and the Edge agentic API all work as you'd expect. Spin up VMs, configure DNS, ship.

Reference architecture

How Statamic maps to Edge

Two flavours: a small VM running Statamic (PHP) for dynamic sites, or pure CDN + Storage for SSG output. Both share the same asset and image pipeline.

Compute

Runs PHP-FPM + Nginx serving Statamic (or just builds the SSG output)

Storage

S3-compatible asset containers for uploads, generated thumbs and SSG output

CDN

Caches the front-end globally; optional origin pull from the SSG bucket

Image Optimization

Drop-in replacement for Glide URLs with on-the-fly transforms

DNS

Anycast DNS for the apex, www and any preview branches

# Antler template — Edge image URL

<img

src="https://cdn.example.com/{{ asset:url }}?w=1200&fm=webp"

srcset="https://cdn.example.com/{{ asset:url }}?w=800&fm=webp 800w,

https://cdn.example.com/{{ asset:url }}?w=1600&fm=webp 1600w"

alt="{{ alt }}"

# Or stick with Glide tags — both work

Common questions

Static, dynamic, or both?

Either. For a content site, run `php please ssg:generate` in CI, sync the output to Edge Storage, serve from the CDN — no origin VM needed at all. For a Statamic app with form submissions or member areas, run it on a small VM the same way you would Laravel.

How do asset containers work?

In `config/filesystems.php`, define an `s3` disk pointing at Edge Storage and reference it from your asset container config. Uploads, focal-point crops and Glide-cached variants all land in the bucket.

What about Statamic Pro / Eloquent driver?

Both work. The Pro features (multi-site, users, forms, REST/GraphQL APIs) are unaffected by where you host. If you switch to the Eloquent driver, just point Statamic at MySQL/PostgreSQL on the same VM or a separate Edge VM.

How do I deploy content updates?

Two patterns: (1) Edit in the control panel on the VM, then run `ssg:generate` and sync to Storage; (2) Commit content as code, push to git, let CI build and ship. The agentic API can wire either pattern up for you.

By Stack