INTRODUCTION / 01
Start with a project.
NexaCloud is currently a private developer preview. Static hosting is operational, and the owner console is access-controlled. Public signups and customer billing are not yet enabled.
As the platform opens to more users, the workflow will be simple: create a project, add your site's files, and publish a version to the edge.
Owner console ↗
DEPLOYMENTS / 02
Publish static sites.
The platform stores HTML, CSS, JavaScript and other supported static files in a dedicated Cloudflare R2 bucket. A Cloudflare Worker serves each site's active version.
- Create a project in the authorized console.
- Create a deployment draft.
- Upload your static files, including
index.html at the root. - Publish the draft to make it the active deployment.
my-project/
├── index.html
├── style.css
├── script.js
└── images/
└── logo.svg
There is no public command-line deployment tool yet. Do not run commands claiming to be an official NexaCloud CLI.
SOURCE CONTROL / 03
Import from GitHub.
The prototype supports importing small public, static GitHub repositories. Repositories need a root index.html, and supported assets are copied without executing scripts or installing npm dependencies.
Full GitHub App installation, OAuth, preview builds and private-repository access are on the roadmap.
ROLLBACK / 04
Control every version.
Each static deployment is stored as a separate version. The platform records which version is currently active and allows manually promoting a previously published version.
Version management is implemented in the private owner console; automated deployment triggers are not enabled for customers.
DNS / 05
Your project, your URL.
Free preview URL
Individual static projects can be assigned a dedicated workers.dev address within the available Cloudflare account limits. This is proven with an isolated live test project; automatic provisioning for public customers is not yet active.
Bring your own domain
Domain registration and DNS TXT ownership verification are implemented in the owner console. After verification, the domain remains verified_pending_routing until custom hostname routing and a valid SSL certificate are configured.
Type: TXT
Name: _nexacloud-verification.yourdomain.com
Value: nexacloud-verify=<unique-token>
Custom hostname traffic requires additional Cloudflare for SaaS setup, which may need payment information. No custom domain is considered live before SSL and routing are verified.
CLOUDFLARE WORKERS / 06
Dynamic applications: early preview.
The owner console can now configure a project as a separate Cloudflare Worker, inspect public GitHub repositories for framework compatibility and verify an actual deployed runtime. No customer code is executed inside the admin Worker.
See a live dynamic Worker demonstration ↗, including a computed API route.
To build from a Git repository today, connect the compatible Worker through Cloudflare Workers Builds directly. A protected Cloudflare Deploy Hook may now be registered in the owner console for a connected Worker, allowing manual build requests. Automatic GitHub connection, framework-specific adapters and customer runtime logs are not yet operational.
TRANSPARENCY / 06
Preview limitations.
The current system is a restricted static-hosting preview. Internal safeguards include a maximum of 20 projects, 12 versions per project, 30 files and 8 MB per version, and 1 MB per file. These are preview implementation limits, not published pricing entitlements for future customers.
Dynamic backend hosting, isolated builds from arbitrary code, customer accounts, custom domain routing, commercial billing and domain resale are still in development.
Explore current platform status ↗