Deploy a project
springroll.deployRegisters the project if it is new, attaches whatever source you give it, and deploys it using the application's Deployment workflow. Direct applications go to Production; Staged applications go to Development. Returns the live URL, or a deployment id to poll if the build is still running.
You do not decide whether this project needs git. Send what you have and SpringRoll works it out:
• a pushed git remote → pass repositoryUrl (and ref if not the default branch)
• no remote, or uncommitted work → pass archive, a base64 tar+gzip of the source:
tar --exclude=node_modules --exclude=.next --exclude=.git --exclude='.env*'
-czf - . | base64 -w0
• both → SpringRoll builds from git, and falls back to your files if the ref cannot be resolved (an unpushed branch, typically)
• neither, on an app that already exists → redeploys its current source
Upload SOURCE, not build output: SpringRoll runs the build. node_modules, .next, dist, build, out, coverage and .log files are dropped automatically and reported. Every .env file and .git/ is REFUSED outright, naming the offending path: configuration belongs in SpringRoll, not in the bundle. Upload limits are about 3 MB compressed on the wire (a platform request-body cap, not a preference), 20 MB expanded, 2000 files, 512 KB per file; a project past them should pass repositoryUrl instead, which SpringRoll clones directly with no size limit. Sending the same files twice is free, because bundles are addressed by content.
Direct to Production skips workflow approvals but keeps production safety checks. Staged applications continue to use explicit promotion and approvals.
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| ref | No | Branch, tag, or full commit SHA. Defaults to the app's default revision. | |
| name | No | ||
| slug | No | ||
| tags | No | ||
| files | No | Path-to-contents map. Use `archive` for anything beyond a few files. | |
| archive | No | Base64 of a gzipped tar of the project source. Preferred over `files`. | |
| context | Yes | Explain why you are calling this tool and how it fits into the user's overall goal. This parameter is used for analytics and user intent tracking. YOU MUST provide 15-25 words (count carefully). NEVER use first person ('I', 'we', 'you') - maintain third-person perspective. NEVER include sensitive information such as credentials, passwords, or personal data. Example (20 words): "Searching across the organization's repositories to find all open issues related to performance complaints and latency issues for team prioritization." | |
| manifest | No | A SpringRoll manifest. Supersedes the metadata fields below; the source fields still apply. | |
| framework | No | ||
| placement | No | Optional, provider-neutral hints about what this application needs. SpringRoll chooses the provider and plan; these only inform that choice. Leave out anything you do not actually know: monthly billing quantities remain unknown; ordinary workload hints are inferred from the source and named on the placement receipt, which is more useful to the user than a confident guess. | |
| department | No | ||
| application | No | An existing app's slug or id. Omit on the first ship; `name` implies it. | |
| description | No | ||
| waitSeconds | No | How long to wait for the build before returning. Defaults to 20. A real build usually outlasts this; poll springroll.deploy.status after. | |
| buildCommand | No | ||
| preferSource | No | Tie-breaker when both a repository and files are given. Defaults to git. | |
| filesEncoding | No | ||
| repositoryUrl | No | ||
| rootDirectory | No | ||
| idempotencyKey | Yes | Required. A stable, caller-generated key. Retrying with the same key returns the original result instead of creating a duplicate. | |
| installCommand | No | ||
| supportContact | No | Team channel or email for users of this app. Required before production. | |
| outputDirectory | No | ||
| dataClassification | No |