Service Hub

Vercel for Backend, In Your Own Cloud

Connect a Git repository and every push becomes a running deployment — no pipeline YAML, no Dockerfile required, with results written back into GitHub checks and deployments.

For the developer who wants a push to mean deployed, and the platform engineer who wants that push to obey the environment’s gate.

How It Works

1

Connect

Connect a repository once. From then on every push carries the record.

2

Push

Every push is built, containerized, and deployed. No pipeline YAML, no Dockerfile required.

3

Promote

Promotion follows the order your environments declare; a protected environment carries a manual gate and refuses self-approval.

4

Written Back

The result lands in GitHub as checks and deployments, so the person who pushed learns what happened where they already are.

What You Get

Shipped behavior, stated as it works today.

Nothing to Write for the Build

The build runs through Buildpacks from the repository as it is: no pipeline YAML and no Dockerfile to write or keep.

Promotion in Your Environments’ Order

Builds can be manual, from a branch, or from an exact commit; promotion follows the order your environments declare; protected environments carry a manual gate.

A Protected Environment Refuses

A rejected environment is never touched, and a service with deployments in a protected environment refuses deletion outright.

Usage Never Becomes an Invoice Line

Runner minutes are never billed. Usage is recorded for abuse protection and nothing else.

A deployment, from a push

trigger

push to main · 4f2a9c1 · "checkout: retry on timeout"

build

buildpacks · no Dockerfile · 2m 41s est.

promotion

dev → staging → prod (protected: manual gate)

approval

prod gate resolved by a reviewer · never the initiator

github

check passed · deployment active

record

one run, kept with its log and its revision

An illustration of the record the product shows. Figures marked est. are examples; a real record carries its own.

Where This Is Proven

The same claims, written for the person who signs, with the record beside each one.

Rules and Approvals

Deployment budgets that pause a deploy, protected environments that refuse self-approval, a curated catalog, and sensitive fields that only take managed secrets.

What It Proves →

The Record

Every infrastructure change is one Infra Job, kept and queryable with its configuration, cost fact, verdicts, approvals, and the snapshot of what exists afterward.