How to deploy a vibe-coded app to production

Identify whether the app is static or needs a server, remove exposed secrets and replace local-only storage with suitable shared persistence. Run its production build, choose a compatible hosting workload and submit a recorded release. Follow the deployment to READY, test the real URL and verify both the intended audience and direct-origin protection.

The sequence matters because a successful local demonstration answers a narrower question than a team launch. You need to know what will run without the builder's laptop, what data it may receive and who maintains the result. Begin with fictional records and one complete task whose expected outcome is easy to check after deployment.

Ask the coding agent to inspect the actual project files and production output. A static front end serves built assets to the browser. A full-stack app also needs server execution for routes, rendering or privileged operations. A static front end can call an authenticated API, but that API is still a service with its own ownership and access requirements.

List the package manager, framework version, production build command and output directory. Identify database queries, file uploads, scheduled tasks and external APIs. Keep uncertain requirements visible instead of assuming they are absent. A framework name alone does not establish that every dependency or feature works on a particular host.

Scroll sideways to see all columns. With the table focused, use the arrow keys.

Search for localhost and development-only addresses in the source and configuration. A colleague's browser cannot use a service running only on your laptop. Point requests at the intended deployed service or a suitable server route, then verify the actual network request after deployment. Do not simply replace every hostname without checking which service the request should reach.

Review environment variable names and whether each value is consumed during the build, on the server or in browser JavaScript. Keep secrets out of source, generated assets and chat. Some framework variables are deliberately public and embedded into a bundle. Inspect the output and rotate any credential already exposed; deleting the latest visible copy does not disable an older key.

A prototype may save to local storage, a SQLite file or an uploads folder beside the source. Decide which records must survive a release and which changes two users should see. Choose a suitable shared database or storage service rather than assuming that the deployment copies the builder's disk into a durable production system.

Test a create and read across separate sessions using fictional data. Then verify the same record after an application update. Review file access, backups and retention with the responsible team where they matter to the task. If the app only displays a fixture, label that limitation and keep it separate from a claim that it already supports a shared business workflow.

For company data reached through SpringRoll Connect, review a scoped grant for the application environment. Data-product queries and native endpoint access have different boundaries. Keep source credentials in the server-side connection and use the app's own identity for its permitted route. Personal access held by the builder is not the app's authorization.

• Plan the app's approved data access →

SpringRoll's managed path evaluates available Vercel and Cloudflare workloads against the application's requirements. Eligibility and provider terms constrain the choices before estimated cost is compared. Inspect the selected workload and the assumptions on its placement receipt. Do not describe an unknown estimate as free, or expect every feature in a provider's catalog to be available through the current managed adapter.

If the prototype already uses a personal provider account, review its permitted use and ownership before turning it into a company dependency. A small internal tool can still support business activity. Use current provider terms and your organization's agreement to resolve that question. A private audience and a plan appropriate for company use are separate requirements.

Resolve workers, long-lived connections, native dependencies and persistent file writes before deployment. A host may support the framework while a particular dependency remains incompatible. Compare the actual workload and backing services rather than choosing only by the name of the coding agent that created the project.

• Check the Vercel Hobby question →
• Compare Vercel and Cloudflare runtime fit →
• Read managed hosting and placement guidance →

Run the declared production build and inspect the output folder or server artifact it produces. Keep the lockfile and required configuration with the project. Exclude private configuration, unnecessary local dependencies and unrelated files from the source bundle. Check that the build does not depend on an unpublished file or a service available only on the builder's machine.

Serve or run the production output in an appropriate local check before submitting it. Complete the core task and test an empty result and an unavailable dependency. This verifies packaging and behaviour, not a live provider deployment. Preserve the expected result so you can repeat the same task once the managed build returns a working URL.

• Use a worked example with a reproducible build →

Use the setup instructions for your actual coding client. The optional SpringRoll skill supplies a guided workflow; manual MCP setup connects tools and supports a plain-language prompt. On authorization, sign in, choose the correct workspace and review the requested access. The agent inherits the member's permissions and cannot record a required human approval.

Before deployment, have the agent show the app name, accountable owner, support contact, workflow and target environment. Direct to Production is the default. Configure Staged first if the app must pass Development, UAT and Production review. A request that requires a person's decision should name that next action rather than claiming that the agent approved it.

npx skills add springroll-dev/springroll-skill --skill springroll

• Deploy a Claude Code project →
• Set up deployment from Codex →
• Use another compatible MCP client →

Give the agent the deployment request below after reviewing the project. Keep the returned application, release and deployment references. A queued or running build is still in progress. Follow it to READY or a terminal failure, and inspect the actual build error if it fails. Avoid submitting duplicate unchanged work merely because the first response returned before the asynchronous build finished.

Open the working URL after READY and repeat the acceptance task using the intended environment. Compare the result with the known fixture and check the error path. Preserve the executed provider and placement assumptions beside the test result. A reachable landing page does not establish that a server action, shared record store or background job works.

Prepare this project for SpringRoll. Check the build, workspace, owner and deployment workflow; tell me the target environment, then deploy and follow the build to its actual result.

Choose the app audience and copy the SpringRoll launch link for the right environment. Test an intended colleague and a separate account outside the audience. Verify application business permissions and data access as well as the portal launch. For a staged app, Test and Production have different purposes, so label the handoff clearly.

Apply the linked deployment-origin security guidance and record the outcome alongside the portal test. Keep the test identities, release and environment without exposing credentials. Give users an owner and support route with the link so the app can be maintained after the builder's initial session ends.

• Understand the origin-access boundary →
• Complete the team sharing checks →

Keep developing the source and deploy a new immutable release when the app changes. Verify the latest attempt separately from the current working version. Revisit the data scope, audience and runtime requirements when a new feature changes them. A small visual fix may need a narrow check, while a new export or external API operation needs a broader review.

Transfer ownership through the appropriate process when responsibility changes. Preserve the source, support contact and unresolved work so another maintainer can make the next safe update. If the app is no longer needed, review its old provider endpoints and grants as part of suspension or retirement rather than leaving a forgotten prototype reachable indefinitely.

• Record the maintenance handoff →
• Set the policy for future changes →