Introduction

“git push, and it’s live” reads like magic. Under the hood it’s a pipeline with strict guarantees. This post walks through what actually happens between your terminal and a healthy rollout.

From webhook to image

When you connect a repository, Squark installs a GitHub App scoped to the repos you choose. A push to the tracked branch fires a webhook; Squark checks out the commit, resolves your build context and Dockerfile, and builds the image.

Builds are reproducible and tagged with the commit SHA, so every running container answers the question “what code is this?” precisely.

From image to rollout

The image is pushed to a registry in your cloud account, then rolled out to your cluster with health checks gating the switch. Traffic only shifts when the new revision reports ready — a failed deploy never takes down the old one.

Env var changes, scaling updates, and rollbacks are modeled as deployments too. History stays linear and auditable: every change to production has a trigger, an author, and a diff.

Why it matters

Deployment tooling fails in the gaps — the undocumented script, the manual kubectl apply. Making every change a first-class deployment removes the gaps, which is what makes one-click rollback trustworthy.