Continuous deployment

Continuous Deployment

Every git push can deploy automatically: the platform listens for GitHub webhooks from your connected repositories and rebuilds the service as soon as a commit lands on the tracked branch.

How it works

1. You push a commit to the tracked branch (for example main).
2. GitHub notifies the platform via the GitHub app installed on the repository.
3. A build starts (see how builds work).
4. If a kx712.yml file defines checks (tests, lint), they run first, and a failure cancels the deployment.
5. Build succeeds → the new version replaces the old one with no downtime.

The commit, its message, and its deployment status are visible in the Deployments tab, and reported back to GitHub (commit status).

Enable / disable automatic deployment

Automatic deployment is set per service in its settings. When disabled, pushes no longer have any effect: you deploy manually with Redeploy. This is useful for an environment you want to freeze.

Filtering triggers

Without configuration, any push to the tracked branch triggers a build. The kx712.yml file lets you refine this:

• branches: only react to certain branches;
• paths: ignore a push that doesn't touch any relevant file. This is useful in a monorepo: the backend service doesn't rebuild when only frontend/** changes.

On failure

A failed build or check does not affect the live version: the service keeps running on the last successful deployment. Fix it, push again, or roll back to a previous version at any time.

No GitHub? Services deployed from a Docker image update by redeploying from the dashboard, the CLI, or the VS Code extension.