Shipping with Spacefast

I’ve been shipping real work on Spacefast since August 26. That’s about a month before its soft launch — and well before yesterday, when it opened to everyone.

So I’ve had some time to form opinions.

Editor’s note

I work at Automattic, and Spacefast is an Automattic company. Nobody asked me to say nice things. This is just how I use it.

If you haven’t seen it yet, the idea is simple:

You hand Spacefast a folder of files.
Seconds later, it’s live at a URL.

Each project is called a Space. Spaces are private by default. Every publish is saved as a version you can roll back to. Custom domains even work on every plan — even the free one.

That’s it. Simple.

I needed a docs site for WordPress core work

The Secrets API is headed for WordPress 7.2. While building the feature, I learned that a core proposal generates a lot of writing that doesn’t belong in a README. The spec. Decision records. The changelog. Lists of questions we still haven’t answered.

All of it lives at secretsapi.dev — a site has been a Space from day one.

The docs live in the same repository as the code. When I merge a change, GitHub Actions builds the site and publishes it. I never touch a server.

Here’s what that looks like in practice. A reviewer asks a question on the Trac ticket at 9:00. I write up the decision. By 9:15, the answer has a permanent URL I can link back to.

Fifteen minutes. No server to patch. No pipeline to babysit. And every version of the documentation is instantly recoverable.

The conversation around a core proposal is scattered — Trac, Slack, make/core. Having one home for the answers that updates as fast as I can type was more than worth the few minutes it took to set up.

I also publish by hand when I’m in a hurry

Some things don’t deserve a pipeline.

I have other Spaces I deploy straight from my laptop. Quick, branded docs for customer engagements. One command and they’re live.

A lot of them are for people outside the building. My day job puts me in front of external engineering teams, and much of what I hand them is a document — an assessment, a report, a testing plan.

PDFs go stale the moment you hit send. Shared docs are better, but they drag in whatever account system the other company does (or doesn’t) use — like when I send a Google Doc to a shop that exclusively uses Office.

Instead, each one is a Space. It’s private, shared exclusively with the people who need it. When the plan changes, I publish a new version to the same link. If I get something wrong, a revert is one command away.

The recipient just sees a fast, clean page that’s always current.

Sometimes a static page isn’t enough

A test plan is far better when the people running it can check things off. A kickoff questionnaire works better as a form than as a list of questions in an email.

I’m a lazy developer. I could write a backend for that and handle the data storage. I just don’t want to.

Conveniently, Spacefast means I don’t have to. A Space can handle a little dynamic behavior on its own, and two built-in features cover the rest:

Storage holds whatever the running app uploads, separate from the published files.
Crons are scheduled requests to a path on your own site. You declare them in sf.jsonc, so they’re versioned with everything else.

Put them together and the checklist I share with a remote team remembers its state. A form submission lands somewhere I can read it. A scheduled job rolls up progress while I’m asleep and a team twelve time zones away is working.

It all still ships with a single publish.

There’s a full WordPress install back there

I’ve been working on WordPress for a very long time. When I first read that every Space has a full WordPress install sitting behind its published files, I had to go look.

Static files are served first, so a static Space never touches WordPress. But it’s there when you want it. Storage is its media library. The database is its MySQL. And sf wp passes commands straight through to WP-CLI.

I haven’t needed it for most of what I publish. Still, I like knowing that the day a project outgrows flat files, the thing waiting behind them is software I know inside and out.

The same goes for the hosting itself. Spacefast runs on the infrastructure that already serves WordPress.com and Tumblr — more than 15 billion page views a month, by Automattic’s count.

I’ve been on the wrong side of enough launch-day outages to care more about boring, proven plumbing than a shiny feature list.

It still has rough edges

It’s a young product. It shows.

Local development doesn’t cover everything yet. Some of the dynamic pieces you only see working after you publish.
Remote sf wp tells you whether a command succeeded and nothing else. If you need the output, you run it with --local or go through sf db.
Storage caps uploads at 5 MiB per file.
Crons are plain GET requests with no retries. The free plan gets three per Space.

None of these have blocked me. But they’re the kind of thing I’d want to know before betting a project on it.

Give it a try

Most of the launch coverage frames Spacefast as a home for apps built by AI agents. It’s good at that. My use is more mundane — I have things to publish, I want them live now, and I don’t want to run the server.

Spacefast gets the job done.

The free plan doesn’t need a card, and you can publish your first Space without even creating an account. The quickstart takes a few minutes.

If you’d rather read what other people are saying first:

What would you publish if going live took seconds instead of an afternoon?