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