You can now describe an internal tool in plain English inside Cursor, let a cloud agent build it, and share a live link with teammates — without standing up hosting yourself. On November 5, 2026 Cursor launched Build Live Apps: a cloud agent scaffolds the web app, can spin up a Postgres database, puts private apps behind Cursor sign-in, runs security checks, and deploys only after you publish. This guide is for people who already use Cursor (or are about to) and want a working dashboard, signup form, or ops portal today — not for writing deployment scripts by hand.

Nothing below requires you to write application code. Optional API-key examples for scripts sit in a short appendix.

Last checked: November 6, 2026 (Asia/Shanghai), against Cursor’s Build Live Apps changelog, the Apps docs, Cloud Agents overview, and Models & Pricing. Menu names and plan bundles change; those pages are the source of truth.

The short version

• What it is: Cloud Agents can build a working web app (dashboard, portal, microsite). You describe what you want; Cursor handles hosting, database, auth and secrets (Apps docs).
• Who can use it: Apps is available on all paid plans that have Cloud Agents. Cursor’s Cloud Agents troubleshooting page says Free and Plus do not include Cloud Agents; you need Premium and higher, Teams, Enterprise, or a legacy paid plan that still has them. On current X Subscription pricing, Plus explicitly lists no Cloud Agents; Premium adds them (Models & Pricing).
• Must be a cloud agent: The Apps docs say this feature is not supported locally. Start a cloud agent and say explicitly that you want to build an app.
• Repos: Cursor Origin (new repo from scratch) or an existing GitHub repo. The changelog says GitLab support for deploying apps is coming soon.
• Nothing goes live until you publish: Preview first. Publish picks a URL, runs checks, then returns a live link only if checks pass and you confirm.
• Sharing: Invite specific people/groups, whole team (behind Cursor sign-in), or — on individual plans — public. Public sharing is off by default for Teams and Enterprise until an admin enables it.

What kinds of apps Cursor says people are building

The changelog lists internal examples Cursor’s own teams use:

• Ops tools for event registration, account assignments and desk seating
• Multimedia presentations that mix slides, video and interactive demos
• Training, enablement and onboarding for new hires
• Live sales dashboards for pipeline and opportunities
• Portals that manage engineering services

If your need looks like “a small web tool my team opens in a browser,” this release is aimed at you. If you only need a one-off script or a pull request into an existing product, a normal cloud agent (or another coding agent) may be a better fit — see also our guide to Replit Cloud Agents on a company codebase for a PR-oriented workflow.

Before you start: checklist

1. Confirm your plan includes Cloud Agents. In Cursor desktop, open the agent input and look for Cloud in the dropdown. Or open cursor.com/agents on the web. If Cloud Agents are missing, you are likely on Free or Plus — upgrade to Premium or higher (or use a Teams/Enterprise/legacy paid seat that still includes them).
2. Update Cursor if you use the desktop app. The changelog says to update to try Apps.
3. Connect source control if you will deploy an existing repo. A Cursor account admin must connect GitHub (or another supported provider) before anyone can start a cloud agent from a repository. To start without a repository, use Start from scratch, which creates a new repo on Cursor Origin.
4. Know who should see the app. Decide invite-only, whole team, or public (individual plans / admin-enabled Teams) before you publish.
5. Have secrets ready off-screen. If the app needs a warehouse key or API token, a team admin usually creates team secrets in the Apps dashboard. The agent is prompted for secrets and never sees the values (Apps docs).
6. Expect usage cost. Cloud Agents draw from your plan’s usage (and may ask you to set a spend limit the first time you use them). Building and iterating an app is agent work, not a free hosting promo.

Step-by-step: build and publish your first live app

These steps follow Cursor’s Apps docs and changelog. Exact button labels can move; if yours differ, trust the docs page.

1. Start a cloud agent (not a local one)

Pick any of the access paths Cursor documents:

1. Cursor Desktop: under the agent input, choose Cloud.
2. Cursor Web: go to cursor.com/agents.
3. Cursor iOS app, Slack (@cursor), GitHub/Bitbucket comment (@cursor), Linear, or the Cloud Agents API.

On Android, Cursor points you to cursor.com/agents in Chrome (installable as a PWA). Local Agent mode will not publish Apps — the docs are explicit that Apps need a cloud agent.

2. Tell it you want an app — be explicit

Cursor’s getting-started note: be explicit that you want Cursor to build an app. Sample prompts from the docs (copy and adapt):

• “Build an app that shows our weekly signups as a dashboard, with a chart and a table I can filter by plan.”
• “Build an internal app where my team can submit bug reports and track their status.”
• “Build a microsite for our product launch with a sign-up form that collects emails.”
• “Deploy this repo as an app.”

Prompt tips that save a round trip:

• Say who the app is for (only me, my sales team, the whole company).
• Say whether you need a database (forms, status tracking, signup lists usually do).
• Say Start from scratch vs use this GitHub repo.
• Avoid dumping secrets into the chat. When Cursor asks for a secret, use the secrets UI so the agent never sees the value.

3. Watch the tray: preview before publish

When the agent has prepared the app, Cursor shows a tray where you can preview and then publish. Use preview to click through the happy path yourself. If something is wrong, reply in the agent thread (“make the filter default to this month”, “add a CSV export”) instead of publishing.

4. Publish: pick a URL and pass security checks

When you publish:

1. You pick a unique domain (you can change it later).
2. Cursor runs deterministic and agentic security checks.
3. If checks pass, you get a live link.
4. If checks fail, the agent lists what to fix. Tell it to fix those issues, then publish again.

The changelog and docs both stress: nothing goes live until the checks pass and you explicitly publish.

5. Share the link the way your plan allows

Visibility	Who can open it (per Apps docs)
People you invite	Only you or specific team members and groups signed into Cursor
Team	You and your entire Cursor team, signed in
Public	Anyone with the link

Public sharing is disabled by default for Teams and Enterprise. A team admin can turn it on in the Apps dashboard. On individual plans, you can share apps publicly; public apps do not require Cursor auth.

What Cursor provisions for you

From the Apps docs “How it works” section:

• Hosting. Each app lands in a dedicated hosting account Cursor creates for your team (or for you on an individual plan). Accounts are isolated from other teams and users.
• Database. If the app needs one, Cursor provisions Postgres automatically.
• Auth. Private and team apps sit behind Cursor sign-in. Public apps on individual plans skip that gate.
• Secrets. For your own resources (for example a data warehouse), Cursor prompts for secrets. Prefer team secrets created by an admin in the Apps dashboard; personal secrets are available if your account allows them.

You can configure secrets and keys while building or later in the Apps dashboard. Bring-your-own integrations are supported the same way.

Security checks you should expect (and not try to bypass)

Four checks run before every publish, even if the broader AI security review is turned off:

1. Block secrets written in app files — stops publish if a file contains an API key or access token.
2. Block credential files — private keys, service-account keys, files with auth tokens.
3. Never publish .env files — .env is left out of what ships.
4. Never publish source maps — visitors can’t read original source from maps.

On top of those, an AI security review reads the app’s files and can block serious issues. Team admins can add custom instructions to that review in the Apps dashboard. Custom rules can add requirements; they cannot remove Cursor’s built-in checks.

Team admins can also:

• Turn Apps on or off for the team
• Allow or disallow public apps (disallowing moves existing public apps back to team visibility)
• Allow or disallow API keys opening apps
• Approve publishes the review blocked — except for malicious code, hardcoded secrets, or exposed credentials
• See every app and secret on the team and unpublish any app

Setting changes are recorded in the team’s audit log. If a publish is blocked for a hardcoded secret, fix the app — don’t ask an admin to rubber-stamp it.

Gotchas that trip people up

You used a local agent. Apps are cloud-only. Switch the dropdown to Cloud (or use cursor.com/agents) and start again.

You’re on Plus or Free. Cloud Agents (and therefore Apps) are not on those tiers per Cursor’s Cloud Agents troubleshooting and current pricing pages. Premium is the first individual tier that lists Cloud Agents.

GitLab repo. Changelog: deploy from new or existing repos on Cursor Origin and GitHub; GitLab is coming soon. Until then, mirror to GitHub or start from scratch on Origin.

You pasted an API key into the prompt. Prefer the secrets flow. Built-in checks will block shipping keys that landed in files; cleaning chat history is separate from cleaning the repo.

Teammates can’t open the app. Private/team apps need Cursor sign-in and the right share setting. Confirm invite vs team vs public. For viewing cloud agent runs (not the published app), Cursor also requires the teammate to be on the same team and to have repository access — different gate than Apps sharing.

Public link on a Team plan does nothing useful. Public is off by default for Teams/Enterprise until an admin enables it.

Agent “can’t start”. Cloud Agents docs troubleshooting: log in, connect GitHub/GitLab/Azure DevOps/Bitbucket with the right repo permissions, and use a plan that includes Cloud Agents. New secrets apply to new agents only — restart after adding secrets.

Hosting is not a Cursor product guarantee. Cursor’s Apps page states hosting is separate from its services, provided “as is” and “as available,” and that subdomains or published apps may be revoked for policy or business reasons. Treat Apps as a fast internal/shareable tool lane, not permanent production hosting with an SLA spelled out there.

How this compares to nearby tools

Need	Cursor Apps (this guide)	Replit Cloud Agents	Claude Code in the cloud
Primary outcome	Live web app URL with hosting/DB/auth	Pull request into your company repo	Agent work / PRs in Claude’s cloud flow
Best when	Ops dashboard, portal, microsite for your Cursor org	Change an existing product codebase	You already live in Claude Code
Auth for viewers	Cursor SSO for private/team apps	N/A (you deploy elsewhere)	N/A
Our deeper guide	this page	Replit Cloud Agents	Claude Code in the cloud

Cursor remains an IDE-first agent product (Composer 2.5 still matters for day-to-day coding). Apps is the path when the deliverable is a shareable web tool, not a diff. If you mainly wire ChatGPT, Claude and Cursor into automations, see IFTTT with Claude, ChatGPT and Cursor.

Suggested first projects (copy these briefs)

Use these as first prompts if you are stuck:

1. Team PTO calendar: “Build an internal app where teammates submit PTO requests with start/end dates and a manager dropdown. Store them in a database. Only our Cursor team can open it. Show a simple calendar and a table I can filter by person.”
2. Launch waitlist: “Build a public microsite for our product launch with an email signup form, store emails in Postgres, and show me an admin page only I can open that lists signups.” (Public needs an individual plan or a Team admin who enabled public apps.)
3. Bug inbox: “Build an internal app where my team submits bug reports with severity and screenshot URL fields, tracks status (new / in progress / done), and lets me filter by severity.”
4. Deploy existing marketing site repo: “Deploy this GitHub repo as an app” — only after the repo is connected and you have confirmed it should be public or team-visible.

Start with one narrow tool. Publish, share with one teammate, then iterate. Large “rebuild our CRM” prompts burn usage and fail security review more often.

Troubleshooting and FAQ

I don’t see Apps or a publish tray. Confirm you started a cloud agent, your plan includes Cloud Agents, and you explicitly asked to build an app (or deploy a repo as an app). Update the desktop app.

Publish keeps failing on secrets. Remove keys from source files, store them as Apps dashboard secrets, ask the agent to read from secrets instead of hardcoding, then publish again. Admins cannot approve publishes blocked for hardcoded secrets or exposed credentials.

Can I change the URL later? Yes. The Apps docs say you pick the app’s URL when publishing and can change it later.

Do viewers need Cursor seats? For private and team apps, yes — they must be signed into Cursor and included in the share settings. Public apps (when allowed) open for anyone with the link.

How do scripts or Grok Bot call a private app? Use a Cursor API key in the x-cursor-app-token header (see appendix). Query parameters and cookies are not supported for the key.

Does this replace Vercel/Netlify for production? Cursor does not claim that in the Apps docs. Use Apps for internal tools and lightweight shareable sites; keep mission-critical production on the host your team already runs with proper SLAs.

Is it free with my Plus plan? No. Plus does not include Cloud Agents on the current pricing page.

Appendix (optional): API keys for scripts and Grok Bot

You can skip this if you only share apps with people in a browser.

Private and team apps sit behind Cursor sign-in, which automated tools cannot complete. Cursor lets you provision an API key so Grok Bot, scripts or CI can use an app the way a signed-in user would:

• Personal API keys open the apps their owner can open.
• Team API keys open only the team apps they’ve been given access to.
• Public apps open for either key the same way they would for a visitor.

Send the key on every request as a header (not a query param or cookie):

curl -H "x-cursor-app-token: $CURSOR_API_KEY" https://<your-app-url>

Requests made with a key are marked as automated and identify the key, never a person. Manage keys in the Apps dashboard. Team admins can disallow API keys from opening apps entirely.

Sources

• Cursor Changelog: Build Live Apps in Cursor (November 5, 2026)
• Cursor Docs: Apps
• Cursor Docs: Cloud Agents
• Cursor Docs: Models & Pricing

More guides on the 7minai homepage.