How to Set Up Cursor for a Production Codebase

Most guides show you how to set up Cursor by opening a toy project and watching it autocomplete a function. That is not the hard part. The hard part is making Cursor useful, safe and affordable inside a real production codebase, where there are hundreds of thousands of lines, conventions the model has never seen, secrets it must never read, and a main branch that real users depend on. This guide walks through that setup end to end.

Cursor is an AI-first IDE from Anysphere, a fork of VS Code rebuilt around the model. Out of the box it will edit anything you point it at. To run Cursor for a production codebase you have to give it context, constrain its spending, and put humans back in the loop before its changes ship. The steps below assume you are a developer joining an existing project, not someone starting from a blank file.

Step 1: Install Cursor and import your VS Code setup

Download Cursor from the official site and run the installer for your platform. On first launch it asks whether you want to bring over your existing VS Code configuration, and you should say yes. It imports your extensions, themes, keybindings and settings in one pass, so the editor feels familiar from the first minute.

Almost everything you rely on in VS Code keeps working: your linter, your formatter, your debugger, your language servers. Sign in so usage and rules sync, then open your real repository rather than a scratch folder. Resist the urge to start typing prompts immediately. The setup that follows is what separates a useful assistant from one that confidently rewrites code it does not understand.

Step 2: Index your codebase and set context

When you open a repository, Cursor begins indexing it. Indexing builds a searchable map of your files so the model can retrieve relevant code instead of guessing. Let it finish before you lean on the agent for anything substantial. On a large monorepo the first pass can take a few minutes, and the status appears in the indexing settings.

Indexing respects your .gitignore, so build artifacts and dependencies that are already ignored stay out. For day-to-day work, get specific about context rather than hoping the model finds the right files. You can reference a particular file or folder directly in chat so the agent reasons over the code that actually matters, which also keeps requests cheaper and more accurate. On a sprawling codebase, a tightly scoped question about three files beats a vague question about the whole tree every time.

If your team works across several repositories, index each one as you open it. Cursor's retrieval is only as good as what it has mapped, and pointing it at the right slice of the codebase is a major lever on output quality.

Step 3: Write project rules

Rules are where a production setup earns its keep. A rule is a plain-text instruction that travels with every request, so you stop re-explaining your stack in each chat. Cursor supports two formats. The current approach uses the .cursor/rules directory, where you can keep several focused files. The older single-file format is a .cursorrules file in the repository root, which still works if you prefer one place for everything.

Write rules the way you would brief a competent new hire. Name the framework and version, the language conventions, how you structure folders, which testing library you use and how you expect tests to be written. Spell out the things the model gets wrong on your project: maybe it keeps reaching for a deprecated API, or formatting imports the wrong way, or inventing helper functions that already exist. Each correction you turn into a rule is a mistake you never have to fix by hand again.

Keep rules concrete and short. A rule that says "follow best practices" tells the model nothing. A rule that says to use the existing API client in a named module, never call fetch directly, and colocate tests next to the file under test will actually change the output. Good rules are the highest-leverage thing in this whole guide, which is why they top the list of Cursor best practices we cover in our full review.

Step 4: Match models to tasks to control cost

Cursor runs on a usage-credit model, and this is where production teams either save money or burn it. The Pro plan is $20 a month and includes roughly $20 of agent usage. Tab completion is unlimited, but the agent draws down credits, and frontier models cost far more per request than cheaper ones. A heavy agent user on top-tier models can blow past the included quota quickly, which pushes them toward Pro+ at $60 a month or Ultra at $200.

The fix is not to buy a bigger plan reflexively. It is to match the model to the task. Reach for a cheaper, faster model for boilerplate, mechanical refactors, renaming, test scaffolding and anything where the answer is obvious. Save the frontier models for genuinely hard reasoning: tricky concurrency bugs, a subtle architectural decision, untangling code nobody understands anymore. Most of what a developer does in a day does not need the most expensive model in the menu.

Watch the usage meter for your first couple of weeks so you learn what your real spend looks like, then size your plan to that. The economics of metered AI tooling are reshaping the market, a shift we unpack alongside Cursor's $2B ARR milestone.

Step 5: Use Composer and agents for scoped changes

Composer is Cursor's multi-file editing surface, and the agent can plan a change, touch several files and run commands to carry it out. This is the feature that makes Cursor feel different from plain autocomplete, and it is also the one most likely to cause damage if you let it roam.

The discipline that makes agents safe in production is scope. Give the agent a clear, bounded task: add a field to one model and update the three places that consume it, not "improve the checkout flow." Point it at the relevant files so it is not reasoning over the entire repository. Read its plan before you let it run, and review every diff before you accept it. The agent is fast and often right, but it does not carry responsibility for what breaks, and you do.

Background and cloud agents can handle longer tasks while you do something else, which works well for well-defined jobs. Treat their output exactly like a pull request from a new contributor: often good, never merged unread.

Step 6: Add review gates with Bugbot and PR review

No matter how good the model is, AI-written code needs a review gate before it reaches your main branch. Cursor's Bugbot reviews changes and flags likely bugs, and on Teams plans it can comment on pull requests automatically, giving you a second pass that catches problems a tired reviewer might miss.

Treat that automated pass as a complement, not a replacement, for human review. Wire Bugbot or your pull-request review into the workflow you already trust: require a human approval on every merge, keep your existing CI checks and tests, and do not let the fact that an AI wrote the code lower the bar. If anything, AI-generated changes deserve closer reading, because they can be confidently wrong in ways that look plausible.

The goal is layered defense. The model proposes, automated review flags, CI verifies, and a person approves. Each layer catches a different class of mistake, and together they let you move fast without shipping quiet regressions.

Step 7: Protect secrets and privacy

A production repository has things the model should never see. The first guardrail is a .cursorignore file in the repository root. It works much like .gitignore: anything you list there is kept out of the index and out of the model's context. Use it for environment files, credentials, key material, large generated assets and any directory the agent has no reason to read. Add it before you do serious work, not after a secret has already been indexed.

The second guardrail is privacy mode. With privacy mode on, your code is not retained for model training, which is usually a requirement for proprietary or regulated work. Turn it on in settings, and on a team configure it as policy so it is not left to each developer to remember.

These two settings are cheap to enable and expensive to skip. A .cursorignore that excludes your secrets, plus privacy mode for your source, covers the two failure modes that worry security teams most: sensitive data entering the index, and proprietary code leaving your control.

Step 8: Configure team settings and shared rules

What you have set up so far is per-developer. The point of a production setup is that the whole team gets it consistently. The mechanism is the repository itself. Commit your .cursor/rules and .cursorignore files, and every teammate who clones the repo inherits the same context, the same conventions and the same exclusions with no extra steps. This is the easiest way to share Cursor settings across a team, and it keeps the configuration versioned alongside the code it governs.

Account-level controls sit on top of that. The Teams plan, at $40 per user per month, adds pooled usage, SSO, Bugbot and shared context, while Enterprise adds SCIM provisioning, access controls and audit logs. An admin configures privacy enforcement and access once, so individual developers cannot accidentally opt out of your security baseline.

Keep your rules under code review like anything else. When a convention changes, update the rule in a pull request, and the whole team picks it up on their next pull. For how this compares with other team setups, our Cursor vs GitHub Copilot breakdown looks at how each handles shared configuration and governance.

Common mistakes to avoid

The most common mistake is skipping rules entirely and then complaining that Cursor does not follow your conventions. It has no way to know them unless you write them down. A close second is letting the agent run unscoped against the whole repository, which wastes credits and produces sprawling diffs nobody wants to review.

Two more are worth naming. Reaching for the most expensive model for every trivial edit drains your usage budget for no benefit. And accepting agent diffs without reading them, because the code looked fine at a glance, is how confidently wrong changes slip into production.

Finally, do not forget the .cursorignore until after something sensitive has been indexed. Set up your secrets exclusions and privacy mode on day one, before the model has touched anything you would regret.

Next steps

Once the basics are in place, the work is mostly maintenance. Tend your rules as the codebase evolves, refine your model choices as you learn what each task actually needs, and keep your review gates honest. The teams that get the most from Cursor treat it as a fast junior developer who needs clear instructions and careful supervision, not a magic box.

For a deeper look at how the tool performs and where the usage-credit math bites, read our full Cursor review. If you are still deciding whether Cursor is the right fit for your team at all, our best AI coding tools guide ranks it against the alternatives by use case.