Deployments
A deployment takes a specific commit from clone to a live URL. Each project has one production environment, and each deployment replaces what that environment is serving.
What starts a deployment
A push to the default branch. When the GitHub App delivers a push for the connected repository's default branch, Vinssi starts a deployment for the new commit. Pushes to other branches and tags are ignored. A commit that has already been deployed to the environment is not deployed twice.
Deploy from the dashboard or CLI. The Deploy button deploys the default branch. The CLI lets you choose a ref:
vinssi deploy <projectId> --ref my-branch
Rollback. See below.
Starting a deployment cancels any deployment already in progress for the same project.
A push is ignored silently, with no deployment created, when the project has no active plan, when it is deactivated or scheduled for deletion, or when the GitHub App installation has been suspended or removed.
Stages
The dashboard shows each deployment as a sequence of steps. In order:
| Step | What happens |
|---|---|
| Pre-checks | Clone the commit, detect the app type, package manager and commands. |
| Preparing | Run the install and build commands in an isolated builder and package the output. |
| Publishing | Start the new version and wait for it to accept connections on port 3000. |
| Live | Traffic is switched to the new version. |
The new version is started alongside the old one and only takes over once it is ready. If it never becomes ready, the old version keeps serving.
Failure states
| Shown as | Meaning |
|---|---|
| Pre-checks failed | The commit could not be cloned or no supported app type was detected. |
| Couldn't prepare | The install or build command exited with an error, or the 25 minute build limit was hit. |
| Publish failed | The built app did not start listening on port 3000 within about two and a half minutes, or the rollout timed out after ten minutes. |
| Issue detected | The app became ready and later stopped answering on port 3000. |
| Cancelled | A newer deployment superseded this one. |
A deployment that stalls in any stage for more than 25 minutes is marked failed automatically.
Readiness and health
Vinssi checks that your app accepts TCP connections on port 3000. It does not request any HTTP path, so you do not need a health endpoint. Once live, the app is never restarted for health reasons; a crash keeps the container down until the next deployment.
Logs
Build output is captured line by line and shown on the deployment page as it arrives, and is kept with the deployment. From the CLI:
vinssi deployments logs <deploymentId>
Runtime output from the running application is not available in the dashboard yet. If an app starts and then misbehaves, reproduce it locally with the same environment variables and PORT=3000.
Rollback
Open a previous deployment that reached Live and choose Rollback, or run:
vinssi deployments rollback <deploymentId>
Rollback creates a new deployment that rebuilds the exact commit the earlier deployment used, with the project's current environment variables and build settings. It is a fresh build, so it takes as long as any other deployment. The source deployment must have been healthy and must still have its commit available in the repository.
Limits
- Deploy and rollback requests are limited to 20 per five minutes per workspace.
- Builds run with 2 CPUs and 4 GB of memory available and a 25 minute hard limit.
- One deployment runs at a time per project; starting another cancels the first.