How to Deploy a Website with Cursor AI (No GitHub)

Build the project, connect Cursor to Birta through MCP, and ask the agent to publish the finished files. You get a stable live URL without pushing the repository to GitHub or copying a ZIP into another deployment dashboard.

1. Step 1BuildCreate index.html
2. Step 2ConnectAdd and authorize the MCP
3. Step 3DeployPublish and test the live URL

Use Cursor AI to build and deploy a website

Cursor is an AI code editor built on the VS Code interface. Its agent reads a project, creates and edits files, runs terminal commands and inspects errors in the same workspace. That solves the coding part. A local preview at localhost is not a public website: it stops when your machine does, and nobody else has a durable URL.

A landing page, portfolio, documentation site, public menu or browser-only prototype usually fits static hosting. A web application that owns authentication, a database, server-side API routes, background jobs or private secrets does not. If the boundary is unclear, read the static website versus web application test before deploying.

Start by asking Cursor to classify the current project:

Inspect this project without changing it. Decide whether it can run entirely as a static website after a production build. Check the framework, package scripts, server routes, authentication, database code, background jobs, private environment variables, and any local video or PDF assets. End with either "Ready for the Birta static publish workflow" or a specific list of blockers.

Step 1: Build the Cursor website

Birta hosts production output, not the project source and not a development server. Run the production build and note the folder it writes into, dist, build, out, whatever the framework uses. That folder needs index.html at its root with every referenced CSS and JavaScript file beside it, and asset paths have to work from a hosted URL rather than only from your project root. The folder's name means nothing to Birta: what you publish is addressed from the site root.

Do not guess whether the project uses Vite, Astro, plain HTML or React. Let the agent inspect package.json and the framework configuration first:

Prepare this project for a static Birta deployment. Inspect the framework, package scripts, and existing build configuration before editing. Run the correct production build, tell me which folder it writes into, and make sure that folder has index.html at its root. Check routes, internal links, and asset paths as they will work from a hosted URL. Do not publish yet. Report the command you ran, the resulting file tree, and every blocker.

Test the production build locally after the development preview works. A successful npm run dev proves a local server can render the project, not that the built folder can be served as a static website.

Step 2: Connect Birta to Cursor with MCP

Cursor supports Model Context Protocol servers natively. The Birta connection gives the agent a narrow set of tools: listing projects, publishing a version, inspecting version history, rolling back. It gives Birta no access to your editor or repository.

In Cursor, open Settings → Cursor Settings → Tools & MCP, choose New MCP Server, and add this to the mcp.json Cursor opens:

{
  "mcpServers": {
    "birta": {
      "url": "https://birta.dev/mcp"
    }
  }
}

For every Cursor project, use the user-level file at ~/.cursor/mcp.json. To scope the connection to one repository, put the same JSON in .cursor/mcp.json inside it.

Return to Tools & MCP and enable the birta server. The first time Cursor calls a Birta tool your browser opens: sign in with the one-time code sent to your email and allow access. The connection keeps its own OAuth authorization, so there is no API key in source code.

Ask Cursor to list your Birta projects. Names and addresses coming back means the integration is ready. The short Cursor connection guide is the compact reference, Cursor's own MCP documentation covers Streamable HTTP, OAuth and configuration scope, and what MCP actually is is worth reading before the JSON. Cursor can also find this connector itself, by reading the llms.txt file the agent reads first.

Step 3: Deploy the Cursor website to a live URL

Create a Birta project in the dashboard if you do not have one, return to the Cursor workspace holding the built output, and use one explicit prompt so the agent rechecks the folder, shows ambiguous destinations and preserves nested paths.

Use the connected Birta tools to list my projects. Ask me to choose if more than one project could be the destination. Verify that the build folder has index.html at its root. Publish all built files, images and fonts included, to the selected project with the description "Initial Cursor website publish", addressing every path from the site root: index.html at the root and nested files under the same relative paths as in the build folder, without the folder name in front. Return the live URL, version number, preview URL, and every warning exactly as Birta reports them.

Birta validates the package before changing the public site. A missing index page or invalid payload is rejected while the current version stays live. A successful deploy returns the public URL, the preview and the version number.

Test the deployed website, not only Cursor's preview

A website can pass its build and still fail after deployment. Open the live URL in a private browser window so local files, extensions, and signed-in sessions cannot hide a problem.

1. Hard-refresh the home page on desktop and mobile.
2. Open every route and use the navigation, buttons, and forms.
3. Check CSS, JavaScript, images, and fonts for 404 responses.
4. Inspect the browser console and network panel for errors.
5. Search the production files for secrets and private API keys.
6. Confirm that the URL belongs to the intended Birta project.

If an image or font is missing, check the path and filename case first. Those files are published and served like any other asset, so a mismatch there is the usual cause. A missing video or PDF is expected: those are not served from the site and need a public source.

Birta, GitHub Pages, Vercel, Netlify, or app hosting?

There is no single best host for every project made with AI coding tools. Choose from what the built website needs after it leaves your development environment.

• Birta when Cursor already holds a finished static directory and you want the same agent to publish, version and roll it back without a repository handoff.
• GitHub Pages when the project belongs in a public repository and a Git-based static deployment is part of the workflow.
• Vercel or Netlify when you want their framework integrations, preview deployments, build pipeline, functions or repository automation.
• Application hosting when the app needs a server, database, private environment variables, authentication, background work or persistent state.

Do not remove required server behaviour to fit a simpler hosting screen.

Add a custom domain after the first deployment

Publish to the standard Birta address first and verify the site there. Then open the project dashboard, add a root domain such as example.com or a subdomain such as www.example.com, and copy the DNS record Birta shows. The project address keeps working while the custom domain is pending and after it becomes active.

A root domain uses the A record shown in the dashboard, a subdomain the displayed CNAME target. If your DNS provider can proxy the record, disable the proxy during verification. HTTPS becomes available on the active domain without changing the Cursor project. What decides whether this takes two minutes or an afternoon, apex versus www and the proxy that breaks verification, has a page of its own.

Update the website in Cursor and roll back safely

Keep editing the same codebase. After a visible change, review the diff, run the production build again, and publish the built files to the same project with a useful description. Each successful publish becomes a distinct version instead of silently overwriting the live site.

Review the current changes, rebuild the static website, and verify that the build folder has index.html at its root. Check the built output for unexpected files and private values. Publish the built files, addressed from the site root, to the same Birta project with the description "Update: [summarize the visible change]". Return the live URL, new version number, preview URL, and warnings. Then list the latest versions and identify which one is live.

If the update is wrong, ask Cursor to list versions before it changes anything, then select a known-good one and restore it. The newer version stays in history, and the rollback does not touch your local files or Git history.

List the versions of my Birta project and mark the live one. Do not change anything until you show me the choices. After I select a version, roll back to it and return the restored version number and live URL.

A full rebuild is not the only route for a one-line fix: the connected agent can also change a published page in place, editing that one file inside a fresh version.

Cursor deployment troubleshooting

Birta is missing in Tools & MCP

Confirm that mcp.json contains a valid birta entry and the remote URL. Save the file and return to Cursor Settings. If the server appears but is off, enable it instead of creating a duplicate entry.

Authorization never completes

Trigger a Birta tool again, finish the one-time email sign-in in the browser, and allow access. Do not put an email code, access token, or invented API key into the repository.

The deployment has no index page

The published site has no index.html at its root. Inspect the framework output directory, rebuild from the project root, and publish its files with the paths taken from that folder rather than with the folder name in front of them.

The production build expects a server

A route, API, database, or runtime environment variable is still required after the build. Choose an application host; suppressing the error does not make the architecture static.

The live page is blank or unstyled

Check the browser console, base path, asset URLs, and filename case. Make sure the build references files inside the build folder and does not point to localhost, the source folder, or an absolute path on your computer.

Cursor selected the wrong project

Stop before publishing. Ask the agent to list projects with their names and addresses, then name the exact destination. Never infer the deployment target from a similar project name.

Frequently asked questions