How to Deploy an App Built With Cursor: A Stack-Aware Production Guide

Read the repository entry points, manifests, lockfiles, framework configuration, container files, and infrastructure definitions. Write a simple architecture map showing clients, server processes, data stores, queues, scheduled jobs, file storage, and external services. Mark every network boundary and whether it carries public, authenticated, administrative, or service-to-service traffic.

Translate that map into runtime requirements: language and version, build output, startup command, ports, memory, CPU, request duration, persistent connections, background execution, filesystem use, and regional constraints. A static host cannot execute private server logic, and a short-lived function may not suit a long job. Choose a deployment model only after these constraints are explicit.

Prioritize code that handles identity, permissions, money, personal data, file parsing, queries, cryptography, and external calls. Trace data from request to storage and response. Check that validation happens at trusted boundaries and that error handling does not reveal secrets. Look for partially implemented branches, broad exception catches, placeholder data, permissive defaults, and code copied for a framework version the project does not use.

Keep pull requests small enough to review and require a human to explain significant generated changes. Run type checking, linting, dependency and secret scanning, and targeted tests in continuous integration. Automated scanning is not proof of safety; it helps reviewers locate risk. Remove unused dependencies and generated abstractions that add complexity without a product requirement.

Create separate accounts or projects for staging and production data, authentication, storage, payments, messaging, and other integrations. Keep secrets in environment-scoped secret storage, expose only explicitly public configuration to clients, and fail fast when required values are absent. Use workload identity or narrowly scoped service credentials where available and rotate anything previously committed or shared insecurely.

Authentication establishes identity; authorization decides what that identity may do. Enforce both in server endpoints and data policies. Derive user and tenant identifiers from verified sessions rather than request bodies. Review invitation, reset, verification, session expiration, account deletion, and administrator workflows. Apply rate limits and audit logging to sensitive actions, and do not make a client-side route guard the only protection.

Commit ordered database migrations and review them with application changes. Add constraints for uniqueness and valid relationships, transactions for atomic workflows, and indexes for important queries. Rehearse migration duration and locking on representative data. Prefer additive changes followed by backfill and later cleanup so both current and previous application versions can run during rollout or rollback.

External APIs fail in ways a local happy path does not show. Set deadlines, use bounded retries with backoff, and retry only safe or idempotent operations. Verify inbound webhook signatures and deduplicate event IDs. Place slow or retryable work in a durable queue and make workers safe to run more than once. Track provider quotas and cost alongside technical health.

The deployment pipeline should run on reviewed commits and produce an identifiable artifact. Execute formatting checks, type checks, tests, security checks, and the exact production build. If practical, promote the same artifact through staging and production rather than rebuilding from a moving dependency set. Protect production branches and environments with appropriate review and approval rules.

Use staging for production-like integration tests without real customer data. On release, apply compatible migrations, deploy the artifact, and run smoke tests against the public domain. Verify TLS, redirects, security headers, authentication callbacks, one core read and write operation, and job processing. Roll out high-risk changes gradually and define measurable abort criteria before starting.

Instrument the application for structured logs, exceptions, request latency, job status, and domain-level outcomes such as successful checkout or document processing. Include correlation and release identifiers, and remove credentials and sensitive payloads. Establish service objectives for the workflows that matter, then alert on sustained violations with links to concise runbooks.

Back up every source of durable customer state, including the database and private object storage, according to defined recovery objectives. Restore into an isolated environment and validate the result. Keep the previous artifact available and document configuration rollback. Because rolling code back cannot undo a destructive schema or external side effect, design migrations for compatibility and prepare forward repairs for data incidents.