Spacefast: Your AI Built the App. Who Gets It Online?

  • Cloud
  • Spacefast
  • AI apps
  • Deployment
  • Small business
Published
Reading time
6 min read
Spacefast deployment review checks access, the working application and ownership.
An original editorial illustration, not a screenshot of a deployed project.

Spacefast addresses a familiar gap: an AI has produced an app, but somebody still has to put it online and keep it usable. Automattic's service offers hosting and supporting infrastructure for work created with the AI tools people already use. Its own homepage says it is not an AI builder[1].

That is a useful distinction for a founder or freelancer. You may not need another chat window. You may need the existing project to have a stable address, working data, controlled sharing and an owner who can maintain it.

This guide is based on current product pages and launch reporting checked November 10, 2026. I have not deployed a project to Spacefast or tested its billing and rollback behavior. The checks below are proposed acceptance checks, not a completed service review.

What Spacefast adds to an AI-built project

The homepage describes publishing from an AI conversation, a command-line tool, a folder upload or a connected Git repository. It also describes databases, file uploads, analytics, retained versions and sharing controls[1].

Automattic's November 9 announcement positions it as infrastructure that works with the agent you already use, rather than requiring you to replace that agent[2]. TechCrunch's reporting describes the same broader move toward hosting AI-built apps and sites[3].

For a small team, the appeal is less setup between an idea and a usable link. But the link is the beginning of the handoff, not the end of it. A page can load while its form, permissions or saved data still fail.

Publishing does not mean everybody can see it

Spacefast says new Spaces are private. Its FAQ distinguishes inviting people, creating a share link and making a Space public. Search indexing is a separate setting[1].

Before sending a client a link, decide the intended audience. Then test access as a viewer, not only in the account that created the project. A private project can be correctly deployed and still inaccessible to its intended reviewer.

The reverse mistake matters too. A preview with internal prices, customer data or unfinished copy should not become public simply because somebody asked the AI to put it online. Treat publication state and audience as explicit choices.

A database is not the same as a correct data model

The current homepage says each Space comes with a database and supports file uploads[1]. Those capabilities can remove infrastructure work. They do not decide which users may read or change each record.

For a lead form, test what happens after submission. Is the record saved? Who can see it? Can the same request create unwanted duplicates? Does an error leave the user believing the form succeeded?

For an app with accounts or orders, use non-sensitive test data first. Check ownership boundaries between users and inspect the actual saved state. A convincing interface is not evidence that authorization or persistence is correct.

Check the framework path before committing

Spacefast lists supported Next.js, TanStack Start, Astro and PHP projects, with runtime behavior depending on the deployment path. Its FAQ directs readers to framework guides rather than promising identical behavior for every project[1].

That means the question is not just whether your repository contains a familiar framework name. Check which features the chosen path supports, what happens to server-side code and where application data lives.

Do this before building a client workflow around a feature you have not verified. A static landing page and an app with background jobs, private uploads or unusual server dependencies are different deployment problems.

A Spacefast handoff checks the audience, application behavior and ownership
Proposed deployment checks. This diagram does not report a completed Spacefast test.

Spacefast says an unclaimed Space normally expires 33 hours and 20 minutes after creation or the latest publish that changes files, with a cap of 30 days from creation. Claiming it removes that anonymous expiry. Claimed Spaces remain live until unpublished, while retained versions follow the plan's history policy[1].

For a quick experiment, an expiring link may be acceptable. For a client review, sales page or internal tool, write down who owns it and make sure the project is claimed before other people depend on it.

Do not confuse having a link with having durable control. Keep the relevant account, project and recovery route clear in the handoff. A project that disappears after a presentation is still unfinished work, even if the first demo went well.

Version history helps, but it is not the whole recovery plan

The service describes saving versions and restoring retained versions[1]. That can be useful when a new change breaks a page.

Still, test what a rollback actually covers for the project. Reverting code and reverting application data are not necessarily the same operation. Do not assume restoring yesterday's interface also restores a deleted record or reverses an external email.

Before a risky change, preserve the data and state needed to recover. Keep a known-good version and an acceptance check. A rollback button is most useful when you know which version worked and why.

The pricing and feature pages do not all agree

The launch release describes Go and Pro plans and marks built-in authentication, transactional email and shared team knowledge as coming in the following weeks[2]. The current homepage presents Personal and Enterprise pricing, while another official open-source hosting page uses Free, Go and Plus names and lists additional included features[4].

I would not turn that mix into a definitive plan table or promise that every feature is available through every path today. Check the live account offer, relevant documentation and final billing terms for the project you intend to run.

The practical takeaway is simple: free to start does not establish unlimited use, a particular production allowance or a fixed team price. Confirm expected usage and what happens when limits are exceeded before a public launch.

Know what leaving would involve

The homepage says files can be downloaded from a retained version. Static sites generally move to another host as they are, while apps using Spacefast runtimes need code changes and application data exports separately[1].

For a client project, that is an ownership question worth settling early. Can the client obtain the code and data? Who can export them? Which features depend on the host rather than on portable project files?

Export is not the same as a verified migration. Try the exit path with a small project before promising that a complex application can be moved without work.

My recommendation

Spacefast is worth considering when the bottleneck is getting an AI-built project online with less infrastructure setup. Start with a small, non-sensitive project and a clearly defined audience.

Accept the handoff only after checking access, the core workflow, saved data, ownership, expiry and recovery. Deployment removes one kind of work. It does not remove the responsibility to verify the thing people will actually use.

FAQ

Is Spacefast another AI app builder?

Its homepage says no. It supplies tools and infrastructure for the AI or agent you already use.

Is a published Space public?

Not by default. Spacefast says new Spaces are private, with separate invitation, share-link and public-access choices.

Can I publish without an account?

The service says you can start without one, but unclaimed Spaces have expiry rules. Claim an important project before relying on it.

Does deploying an app prove it is ready for customers?

No. Test its actual workflow, data, permissions, errors and recovery behavior separately.

Can I export my project?

Spacefast describes file downloads from retained versions. Static sites are more portable; runtime-dependent apps may need code changes and separate data exports.

Have you tested Spacefast for this article?

No. This is a current-source explanation and proposed deployment checklist, not a hands-on hosting review.

Sources

  1. Spacefast homepage and FAQ (opens in a new tab)
  2. Automattic launch announcement (opens in a new tab)
  3. TechCrunch: Automattic debuts Spacefast (opens in a new tab)
  4. Spacefast open-source hosting information (opens in a new tab)

Elsewhere on this site

Claude Fable 5.2: release, pricing and access explains a model announcement separately from the infrastructure needed to run its output.

Let's build something great together. . EMAIL ME