Deploy direkte fra GitHub til dit cluster
Peg en cluster-service mod et Git-repo, og Suble bygger det for dig. En on-demand builder-VM kloner repoet, bygger et image — fra en Dockerfile, med Railpack eller som statisk side — pusher det til dit Container Registry, og den rullende deploy sender det ud. Ingen CI at koble op, ingen build-boks der skal køre.
The Suble team
Engineering ·
Dine cluster-services kan nu bygge direkte fra Git. Giv en service et repository og en branch, vælg hvordan det skal bygge, og hvert gem gør den seneste commit til en kørende release — klonet, bygget, pushet til dit registry og rullet ud en replica ad gangen. Det er Coolify-stil-flowet, på din egen danske infrastruktur.
Det bedste er alt det, du *ikke* skal sætte op: ingen CI-pipeline at koble credentials ind i, ingen build-server der altid kører, intet docker build && docker push på din bærbare. Suble starter kun en builder, når der er noget at bygge, og river den ned igen bagefter.
Kobl et repo op i tre trin
Det hele bor i dashboardet, under Console → Clusters → en service:
- Peg servicen mod Git. Vælg Git som kilde, indsæt repository-URL'en, og vælg den branch der skal følges. Den branchs seneste commit er det, der bygges.
- Vælg en build-metode. Dockerfile, Railpack eller Static (mere om hver nedenfor). Sæt en base-mappe, hvis servicen ligger i en undermappe.
- Gem. En builder starter, imaget bygges og pushes til dit registry, og den rullende deploy ruller det ud i dit cluster. Loggen streamer hele vejen.
✓ Builder klar — kloner github.com/acme/web @ main
✓ HEAD er 2f9c1a4 "fix: cache headers"
✓ Bygget + pushet registry.suble.io/acme/web:2f9c1a4
✓ Ruller ud til service "web" (3 replicas)Imaget bygges ind i dit eget registry.suble.io/<projekt>/…-namespace, tagget med commit-hashet — så hver build også dukker op i dit Container Registry, og hver tag er en version, du kan rulle tilbage til.
Tre måder at bygge på
Hvert repo er forskelligt, så du vælger build-metoden — og du kan skifte den senere og bygge igen:
- Dockerfile — byg fra en Dockerfile i dit repo. Du vælger base-imaget og styrer hvert lag. Bedst når du allerede har en Dockerfile eller vil have fuld kontrol.
- Railpack — ingen Dockerfile? Railpack registrerer automatisk din stak (Node, Python, Go, PHP, Rust og flere) og laver et fornuftigt produktions-image for dig. Det er et moderne alternativ til Nixpacks — bedst til en almindelig app, når du helst ikke vil vedligeholde en Dockerfile.
- Static — server repoets filer som en statisk side bag nginx. Peg base-mappen mod den mappe der skal serveres. Bedst til byggede frontends, landingssider og genereret dokumentation.
Monorepos er førsteklasses
Sæt hver services base-mappe til dens undermappe, og et repo kan fodre flere services i samme cluster — hver bygget fra sin egen sti, med sin egen build-metode.
Builderen er on-demand
Builds kører ikke på dine cluster-medlemmer, og der er ingen build-server der står tændt og brænder penge af. Når en build er i kø, og ingen builder allerede er varm, provisionerer Suble en builder-VM, kører selve build-jobbet og pusher resultatet. Efter build-jobbet bliver den varm i et kort tomgangsvindue (20 minutter som standard), så en efterfølgende build er øjeblikkelig — derefter slettes den, og dens IP frigives.
Du betaler kun pr. time for den tid, en builder faktisk er oppe, til dens størrelses takst. Ingen builds i gang betyder ingen builder og intet at betale. Både tomgangsvinduet og builderens størrelse er indstillinger pr. cluster: hold vinduet kort for at spare, skru størrelsen op for at få store builds hurtigere igennem.
Private repos
Offentlige repos kræver intet som helst. Til et privat repo gemmer du en Git-access-token en gang under Projektindstillinger → Git — en personlig access- eller deploy-token med læseadgang er nok. Suble bruger den til at klone under builds; den er bundet til projektet, krypteret i hvile og deles af alle services i projektet.
Tokenen forlader aldrig builderen
Dine Git-credentials bruges kun på den flygtige builder til at hente kildekoden. De skrives aldrig ind i imaget, så en kørende container kan ikke læse dem. (SSH-deploy-nøgler er på vej; brug indtil da en gemt token.)
Se den bygge, byg igen når som helst
Hver build streamer sit output til dashboardet, mens det sker — klon, build-trin, push og udrulning — så en fejlet build fortæller dig hvorfor med det samme. Når den er færdig, føjes den til servicens build-historik med commit, resultat og varighed, og en enkelt Byg igen-knap kører den nuværende branch forfra (praktisk efter et skift af base-image eller en ustabil build).
Prøv det
Tilføj en service til et cluster, peg den mod et repo, vælg en build-metode, og se en git push blive til en udrullet release uden en linje CI. Den fulde reference findes i Cluster Git-builds-dokumentationen, og er clusters nye for dig, så start med Kør din app på tværs af mange maskiner.
Skrevet af
The Suble team
Engineering