I’m building a real business site (676 pages, Stripe, PDFs) with Cursor. After three full days, the site still isn’t live. The product is strong at writing code, but the deployment workflow is brutal for non-developers.
I had to manually sign up for Cloudflare, authorize GitHub, create a repository, install GitHub Desktop because Git isn’t available in the terminal, delete and recreate the repository, publish, and then go back to Cloudflare — all steps were taken one click at a time with the agent.
For a “top-tier” dev tool, there’s no good reason the agent shouldn’t be able to connect to GitHub, Cloudflare, and Stripe (with my approval) and handle this tedious work. The current flow consumes days per project. I can’t spend 3–7 days on setup for every small project. That’s a subscription decision for me: if the tool can’t shorten end-to-end time to live, not just time to code, the cost becomes questionable because it’s not just money I’m spending.
Hey, thanks for the detailed feedback. Your request is clear: you want an agent that, with your approval, can connect to GitHub, Cloudflare, Stripe, and handle the whole deploy flow, instead of sending you through dozens of manual clicks. That makes sense. I’ll move this thread to Feature Requests so it reaches the right team and can collect votes. There are also a couple related deploy threads where you can add a vote or extra details: Deployments support in Cursor and Request for Cursor to Support Remotely Hosted Deployments.
For now, you can already cut down some of the steps:
Git in the terminal: Cursor uses your system git, it doesn’t ship its own. Install git on your machine on Windows, use Git for Windows. After a restart, git will be available in the terminal, and you won’t need GitHub Desktop.
Deploy via CLI with auto-run: the agent can run CLIs like wrangler for Cloudflare, gh for GitHub, and stripe right in the terminal. You log in once wrangler login, gh auth login, then the agent can do push and deploy for you if you enable terminal auto-run.
What still can’t be automated is the initial signup and first-time auth for new third-party accounts. That requires manual OAuth or login on your side for security reasons.
Let me know how it goes with git and the CLI, it should remove a good chunk of the routine.
The “with my approval” part seems like the key distinction here. I would not want an agent to hold broad, long-lived GitHub/Cloudflare/Stripe credentials, but I do want it to get much closer to “prepare the deploy, show me the exact actions, I approve, then produce a revocable preview/live URL.”
I’m trying to understand where people draw the line: is one-time CLI auth + agent-run commands enough, or do you specifically need a safer handoff layer around deploys — TTLs, spend/request limits, audit log, and easy revoke — before you’d trust this for repeated small projects?
Hey, good clarification. “With my approval” really is the key part here, and the line is pretty much where you drew it.
Today we already have pieces of this:
Auth is done once via the service CLI itself wrangler login, gh auth login. The agent does not store or create long-lived creds. It works on top of the session you already granted, which is stored by the CLI tool itself, not Cursor.
Important security note specifically for deploys: Cursor allowlist and autoRun are meant as best-effort convenience, not a security guarantee, and the docs say that. Also, Run Everything bypasses all screening. So they are great UX controls to reduce routine work, but you should not treat them as a hard security boundary around deploys.
What you describe next, TTL, spend or request limits, audit log, easy revoke focused on deploys as a separate safer handoff layer, is not available as one unified layer yet. There is an FR looking in that direction for more granular approval options: Granular approval options for terminal commands and MCP tool calls. It makes sense to upvote it and add concrete scenarios, especially TTL, revoke, and audit as clear requirements.
So the answer to “is one-time CLI auth enough” is: for one-off projects it is enough for many users, but for repeat small deploys, a revocable, scoped, auditable handoff is what is missing. It is a votable direction, not a closed question.
This is where “agentic coding” stops being only a code generation problem.
For real projects, time to live includes repo setup, GitHub permissions, environment variables, deploy targets, billing setup, and rollback paths. Even if first time OAuth must stay manual, the agent should be able to turn the rest into a repeatable checklist or runbook instead of making the user rediscover it project by project.
Hey, good call. Runbook instead of reopening the same problem on every project is exactly the gap that hurts the most.
Some of this can already be set up today, without waiting for a turnkey flow:
Skills SKILL.md You can write your deploy runbook once: push to deploy steps, required env vars, deploy targets, rollback path, and the agent will reuse it across projects. This is the repeatable checklist you mean. More details: Agent Skills | Cursor Docs
Project rules .cursor/rules For repo specific conventions like always deploy via wrangler with these flags so you do not have to explain it again. Rules | Cursor Docs
What is still missing as a single layer is a unified safe handoff around deploys: scoped and revocable access, audit logs, limits. That came up above. It is a votable direction, and there is a feature request here: Granular approval options for terminal commands and MCP tool calls It is worth upvoting and adding concrete details about runbook and rollback as requirements.
So first time OAuth is still manual for security reasons, but everything else is already pretty workable with Skills plus rules. Try it and let me know how much it covers your case. That will help clarify what is actually missing in the feature request.