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.
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.
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/pipery-npm-ci@v0
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/pipery-cloudrun-cd@v0
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:
- remote: https://raw.githubusercontent.com/pipery-dev/pipery-npm-ci/v1/.gitlab-ci.yml
- remote: https://raw.githubusercontent.com/pipery-dev/pipery-cloudrun-cd/v1/.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 template repository in the same Bitbucket workspace:
# shared-pipelines/.bitbucket/shared-pipelines.yml
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-custom: shared-pipelines:master:.bitbucket/shared-pipelines.yml
pipery-standard: shared-pipelines:master
pipelines:
branches:
main:
import: pipery-npm-to-cloudrun@pipery-custom
custom:
run-pipery-npm-to-cloudrun:
import: pipery-npm-to-cloudrun@pipery-standardPipery 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/pipery-docker-ci@v0pipery-dev/pipery-golang-ci@v0pipery-dev/pipery-npm-ci@v0pipery-dev/pipery-python-ci@v0pipery-dev/pipery-java-ci@v0pipery-dev/pipery-cpp-ci@v0pipery-dev/pipery-rust-ci@v0pipery-dev/pipery-terraform-ci@v0CD Actions
pipery-dev/pipery-argocd-cd@v0pipery-dev/pipery-helm-cd@v0pipery-dev/pipery-cloudrun-cd@v0pipery-dev/pipery-ansible-cd@v0pipery-dev/pipery-docker-cd@v0pipery-dev/pipery-terraform-cd@v0If 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.
Social accounts
Follow Pipery for platform updates, demos, and release notes.