Standardized
Consistent pipelines across repos, teams, and CI platforms.
Verified, reusable, observable pipelines

Pipery is a vendor-neutral CI/CD standardization layer for reusable delivery workflows. Start with GitHub Actions, run the same delivery logic on GitLab CI or Bitbucket Pipelines, and keep your pipelines portable as your platform changes.
See how Pipery turns reusable GitHub Actions, GitLab CI, and Bitbucket Pipelines workflows, structured psh logs, and replayable pipery.jsonl output into a clearer CI/CD workflow.
CI/CD pipelines should not be this hard.
Every team ends up rebuilding the same pipelines: copy-pasted YAML, slow and flaky builds, security risks from untrusted workflows, vendor-specific delivery logic, and almost no visibility into what is actually going wrong.
You do not need another CI tool. You need portable delivery logic.
Pipery lets teams define CI/CD once and run it across platforms like GitHub Actions, GitLab CI, and Bitbucket Pipelines.
It provides production-grade, reusable CI/CD pipelines that are standardized, versioned, secure, observable, and designed to reduce CI/CD vendor lock-in.
Consistent pipelines across repos, teams, and CI platforms.
Stable releases with predictable upgrades.
Reviewed and maintained to reduce workflow risk.
Move delivery logic across vendors without starting from blank YAML.
The current Pipery action release is v1.1.0 across the supported CI and CD action catalog. This release focuses on portability, release safety, and GitOps handoff: Go and C/C++ actions support cross-platform compilation, action scenario tests run before release, and the ArgoCD CD action can validate Helm charts before publishing deployment updates.
Use exact v1.1.0 tags in GitHub Actions, GitLab CI includes, and Bitbucket shared pipeline imports when you want fully reproducible adoption.
Go and C/C++ CI can build release artifacts for Linux amd64, Linux arm64, Windows amd64, and Darwin amd64 targets.
Each action repository keeps runnable test projects and scenario coverage so workflow changes are tested before a new release is published.
pipery-argocd-cd@v1.1.0 can validate Helm dependencies, lint charts, render templates, and publish values-driven ArgoCD updates.
Your delivery logic should not be trapped inside one CI vendor.
Pipery is moving CI/CD from provider-specific workflow files toward reusable delivery standards. Use the same Pipery pipeline family from GitHub Actions, GitLab CI, or Bitbucket Pipelines today, and keep a path open for future platforms like CircleCI, Jenkins, and Azure DevOps.
Standardize the build, scan, package, release, and deploy flow as Pipery pipeline logic instead of rewriting it per repository.
Generate GitHub Actions workflows, GitLab CI YAML, or Bitbucket Pipelines YAML from the same catalog of CI and CD building blocks.
When teams move between GitHub, GitLab, or future providers, the delivery model stays familiar.
psh and pipery.jsonl give every supported backend the same structured debugging trail.
Pipery also includes GitHub App services for the parts of delivery that should be deliberate: creating release branches, tagging releases, and scheduling one-time deploys with a clear audit trail.
Create configured release/* branches through a GitHub App, optionally tag them, and publish GitHub Releases from markdown release notes stored in the repository.
Schedule a one-time deploy from a workflow, trigger the selected GitHub Actions job at the requested time, and track attempts in Postgres with a dashboard.
Bots validate Dex-issued tokens, ship Helm charts, and publish ArgoCD Application updates into the private pipery-argocd repository on every release.
From YAML chaos to clean pipelines.
Replace hundreds of lines of brittle vendor-specific workflow logic with a single, trusted pipeline. Pick a platform to see the before and after.
name: Node CI/CD
on:
push:
branches: [main]
pull_request:
permissions:
contents: read
id-token: write
env:
REGISTRY: europe-west1-docker.pkg.dev
IMAGE_NAME: pipery/api
jobs:
ci:
runs-on: ubuntu-latest
steps:
- uses: actions/checkout@v4
- uses: actions/setup-node@v4
with:
node-version: 20
cache: npm
- run: npm ci
- run: npm run lint
- run: npm test -- --ci
- run: npm run build
- uses: google-github-actions/auth@v2
with:
workload_identity_provider: ${{ secrets.GCP_WIF_PROVIDER }}
service_account: ${{ secrets.GCP_CI_SA }}
- uses: docker/setup-buildx-action@v3
- run: gcloud auth configure-docker europe-west1-docker.pkg.dev
- run: |
docker build -t $REGISTRY/$IMAGE_NAME:${GITHUB_SHA} .
docker push $REGISTRY/$IMAGE_NAME:${GITHUB_SHA}
deploy:
needs: ci
runs-on: ubuntu-latest
if: github.ref == 'refs/heads/main'
steps:
- uses: actions/checkout@v4
- uses: google-github-actions/auth@v2
with:
workload_identity_provider: ${{ secrets.GCP_WIF_PROVIDER }}
service_account: ${{ secrets.GCP_DEPLOY_SA }}
- uses: google-github-actions/get-gke-credentials@v2
with:
cluster_name: prod-cluster
location: europe-west1
project_id: acme-platform-prod
- run: |
kubectl set image deployment/api \
api=$REGISTRY/$IMAGE_NAME:${GITHUB_SHA} \
--namespace production
kubectl rollout status deployment/api --namespace productionname: Node CI/CD
on:
push:
branches: [main]
pull_request:
permissions:
contents: write
id-token: write
packages: write
jobs:
ci:
uses: pipery-dev/npm-ci@v1.1.0
with:
node_version: 20
package_manager: npm
run_lint: true
run_tests: true
build_command: npm run build
publish: true
secrets: inherit
deploy:
needs: ci
if: github.ref == 'refs/heads/main'
uses: pipery-dev/cloudrun-cd@v1.1.0
with:
image_name: api
region: europe-west1
project_id: acme-platform-prod
secrets: inheritstages:
- test
- build
- deploy
variables:
IMAGE_NAME: pipery/api
REGISTRY: registry.gitlab.com/acme/platform
npm_test:
stage: test
image: node:20
script:
- npm ci
- npm run lint
- npm test -- --ci
- npm run build
docker_build:
stage: build
image: docker:27
services:
- docker:27-dind
script:
- docker login -u "$CI_REGISTRY_USER" -p "$CI_REGISTRY_PASSWORD" "$CI_REGISTRY"
- docker build -t "$REGISTRY/$IMAGE_NAME:$CI_COMMIT_SHA" .
- docker push "$REGISTRY/$IMAGE_NAME:$CI_COMMIT_SHA"
deploy:
stage: deploy
image: google/cloud-sdk:slim
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
script:
- gcloud auth activate-service-account --key-file "$GCP_SERVICE_ACCOUNT_KEY"
- kubectl set image deployment/api api="$REGISTRY/$IMAGE_NAME:$CI_COMMIT_SHA" --namespace production
- kubectl rollout status deployment/api --namespace productioninclude:
- project: pipery-dev/npm-ci
ref: v1.1.0
file: /.gitlab-ci.yml
- project: pipery-dev/cloudrun-cd
ref: v1.1.0
file: /.gitlab-ci.yml
stages:
- ci
- cd
variables:
PIPERY_PROJECT_PATH: .
PIPERY_NODE_VERSION: "20"
PIPERY_RUN_LINT: "true"
PIPERY_RUN_TESTS: "true"
PIPERY_BUILD_COMMAND: npm run build
PIPERY_IMAGE_NAME: api
PIPERY_REGION: europe-west1
PIPERY_PROJECT_ID: acme-platform-prod
pipery_npm_ci:
stage: ci
extends: .pipery_npm_ci
pipery_cloudrun_cd:
stage: cd
extends: .pipery_cloudrun_cd
needs:
- pipery_npm_ci
rules:
- if: '$CI_COMMIT_BRANCH == "main"'image: node:20
definitions:
services:
docker:
memory: 2048
pipelines:
branches:
main:
- step:
name: Test and build
caches:
- node
script:
- npm ci
- npm run lint
- npm test -- --ci
- npm run build
- step:
name: Build image
services:
- docker
script:
- docker login -u "$REGISTRY_USER" -p "$REGISTRY_PASSWORD" "$REGISTRY"
- docker build -t "$REGISTRY/pipery/api:$BITBUCKET_COMMIT" .
- docker push "$REGISTRY/pipery/api:$BITBUCKET_COMMIT"
- step:
name: Deploy
deployment: production
script:
- gcloud auth activate-service-account --key-file "$GCP_SERVICE_ACCOUNT_KEY"
- kubectl set image deployment/api api="$REGISTRY/pipery/api:$BITBUCKET_COMMIT" --namespace production
- kubectl rollout status deployment/api --namespace production# Pipery shared pipeline repository in the same Bitbucket workspace:
# https://bitbucket.org/pipery-dev/npm-ci/
export: true
definitions:
pipelines:
pipery-npm-to-cloudrun:
- step:
name: Setup npm Environment
image: node:20-alpine
caches:
- node
script:
- cd ${PROJECT_PATH:-.}
- npm ci
- parallel:
- step:
name: SAST Security Scan
image: python:3.11-alpine
script:
- pip install --quiet pipery-tooling
- pipery-tooling sast --project-path ${PROJECT_PATH:-.} --log-file ${LOG_FILE:-pipery.jsonl}
- step:
name: SCA Security Scan
image: python:3.11-alpine
script:
- pip install --quiet pipery-tooling
- pipery-tooling sca --project-path ${PROJECT_PATH:-.} --log-file ${LOG_FILE:-pipery.jsonl}
- step:
name: Build Application
image: node:20-alpine
script:
- cd ${PROJECT_PATH:-.}
- npm run build
- step:
name: Deploy to Cloud Run
image: google/cloud-sdk:alpine
script:
- pipery-cloudrun deploy
- step:
name: Publish Pipery Logs
script:
- test -f ${LOG_FILE:-pipery.jsonl} && tail -n 20 ${LOG_FILE:-pipery.jsonl} || true
---
# Application repository:
# bitbucket-pipelines.yml
definitions:
imports:
pipery-npm-ci: pipery-dev/npm-ci:v1.1.0
pipery-cloudrun-cd: pipery-dev/cloudrun-cd:v1.1.0:.bitbucket/shared-pipelines.yml
pipelines:
branches:
main:
import: pipery-npm-ci@pipery-npm-ci
custom:
deploy-cloudrun:
import: pipery-cloudrun-cd@pipery-cloudrun-cdPipery workflows run task scripts through psh, the Pipery Shell. Instead of asking every pipeline author to hand-write logging, psh observes each command as it runs and writes structured events to pipery.jsonl.
Each logged command carries timing, working directory, runner context, environment details, arguments, exit status, and captured output.
pipery.jsonl is line-delimited JSON, so it can be uploaded as a workflow artifact, searched in the dashboard, or inspected locally with ordinary CLI tools.
Because the log records what ran and how it ran, Pipery can replay the captured execution path so a developer can reproduce a failing step with the same command shape.
{"timestamp":"2026-04-29T10:21:18.492351Z","started_at":"2026-04-29T10:21:15.083104Z","finished_at":"2026-04-29T10:21:18.492351Z","duration":"3.409247s","duration_ms":3409,"system_cpu_cores":4,"system_memory_bytes":17179869184,"process_user_cpu_ms":812,"process_system_cpu_ms":143,"process_max_rss_bytes":73400320,"mode":"shell","builtin":false,"command":"/bin/bash","args":["-lc","docker build -t ghcr.io/acme/api:sha-abc123 ."],"raw_command":"docker build -t ghcr.io/acme/api:sha-abc123 .","before_cwd":"/github/workspace","cwd":"/github/workspace","before_env":["GITHUB_ACTIONS=true","RUNNER_OS=Linux"],"env":["GITHUB_ACTIONS=true","RUNNER_OS=Linux"],"stdin":"","stdout":"Successfully built image\\n","stderr":"","exit_code":0,"pid":12842}
{"timestamp":"2026-04-29T10:22:07.819604Z","started_at":"2026-04-29T10:22:04.112008Z","finished_at":"2026-04-29T10:22:07.819604Z","duration":"3.707596s","duration_ms":3707,"system_cpu_cores":4,"system_memory_bytes":17179869184,"process_user_cpu_ms":1204,"process_system_cpu_ms":196,"process_max_rss_bytes":104857600,"mode":"shell","builtin":false,"command":"/bin/bash","args":["-lc","npm test -- --ci"],"raw_command":"npm test -- --ci","before_cwd":"/github/workspace","cwd":"/github/workspace","before_env":["GITHUB_ACTIONS=true","RUNNER_OS=Linux"],"env":["GITHUB_ACTIONS=true","RUNNER_OS=Linux"],"stdin":"","stdout":"","stderr":"1 failing test\\n","exit_code":1,"pid":12911}Pipery Dashboard turns raw pipeline logs into a searchable debugging workspace. Open a workflow run, inspect the pipery.jsonl timeline, and move from “the build failed” to the exact command, output, timing, and context that explain why.
Browse recent workflow runs and open their Pipery logs without digging through downloaded artifacts by hand.
Filter entries by command, output, status, timing, or environment context so the noisy parts of CI stay out of the way.
Reopen recent logs for offline review, compare what changed between runs, and share a clearer failure story with the team.
Everything your pipelines were missing.
Use the same proven pipelines across repositories and CI providers.
Reduce exposure to risky third-party actions and fragile workflow logic.
Pin versions, manage upgrades cleanly, and avoid breaking changes.
Track runtime, failures, and trends across your pipelines.
Ship with faster builds, better defaults, and less CI waste.
GitHub Actions, GitLab CI, and Bitbucket Pipelines are supported now, with more CI ecosystems on the roadmap.
Start with the essentials.
CI Actions
pipery-dev/docker-ci@v1.1.0pipery-dev/golang-ci@v1.1.0pipery-dev/npm-ci@v1.1.0pipery-dev/python-ci@v1.1.0pipery-dev/java-ci@v1.1.0pipery-dev/pipery-kotlin-ci@mainpipery-dev/pipery-android-ci@mainpipery-dev/pipery-swift-ci@mainpipery-dev/pipery-ios-ci@mainpipery-dev/cpp-ci@v1.1.0pipery-dev/rust-ci@v1.1.0pipery-dev/terraform-ci@v1.1.0CD Actions
pipery-dev/argocd-cd@v1.1.0pipery-dev/helm-cd@v1.1.0pipery-dev/cloudrun-cd@v1.1.0pipery-dev/pipery-googleplay-cd@mainpipery-dev/pipery-appstore-cd@mainpipery-dev/ansible-cd@v1.1.0pipery-dev/docker-cd@v1.1.0pipery-dev/terraform-cd@v1.1.0If you want a faster path than reading every README, start with one of these action-specific guides. Each one shows the workflow shape, the inputs that matter first, and where Pipery observability helps when a run fails.
Built for teams tired of rewriting pipelines every time repositories, standards, or vendors change.
Pipery is designed for startups and platform teams that want faster, safer, and more maintainable CI/CD without rebuilding the same workflows over and over again. It gives platform engineering teams a practical delivery portability layer today, without requiring a heavy custom DSL before the value is obvious.
Stop maintaining vendor-specific pipelines.
Start shipping faster with Pipery.