Connect GitHub

Deploy from GitHub, on every push

Install the Suble Deploy GitHub App and your repos and branches show up in the dashboard — no URLs or tokens to paste. Point a cluster service at a repo, and every git push builds a new image and rolls it out automatically.

Guide: connect GitHub Full build reference
from Connect GitHub to a push-to-deploy service
Project → Settings → Git
   │  Connect GitHub  →  install "Suble Deploy"
   ▼
┌──────────── your org / account ────────────┐
│  repos + branches appear in dropdowns       │
└─────────────────────┬───────────────────────┘
                     ▼
   Cluster → Add Service → GitHub App
   pick installation · repo · branch · build method
                     │  git push
                     ▼
   webhook → build on the on-demand builder → rolling deploy

Connect in two steps

The GitHub App is the native front-end to Suble’s cluster Git builds. Install it once per org or account, then wire up as many services as you like.

1

Install the GitHub App

In the dashboard, go to Project → Settings → Git and hit Connect GitHub. That installs the Suble Deploy App on your org or account — no URLs or tokens to paste. Once it's installed, your repositories and branches show up in dropdowns.

connect once
Project → Settings → Git
[ Connect GitHub ]  →  install Suble Deploy
✓ 1 installation · 24 repositories available

2

Add a service from a repo

In a cluster, choose Add Service → GitHub App. Pick the installation, the repository and the branch to track, then a build method (Dockerfile, Railpack or Static) and a base directory. Leave Auto-deploy on push on and you're done.

add a service
Add Service → GitHub App
Installation   acme
Repository     acme/web
Branch         main
Build method   Dockerfile
Auto-deploy    on push  ✓

Prefer the old way? Pasting a personal access token under Project Settings → Git still works as an alternative — but the App is easier and scopes access more tightly.

What you get

Connecting through the App upgrades three things over a pasted token: how private repos are cloned, how deploys are triggered, and how much access GitHub hands over.

Private repos just work

No token to paste. Each build clones with a short-lived installation access token minted just for that build — never stored, and never written into the image. A running container can't read it.

Every push ships

A git push to the tracked branch fires a webhook. Suble rebuilds the image on the on-demand builder and the cluster's rolling deploy rolls it out — one replica at a time. Auto-deploy is a per-service toggle you can flip off any time.

Least privilege by default

The App only requests read-only access to repository Contents and Metadata, and the person connecting has to actually own the installation — verified through GitHub OAuth at connect time. Tokens are short-lived.

The App feeds the same pipeline as the rest of cluster Git builds — the on-demand builder, build methods, registry push and rolling deploy. For build methods, the base directory, Dockerfile location and per-cluster builder settings, see the full Cluster Git builds reference. New to clusters? Start with Container clusters.