Find the website's package.json, source and build configuration. In a monorepo, confirm the intended app rather than a shared package.
Cursor guide
How to host a Cursor website.
Cursor can make it quick to build or revise a website, but a workspace can contain more than one project. This guide helps you find the publishable static site, verify its output and publish it from GitHub through Host Luma.
Start with the workspace
Make sure you are hosting the website, not the wrong folder.
A Cursor workspace may open a parent directory, a monorepo, a starter project and generated files together. Before publishing, identify the folder that contains the actual website source and its production build configuration. Check its Git remote and branch rather than assuming the folder currently open in the editor is ready.
Host Luma's public AI Hosting workflow publishes supported static output. It is a fit for a finished website that can run as files in a browser. It is not a runtime for a custom Node process, PHP application, database, Docker service, background worker or server-side rendering.
Pre-flight check
Prepare a Cursor website for a clean deployment.
Review changes and make sure the branch contains the version you intend to publish. Do not treat unsaved editor state as a release.
Use the project's normal build command and inspect the generated files. A development preview can hide static-output and asset-path issues.
Open the built site, follow key links and check images, forms and browser-side integrations before publishing.
Commit the verified source so the publishing workflow has one visible, repeatable source of truth.
Publish from GitHub
Use one connected workflow for each release.
Create an AI Hosting project, select the GitHub repository and choose the branch that contains the website you tested. A successful supported static build receives a permanent HTTPS preview URL. Use that URL to review the public result and the deployment record before sharing it more widely.
For revisions, keep working in Cursor but commit the chosen changes to GitHub before publishing. This keeps the source history, build output and deployment result understandable for you, a teammate or support.
Avoid false fixes
Do not solve a static-build issue by adding server work.
If a Cursor-generated project fails, look at the first relevant build error and reproduce the production build locally. Typical fixes are in the project: an output folder, dependency, base path or static-export setting. The framework guide shows which common project types fit the current workflow.
A request for an API server, protected environment value or database is not a reason to keep retrying a static deployment. It means the architecture needs a different hosting model. Identifying that early is faster and safer than adding manual server changes.
Related guides