No database by default
A brochure site gets no database, no permanent Node process and nothing to patch. There is simply less to break.
HOSTING
Static first. Real infrastructure only when something needs it.
Hosting for the things Hostingsurge builds: static output, full code projects and managed services — each on an isolated, reproducible deployment with real state, real logs and no vendor control panel.
Availability: managed source, isolated builds, the hash-verified artifact store and the deployment adapter are implemented and verified in development. Customer publish and custom-domain attach are the next customer-facing step and are still being wired, so nothing here is claimed as a public launch.
Queued is not liveNo-network build sandboxHash-verified artifactsIsolated runtimeReal logsNo vendor panels
How a deployment actually happens.
The same six steps whether the project came from the AI builder, an import or your own code.
- SourceA managed project keeps its source in platform version history. You edit in the browser or import a project — the versions are kept for you, not by you.
- Version commitA build is always bound to one completed saved version, so what was built stays exactly identifiable later. Nothing is built from an unnamed working copy.
- Isolated buildThe build runs in a container with no network access, capped memory, CPU and process limits, a read-only filesystem and a bounded wall-clock timeout. No Docker socket, no host mounts.
- Verified artifactArtifact bytes are hash-verified and stored before the platform records a build receipt. The database keeps identity, size, entry count, duration and runner evidence — never your content.
- PreviewA deployment is reachable as a preview first, so a change is reviewed in the real world before it replaces the live site.
- PublishPublish promotes a verified build to production. This is the step currently being wired to the customer interface — it is in development, not a shipped button.
States you can trust.
Every run carries an explicit state, and the states are not decoration: a run that has not succeeded is never displayed as if it had.
| State | What it means |
|---|---|
| Queued | Accepted and durable, waiting for a worker. Nothing has been built yet. |
| Running | A worker holds a bounded lease and is executing the step it reports. |
| Waiting for you | Progress is blocked on a customer decision — for example a change that needs approval. |
| Retrying | A bounded retry is in progress. The attempt count and the limit are recorded. |
| Succeeded | The step completed and its evidence was recorded before the state changed. |
| Failed | A terminal failure with an honest error category. Reserved credits are released, the previous verified deployment stays where it is. |
| Cancelled | Stopped on purpose. What was already confirmed is kept as history, not silently deleted. |
Build receipts and credit history are append-only: the platform cannot quietly rewrite what happened.
Static by default, because most sites do not need a server.
Static-first is a product rule rather than a cost optimisation. A generated site is deployed as static output unless a feature genuinely requires more.
Tiny footprint
Simple sites are optimised for a small runtime footprint, which is why hundreds of them coexist comfortably.
Backend on demand
Login, persistent records, private uploads, server-side secrets or scheduled jobs are what trigger infrastructure — not the fact that AI wrote the page.
Full projects supported
React, Vite, Astro, statically configured Next.js and plain HTML/CSS/JS all fit the same pipeline. A framework is never used for branding reasons.
Storage stays separated by purpose: source code, deployment files, database storage, customer uploads and backups are different things, not one disk bucket.
Where your work runs.
The platform schedules work onto nodes it knows the role, capacity, health and location of — you never pick a machine.
Placement is decided from node role, available capacity, project requirements, region and risk profile, and a node that is draining accepts no new workloads. Nothing is hardcoded to one server: the model is built so more can be added without changing what customers see. Today that means one hardened, externally provisioned EU server with firewall, TLS and a hardened proxy — no vendor panel exposed to you.
Capacity, utilisation, health and drain status are tracked per node, so placement is a platform decision rather than a per-customer one.
Node roles
- WEBStatic and web delivery
- APPRunning application processes
- DATABASEManaged data services
- BUILDIsolated build execution
- AGENTPrivate agent runtimes
- INTERNALThe platform itself
What the build sandbox refuses to allow.
Untrusted builds do not run next to anything that matters.
// fixed static build recipe no network access --network none memory cap 512m cpu cap 1 process cap 128 root filesystem read-only writable scratch bounded, noexec Docker socket not mounted host mounts none wall-clock timeout enforced, container removed by name source limits 1000 entries / 256 KB per file / 16 MB
- Artifacts are assembled deterministically, so the same source produces the same bytes and a crash cannot leave a half-written artifact under a final name.
- A lease-renewal fence means a worker that loses ownership stops without recording anything, rather than racing another worker.
- Customers never get proxied access to provider APIs, and no provider dashboard is exposed to normal workflows.
Where this stands. The isolated build runner, the atomic artifact store, the lease and recovery logic and the deployment execution and recovery module are implemented and verified in development against real disposable infrastructure, with injected synthetic provider transports. Live hosting capacity, external backup/restore and the public publish path are not verified, so this page describes the designed contract rather than a finished public service.
Questions, answered plainly.
Access, isolation and what happens when something breaks.
Do I get SSH, root or a control panel?
No, and that is deliberate. You never manage servers, proxies or infrastructure dashboards. Customer actions go through Hostingsurge permissions and the platform API instead of a vendor console, which is also why there is no panel to leave open.
Can I run my own Docker containers?
Custom Docker is a premium and developer capability in the app catalogue rather than a default. It runs under the same isolation rules: no privileged containers, no Docker socket and no host filesystem mounts.
Which frameworks can I host?
Plain HTML/CSS/JS, static builds from React, Vite and Astro, statically configured Next.js, and full code projects on the same pipeline. Static output is preferred where it is possible because it gives you fewer moving parts.
What happens if I deploy something broken?
The build fails as a build, with a real error category and real logs, and the previously verified deployment keeps serving. There is no code path where a failed run is displayed as live, and reserved credits are released instead of consumed.
Do you measure resource usage?
Yes. CPU allocation and runtime, memory, storage, build minutes, database and object storage and AI cost are metered from day one, even where a plan describes something as included — fair-use still means measured.
One product. Zero vendor noise.
Deployments, versions, domains and logs inside Hostingsurge. No SSH, no control panel from a vendor, no infrastructure dashboards.