Sites and deployments

Start by choosing whether Cloud should provision a managed site or deploy an application from a repository. These paths use different controls and have different access requirements.

Create a managed site#

1. Open New project while signed in.
2. Choose WordPress, PrestaShop or PRISM. Choose the native CMS only when you want a PRISM starter with content management.
3. Enter a site name. Managed slugs use 1 to 28 lowercase letters, digits or dashes, with no leading or trailing dash.
4. Follow the provisioning progress. WordPress and PrestaShop install in the background; submitting the form does not mean they are ready.
5. Save the back-office credentials when the result is displayed. Background installation credentials are returned once.

The staging hostname is <slug>.staging.bext.dev. Cloud checks your account's site allowance and subscription before creating another managed site. A name held by another managed project is unavailable even if you cannot see that project.

A managed site's name and framework are fixed because they identify the live installation. A PRISM starter is already provisioned and does not accept a Git deployment; create a separate Git project to deploy repository code.

Deploy from a repository#

Create a project with a supported framework, its repository URL and, when needed, an existing deployment target. Open the project to request a deployment and follow its build history.

Repository builds on the managed platform are currently restricted to platform administrators. Creating a project or providing a repository URL does not remove that restriction. External targets are subject to their own provider and connection checks. If Cloud refuses a deployment, use the returned explanation rather than treating the project as successfully deployed.

To request a deployment through the API:

curl -X POST \
  "https://cloud.bext.dev/api/projects/$PROJECT_ID/deploys" \
  -H "Authorization: Bearer $BEXT_CLOUD_TOKEN" \
  -H "Content-Type: application/json" \
  -d '{"git_ref":"main"}'

PROJECT_ID comes from GET /api/projects. The Git ref must exist in the configured repository. This example requests a build; inspect deployment history for its result:

curl "https://cloud.bext.dev/api/projects/$PROJECT_ID/deploys" \
  -H "Authorization: Bearer $BEXT_CLOUD_TOKEN"

Wait for a terminal status, inspect build errors if it fails, and check the application at its served URL after success. A site move, an invalid target, unreadable environment variables or a platform restriction can prevent a deployment.

Connect a domain#

1. Add the hostname to the project's domain list.
2. Publish the DNS ownership challenge and address records shown by Cloud.
3. Run verification. Cloud checks domain control and whether the hostname points to the expected server.
4. Use the site's publication control to select the verified domains and primary hostname.
5. Check HTTPS and the application's response on the public domain.

Publication on your own domain requires an eligible plan. A hostname resolving to the server is not sufficient proof of ownership. Non-administrator accounts must use domains attached to that project, and Cloud rechecks ownership before publication.

For MCP, use add_domain, verify_domain, then publish_site with dry_run: true to preview the operation. A real publication uses dry_run: false and confirm equal to the exact site slug. See the MCP workflow.

Roll back a Git site#

Where retained Git releases are available, Cloud can reactivate the previous release. Other providers can reject rollback as unavailable. A historical deployment record alone does not guarantee that its files can be restored.

The MCP rollback_site tool activates the immediately previous retained Git release. It requires the exact project ID as confirmation; it does not select a release by deployment ID. After rollback, check the site and deployment history again.

Before deleting a site#

Download any backup you need to keep before destroying a managed site. Site destruction can remove its live installation; requesting a file purge also removes its files. A managed site's project is its ownership record, so use the site destruction action rather than deleting that project record independently.

For backup availability and retention, see Cloud backups. For build and routing failures, start with troubleshooting.