Documentation
Docs for what actually exists.
Hostingsurge is in active development. These docs describe the modules that are implemented, say plainly which ones are not, and never describe a feature as if it were live when it is still being built.
Start here
The path a new account takes through the platform today.
- Create an accountSign up with email and password, then confirm the address from the verification mail. A verified signup brings 5 one-time Build Credits.
- Describe what you wantThe prompt on the landing page carries your description and starter choice through signup, verification and onboarding as a named intent field — it is not thrown away at the next screen.
- Let onboarding create the first projectOnboarding shows your description back, preselects the matching project kind and creates the project through the real projects API.
- Save a first versionEvery managed project gets private source. The source browser lists its files, shows them as inert text, and lets you edit or restore — each save is a new immutable version, never a rewrite of history.
- Run the AI builderFrom the project view you can start a builder run from a description. The run plans, generates, checks the result, repairs within a bounded budget and commits through the same source path as a manual save.
- Build an artifactAn isolated static build runs in a no-network sandbox and produces a hash-verified artifact with recorded runner evidence. A build that fails is a failure, never a silent success.
Steps 5 and 6 need the platform workers to be running, and AI generation needs a configured AI provider key. Without a key, a builder run reports not_configured instead of inventing output.
What is implemented today
Module by module, with the honest state of each.
| Module | State | What that means |
|---|---|---|
| Identity and accounts | Implemented | Signup, email verification, sign in and out, password reset, TOTP MFA with recovery codes, session and tenant resolution, security audit and database-backed rate limits. |
| Teams and permissions | Implemented | Six roles (owner, admin, developer, billing, editor, viewer), encrypted invitations, project grants and serialized last-active-owner protection. |
| Credentials and approvals | Implemented | Scoped API and MCP credentials with explicit lifetime, plus short-lived operation approvals bound to the user, organization, project, action, target and input digest. |
| Projects | Implemented | Create and list managed projects with their source preparation state. Creating a project is idempotent and retry-safe. |
| Source versions | Implemented | Save an edit, restore an older version, compare two versions and page through history. Every action creates a new version. |
| Export | Implemented | A deterministic ZIP of any saved version, bounded at 1000 entries, 256 KB per file and 16 MB per archive. |
| Isolated builds | Implemented | A static build in an isolated sandbox with no network, capped memory, CPU and process count, a read-only filesystem and no Docker socket. Artifact digest, size and entry count are verified before the receipt is written. |
| AI builder runs | Needs a provider key | A run state machine from queued to preview_ready with an append-only event log, repair rounds and generated-file counts. Without a configured AI provider key the run refuses with not_configured. |
| Billing and credits | Backend implemented, not live | The credit ledger, verified top-ups, subscription fulfillment, refunds and disputes are implemented and tested. No price catalog has been published, so no purchase can be made. |
| Domains, WordPress, App Store, AI agents, backend, usage, admin | In development | Specified and not shipped. They are absent from the customer navigation rather than shown as empty panels. |
Guides and their state
The specification asks for guide coverage for every module. A guide is published when the module it describes can be used.
| Guide | State |
|---|---|
| Getting started | Available — this page |
| Project export | Available — see Developers |
| API | Available — see Developers |
| MCP | Design only — server in development |
| AI Builder | Partial — run states are real, the workflow guide grows with the module |
| Publishing | In development |
| Domains | In development |
| WordPress and connecting WordPress | In development |
| Importing Vercel, importing Lovable, migrating Supabase | In development |
| GitHub / GitLab (Developer Mode) | In development |
| Backend | In development |
| Storage | In development |
| AI agents | In development |
| App Store | In development |
| Billing | Backend implemented; customer purchase flows are not live |
Nothing is documented here as usable before it works. When a module lands, its guide appears and the status page stops calling it in development.
Screens in the product
Where each implemented area lives, so you can find it without guessing.
| Module | Route | State |
|---|---|---|
| Marketing | /, /pricing, /developers, /mcp, /docs, /status, /security, /about | This set of pages |
| Account | /account, /account/onboarding | Overview, teams and projects; onboarding creates the first project |
| Projects and source | /account/projects, /account/versions, /account/source | Project list and project view, version history, file browser, comparison and export |
| Team and access | /account/teams, /account/credentials, /account/policies | Memberships and invitations, API and MCP keys, AI policy editor (Business) |
| Billing | /account/billing | Plans, credits, orders and subscription controls |
| Authentication | /account/login, /account/signup, /account/verify, /account/forgot-password, /account/reset-password | Session, verification, MFA challenge and recovery |
Read the boundary, then build.
The developers page lists every endpoint that exists today, with its authentication. The status page says what is live right now.
These docs are maintained next to the code. If something is described here, it exists in the current build; if it does not, the page says in development instead.