Cursor guide

Host a Cursor website from the right workspace.

Cursor can open a complete app, a static site and temporary experiments together. Identify the actual production project before connecting GitHub.

Start with the workspace

Choose the deployment type from what the project actually does.

Static site

Choose static when the production build produces HTML, CSS, browser JavaScript and assets that work without your own application process.

Managed Node 22 web application

Choose Node only for a supported HTTP application with npm start, Host Luma’s supplied PORT and GET /health.

Different service required

PHP, WordPress, databases, Docker and arbitrary workers are outside AI Hosting’s Node web-application scope.

A development preview, a monorepo root or a workspace instruction is not production proof. Find the project package configuration, source root and Git remote that represent the application you intend to release.

Pre-flight check

Prepare a Cursor project for a repeatable deployment.

01Locate the real root

Confirm the intended app folder, build or start configuration and repository branch.

02Test production behaviour

Inspect static output, or test a Node HTTP app on a supplied port with its health endpoint.

03Check secrets and integrations

Do not commit credentials. Identify external APIs, forms and data services rather than assuming AI Hosting provides them.

04Commit and deploy

Push the tested project to GitHub, deploy from the Portal and use the release logs as the system record.

Operate the release

Use the preview, logs and domain controls accurately.

Successful releases receive an HTTPS preview URL. Review it before sharing, then attach and verify one custom domain per application in the Portal to use CDN delivery. A preview URL is not automatically a connected custom domain.

Build logs describe static releases; deployment and runtime logs describe supported Node applications. You can publish a correction from GitHub, or queue a previous-version redeployment from a recorded successful Git commit. That is a normal new deployment, not a snapshot, database or environment restore.

Avoid false fixes

Do not turn a runtime requirement into a static retry loop.

A request for a database, a Docker service, a queue, a persistent worker or a non-Node runtime signals a different architecture. A server-driven JavaScript project may still fit only where it meets the documented Node contract.

When a deployment fails, read the first relevant log error, reproduce the issue locally where possible and make one focused GitHub change. See the framework reference for the public compatibility boundary.