How to Deploy a Vibe-Coded App Without Confusing Deployment With Production

Start by tracing the application from an incoming request to every system it touches. A static front end can often be served from a content delivery network, while a server-rendered application, background worker, WebSocket service, or scheduled job needs a compatible runtime. Inspect package scripts, framework configuration, database clients, file writes, queues, and third-party SDKs rather than relying on a README that may have been generated with the code.

Also establish where state lives. Local SQLite files and uploads written to the project directory often work in a preview but fail on ephemeral or horizontally scaled hosts. Move durable state to an appropriate managed database or object store, or deliberately select infrastructure with persistent volumes and operational ownership that matches the design.

Framework-native platforms are convenient for common web workloads, but convenience is not compatibility. Check execution duration, memory, region availability, request body limits, streaming support, cron behavior, and whether serverless connections suit the database. A container platform may be better for a custom server or worker; a static host may be sufficient when all computation happens through external APIs.

Prefer the simplest model that supports the known workload, then document the constraints. Avoid introducing Kubernetes, multiple clouds, or a complex network solely to appear production-grade. Operational complexity creates its own failure modes, particularly when no one is assigned to maintain it.

A deployment should be reproducible from a specific commit and lockfile. Pin the runtime, install dependencies with the package manager's frozen-lockfile mode, run the production build in a clean environment, and fail on type or compilation errors. Build-time variables must be distinguished from runtime variables because many front-end frameworks embed public values into client assets permanently.

Keep configuration outside source control. Use the hosting provider's encrypted secret store, grant access only to the people and services that need it, and create separate credentials for preview, staging, and production. Never expose server credentials through variables designated as public, even if the generated code expects them in the browser.

Create production data services independently from local and preview environments. Apply least-privilege credentials, encrypted connections, connection pooling where needed, and explicit network rules. Confirm that application instances in the selected region can reach the service without excessive latency.

Treat schema changes as release operations. Review generated migrations, test them against a representative copy, back up before destructive changes, and avoid coupling an irreversible migration to application startup. For changes that cannot happen atomically, use an expand-and-contract sequence so the old and new application versions can run during a gradual rollout or rollback.

Attach the custom domain only after the deployment is stable on its provider URL. Verify DNS records, automatic certificate renewal, canonical host redirects, and whether both apex and www names should resolve. Set the application's public base URL explicitly so authentication callbacks, email links, metadata, and CORS rules do not continue pointing at localhost or a preview domain.

Update every provider that trusts an origin or callback URL, including identity, payments, webhooks, and OAuth integrations. Use production webhook secrets and test signature verification. A DNS cutover does not update these systems automatically, and an overlooked callback is a common cause of a release that looks healthy but cannot complete core workflows.

Run a small deployment smoke test that covers the home page, authentication boundary, one read, one write, and the most valuable transaction. Observe application and provider logs while testing. A health endpoint should verify that the process is responsive, while deeper synthetic checks can verify dependencies without exposing sensitive diagnostics publicly.

Define rollback before routing users to the new version. Know how to restore the previous artifact, which database changes are backward-compatible, and who can execute the action. Deployment previews and blue-green or canary releases reduce risk, but they do not replace a tested rollback procedure or database recovery plan.