Skip to content
← Documentation
On this page

Deploy from GitHub

Point an app at a GitHub repository and Anyport builds it and ships it. After the first setup, pushing is the deploy.

Connecting GitHub#

You connect GitHub once per organization by installing the Anyport GitHub App and granting it access to the repositories you want to deploy. An organization can hold more than one installation, so repositories spread across several GitHub accounts can all be deployed from the same place.

Anyport only sees the repositories you grant.

Creating an app from a repo#

  1. In a project, create an app and choose Deploy from GitHub.
  2. Pick the repository and branch.
  3. Configure the build, then create the app.

Anyport builds the image and rolls it out. The build runs on your own cluster, not on ours—which is why there is no build-minute charge and no queue behind other customers' builds. On Anyport Cloud the cluster is ours, so builds there are billed from credit for the CPU and memory they use, like any app.

Build args that reference other things#

A build takes build args from the app's Source settings. A value can be plain text, or a reference to a project variable, a secret, a managed service or another app, written ${{ name.KEY }}: ${{ api.URL }} bakes in another app's address, for example. References are read when each build starts, so a rotated secret or a moved app is picked up by the next build without editing anything. A build arg can end up in the image, so keep private credentials out of them. References need agent v0.0.52 or later on the cluster.

Auto-deploy on push#

Auto-deploy is off when an app is created, so the first deploy is always one you asked for. Turn it on from the app's Source settings and pushing to the connected branch then triggers a build and rollout on its own. Each deployment records where it came from: the commit, the branch, and whether it was triggered by a push, a manual run, or a redeploy.

The commit that leaves your terminal is the commit named on the row that goes live. The revision it replaces goes quiet in the same beat.

Leave it off per app if you'd rather deploy deliberately.

Rapid pushes#

If several pushes land while a build is already running, Anyport does not start a build for each one. Pushes to the same app coalesce, so you get a build of the newest commit rather than a backlog of stale ones.

Builds share the cluster with your apps#

Builds are heavy, and a burst of them on a small cluster used to crowd out the apps it was serving. Each cluster now sets aside a build pool, a quarter of its CPU and memory by default, and a build starts only when a slot in that pool is free. One that does not fit waits its turn, and the builds list shows it as Queued · 2 ahead, with its time in the queue shown apart from its build time. A newer build of the same app replaces one that is still queued, so a queue never fills with stale commits.

The pool is set in the cluster's Settings → Builds: the share of the cluster builds may use, the size of each build, and how many may run at once. An app whose build needs more than the default size can override it in its Source settings, up to what the pool can hold.

On Anyport Cloud builds have room of their own, apart from your apps, sized by Anyport: one runs at a time and the next waits in the queue.

When a connection breaks#

If the GitHub App is uninstalled or loses access to a repository, Anyport pauses auto-deploy for the affected apps rather than repeatedly failing. Restore access and it resumes.

Knowing which commit is running#

The container is told what it was built from: ANYPORT_GIT_COMMIT_SHA, ANYPORT_GIT_BRANCH, ANYPORT_GIT_REPO_OWNER, ANYPORT_GIT_REPO_NAME, ANYPORT_GIT_COMMIT_MESSAGE and ANYPORT_GIT_AUTHOR are set on every source-built app, alongside the project and app variables every app gets. Use them for a release tag or a version endpoint instead of baking the commit into the image. See Variables Anyport sets.

Deploying an existing image#

If you already build images in your own CI, skip the repository connection and deploy the image directly. You keep your pipeline; Anyport handles the rollout, revisions, and rollback. From GitHub Actions that is one step with anyport-labs/deploy-action; from any other CI it is anyport app deploy with a service token.

Watching a deployment#

Every build and rollout for an app appears in one timeline—what shipped, from which commit, and when. If a release misbehaves, roll back to any previous revision from the same place. See Apps.

Next steps#

  • Preview environments — What the same connection gives a pull request.
  • Apps — Scale, health checks, variables, and rollback.
  • Projects — Where apps live.
  • Quick start — End to end, from sign-up to first deploy.