Deploy from GitHub

Deploying from a Git repository is the most common way to run an app on Helicarrier Cloud. You connect a repo, Helicarrier builds it into an image, and it runs the result — rebuilding on every push if you want.

Connect a repository

When you add a Git repository service, you have two ways to point at your code:

• GitHub App — connect your GitHub account and pick a repository from the list. This also enables push-based auto-deploys and shows commit details on each deployment.
• Direct Git URL — paste any public Git URL. Useful for public repos or providers outside the GitHub connection. (Push webhooks are only available through the GitHub App.)

Choose a branch to deploy; Helicarrier tracks that branch for builds and (if enabled) auto-deploys.

How it builds

Helicarrier picks a build strategy automatically:

• Railpack (zero-config) — for most apps, Helicarrier detects the language and framework and builds a production image with no configuration. Node, Python, Go, Ruby, PHP, static frameworks, and more are recognized out of the box.
• Dockerfile — if your repo has a Dockerfile, Helicarrier uses it. Point at a custom path in build settings if it lives somewhere other than the root.

Either way, the build runs on managed build infrastructure — you do not provision anything.

Build settings

Under the service’s build settings you can fine-tune:

• Root directory — build a subfolder of a monorepo.
• Install / build / start commands — override the detected commands.
• Release command — a pre-deploy step (for example, database migrations) that runs before the new version takes traffic.

See Build & runtime settings for the details.

Auto-deploy on push

Enable auto-deploy on the service, and every push to the connected branch triggers a new deployment. Helicarrier verifies the GitHub push webhook, builds the new commit, and rolls it out with a health check — no manual step needed. Each deployment records the commit SHA and message so you can see exactly what shipped.

You can turn auto-deploy off to deploy manually, and you can always trigger a deploy by hand from the service.

Branches, tags and commits

A service tracks one ref — set it in Settings → Branch or tag:

• A branch (main) is the usual choice: auto-deploy ships every push to it.
• A tag (v1.2.3) pins the service to that release. It stays there until you change it, since nothing new is ever pushed to a fixed tag.

Deploy one ref without changing what you track

To ship a specific commit or tag once — a release, a hotfix, testing a branch before it merges — use Deploy a specific ref on the Deployments tab and enter a branch, tag, or commit SHA.

This is a one-off: your service keeps tracking the branch it tracked before, so auto-deploy carries on unchanged. The deploy history records what was built, e.g. manual @v1.2.3.

From CI/CD

The same thing from a pipeline — deploy a tag without merging to main:

curl -X POST "$HELI_DEPLOY_TRIGGER" \
  -H 'Content-Type: application/json' \
  -d '{"ref":"v1.2.3"}'

See deploy triggers for the full setup, including a GitHub Actions job that fires on tag pushes.

Next

• Prefer a prebuilt image? See Deploy a Docker image.
• No git? Deploy from an upload — a folder or archive.
• Choose the right service kind in Service types.
• Learn the rollout and rollback model.