Deploy and update applications
Hallvi deploys one exact commit to one server with Docker Compose, then checks that the application works.
In short
- A release counts as deployed only after a check of the running application passed.
- Hallvi never edits your branches. It can propose a change as a pull request from a
hallvi/branch, and never merges. - Hallvi never retries a failed deployment by itself. Press Retry on the Deployment page.
GitHuba branch, pinned to one commit
Your computerdownloads that commit
SSH
Serverbuilds and starts it with Compose
Checktests the running application
Releasedeployed only if the check passed
Finished is not verified
A command that finished is not a working application. Hallvi calls a release deployed only after a check of the running application passed, and says what it checked.
Deploy a new version
Ask
Write it in the main conversation, for example Deploy the latest commit on main.
Deploy latest
Press it on the Deployment page, once a first release is verified. It needs a GitHub connection.
Or let Hallvi deploy every new commit by itself. Your data stays in place between versions.
What Hallvi changes
- It changes what the application runs on: the server, Docker and Compose files, configuration, secrets and the web server in front.
- It does not edit your code on your branches. It can propose a small change, such as a health check, as a pull request from a
hallvi/branch. It never merges.
When a deployment fails
| Attempt | What to do |
|---|---|
| failed | Read why on the Deployment page, and ask Hallvi what is running now. Press Retry to try the same commit again. Hallvi never retries by itself. |
| interrupted | Hallvi stopped mid-deployment, so what reached the server is unknown. Continue the conversation, or deploy again. |
Limits
- One stack on one server. No clusters, replicas or failover.
- The source copy can be up to 48 MiB compressed and 128 MiB unpacked, without Git submodules or Git LFS files.