Run ngit-ci

ngit-ci watches NIP-34 repositories, reads workflows at the exact commit, executes selected jobs, and publishes signed results to Nostr.

There is no runner registration with a central forge. Several coordinators may serve the same repository, and each consumer decides which identities to trust.

The pipeline

1. Watch repository announcements, pushes, and pull request updates.
2. Read matching workflows from .ngit/act/workflows/ at the target commit.
3. Run each job with embedded act or an execution adapter.
4. Publish signed job, progress, and workflow result events.

Compose quick start

git clone nostr://npub15qydau2hjma6ngxkl2cyar74wzyjshvl65za5k5rl69264ar2exs5cyejr/relay.ngit.dev/ngit-ci
cd ngit-ci
NGIT_CI_REPOS=npub1example.../my-repo docker compose up --build -d

The default stack includes a dedicated Docker-in-Docker daemon. On first start, the coordinator creates a signing identity and keeps it in the coordinator data volume.

CI executes repository code

The coordinator does not run workflow steps directly on the host, but its container runtime is still a high-value boundary. Keep the daemon socket out of jobs, enforce resource limits, and use the microVM adapter for less-trusted workflows.

Choose an execution boundary

Runner	Isolation	Use when
Embedded act	Per-job container	You control the repositories and host runtime
Socket adapter	Adapter-defined	You already operate a compatible sandbox
First-party microVM adapter	Fresh QEMU/KVM VM per job	You need a stronger boundary

The coordinator and microVM adapter are separate processes. Their generated configuration pages stay separate so options cannot be applied to the wrong service:

• ngit-ci reference
• coordinator configuration
• coordinator constraints
• secret resolution
• microVM adapter

Execution policy

By default, push and pull-request workflows wait for a maintainer-signed service request addressed to the coordinator. Automatic execution is an explicit trust and resource decision, not a quick-start default.

Write workflows

Repositories use GitHub Actions-compatible workflow syntax at:

.ngit/act/workflows/*.yml

Compatibility is not identical to GitHub-hosted runners. Keep architecture- specific jobs in separate workflow files so a coordinator can claim a complete file it can actually execute.

For contributor-facing commands and trust gates, see CI.

Next

• Use CI with ngit
• Host ngit-grasp
• Self-hosting overview