Registers 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.