The Flying Squirrel: when the SPIP CMS goes serverless

In the beginning..

The French Web was formless and empty.. a handful of sites (academic ones especially), tied to one another by links and listed in directories.

1996: the first web hosting services, Mygale, then Chez.com. "There was evening, and there was morning. The first day."

1999: As a teenager, I learn PHP. "There was evening, and there was morning. The second day."

2000: The first CMS give non-developers the power to become editors. Drupal, then SPIP. And MySQL databases. Not much content to publish on my side, but I read a lot. I watch sites (many left-wing activist ones like uZine, rezo.net..) pick up the tool. "There was evening, and there was morning. The third day."

2003: WordPress and Dotclear. So easy to write without developing; I set dev aside for a while. "There was evening, and there was morning. The fourth day."

2016: thanks to a few pioneers, I discover the cloud. I am blown away by AWS's ability to summon infrastructure on demand, and by what it lets me offer: highly available, scalable applications. "There was evening, and there was morning..."

And then, all of a sudden.

May 2026, a phone call. "Paul, I want to build an app. But I have one non-negotiable requirement: the backend must run on SPIP."

As often on the projects I support: no infra skills available. And the ambition to ship a consumer-facing application (more on that soon).

With the CMS imposed, how do I:

• run it without paying around the clock (including at 3am when there is not a single visitor)?
• without maintaining servers?
• while keeping up with the load when our app takes off?

Serverless, of course. It remained to be seen whether it would actually work.

On the sixth day, Paul created SPIP-serverless

I discover SPIP, a French free-software CMS, written in PHP and maintained by its community for 26 years. The project's architecture is not exactly modern.. and above all, it is designed to be simple to administer, for non-technical people, to be deployed on a single machine rather than in a distributed compute environment built for high availability: no session handling in a shared cache, in-place upgrades, and so on.

With its need for a persistent local disk and an always-on database, it was not the natural candidate for serverless.

And yet, I am proud to announce today spip-serverless, a port of SPIP onto a 100% serverless architecture. You can put away your shared hosting :)

The project is available on GitHub, under the MIT license. And you can see it in action on this demo site. It will likely be many months before this site costs me a single euro in hosting.

SPIP-serverless: how does it work? The main architecture choices

Here are some of the decisions behind SPIP-serverless:

• Compute runs on the Function-as-a-Service AWS Lambda. Running PHP in there is possible thanks to Bref, which gives PHP a real Lambda runtime (FPM). (For the full picture of how PHP fits into AWS serverless, I wrote a series that starts here: How to run PHP on AWS serverless.)
• Sessions do not live on the local disk: they go to DynamoDB (on demand).
• Uploaded media does not live on the local disk: it goes to S3 (direct presigned uploads from the browser, a stream wrapper, and a small patch so SPIP reads and writes its media on S3).
• A CloudFront CDN caches content so it can be served without necessarily running SPIP's code on every request.
• Secret keys are generated once and stored in SSM Parameter Store, then reinjected at boot so every environment shares the same keys.

But what about the database? A relational database costs an arm and a leg!

The brick that makes pay-as-you-go real is Aurora DSQL, a serverless Postgres billed for what you use.

A SQL CMS normally forces an always-on database, hence a fixed cost floor; DSQL removes that floor, and connections use short-lived IAM tokens (no stored password).

SPIP usually relies on MySQL, though behind an abstraction layer (I would not call it an ORM ^^), so I had to tinker a bit to get Aurora DSQL working. Fortunately, the community had already done an experimental port to PostgreSQL.

With Lambda and API Gateway per request, DynamoDB on demand, S3 and CloudFront for delivery, an idle site costs almost nothing and wakes up on the first request.

The serverless tradeoffs

The essential tradeoff is in SPIP administration: serverless rests on an immutable-infrastructure paradigm (the container that runs SPIP's code cannot be modified at runtime, and even if it could, it would be destroyed and replaced by another one a few minutes later).

• For the editor, nothing changes: content is edited online (database and S3).
• But the administrator's tasks (editing templates, deploying plugins, version upgrades) happen through code and continuous integration.

Versioned, reviewed, reproducible: a real modern dev workflow :)

And on the seventh day, Paul @ TerraCloud rested

The code is open source (MIT) and generic: you can deploy your own SPIP the same way.

• To get started, visit the github.com/psantus/spip-serverless repository
• and browse my demo site

As for me, I will not rest completely:

• First, I will be counting your stars on the repo.
• Then, I plan to maintain and improve this project based on real needs:
  • If something is missing for your use case, open an issue and let's talk.
  • If you would like a hand building or deploying your own SPIP-based project, reach out on terracloud.fr or via LinkedIn!