22 June 2021

Using Statamic on Laravel Vapor

We’ve recently been working on a Laravel project where we’ve needed to add some ‘marketing’ type pages. We decided on using Statamic as the CMS for these marketing pages.

When it comes to hosting our Laravel apps, for the most part, we use Laravel Forge. It’s great and the whole team knows how to use it.

However, this project in particular needs to be able to scale seamlessly when users log in to the platform. This is why we’ve chosen to use Laravel Vapor for this project.

When pairing Laravel Vapor and Statamic together, there’s a couple of things you’ll need to watch out for – that’s what I’m mostly going to cover in this post:

Control Panel

This is probably the biggest pain point… the Statamic CP doesn’t really work with Vapor.

It will run. You can log in, you can view entries, view your taxonomies, etc. But what you can’t do is create/edit anything.

Because of the way Vapor works – you can’t write to the filesystem. If you try, you’ll get a file_get_contents error.

You could probably get around this by using the Eloquent entries addon, which means your entries are stored in the database, rather than in markdown files. However, this doesn’t solve the problem for things like taxonomies and globals.

In the end, we went down the route of setting up a ‘CMS site’. Basically, we have a cheap Digital Ocean droplet, provided with Forge, that the client can use to update the site’s content.

We’re using the Git integration built into Statamic to automatically commit & push any content changes to our Git repository. This will then trigger a Laravel Vapor deployment through Chipper CI, our CI tool.

Cache server

Initially, when I was setting up Statamic on Vapor, I found it to be really slow compared to our Forge server.

Under the hood, Statamic’s ‘stache’ (the caching layer between Statamic and your markdown files) stores its data in Laravel’s cache.

After some digging and talking to folks on the Serverless Laravel Slack, it turns out that having a big cache could be what’s causing the site to be so slow.

The solution to this was to create a separate Cache in the Vapor dashboard and then configure that in our vapor.yml file.

        memory: 1024
        cli-memory: 512
        database: platform-staging-db
        cache: platform-staging-cache
        runtime: docker
            - 'COMPOSER_MIRROR_PATH_REPOS=1 composer install --no-dev'
            - 'rm -rf node_modules'
            - 'npm ci && npm run prod && rm -rf node_modules'
            - 'php artisan migrate --force'

After that, I did see an improvement but it still wasn’t as fast as the Forge server we were using for testing. That’s where my final improvement comes in…

Disabling the Stache watcher

By default, Statamic’s Stache (the caching layer) reads all of your markdown files on each request to check for any changes and then re-caches them.

Since we can’t change files anyway (Vapor has a read-only filesystem), it made sense to have this disabled.

// config/statamic/stache.php


return [

| File Watcher
| File changes will be noticed and data will be updated accordingly.
| This can be disabled to reduce overhead, but you will need to
| either update the cache manually or use the Control Panel.

'watcher' => env('STATAMIC_STACHE_WATCHER', true),

We’ve changed the watcher’s value to be a .env variable (which is true by default). This means we can enable/disable it depending on the environment. As I said, we’ll want it disabled in Vapor but enabled locally.


Hopefully, this post was helpful – even if I didn’t tell you how to fix the file-write issue (sorry if you were expecting that).

If you’re new to Laravel Vapor, I’d recommend buying the Serverless Laravel course. I watched a ton of them while getting Laravel Vapor set up on this project, and I’ve found them very helpful.

Now that we know that Laravel Vapor and Statamic work well together, we’re planning on using this combination in future projects.

Duncan McClean

Web developer at Steadfast Collective.

Share Article