openpreflight icon

openpreflight

openpreflight is a self-hosted CI service for GitHub repositories, running install, test, and build pipelines with native Check Runs on your infrastructure.

openpreflight

Self-hosted CI for focused GitHub checks

openpreflight is a self-hosted continuous integration service for GitHub repositories. It runs as a Go binary on infrastructure you control, receives GitHub webhooks through a GitHub App, and publishes native Check Runs for configured commits.

It is designed for repositories that need a straightforward pull-request or branch gate based on install, test, and build commands. Configuration can live in .ci.yml or in repository bindings, while execution uses the host process or an explicitly selected Docker runtime. The product deliberately omits broader pipeline orchestration such as matrices, artifacts, and parallel stages.

Features

Single-process CI service

A single Go binary combines the web UI, JSON API, webhook receiver, and job runner, without a separate message broker or frontend deployment.

Native GitHub Check Runs

Create or register a GitHub App, bind repositories, and enable branches and optional path patterns from the web UI. Installation tokens are minted per job.

Simple command pipelines

Define install, test, and build commands in a root .ci.yml file, or override them per repository binding. A non-empty runtime image runs steps with docker run --rm.

Commit-specific execution

The worker fetches the exact commit, uses a detached checkout, removes remote credentials before execution, and enforces a run timeout.

Run status and logs

Stdout is sent to the GitHub Check Run while the complete log is available on the product's details page. Runs support passed, failed, skipped, error, and cancelled states, with re-run controls shown in the interface.

SQLite-backed storage

State is stored in one SQLite file, with secret columns encrypted at rest using AES-256-GCM. Run history and logs are pruned according to a retention window.

Use cases

  • Private repository gates

    Bind a private repository to a GitHub App, define its test and build commands, and use the resulting Check Run as a required branch-protection check.

  • Small self-hosted teams

    Run focused CI on a VPS or other host the team already operates, using one process and a SQLite file rather than deploying a separate CI platform stack.

  • Open-source contribution checks

    Give contributors an automated check for straightforward repository commands while retaining control over the worker host and repository bindings.

  • Mixed repository conventions

    Keep repository-specific commands in .ci.yml, with binding-level overrides for repositories that need different branches, paths, commands, or timeouts.

Pros and Cons

Pros

  • Native GitHub Check Runs can be used as a single branch-protection gate.
  • A single Go binary includes the main service components, reducing the number of deployed services.
  • Repository commands can be kept in a small .ci.yml file without GitHub Actions workflow boilerplate.
  • The worker handles exact-commit checkout, credential cleanup, timeouts, encrypted secret storage, and retained logs.

Cons

  • The pipeline model is intentionally narrow: it does not provide matrices, parallel stages, conditional steps, caches, or artifacts between steps.
  • Execution and persistence are centered on infrastructure you operate, including the host, SQLite state, webhook endpoint, and optional Docker engine.
  • The site does not publish pricing information; the pricing URL currently returns a not-found page.

FAQ

How is openpreflight installed?

Install the Go binary with Docker Compose or run a release binary, open the web UI, complete the first-boot wizard, register a GitHub App, and enable repository bindings. A Docker Compose example is provided on the product site.

How does a run move from a GitHub event to a Check Run?

A GitHub App receives check-suite webhooks at the configured host, where HMAC is verified and the delivery is queued. The worker creates a Check Run, fetches the exact commit, runs the configured commands, and reports the result to GitHub; full logs remain available on the details page.

What can a pipeline run?

The pipeline supports install, test, and build shell commands, an optional runtime container image, and a timeout. Configuration can come from .ci.yml, binding overrides, or limited Node defaults inferred from package.json.

When is openpreflight not the right fit?

No. The documented scope excludes stages or needs, fan-out and parallel steps, conditional steps, caches between runs, artifacts between steps, build matrices, and steps outside install, test, and build. GitHub Actions remains the better fit when those capabilities or multi-platform runners are required.

Can teams use one GitHub App across multiple repositories?

One worker produces one Check Run for a job, which can be selected in branch protection. A single GitHub App can cover multiple repositories, but each repository still needs its own enabled binding.

Quick Facts

Category
Developer Tool / Self-hosted CI
Primary platform
GitHub repositories and Check Runs
Deployment
Docker Compose or release binary on infrastructure you control
Core runtime
Go binary with SQLite state
Pipeline model
Install, test, and build commands; optional Docker runtime
Source domain
openpreflight.xyz