How to deploy an AI-built internal app

Use a SpringRoll workspace, a coding client that can follow the current skill or MCP instructions, and application source you are authorized to deploy. Start with a bounded non-sensitive workflow. Never paste a runtime token, database password, magic link, source credential, or private customer value into a prompt, commit, issue, or screenshot.

Open the public docs and follow the current setup for your client. The MCP path uses browser authorization so the client receives its own credential scoped to your membership; a copied install command by itself is not a completed connection.

Confirm the application name, source, owner, support contact, data classification, and intended environment. The normal MCP path is to read the current organization context and then call springroll.deploy, which creates or updates the application record, captures an immutable release, and starts the deployment. Preserve the returned identifiers instead of hiding a failure behind repeated attempts.

Use springroll.deploy.status or the web deployment record to follow the build. Creating a deployment row is not activation: the governed URL is ready to open only after the runtime reports READY. A BUILDING or failed state is evidence to inspect, not a promise about completion time.

An organization can use Direct to Production or a staged approval policy. An agent may submit an approval request but cannot record the human decision. Governed data access is requested separately: the running app uses its own identity and a scoped grant rather than receiving the source credential, and that grant can be limited or revoked without rewriting the app.

Keep the exact error, correlation id, application slug, deployment id, and source revision. Check the current docs, repository authorization, and configured runtime before retrying. If the evidence still does not explain the stop, use /contact without including secrets.