Deploy from GitHub
Connect a repository and every push to its branch builds and deploys.
Web services and workers can build from a GitHub repository, public or private. Building from GitHub needs a plan.
Connect GitHub
- When you create a service from a repository, install the wabi GitHub App on your GitHub account or organization and choose the repositories it may read.
- GitHub asks you to authorize the app as part of the installation. wabi links the installation to your account only after GitHub confirms that you can access it.
- Back in the dashboard, wabi lists the repositories the installation covers.
Each build reads its repository with a token limited to that one repository and to reading its contents.
Create the service
| Setting | What it does |
|---|---|
| Repository and branch | what to build; pushes to this branch deploy |
| Root directory | the directory to build, for a repository that holds several apps; the repository root by default |
| Port | where the app listens, 8080 by default; wabi sets PORT to it |
| CPU, memory, volume | the service's size (Sizes) |
| Start command | replaces the image's own start command |
| Pre-deploy command | runs before each rollout (Pre-deploy command) |
| Health path | the path the health check requests (Health checks) |
Creating the service builds the head of the branch. If the app needs variables at build time or at start, choose to add them first, then deploy.
Every push builds
A push to the service's branch builds that commit and deploys it. Each deployment shows its commit SHA and message. Deploying by hand builds the head of the branch again.
How wabi builds
wabi looks in the root directory at the pushed commit:
| The root directory holds | wabi builds with |
|---|---|
a Dockerfile | BuildKit, from that Dockerfile |
no Dockerfile | Cloud Native Buildpacks with the Paketo builder, which detects the app and builds an image without a Dockerfile |
The image goes into wabi's registry, where only your own builds and services can read it.
Builds run in their own microVM
Each build runs in a Kata microVM of its own, apart from your services and from every other customer. BuildKit gets the privileges it needs inside that VM, and they end at the VM's boundary. A build reaches DNS, wabi's registry and the internet, and none of your services, other customers' services or wabi's other systems. A step that needs your database belongs in the pre-deploy command, which runs on your private network.
| Limit | Value |
|---|---|
| Time per build | 15 minutes |
| Resources per build | 4 vCPU and 6 GB of memory |
| Concurrent builds | Hobby 1, Pro 1, Scale 2; staking tier C adds 1 |
A build waiting for a slot shows queued. Its 4 vCPU and 6 GB are separate from your services' allocation.
Variables in the build
The build receives the service's variables, opened inside the build's microVM, in memory.
For a Dockerfile build, every variable is a BuildKit secret. A step reads one by mounting it, and it stays out of the image:
FROM node:22-alpine
WORKDIR /app
COPY package.json package-lock.json ./
RUN npm ci
COPY . .
RUN --mount=type=secret,id=NEXT_PUBLIC_SITE_URL,env=NEXT_PUBLIC_SITE_URL npm run build
CMD ["npm", "start"]For a Dockerfile that reads a value with ARG, mark that key as a build arg in the service's settings. It is then passed as a build arg as well, and, as Docker does with every build arg, its value is recorded in the image the build produces.
For a buildpacks build, the variables are written to the platform env directory, where buildpacks read their build-time environment.
Build log
The build log streams live in the dashboard while the build runs. Opening it later replays it from the start.
Pre-deploy command
A pre-deploy command runs once per deployment, after the build and before the rollout. A typical one applies database migrations:
npx prisma migrate deployIt runs on the new image, with the same variables as the deployment, in its own microVM. With DATABASE_URL set to ${{db.DATABASE_URL}} (Postgres), the migration reaches your database over the private network.
The command has 10 minutes. The rollout starts only if it exits successfully. If it fails or runs out of time, the deployment fails and the live deployment keeps serving. Since the live version runs while the command does, write migrations the live version can work with.
Health check and rollout
The new image starts next to the live one; a service with a volume restarts instead. Once the new instance passes its health check, it takes traffic and the old one stops. A new instance that fails its health check halts the rollout, and the deployment fails without touching what is live (Rolling updates).
Cancel a build
A deployment that is queued or building can be cancelled. It becomes cancelled, and the live deployment carries on.
Roll back
Rolling back reuses the image an earlier deployment built, so nothing rebuilds. The service runs that image and its settings with your current variables (Rollback).
Build minutes
Build time counts against your plan's build minutes for the calendar month:
| Plan | Build minutes a month |
|---|---|
| Hobby | 300 |
| Pro | 1,000 |
| Scale | 3,000 |
The dashboard shows the minutes used this month.