Deploy a Bolt.new App Without Carrying Prototype Risk Into Production

Sync or export the complete project into an organization-owned Git repository. From a clean clone, use the package manager indicated by the lockfile, run the production build, and start the built application. Do not silently regenerate the lockfile during deployment. Pin a supported runtime version and ensure that generated files required at runtime are either committed intentionally or produced by a documented build step.

Inspect the framework configuration and network calls before choosing a host. A static frontend cannot safely hold private credentials or execute trusted business logic. A framework with server routes or actions needs a compatible server runtime. Background workers, long-running connections, filesystem writes, and scheduled jobs may need separate infrastructure. Choose hosting from these requirements rather than from the preview's behavior.

Read the code paths that create users, alter data, charge money, send messages, upload files, and call AI services. Generated code often optimizes for a successful demonstration and may omit retries, permission checks, schema validation, or failure handling. Remove dependencies and routes that are no longer used, review package licenses and advisories, and replace unmaintained libraries where they sit on a critical path.

Search both source and Git history for secrets. A secret removed in the latest commit is still compromised if it was ever published or shared. Rotate it at the provider and remove it from history where appropriate. Also inspect browser bundles and network requests: environment variable naming conventions vary by framework, and values marked as public are normally visible to every user.

Create separate development, preview, and production projects for the database, auth provider, storage, and other integrations. Store their values in environment-scoped deployment settings, not committed files. Include an env example file with names and documentation, and validate variables during build or server startup. Limit production access to the people and automation that need it.

Proxy privileged operations through authenticated server code. The server should derive the current user from a verified session, enforce role and resource ownership, and use private credentials only after authorization succeeds. Do not rely on a disabled control, a client route guard, or a user ID supplied in JSON. If a service supports direct browser access, configure its row, document, or object policies as though its public endpoint will be called manually, because it will be.

Represent schema changes as versioned migrations and apply them through a controlled release process. Add database constraints for invariants that must survive concurrent requests. Use transactions for related writes, idempotency for operations that may be retried, and indexes based on the production query paths. Test migrations on representative data and estimate locks or rewrite time before applying them to a busy database.

Review the complete authentication lifecycle: account creation, verification, sign-in, sign-out, expiration, password reset, invitation, account linking, and deletion. Make administrative roles explicit and auditable. For webhooks and background work, verify signatures, deduplicate events, persist job state, retry with limits, and route permanently failing work to an inspectable queue instead of dropping it silently.

Configure continuous integration to install from the lockfile and run linting, type checks, tests, and a production build. Add focused integration or end-to-end coverage for the primary workflow and high-risk boundaries. Preview deployments are valuable for review, but they should use isolated non-production data and credentials. Treat logs and build artifacts as potentially sensitive.

Promote a reviewed commit to production and attach the commit identifier to the release. Run migrations as a deliberate step and use backward-compatible changes so old and new application versions can overlap safely. Smoke-test the public domain after release, including authentication callbacks and one read and write path. For a significant change, use a limited rollout or feature flag and define the condition that will stop the launch.

Capture frontend exceptions, server errors, latency, database health, job failures, and integration failures with environment and release tags. Redact authorization headers, cookies, tokens, and sensitive fields before telemetry leaves the application. Create alerts around sustained user impact, and maintain a small dashboard for sign-in success, core workflow success, error rate, and resource pressure.

Enable provider-supported database backups and point-in-time recovery, and protect uploaded files according to their value and retention needs. Test a restore into an isolated project and verify record counts and application behavior. For code, keep immutable release references and a one-command or well-documented redeployment path. For schema incidents, prefer forward-compatible repairs; know exactly when point-in-time restoration is justified and what newer writes it would discard.