Containerized CI/CD pipelines defined in Go — identical builds on your laptop and in CI.
Every team hits the same wall. The build passes on your laptop but breaks in CI. A new developer joins and loses a day setting up their environment. A silent version mismatch ships a broken artifact to production.
You end up debugging your pipeline instead of building your product.
ContainifyCI eliminates this entire class of problems. Define your pipeline in Go, run it in containers, and get identical results everywhere — your machine, your teammate's machine, and CI.
$ engine-ci run
One command. No YAML. No drift. No surprises.
Write your build pipeline in Go — a real language with types, tests, and your IDE's full support. No more guessing if your YAML is valid.
Every step runs inside a container with pinned tool versions. What runs on your laptop is exactly what runs in CI.
One binary, zero dependencies. Works anywhere Docker or Podman runs — macOS, Linux, GitHub Actions, or your own infrastructure.
Containers lock down every tool version. The "but it works on my laptop" conversation is over.
New team members run engine-ci run and get the exact same build as everyone else. No setup wikis. No tribal knowledge.
Go, Java, Python, and more through a modular extension system. Your team learns one workflow regardless of the stack.
Container image scanning, secret management, and automated dependency updates are part of the pipeline — not afterthoughts.
Build steps run in parallel where possible. No configuration needed — ContainifyCI figures out what can run concurrently.
Works with Docker and Podman. Runs in GitHub Actions, GitLab CI, or any environment with a container runtime. Your pipeline is yours.
# 1. Install
go install github.com/containifyci/engine-ci@latest
# 2. Initialize your project
engine-ci init
# 3. Build — same result everywhere
engine-ci run
engine-ci init creates a .containifyci/containifyci.go file — your entire build pipeline in a single Go file that you can read, test, and version-control like any other code.
Here's how dunebot — a real ContainifyCI project — defines its entire build and CI pipeline.
package main
import (
"os"
"github.com/containifyci/engine-ci/client/pkg/build"
"github.com/containifyci/engine-ci/protos2"
)
func main() {
os.Chdir("../")
opts := build.NewGoServiceBuild("dunebot")
opts.Application = "dunebot"
opts.File = "main.go"
opts.Properties = map[string]*build.ListValue{
"goreleaser": build.NewList("true"),
}
build.Serve(opts)
}name: Pull Request
on:
pull_request:
branches: [main]
jobs:
build:
name: Build
uses: containifyci/.github/.github/workflows/pull-request.yml@v1
secrets: inheritname: Release
on:
push:
branches: [main]
paths-ignore: ['.github/**']
jobs:
build-and-release:
uses: containifyci/.github/.github/workflows/release.yml@v1
secrets: inheritOne Go file for your build logic. Two tiny YAML files to connect it to GitHub Actions. The same engine-ci run command works locally and in CI — no divergence, no surprises.
See the full working example at containifyci/dunebot.
ContainifyCI is a growing toolkit for modern CI/CD.
The core — containerized CI/CD pipelines defined in Go
Java & Maven build support
Python build support
GitHub App that auto-reviews and merges dependency PRs
Secret management for GitHub Actions (Google Secret Manager, dotenv, and more)
One-time secret retrieval for secure cloud provisioning
Add auto-update capabilities to any Go CLI
Auto-generate Dependabot configs for multi-folder repos
| YAML Pipelines | Go Pipelines (ContainifyCI) | |
|---|---|---|
| Error detection | Runtime — fails mid-build | Compile time — fails before build starts |
| Testing | Manual / none | Unit tests with go test |
| IDE support | Syntax highlighting only | Full autocomplete, refactoring, go-to-definition |
| Reuse | Copy-paste snippets | Import packages, call functions |
| Debugging | Push and pray | Run locally, set breakpoints |
(.containifyci/containifyci.go)
engine-ci reads your build definition from .containifyci/containifyci.go, compiles it into a self-contained binary, and orchestrates containers to execute each build step in isolation. Tool versions are pinned inside the containers — not on the host machine.
Language support is modular. engine-java and engine-python are extensions that plug into the core. Adding support for a new language means writing a Go package that implements the build interface.
ContainifyCI is open-source under the Apache License 2.0. We welcome every kind of contribution.
Try engine-ci on your project and tell us what breaks.
Found a bug? PRs are always welcome.
Build a language extension and share it with the community.
Open issues, start discussions, share your experience.