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

Build the project into dist/, connect Cursor to Wibe 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 dist/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 familiar VS Code interface. In web development, its agent can read a project, create and edit files, run terminal commands, inspect errors, and improve the result in the same workspace. That solves the coding part. A local preview at localhost still is not a public website: it stops when your computer or development server stops, and nobody else has a durable URL.

You can use Cursor Chat and clear natural-language prompts to scaffold a React app, generate code, write tests, or debug an existing codebase. That makes Cursor useful to people with different levels of coding experience. It does not make every app with Cursor automatically secure, production-ready, or compatible with static hosting. AI tools accelerate the work; the deployment architecture still follows the software.

A landing page, portfolio, documentation site, public menu, or browser-only prototype is often a good fit for static hosting. A web application that owns authentication, a database, server-side API routes, background jobs, or private secrets is not. Read the static website versus web application test before you deploy if the boundary is unclear.

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 local binary assets. End with either "Ready for the Wibe static publish workflow" or a specific list of blockers.

Step 1: Build the Cursor website into dist/

Wibe hosts production output, not the Cursor project source and not a development server. The final directory needs dist/index.html as its entry point. Every referenced CSS and JavaScript file must sit below dist/, and asset paths must work from a hosted URL rather than only from the project root on your computer.

Do not guess whether the project uses Vite, Astro, plain HTML, React, or another framework. Let the agent inspect package.json, the build scripts, and the framework configuration before it changes anything:

Prepare this project for a static Wibe deployment. Inspect the framework, package scripts, and existing build configuration before editing. Run the correct production build and make the final browser output available under dist/ with dist/index.html present. 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 only that a local server can render the project. It does not prove that the built folder can be served as a static website.

Step 2: Connect Wibe to Cursor with MCP

Cursor has built-in support for Model Context Protocol servers. The Wibe connection gives the agent a narrow set of tools for listing projects, publishing a version, inspecting version history, and rolling back. It does not give Wibe general access to your editor or repository.

In Cursor, open Settings → Cursor Settings → Tools & MCP, then choose New MCP Server. Cursor opens mcp.json. Add this configuration and save the file:

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

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

Return to Tools & MCP and enable the wibe server. The first time Cursor calls a Wibe 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 to paste into source code.

Ask Cursor to list your Wibe projects. If it returns the names and addresses, the integration is ready. The short Cursor connection guide remains the compact setup reference. Cursor's official MCP documentation documents Streamable HTTP, OAuth, project and global configuration, and how the agent uses available tools.

Step 3: Deploy the Cursor website to a live URL

Create a Wibe project in the dashboard if you do not already have one. Return to the Cursor workspace that contains the built output. Use one explicit prompt so the agent rechecks the folder, shows ambiguous destinations, and preserves nested paths.

Use the connected Wibe tools to list my projects. Ask me to choose if more than one project could be the destination. Verify that dist/index.html exists and that every file you send is text. Publish all text files under dist/ to the selected project with the description "Initial Cursor website publish". Keep nested paths intact. Return the live URL, version number, preview URL, and every warning exactly as Wibe reports them.

Wibe validates the deployment 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, preview, and recorded 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 Wibe project.

If an image or font is missing, check the path and filename case first. If the missing asset is a local PNG, JPEG, WebP, PDF, WOFF, or WOFF2 binary, give it a public source or use another supported upload path. Repeating the text-only publish will not transfer the binary.

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

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

• Use Wibe 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.
• Use GitHub Pages when the project belongs in a public GitHub repository and a Git-based static deployment is part of the desired workflow.
• Use Vercel or Netlify when you want their framework integrations, preview deployments, build pipeline, functions, or repository-based automation.
• Use application hosting when the Cursor app needs a server, database, private environment variables, authentication, background work, or persistent state. This may be a managed platform, an AWS service, or a VPS that you operate.

Do not remove required server behavior just to fit a simpler hosting screen. Static deployment is the right architecture for a static website, not a workaround for a full-stack application.

Add a custom domain after the first deployment

Publish to the standard Wibe address first and verify the live website 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 Wibe shows. The project address continues to work while the custom domain is pending and after it becomes active.

A root domain uses the A record shown in the dashboard. A subdomain uses the displayed CNAME target. If your DNS provider can proxy the record, disable the proxy during verification so the domain points directly to Wibe. HTTPS becomes available on the active domain without changing the Cursor project.

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 dist/ to the same project with a useful description. Each successful publish becomes a distinct version instead of silently overwriting the only copy of the live site.

Review the current changes, rebuild the static website, and verify dist/index.html. Check the built output for unexpected files and private values. Publish dist/ to the same Wibe 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. Select a known-good version and restore it. The newer version remains in history, and the rollback does not rewrite your local files or Git history.

List the versions of my Wibe 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.

Cursor deployment troubleshooting

Wibe is missing in Tools & MCP

Confirm that mcp.json contains a valid wibe 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 Wibe 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 payload does not contain dist/index.html. Inspect the framework output directory, rebuild from the project root, and put the finished static files under dist/ without an extra nested folder.

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 dist/ 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