CURSOR HOSTING
Cursor hosting: you built it, now put it somewhere
Cursor is an editor, so there is no export step and no Cursor-shaped output. What you have is a project on your own machine. Build it, upload the folder that appears, and it is live at an HTTPS address without you configuring a deploy for it.
Free plan, free SSL, no credit card.
- 23
- framework guides, one per build command
- 0
- pipelines to configure before the first publish
- 1
- free site with HTTPS, no card
- 25
- publishes a day on the free plan
What you are holding
What Cursor outputs
Your project. Cursor is a code editor with an agent in it, not a generator with a house stack, so there is nothing Cursor-shaped about the result. Whatever framework you chose is the framework you have, and its build is the build that matters.
That makes this page shorter in one respect and more useful in another. There is no export menu to describe, because the code never left your machine. What is worth writing down is the part people actually get wrong: which folder to upload. A build writes its output somewhere specific, and uploading the project folder instead produces a page that is broken rather than merely unstyled, because the browser is handed TypeScript and bare module imports it cannot execute.
The other half of the answer is which projects cannot be published as files at all. If the agent scaffolded a Next.js app with route handlers, a Remix app, or anything with a server in it, only the static half can be served here. That is not a limitation of the upload; it is what static hosting is. The export guide lists which frameworks can be switched to a static build and how.
The fork
Which of the two paths you are on
Open the project. The presence of a build script is the whole question.
Already static, no build
A folder of HTML, CSS, JavaScript and images, with an index.html at the root. Plenty of things built in an editor are exactly this.
- Upload the folder directly, or zip its contents with
index.htmlat the top level. - A single self-contained page can be dropped on its own with nothing around it.
- A single
.jsxor.tsxworks too, transformed in the visitor browser with no build. - Up to 25 MB per upload on the free plan, 25 MB across the account.
A project, build it first
There is a package.json with a build script. Run it, then upload the folder it wrote, not the one you ran it in.
- Vite, Astro and Vue write to
dist. - Create React App and Docusaurus write to
build. - Next.js with a static export writes to
out; Gatsby writes topublic. - The deploy guides name the exact command and folder for 23 frameworks.
Step by step
From a Cursor project to a live address
There is no export step, because there is nothing to export from. These are the five things between a finished project and a URL.
-
Confirm the project is static
Look for server code: route handlers, an API folder, anything that listens on a port. If the app needs it at runtime, that half cannot be published as files by anyone.
-
Run the build
Run
npm installif you have not, thennpm run build. Cursor's terminal is as good a place as any to do it. -
Find the output folder
It is the folder the build just created, not the one you ran the command in. If it contains a
package.json, it is the wrong folder. -
Upload it
Drop the folder here, or zip its contents with
index.htmlat the top level. Pick a name and the site is live over HTTPS. -
Turn on the SPA switch if the app routes in the browser
React Router, Vue Router and their equivalents need unknown paths served the root
index.html. The Single-page app switch in the site settings does that, on every plan, without a redeploy.
This page makes no claim about Cursor's menus, because publishing a project built in an editor does not involve any. The build commands and output folders above are the ones this site documents per framework in its own deploy guides, which read their advice from the same detector the upload pipeline uses, so a guide and a failed deploy cannot contradict each other. The one claim about Cursor itself, that it uses Open VSX rather than the Visual Studio Marketplace and that not every Marketplace extension is listed there, is from Cursor's own extensions documentation at cursor.com/docs/configuration/extensions. All read 8 September 2026.
Who it is for
The people who reach for this
-
Developers
The reason this page exists: a finished build at a URL without adding a deploy target, a config file or a CI job for it.
-
Designers who write code
A front end you actually built, on a real device at a real address, rather than screen-shared from localhost.
-
Solo builders
The project works. What is missing is the boring part, and the boring part should take one upload.
-
Students
Coursework at a permanent link you can put on an application, with no platform account for whoever opens it.
In detail
What you actually get
Publishing without a pipeline
The whole proposition for someone who already has a terminal open: no repository to connect, no build settings to fill in, no environment to provision.
- Upload the folder or a ZIP of it. Both are first-class.
- Nothing is installed on our side and nothing you upload is executed on our infrastructure.
- A public API and a VS Code extension exist for when you would rather not use a browser.
- The extension is published on the Visual Studio Marketplace. Cursor uses the Open VSX registry instead, so it does not appear in Cursor's extension search today.
The same address across every rebuild
An agent-assisted project changes quickly. The URL belongs to the site rather than to the upload, so iteration does not generate links.
- Up to 25 publishes a day on the free plan.
- From Pro, returning to the version that worked is one click.
- The swap is atomic, so a visitor never sees a half-published page.
- Expiring links from Starter, when a preview should not outlive the review.
Controls a localhost preview does not have
Once it is at an address it can be shared properly, which usually means limiting who sees it.
- Password protection from Starter, checked at the edge before any file is served.
- Visitor analytics from Pro.
- Custom domains from Pro, $15 a month.
- HTTPS with a real certificate, issued and renewed for you.
Troubleshooting
What breaks, and why
Two of these are specific to publishing a project you built yourself rather than one a generator handed you.
-
The uploaded site shows a directory listing, or raw code
Why You uploaded the project folder instead of the build output. The browser is being handed
src/main.tsxand apackage.json, neither of which is a web page.Fix Run the build, then upload the folder it created. If what you uploaded contains a
package.json, it is the wrong folder. The export guide lists the output folder per framework. -
It works on localhost and 404s everywhere once published
Why Your dev server rewrites unknown paths to the app automatically. A static host does not, because a multi-page site should return real 404s. So the routing that worked in development stops working the moment it is a set of files.
Fix Turn on the Single-page app switch in the site settings. It applies to the live site with no redeploy and costs nothing on any plan.
-
Every route except the home page returns a 404
Why The app routes in the browser, so /about exists only once JavaScript has run. A static host asked for /about looks for a file at that path, does not find one, and answers 404 before your code loads.
Fix Turn on the Single-page app switch in the site settings. Unknown paths are then served the root index.html and the client router takes over. Free on every plan, applied without a redeploy, and off by default because a multi-page site wants real 404s.
-
The API keys the tool wrote into the code are now public
Why AI tools fill in the value they can see, and a key in front-end code is readable by anyone who opens the page. No host can fix that: a published page is public by definition.
Fix The deploy-time security check names the key it found. Rotate it, then move the call behind something that can hold a secret. Every plan, free included, and it never blocks the publish.
No card required
What the free plan includes
Nothing about publishing a build costs anything until you want a domain on it, which is the order those things should happen in.
- 1 live site on a real free plan, not a trial of a paid one, with HTTPS and no card to start.
- Up to 25 MB per upload and 25 MB of storage across the account.
- 5,000 visits and 5 GB of traffic a month.
- Up to 25 publishes a day, which is the number that matters when you are regenerating.
- The Single-page app switch, so a client-routed build works without paying for anything.
- The deploy-time security check, which warns about a stray .env file, a .git folder, a private key or an API key left in your JavaScript.
- A small Droply badge in the corner of the page. Removing it starts on Starter.
- Free sites are served noindex, so search engines do not list them. Search visibility starts on Starter.
Droply vs Static.app
How this compares with the other host built for AI output
Static.app has a Cursor page of its own. These rows come from its published pricing and its own documentation.
| Droply | Static.app | |
|---|---|---|
| Upload a build folder | Yes, directly, no archive required. | ZIP is the documented path. |
| Public API and editor extension | Both. The VS Code extension signs in with email and works on every plan; raw API tokens are a paid feature. | An API is listed among its features. |
| Client-side routing | One free Single-page app switch, applied live with no redeploy. | Not documented as a per-site setting. |
| Rollback to an earlier build | From Pro, one click. | Backups are listed as a feature page. |
| Loose .html file accepted | Yes, dropped on its own with nothing around it. | No. Its Claude page states a loose .html file is not accepted and must be zipped. |
| Single .jsx or .tsx without a build | Yes. It is transformed in the visitor browser at the published address. | No. Its Claude page says React-based artifacts need a self-contained HTML version first. |
| Free plan | 1 site, 25 MB storage, no card, and a plan rather than a trial. | A 7-day trial with no credit card, then paid. 1 site and 50 MB during it. |
| Security check on every publish | Every plan, free included: leaked keys, a stray .env, a committed .git folder. | Not offered. |
Static.app figures checked 8 September 2026 on its own pricing page (free tier: 1 site, 50 MB, a 7-day trial with no credit card; Starter $5 a month or $60 a year for 2 sites and 500 MB with a custom domain; Medium $10; Large $15) and on its Claude hosting page, which states that a loose .html file is not accepted and must be zipped, that React-based artifacts need an extra step because you have to ask the model for a self-contained HTML version, and that Import from URL takes claude.ai and claude.site links. Product plans can change.
When Droply is the wrong choice
Somebody working in Cursor is more likely than most readers to be building the kind of application this cannot host, so it is worth being blunt about it.
- The app has API routes, server-side rendering on every request, or a database. Only the static half of it can be served here.
- You want a deploy on every push. There is no Git integration and no CI: this is a place to put a build, not a pipeline to run one.
- The generated app has a database, a login screen or server actions. Those need a runtime; only the static half of it can be published here.
- You want a build to run here, on upload or on every push. There is no build step and no Git integration: you build locally and bring the output.
- You are running WordPress or another PHP application. A static export of it can be hosted here, but the application itself cannot.