The first thing to understand about deploying to SpinForge is what does not exist. There is no spinforge deploy, no spinforge login, no deploy.yaml to commit. Looking for them is the most common wrong turn.
What exists is a workspace, a build plane and a hostname. A deploy moves the first to the third through the second.
Authentication goes through Appmint
SpinForge does not hold your credentials. You sign in to Appmint, and that user token is exchanged for a short-lived SpinForge customer token — roughly an hour — using a partner key held by the service doing the exchange, never by a browser.
Two hops, and the second is the one people forget when a deploy suddenly starts returning 401 an hour into a session.
The site is created before the build
A hostname is a record, and it has a type: static for a pile of files, container for something that listens on a port. Creating it is idempotent — an existing host is reused rather than duplicated.
Getting the type wrong is quietly expensive. A long-running service recorded as static will never run, and nothing about the build output tells you that is what happened.
The workspace rides with the build
The project is zipped and uploaded with the build trigger rather than at pipeline creation, because the workspace changes between builds and the pipeline does not. Server-side it lands where the git path would have left its own archive, so every stage downstream is source-agnostic.
A pipeline is durable and keyed by name. Preview and production are separate pipelines, because they publish to different hostnames and cannot share a stage definition.
Two stages
- Build — detects the project and produces an artifact, or runs a command you specify with an output directory you name.
- Deploy — publishes that artifact to the hostname.
If your files are already built, say so: put the build stage in command mode with a command that does nothing and an output directory of the archive root. Otherwise detection will look for a build that is not there.
When a deploy looks successful and the site is not
Every stage can succeed while the container fails to start, because the pipeline's job ends when the artifact is published. A site that has been deployed but is not serving usually means the app is crashing at startup — read the application's own logs, not the build's.
For static sites the equivalent trap is server configuration rather than the build: if unknown paths return a page instead of a 404, one bad URL will resolve, and any relative link on it compounds from there.
Read next
- Vibe Studio — where most deploys start
- Service rates — what hosting costs