Statamic Hosting and Statamic Deployment With Static Caching on Your Own Servers

Can Statamic run on a VPS instead of managed hosting?

Yes. Statamic is a Laravel package, so it runs on any server that runs a current Laravel app: PHP 8 with the usual extensions, Composer, and Nginx or Apache. A flat file Statamic site does not even need a database, which is why a single 2 GB server can carry several small client sites comfortably.

The managed platforms are a real option and worth naming. fortrabbit sells Statamic hosting on its managed PHP platform and offers a seven day trial without a card. Our fortrabbit pricing comparison works out where its per app billing stops being the cheaper option. Ploi now runs Ploi Cloud, a container platform priced by memory, with regions in Amsterdam, London and Chicago, and Statamic's own blog has announced it. Both remove server work entirely, which is worth paying for if you host one or two sites.

The case for your own server gets stronger as the site count grows. On a VPS you pay for the server once and add sites to it, you pick the US region, you keep SSH and root, and image transforms, queues and scheduled jobs run without platform limits. What you give up is the setup, and that is the part a panel such as DeployManage on DigitalOcean or on Hetzner does for you.

Why zero downtime deploys need extra setup for Statamic

Statamic's own Laravel Forge guide says it directly: zero downtime deployments are disabled by default for Statamic sites, due to the additional configuration required. The reason is the flat file content model.

An atomic release builds each deploy in a fresh directory and then points the live symlink at it. That is exactly what you want for code. But when an editor saves an entry in the Control Panel, Statamic writes a Markdown or YAML file into content/ inside whichever release is live. The next release is a clean copy of the repository and does not contain that file. The entry looks deleted, and so do new users, uploaded assets and form submissions.

There are two clean ways out, and you should choose one before the first deploy:

• Shared folders. Keep content/, users/, public/assets, storage and public/static in a shared directory and link them into every release. Control Panel edits never touch the release, so deploys cannot lose them. This is the simpler setup for agencies whose clients edit daily.
• Content in git. Turn on Statamic's Git automation (a Pro feature) with pushing enabled, so every save becomes a commit that goes back to the repository. Each release then contains the latest content because it is built from the latest commit. This gives you full content history, at the price of a deploy loop you have to break, covered below.

DeployManage does not hide either choice behind a Statamic button. The deploy script is plain shell you edit per site, so you can write exactly the shared folder links or git guard your project needs, and it runs the same way on every server behind the site.

Git automation without a deploy loop

Git automation solves content history and creates a new problem. Every save in the Control Panel pushes a commit, a push triggers a deploy, and a deploy on a busy site can run dozens of times a day for nothing but a typo fix.

Statamic's documentation suggests prefixing automated commit messages with [BOT] so the deploy can tell them apart. Put a guard at the top of the deploy script that exits when the latest commit message starts with that prefix, and content commits stop rebuilding the site. A two line guard does it:

git log -1 --pretty=%s | grep -q '^\[BOT\]' && exit 0
# the normal deploy continues below

Two more settings matter on a real site. Git automation commits on the sync queue by default, which makes every save wait for git. Set STATAMIC_GIT_QUEUE_CONNECTION=redis and run a queue worker under Supervisor so saves return immediately; the queue worker and Supervisor setup is the same as for any Laravel app. And STATAMIC_GIT_DISPATCH_DELAY lets several quick edits collapse into one commit instead of ten.

Static caching on your own server

Statamic has two static caching strategies. The half measure keeps rendered pages in Laravel's cache, so every request still boots PHP but skips most of the work. The full measure writes real HTML files to public/static and lets Nginx serve them before PHP starts, which is the fastest option for content sites with heavy traffic.

Full measure needs one Nginx rule, taken from Statamic's static caching docs:

location @static {
    try_files /static${uri}_$args.html $uri $uri/ /index.php?$args;
}

Statamic invalidates a page's cached file when its entry is saved, but a template change in a deploy affects every page at once. The documented order is to run php please static:clear and then php please static:warm during the deploy. With atomic releases, warm the cache before the symlink switch so the first visitor after the deploy already gets fresh HTML. Keep public/static in a shared folder too, or every release starts with an empty cache. For the rest of the server block, see our production Nginx config for Laravel, which Statamic uses as well.

Statamic hosting cost, with real monthly bills

The Statamic licence is the same on every host. Statamic Core is free with one admin account, and Pro, which adds unlimited users, revisions, multi site and Git automation, is $349 per site with one year of updates and $99 a year after that. Client sites are usually Pro, so budget that line separately. The tables below cover hosting only, with DigitalOcean's published prices: a 2 GB droplet at $12, a 4 GB droplet at $24, a load balancer at $12 and a 1 GB managed MySQL database at $15.15.

DeployManage is the most expensive line in every row, and we would rather say so than hide it. Forge with one 2 GB droplet is very hard to beat for a single site. Starter at $59 covers 3 servers but does not include atomic releases, so a Statamic agency that wants zero downtime deploys should price Growth.

The third row is where the choice changes. A Statamic site on two app servers cannot keep flat file content on local disk, because each server would see different entries. You move content to a database with the Eloquent driver or into git, and then you need every server switched to the same release at the same moment. Forge's native zero downtime deploys stop at one server per site, which is why Forge teams add Envoyer for multi server releases. DeployManage Growth does that on one plan and adds 10 seats and the audit log, which is what an agency running many client sites is paying for.

Moving a Statamic site from another host

Because Statamic content is files, a move is mostly a copy. Launch the new server, add the site and connect the repository, then copy content/, users/ and public/assets from the old host into the shared folders with rsync, warm the Stache, and test on a temporary hostname. Switch DNS last, with a short TTL set a day ahead. If the old host is also where the Control Panel lives, freeze edits for the few minutes between the final rsync and the DNS change. Craft sites follow the same pattern with uploads in a local volume instead of content files, and our Craft CMS deployment page has the Craft version of the deploy script. Drupal sites use the same release flow with drush deploy and a shared files folder, covered on our Drupal deployment page.

Agencies doing this across a whole client list usually move a few sites per server per evening and keep the old host for a week as a fallback. The agency hosting page shows how the server count, not the site count, drives the bill on our plans.