Skip to content

CI for your GitHub repositories
on servers we run ourselves.

Every push and pull request runs your tests in a sandbox on Enzonic hardware that is already running when the job arrives, with live logs and a check on GitHub. Write a short .enzonic/ci.yml, or keep the GitHub Actions workflows you already have.

3,000 minutes a month free. No card.

See a config
$ git push origin maina41c9e2Run #128 passed in 2m 18slint22stest (node 20)1m 08stest (node 22)1m 21sdeploy26spostgres:17 · healthyAll checks have passed4 jobs · Enzonic CI
CI minutes a month
jobs at a time
per job
of dependency cache

Everything a pipeline needs, nothing to babysit

Runners, services, caches and logs are part of the product. You write the steps.

Sandboxes that are already running

Each job gets its own sandbox on hardware Enzonic operates, booted ahead of time and thawed when the job arrives.

Matrix jobs and needs

Test on Node 20 and 22 at once, then deploy only when every cell passed. Jobs wait for the jobs they need.

Postgres and Valkey services

Start a real database next to your tests with one line, health-checked before the first step.

Caches

Keep node_modules, pip wheels or build output between runs with a key built from your lockfile.

Artifacts

Keep coverage reports, builds and screenshots, pass them to later jobs and download them for days.

Live logs

Watch every step as it runs, with colours, grouped by step, failing steps opened for you.

Checks on GitHub

Every job reports a check with annotations on the pull request, ready for branch protection.

Your workflows, unchanged

A large subset of GitHub Actions runs as it is: matrix, services, containers and the common setup actions.

Schedules

Nightly tests or weekly dependency checks with a cron line, in UTC.

Enzica fixes failed runs

One click on a failed job: Enzica finds the cause, pushes a fix branch and runs the pipeline on it.

The waiting is gone, so the run is your steps

Most CI time goes to starting a machine, cloning and downloading dependencies. Enzonic CI does that work before your job arrives.

  1. 01

    Sandboxes are thawed, not booted

    A pool of sandboxes is booted ahead of time. When a job arrives, one is thawed and handed to it, so there is no machine to start.

  2. 02

    Checkouts from a local mirror

    Each runner keeps a mirror of your repository and fetches only what changed, instead of cloning from GitHub for every job.

  3. 03

    Caches linked from local disk

    Dependency caches stay on the runner and are linked into the job, not downloaded and unpacked first.

Every job shows where its time went: queue, sandbox, checkout, dependencies, services, cache and steps.

One file in your repository

Commit .enzonic/ci.yml and push. The jobs run in the order their needs set, matrix cells in parallel, each with its own services, cache and artifacts.

  • lint runs first; both test cells start when it passes
  • each test cell gets its own Postgres on localhost and as postgres:5432
  • npm downloads come from the cache keyed on package-lock.json
  • coverage is kept even when the tests fail
  • deploy runs on main only, with a secret the logs never show
name: CI

on:
  push:
    branches: [main]
  pull_request:

jobs:
  lint:
    image: node:22
    steps:
      - run: npm ci
      - run: npm run lint

  test:
    needs: lint
    image: node:${{ matrix.node }}
    matrix:
      node: [20, 22]
    services:
      postgres:
        image: postgres:17-alpine
        env: { POSTGRES_PASSWORD: postgres }
    env:
      DATABASE_URL: postgres://postgres:postgres@postgres:5432/postgres
    cache:
      key: npm-${{ hashFiles('package-lock.json') }}
      paths: [~/.npm]
    steps:
      - run: npm ci
      - run: npm test
    artifacts:
      - name: coverage-node${{ matrix.node }}
        paths: [coverage/]
        when: always

  deploy:
    needs: test
    if: github.ref == 'refs/heads/main'
    steps:
      - run: npx enzonic deploy --prod
        env:
          ENZONIC_TOKEN: ${{ secrets.DEPLOY_TOKEN }}

Already on GitHub Actions?

Connect the repository and your .github/workflows run here without edits, as long as they use what is listed below. Anything else is refused with a clear message, never skipped quietly.

Runs as it is

  • actions/checkoutThe commit of the run is always checked out
  • actions/setup-node, setup-python, setup-go, setup-javaPick the job image; cache: adds the package manager cache
  • oven-sh/setup-bun, pnpm/action-setupBun image, pnpm installed
  • actions/cache (and /restore, /save)A job cache, restored first and saved at the end
  • actions/upload-artifact, download-artifactArtifacts kept with the run and passed between jobs
  • strategy.matrix, needs, if, services, containerIncluding include / exclude and fail-fast

Not supported

  • Other uses: actions, Docker actions, composite actions and reusable workflows
  • Step and job outputs (steps.*.outputs, needs.*.outputs)
  • Windows and macOS runners
  • pull_request_target
The full compatibility list

Pricing

CI comes with your Enzonic Cloud plan, the same plan that covers Deploy and Databases. Start on Free; upgrade when you need more minutes or bigger runners. Linux runners only.

Enzonic CI plans
Every Cloud plan includes CI
Free
$0
Starter
$5 / month
$4.17 a month billed yearly
Recommended
Pro
$10 / month
$8.33 a month billed yearly
Growth
$19 / month
$15.83 a month billed yearly
Business
$29 / month
$24.17 a month billed yearly
CI minutes a month3,0005,0006,00015,00060,000
Jobs at once2461020
Longest job360 min360 min360 min480 min720 min
Dependency cache2 GB5 GB10 GB20 GB50 GB
Artifacts kept90 days90 days90 days180 days400 days
Logs kept14 days30 days30 days60 days90 days

Grants for builders

Building open source, studying, teaching or running a non-profit? Apply for free Pro or Business time and Cloud credit for Deploy and Databases.

  • Pro or Business plan for up to a year, for Deploy and Databases together
  • Cloud credit added to your balance
  • For your personal account or your whole team
  • Read by a person, usually answered within a few days
  • Open source
  • Students
  • Non-profits
  • Startups
  • Educators
  • Hackathons

Questions

What counts as a CI minute?

Every started minute a job runs, rounded up per job. A minute on a medium runner counts twice and on a large runner four times. Time in the queue does not count, and jobs a re-run keeps from the previous attempt cost nothing.

Where do the jobs run?

On servers Enzonic runs itself, the same ones behind Enzonic Deploy and Databases. Every job gets its own gVisor sandbox with its own filesystem and network, and its service containers sit next to it. Jobs never share a machine's kernel with another customer's code.

Why do jobs start so quickly?

Sandboxes are booted ahead of time and thawed when a job arrives, instead of starting a machine for every job. The checkout comes from a local mirror of your repository, and dependency caches are linked from local disk rather than downloaded. Most of a run is your own steps.

Which operating systems can jobs use?

Linux only. Jobs run in Linux containers; Windows and macOS runners are not available.

Can I keep my GitHub Actions workflows?

Yes, when they stick to the supported subset: run steps, matrix, needs, services, container, and the checkout, setup-node, setup-python, setup-go, setup-java, setup-bun, pnpm, cache and artifact actions. A workflow that uses anything else is skipped with a clear message, and the other workflows still run.

What happens with secrets and pull requests from forks?

Secrets are encrypted, only reach the jobs that use them and are masked in the logs. Pull requests from forks run without secrets, without a GitHub token and without saving caches, or not at all if you prefer.

How do results get to GitHub?

As checks, with the failing lines annotated on the pull request, when the GitHub App has the Checks permission. Without it, as commit statuses. Branch protection rules can require them like any other check.

What if a run fails?

You get an email if you want one, and a Fix with Enzica button on the failed job. Enzica reads the log and your config, pushes a fix to a new enzica/ci-fix branch and runs the pipeline on it. Your branches are never changed; you merge the fix if it is right.

Do I need to host my app on Enzonic?

No. CI works for any GitHub repository. Deploy from a job to wherever you host, with a secret for the token, or to Enzonic Deploy.

Which images can a job use?

Any public container image: node, python, golang, eclipse-temurin, oven/bun or your own. Services such as postgres:17 and valkey/valkey:8 start before the steps and are reachable on localhost and by their service name.

Your next push can run here.

Ship the result too: Enzonic Deploy hosts web apps for free.