What Astropress is
A database-backed web app framework with provider-neutral runtime adapters, a non-technical admin surface, and static output where static output actually makes sense.
Who it fits
Teams that want pages, posts, media, redirects, comments, users, revisions, and localization in one bounded system instead of plugin sprawl.
What it avoids
Site-builder abstraction layers, page-builder lock-in, always-on PHP hosting, and any requirement that editors learn Git just to publish content.
Deployment model
Astropress no longer treats hosting as one overloaded provider choice. It separates the App Hostfrom the Content Services layer. For example, you can run the Astro app on Vercel or Netlify while keeping content, media, and auth services on Supabase. Or you can keep both layers on Cloudflare.
Current maturity
| Local SQLite runtime | Supported | Reference path for local development and the strongest validated flow today. |
|---|---|---|
| GitHub Pages public deploy | Supported | Good fit for public docs and static output, not the canonical write runtime. |
| WordPress staged import | Supported | Creates typed inventory, plan, report, and artifact sets for operator-reviewed migration work. |
| Split hosting matrix | Supported | App Host and Content Services are now chosen separately in the CLI and docs. |
| Hosted adapters beyond Cloudflare and Supabase | Preview | Firebase, Appwrite, and several host combinations are exposed in the matrix, but not all have first-party runtime adapters yet. |
| One-step hosted migration | Not yet | WordPress import is not presented as a one-click persisted hosted migration. |