App host options
| GitHub Pages | Supported | Static-only host for prerendered Astro output. |
|---|
| Cloudflare Pages | Supported | Static output plus Workers-backed runtime paths. |
|---|
| Vercel / Netlify / Render Web | Supported | Free-tier Astro app hosts for SSR or admin-backed deployments. |
|---|
| GitLab Pages / Firebase Hosting / Render Static | Preview | Good static hosting options, but less validated in Astropress today. |
|---|
Content services options
| Cloudflare D1 / R2 / Workers | Supported | One-provider path where Astropress keeps app hosting and content services aligned. |
|---|
| Supabase | Supported | Database, storage, and auth services. The Astro app still needs a separate app host. |
|---|
| Firebase / Appwrite | Preview | Clear service-layer choices in the setup matrix, but not first-party hosted runtime adapters yet. |
|---|
| PocketBase / Nhost / Neon | Preview | Named options in the setup matrix, but not first-party hosted runtime adapters yet. |
|---|
Good combinations today
- GitHub Pages + no hosted data services: static Astro output only.
- Cloudflare Pages + Cloudflare D1/R2: Astro app host and content services on one operational stack.
- Vercel + Supabase: Astro app host on Vercel, content/auth/media services on Supabase.
- Netlify + Supabase: similar split, different app host.
- Render Web + Firebase or Appwrite: Node app host plus a separate services platform.
Selection rule
First choose the App Host, meaning where the Astro web app runs. Then choose Content Services, meaning where Astropress stores content, media, auth, sessions, and the service API behind admin actions. Do not treat Supabase or Firebase as app hosts, and do not treat GitHub Pages as a database platform.