The release stops at build. Logs are kept, staging is untouched, and production keeps running the previous release.
How it works
From source code to production
The full path a change takes through Shipvise, including what happens when something fails.
-
Input
A push to a connected repository, an upload, or an agent calling Shipvise. Each one produces a revision.
-
Build
The revision is built in an ephemeral workspace with no access to the host or to other projects.
-
Artifact
A container image is produced and addressed by digest. This is the thing that will eventually run in production.
-
Staging
The image is deployed to an isolated staging environment with its own URL and its own variables.
-
Test
You use the application. Platform checks run in parallel and report build, health, secrets and dependency results.
-
Review
Optionally request AI review, senior review, or both. Findings arrive with severity, scope and a suggested action.
-
Approval
Promotion to production requires an explicit approval. An agent cannot approve on your behalf.
-
Production
The same digest that ran on staging is deployed to production. Nothing is rebuilt.
-
Rollback
If the release misbehaves, production returns to the previous digest and the incident stays in the release history.
When something goes wrong
Staging still runs so you can investigate, but the release is marked as blocked until the finding is resolved or explicitly accepted.
You get the findings, fix them with your AI or with help, and create a new release. The rejected release stays in the history.
Your AI built the first version. Shipvise helps you take the next step.
Create a workspace, connect a project and deploy it to staging. Decide about production when you have seen it running.