Statamic Hosting: Understanding Your Options

If you’re coming from WordPress, hosting was pretty much a solved question. You got a PHP server with MySQL, installed WordPress, and that was it. Maybe you ended up on WP Engine or Flywheel or a managed host that handled the server stuff for you, but the underlying architecture was always the same: a PHP application talking to a MySQL database, generating pages on every request (or caching them if you were being careful about performance).

Statamic is different. Not in a "it’s just better" kind of way, but in a "there are genuinely different architectural approaches available to you" kind of way. How you host a Statamic site depends on decisions made earlier in the process — how content is stored, how pages are rendered, whether you need real-time dynamic features, and how your team works day to day. The hosting question and the build question are connected, and getting the most out of Statamic means understanding that relationship.

How Statamic stores content

This is the foundational decision that influences everything else, so it’s worth understanding clearly.

By default, Statamic stores all content as flat files — markdown and YAML files that live right alongside your code in the project directory. A blog post is literally a .md file in a folder. A collection of team members is a folder of YAML files. Your entire site’s content can be versioned in Git, deployed with a push, and read by any text editor.

This is one of Statamic’s defining features and it works really well for a wide range of sites. A marketing site with 50 pages, a blog with a few hundred posts, a documentation site, a portfolio — flat files handle all of these comfortably. Content loads fast because there’s no database query involved, just reading a file from disk (and Statamic caches aggressively on top of that).

But flat files have practical limits. When you start getting into thousands or tens of thousands of entries, or when you need complex filtering and sorting across large datasets, or when you have multiple environments that need to write content simultaneously (say, a staging server and production both accepting content changes), flat files start to show strain. File-based reads don’t scale the same way indexed database queries do, and Git-based content workflows get complicated when multiple sources are committing.

For those situations, Statamic has an Eloquent driver that stores content in a traditional database — MySQL, PostgreSQL, SQLite, whatever Laravel supports. Your content editors use the same control panel, the templates work the same way, the API returns the same data. The storage layer changes but the experience on top of it doesn’t. You lose some of the flat-file benefits (Git-versioned content, the ability to edit files directly), but you gain the query performance and concurrency handling that a database provides.

The decision between flat file and database isn’t about which is "better" — it’s about what your site actually needs. A 200-page marketing site with a blog has no reason to run a database. A large membership site with thousands of pieces of content and multiple content editors working simultaneously probably should. Most sites we work on fall comfortably in the flat-file camp, but knowing when to reach for the database is part of getting the architecture right.

Dynamic hosting (traditional server)

This is the closest thing to what you’re used to from WordPress. A server runs PHP, Statamic processes each request, and the response is sent to the browser. Laravel handles the routing, Statamic pulls the content (from flat files or database), the Blade or Antlers templates render the HTML, and the page arrives.

The infrastructure for this is straightforward. You need a server running PHP 8.2+, a web server (Nginx or Apache), and Composer for dependency management. If you’re using the database driver, you need MySQL or PostgreSQL as well. Tools like Laravel Forge, Ploi, or ServerPilot handle the server provisioning and management, so you’re not manually configuring Nginx and setting up SSL — you point them at a cloud server (DigitalOcean, Hetzner, AWS, Vultr, whatever you prefer) and they handle the rest.

Where this gets more interesting than a typical WordPress setup is Statamic’s built-in caching layers. There are a few levels to understand:

Application caching is the baseline. Statamic caches its content store, so repeated requests don’t re-parse YAML files or re-run database queries. This is automatic and handles most of the performance optimization you’d need for a typical site.

Static caching takes it a step further. Statamic can write the fully rendered HTML for each page to disk, and your web server (Nginx, typically) serves that static file directly on subsequent requests without ever hitting PHP. The first visitor to a page triggers the render; everyone after that gets the cached HTML file at essentially static-file speeds. When content changes, the relevant cache is invalidated automatically.

Full measure static caching (the name comes from Statamic’s documentation) goes further still — it pre-generates static HTML for your entire site and serves everything from Nginx. PHP only gets involved when the cache needs to be regenerated. At this point you’re getting CDN-like performance from a single server.

The performance profile here is significantly better than WordPress out of the box, even before you start tuning. There’s no equivalent of the WordPress plugin overhead problem, no database query bloat accumulating over years of adding plugins, and no need for a caching plugin to paper over architectural inefficiencies. The caching is built into the platform and the framework rather than bolted on after the fact.

Dynamic hosting makes sense when your site needs real-time features — form submissions, user authentication, server-side search, content that changes based on the logged-in user, or anything that genuinely needs to execute code on each request. For most marketing and content sites, you’ll pair dynamic hosting with static caching and end up with something that’s fast, simple to manage, and handles traffic spikes without breaking a sweat.

Static site generation

Statamic can generate your entire site as plain HTML files. Every page, every blog post, every archive — rendered once and output as .html files that you can upload to any web host, push to a CDN, or deploy to a platform like Netlify, Cloudflare Pages, Vercel, or an S3 bucket behind CloudFront.

The result is about as fast and secure as a website can get. There’s no server to respond to requests, no PHP to execute, no database to query. Your site is just files on a CDN, served from edge locations around the world, loading in milliseconds. The attack surface is effectively zero — there’s nothing to hack because there’s nothing running.

The Statamic SSG (static site generator) package handles the build process. It crawls your site’s routes, renders each page, and outputs the HTML. You run a build command (either manually or triggered automatically when content changes), and the output is your deployable site.

The trade-offs are real though, and they’re worth understanding before you commit to this approach.

Content updates require a rebuild. When someone publishes a new blog post or edits a page, those changes aren’t live until the site is rebuilt and redeployed. For most sites this takes seconds to a couple of minutes, and you can automate it so that saving content in the control panel triggers a rebuild automatically. But if you’re used to hitting "publish" and seeing the change immediately, the build step is an adjustment. For sites where content changes multiple times per hour, this can start to feel like friction.

Forms need a different approach. Static HTML can’t process form submissions on its own. You have a few options: use a third-party form service (Formspree, Basin, Netlify Forms), set up a serverless function that handles submissions, or route form posts to an API endpoint running somewhere else. All of these work fine, but it’s an additional piece of architecture to set up and maintain.

Dynamic features need to happen elsewhere. Anything that requires server-side logic — user authentication, personalized content, server-side search, real-time data — can’t live in the static site itself. You can handle some of this with client-side JavaScript (search indices built at build time, for example), some with serverless/edge functions, and some by having a separate API that the static site calls. It’s all solvable, but it adds architectural complexity.

The control panel needs to live somewhere. Even though your public site is static HTML, Statamic’s control panel still needs a server to run on. Your content team edits content through the CP, that triggers a build, and the build output gets deployed. So you still have a server — it’s just not the one serving your public traffic.

Static generation is an excellent fit for sites where content changes on a schedule (daily, weekly) rather than continuously, where you don’t need real-time dynamic features, and where you want the absolute best performance and security profile possible. Corporate marketing sites, documentation sites, blogs, and portfolio sites are all strong candidates. We’ve set up a number of Statamic projects this way and the hosting costs are often trivially low — a few dollars a month for a site that handles enormous traffic without flinching.

Headless and decoupled architectures

Statamic has a full REST API and a GraphQL API. This means you can use Statamic purely as a content backend — your content team manages everything through the control panel, and a completely separate frontend application consumes that content through the API and renders it however it wants.

The frontend in this setup is usually a JavaScript framework: Next.js (React), Nuxt (Vue), Astro, SvelteKit, or something similar. The frontend makes API calls to Statamic, gets back structured content data, and renders the pages. The Statamic backend and the frontend are independent applications that communicate over HTTP.

When does this make sense? A few scenarios:

Your frontend has significant interactive requirements that go beyond what server-rendered HTML handles well. Think complex filtering interfaces, real-time data visualization, app-like interactions that benefit from client-side rendering and state management.

Your team already has frontend developers working in React or Vue and you want to let them use the tools they’re most productive with, rather than learning Blade or Antlers templates.

You need to serve the same content to multiple frontends — a website, a mobile app, a kiosk display, a third-party integration. The API gives you one content source that feeds everything.

The trade-offs are significant though, and we’d be doing you a disservice not to be direct about them.

Headless adds real complexity to your architecture. Instead of one application that handles content management and rendering, you now have two that need to be deployed, maintained, monitored, and kept in sync. Build processes get more involved. Local development requires running both the Statamic backend and the frontend. Debugging issues means figuring out which layer the problem lives in.

Performance can actually get worse in some configurations, particularly if your frontend framework is doing client-side rendering. A server-rendered Statamic page with static caching will typically load faster than a JavaScript application that needs to boot up in the browser, make API calls, and then render. Server-side rendering (SSR) with Next.js or Nuxt mitigates this, but adds its own layer of infrastructure (you need a Node.js server or edge runtime to handle SSR).

Hosting costs go up because you’re running two things instead of one. And the talent pool you need to maintain the site expands — you need people who understand both the Statamic/Laravel backend and whatever JavaScript framework powers the frontend.

For the right projects, headless is absolutely the correct architecture. But we see teams choosing it because it sounds modern or because their frontend developer prefers React, without fully accounting for the operational complexity it introduces. If your site is primarily content-driven — pages, posts, resources — and doesn’t need heavy client-side interactivity, a monolithic Statamic setup with Blade templates will be simpler, faster, and cheaper to operate. The headless approach should be a deliberate architectural decision driven by real requirements, not a default.

Hybrid approaches

Most real-world Statamic projects don’t fall neatly into one of the categories above. They end up somewhere in between, picking the right approach for different parts of the site.

A common pattern: static caching handles the bulk of the site (marketing pages, blog posts, documentation) while specific routes remain dynamic because they need to process forms, handle authentication, or serve personalized content. Statamic’s static caching is smart enough to let you specify which routes to cache and which to leave dynamic, so you get the performance benefits of static serving where it matters and the flexibility of server-side processing where you need it.

Another pattern we’ve used: a primarily static-generated site with a handful of serverless functions handling the dynamic bits. The marketing site builds and deploys to a CDN, but form submissions route to a serverless function that processes them and pushes data to the CRM. Search might use a pre-built index (generated at build time) that runs client-side with something like Fuse.js or Pagefind.

You can also run Statamic as a full dynamic application behind a CDN like Cloudflare, where the CDN handles edge caching and serves most pages from cache while letting uncached or dynamic requests pass through to the origin server. This gives you a lot of the performance benefits of static generation without the build step and the restrictions on dynamic features. Cache invalidation becomes the thing you need to manage carefully, but Statamic and Cloudflare both have tools for that.

The point is that these architectures are composable. The right setup for your project might be a combination of approaches, tailored to your specific content workflow, traffic patterns, and feature requirements. This is part of why the hosting conversation needs to happen alongside the architecture conversation — they’re the same decision.

Deployment and workflow

How changes get from your content team’s edits to your live site depends on which hosting approach you’re using, but Statamic’s flat-file architecture (when you’re using it) enables some workflows that are worth understanding.

With flat-file content stored in Git, your deployment pipeline is essentially the same as any modern web application. Content changes get committed to the repository (either manually by a developer or automatically by the control panel), pushed to a remote (GitHub, GitLab, Bitbucket), and a CI/CD pipeline handles the deployment — running any build steps, clearing caches, and deploying to the server or CDN.

This means your content team’s edits go through the same deployment pipeline as code changes, which has some nice properties. You can have a staging environment that mirrors production, let people preview content changes before they go live, and maintain a clean audit trail of what changed and when. Rolling back a problematic content change is the same as rolling back a code change — revert the commit.

For static-generated sites, the workflow typically looks like: content editor saves a change in the control panel → a webhook triggers the build pipeline → the SSG package regenerates the site → the output deploys to the CDN. The whole cycle usually takes under a minute for small to medium sites. Larger sites with thousands of pages might take a few minutes, and there are strategies for incremental builds that only regenerate what changed.

For dynamic sites, deployment is simpler — push to the server, run any migrations or cache clears, and the changes are live. If you’re using static caching, the cache invalidation happens automatically when content changes through the control panel.

The deployment tooling ecosystem is mature. Laravel Forge has one-click deployment with zero-downtime releases. GitHub Actions or GitLab CI can handle custom pipelines. Services like Envoyer provide deployment management specifically designed for Laravel applications. You’re not limited to one approach, and the choice usually comes down to what level of control and automation your team wants.

How we approach hosting decisions

We’re being fairly detailed in this guide because we think it’s important to understand that these are real architectural decisions with real downstream consequences. The wrong hosting setup for your site means either paying too much for infrastructure you don’t need, or running into limitations that force an expensive re-architecture later.

The hosting recommendation comes out of understanding the full picture: how much content the site has and how fast it’s growing, how often content changes, what dynamic features are needed, how technical the team managing it is, what the performance requirements look like, and what the budget supports. These are things we work through during the audit and architecture phases of a migration (our migration guide covers the full process), or during the planning phase of a new Statamic build.

We also offer managed hosting for clients who don’t want to think about infrastructure at all. We set up the environment, configure the deployment pipeline, handle updates and monitoring, and make sure things keep running smoothly. For some organizations that’s exactly what they want — hand off the infrastructure to the team that built the site and focus on creating content. For others with an existing DevOps team, we’ll set things up and hand over the keys with documentation on how everything works.

Either way, the hosting conversation is one we think should happen with someone who understands both Statamic’s architecture and the range of infrastructure options available. It’s not the kind of thing where you want to pick a hosting provider first and then figure out how to make the site work on it.