Deploy with GitHub Actions

The Build and Deploy Image action ships from any GitHub workflow. Drop it into a step, point it at a Dockerfile or an existing image tag, and it handles the rest — building the image, pushing it to your registry, and triggering a deploy on ComputeSphere.

The action exposes four modes. Each one composes three underlying stages — build, push, deploy — so you can grab exactly the work you need without writing the curl-and-jq dance yourself.

Four modes, three stages

build-onlyJust compile the image. Don't push, don't ship.

Build

Push

Deploy

build-and-pushCompile and push the tag to your registry.

Build

Push

Deploy

deploy-onlyPoint ComputeSphere at an image that's already in your registry.

Build

Push

Deploy

build-and-deployThe default. Build, push, ship — in one step.

Build

Push

Deploy

Most workflows use build-and-deploy (the default) for branch pushes and build-and-push for tagged releases. deploy-only is the right call when an upstream pipeline already built the image and you just need to roll it out.

Inputs

Input	What it does	Required in
mode	One of build-only, build-and-push, deploy-only, build-and-deploy.	All modes (default: build-and-deploy)
name	Full image name with tag, e.g. quay.io/acme/api:v0.0.1.	All modes
account_id	Your ComputeSphere account ID.	deploy-only, build-and-deploy
token	A ComputeSphere API token — see API keys.	deploy-only, build-and-deploy
deployment_id	The deployment ID to roll forward.	deploy-only, build-and-deploy
registry	Container registry URL, e.g. quay.io.	When building, pushing, or deploying
type	public (default) or private. Controls whether credentials are used.	All modes
username, password	Registry credentials.	When type: private
provider	other (default), ecr, or gcr. Pick ecr for Amazon ECR, gcr for Google Artifact Registry, other for everything else.	Optional
dockerfile	Path to the Dockerfile, relative to the repo root.	When building (default: Dockerfile)
extra_build_args	Additional flags passed to docker build (e.g. --build-arg API_URL=…).	Optional

For type: public, username and password are ignored — fine to leave blank or omit.

Setup

Three things to grab once, store as repo or environment secrets, and reuse from every workflow:

1. An API token. Open the console → Settings → User tokens → New token. Copy the value and save it as a GitHub secret (e.g. COMPUTESPHERE_API_TOKEN).
2. Your account ID. Visible at the top of Settings → Account, or via GET /v2/accounts. Save as COMPUTESPHERE_ACCOUNT_ID.
3. The deployment ID for the service you want to ship to. Visible on the service detail page in the console, or via GET /v2/services/:id. Save as DEPLOYMENT_ID (a variable, not a secret — it's not sensitive).

For private registries, also save REGISTRY_USERNAME and REGISTRY_PASSWORD.

Add the action

In your repo, create .github/workflows/deploy.yaml:

name: Deploy to ComputeSphere

on:
  push:
    branches: [main]

jobs:
  deploy:
    runs-on: ubuntu-latest
    steps:
      - uses: actions/checkout@v4
      - name: Build and deploy
        uses: computesphere/[email protected]
        with:
          mode: build-and-deploy
          name: ${{ vars.REGISTRY }}/${{ vars.IMAGE }}:${{ github.sha }}
          registry: ${{ vars.REGISTRY }}
          account_id: ${{ secrets.COMPUTESPHERE_ACCOUNT_ID }}
          token: ${{ secrets.COMPUTESPHERE_API_TOKEN }}
          deployment_id: ${{ vars.DEPLOYMENT_ID }}
          type: private
          username: ${{ secrets.REGISTRY_USERNAME }}
          password: ${{ secrets.REGISTRY_PASSWORD }}

Commit, push to main, and watch the workflow run in the Actions tab. On success, the action prints the deployment name, environment, subdomain, custom domain (if set), and spherelet count.

Examples by mode

Pick the tab for the mode you want.

The default. Build the image, push to your registry, roll it out to ComputeSphere.

name: Deploy to staging

on:
  push:
    branches: [staging]

jobs:
  deploy:
    runs-on: ubuntu-latest
    environment: staging
    steps:
      - uses: actions/checkout@v4
      - uses: computesphere/[email protected]
        with:
          mode: build-and-deploy
          name: ${{ vars.REGISTRY }}/${{ vars.IMAGE }}:${{ github.sha }}
          registry: ${{ vars.REGISTRY }}
          account_id: ${{ secrets.COMPUTESPHERE_ACCOUNT_ID }}
          token: ${{ secrets.COMPUTESPHERE_API_TOKEN }}
          deployment_id: ${{ vars.DEPLOYMENT_ID }}
          type: private
          username: ${{ secrets.REGISTRY_USERNAME }}
          password: ${{ secrets.REGISTRY_PASSWORD }}

For a public registry, drop type, username, and password.

Tips

• Tag with the commit SHA, not latest. ${{ github.sha }} gives every deploy an immutable, traceable tag. latest reuses the same tag and breaks rollbacks.
• Use GitHub environments to scope secrets per target. Define a staging and production environment in the repo, then set environment: staging on the job — secrets.COMPUTESPHERE_API_TOKEN will resolve to the staging value automatically.
• Build matrix → deploy matrix. For monorepos, fan out one job per service with a strategy.matrix.deployment_id that maps service names to deployment IDs.
• Cache Docker layers with actions/setup-buildx if your builds get slow. The Build and Deploy action delegates to plain docker build, so Buildx caching applies.

Reference

The action is open-source and published on the GitHub Marketplace.

GitHub Marketplace

Build and Deploy Image to ComputeSphere

Install via the Marketplace UI → open in browser.

Source

computesphere/build-and-deploy-image-action

Read the action source · file issues · open PRs.

What's next

• MCP server — let your AI assistant deploy from chat instead of from a workflow.
• Lifecycle actions — what deploy, redeploy, and rollback actually do under the hood.
• API keys — generate the token used by the action.