# Spacefast Pricing and Deployment: What to Check Before Your First App

Automattic lets your existing AI agent publish apps, but the plan limits and deployment path deserve a closer look before you move a real project.

By Paras Madan | 2026-11-10


Spacefast is Automattic’s hosting platform for projects built with AI agents. It opened to everyone on November 9, with a free Personal plan and paid plans starting at $5 a month. You keep your existing coding agent, while Spacefast supplies the deployment destination and supporting infrastructure.

That separation is useful if you already like the tool writing your code. You can evaluate hosting without moving the entire development workflow. But a working preview, a supported server runtime and a predictable monthly bill are three different things. Check each before handing an agent your production deployment.

## What Spacefast actually provides

The [launch announcement](https://automattic.com/2026/11/09/meet-spacefast/) describes hosting, custom domains, SQL, versioned publishing, collaboration and access through an API, CLI or MCP server. It also describes approval checks for actions such as DNS changes and rollbacks. This is the public launch following a September soft launch, rather than the first appearance of the service.

Spacefast charges for infrastructure rather than adding another pool of AI inference credits. Your existing agent costs still belong in the project budget, but the hosting decision can be made separately from the model decision.

## Spacefast Personal, Go and Pro pricing

The current [pricing page](https://spacefast.com/pricing/) lists these monthly prices in US dollars before tax. Included usage is a credit against metered resources, not money added on top of the subscription.

| Plan | Monthly price | Included monthly usage | Spaces and custom-domain quota | Publishing members |
| --- | --- | --- | --- | --- |
| Personal | $0 | $1 | 20 | 1 |
| Go | $5 | $5 | 100 | 1 |
| Pro | $15 | $15 | 500 | Up to 5 included, then $15 per additional member |

All three allow commercial use. Go adds hourly database backups and datacenter selection. Pro adds team roles and wildcard domains. Enterprise has custom pricing.

The first upgrade decision is often collaboration rather than traffic. A solo founder can evaluate the lower plans, but a second person who needs to publish or change settings pushes the decision toward Pro. Reviewers and app users are different from publishing members.

## A spending cap does not remove runtime limits

Go and Pro have spending caps that initially default to twice the plan price. At the cap, new builds and Workers pause while deployed Spaces continue serving. Personal has similar behavior when its $1 of included usage is exhausted. **Budget limits and application limits need separate checks.**

The [detailed limits](https://spacefast.com/docs/pricing/) give Personal and Go two compute workers per Space, with four on Pro. These govern concurrent dynamic requests. Excess requests wait briefly and can receive a 429. Go can burst to four workers when capacity is available, but that is weaker than guaranteed concurrency.

For example, a dashboard with many visitors reading cached pages has a different bottleneck from an app making slow uncached requests. Paying for Go increases allowances and storage without doubling its base worker count. Before upgrading for a performance problem, identify which limit the application is hitting.

Some resources, including MySQL compute, are currently marked complimentary with future rates displayed. Do not build a long-term cost estimate by treating every temporarily free meter as permanently free.

## Publish a small static project first

For an initial evaluation, use a non-sensitive static page with a known output folder. This gives you a clean way to check deployment and access behavior before adding a database or server-side logic.

The [quickstart](https://spacefast.com/docs/quickstart/) requires Node.js 20.3 or newer for the npm package. Its basic signed-in flow is:

```bash
npm install -g spacefast
sf login
sf whoami
sf publish ./dist
```

Replace `./dist` with your actual built output. Review the sign-in authorization in the browser, then inspect the resulting page and its sharing settings yourself. Verify assets, navigation and any form destination before sharing it with customers.

Anonymous publishing is available, but an unclaimed Space has a serving lifetime of 33 hours and 20 minutes after creation or the latest file-changing publish, capped at 30 days from creation. Claim it before treating the link as a lasting deliverable.

The CLI records the project-to-Space mapping in `.spacefast/space.json`. Keep that mapping with the project so the next publish updates the intended Space. For a claimed Space, `sf versions ls` lists versions and `sf rollback v1` moves the live channel back without rebuilding.

## Check the framework path before migrating

Spacefast distinguishes uploading built output from building source remotely. The [framework documentation](https://spacefast.com/docs/frameworks/) recommends publishing output when it is already available, while `sf publish --remote` sends source through a hosted build. That distinction is worth preserving in an agent workflow: debugging a local build failure is easier than changing application code and hosting configuration at the same time.

Importing deployment configuration also has boundaries. Spacefast can convert supported settings from files such as `vercel.json` and `netlify.toml`, but flags features it cannot convert, including Vercel functions and Netlify edge functions. **Do not silence an unsupported-feature warning just to get a live URL.** A successful page upload can still leave a backend route missing.

Next.js needs particular attention. The [Next.js recipe](https://spacefast.com/docs/recipes/next/) supports server-rendered builds on stable 16.2.x, 16.3.x and 15.5.24 or later 15.5 releases. Several other listed versions support static export only; canary releases are refused. Check the matrix against the exact version in your project rather than reading “Next.js supported” as a blanket compatibility promise.

## When Spacefast is worth trying

A small demo, calculator or client-facing prototype is a sensible first project. It lets you evaluate whether publishing through the agent actually reduces work without simultaneously betting your application’s data and runtime behavior on a new platform.

For an established app, start with an inventory of server routes, external services, deployment assumptions and access requirements. Keep the old deployment until those checks pass on the new one. The useful part of agent-driven hosting is shorter delivery work; it only stays useful when the agent leaves you with a deployment you can inspect, recover and afford.

I’m Paras. I work at the intersection of AI, engineering and distribution.

I help technical founders turn product launches and engineering decisions into clear stories that developers understand and share.

[Book a 30-minute call](https://cal.com/paras-madan/30min).