Your pipeline. Your platform.
Keep your CI.
Ship with Wodby.
Keep the workflows your team knows. Our setup tools connect your pipeline to Wodby, so you can build your application stack and deploy it on Wodby Cloud or your own infrastructure.
One flow, across providers
Build
Build service images using your stack or Dockerfile.
Push
Publish images to the registry connected to your app.
Deploy
Roll out your build to the selected Wodby environment.
An existing app. A few variables. Your first deployment.
Create an app in Wodby, choose its stack and environment, and select your CI provider. Copy the buildable app service ID from Wodby and create an API key. Then add the variables below to your CI provider and commit the pipeline file to your repository.
GitHub, GitLab, and CircleCI examples deploy from main and assume the matching app setup described in each tab. Adapt service names and build steps to your project; full examples include additional options such as caching.
From a GitHub push to a running app.
Install and authenticate Wodby CLI with the official setup action, then run build, push, and deployment commands from a GitHub Actions workflow.
Connect it once
Add WODBY_API_KEY as a repository secret and WODBY_APP_SERVICE_ID as a repository variable. The setup action installs, authenticates, and initializes Wodby CLI.
A Composer project with composer.lock and a PHP stack.
name: Deploy to Wodby
on:
push:
branches: [main]
workflow_dispatch:
permissions:
contents: read
jobs:
deploy:
runs-on: ubuntu-24.04
steps:
- uses: actions/checkout@v6
- uses: wodby/actions/setup-wodby-cli@v1
with:
api-key: ${{ secrets.WODBY_API_KEY }}
app-service-id: ${{ vars.WODBY_APP_SERVICE_ID }}
- run: wodby ci run -- composer install --prefer-dist -n --no-ansi
- run: wodby ci build
- run: wodby ci push
- run: wodby ci deploy
Keep delivery in GitLab.
Run the official Wodby CLI container image in GitLab CI. Pipelines that build application images can pair it with Docker-in-Docker.
Connect it once
Set WODBY_API_KEY as a masked CI/CD variable and WODBY_APP_SERVICE_ID as a CI/CD variable. Use a runner configured for privileged Docker-in-Docker builds.
A Composer project with composer.lock and a PHP stack.
image:
name: wodby/wodby-cli:2.0
pull_policy: always
services:
- name: docker:dind
alias: docker
stages: [deploy]
deploy:
stage: deploy
rules:
- if: '$CI_COMMIT_BRANCH == "main"'
script:
- wodby ci init --dind "$WODBY_APP_SERVICE_ID"
- wodby ci run -- composer install --prefer-dist -n --no-ansi
- wodby ci build
- wodby ci push
- wodby ci deploy
One orb to connect your workflow.
Use the official CircleCI orb with a machine executor to install and initialize Wodby CLI before running the Wodby build and deployment flow.
Connect it once
Set WODBY_API_KEY and WODBY_APP_SERVICE_ID in your CircleCI project environment. The orb installs and initializes the CLI on a machine executor with Docker.
A Composer project with composer.lock and a PHP stack.
version: 2.1
orbs:
wodby: wodby/setup-wodby-cli@1
jobs:
deploy:
machine:
image: ubuntu-2604:current
steps:
- checkout
- wodby/setup:
app-service-id: $WODBY_APP_SERVICE_ID
- run: wodby ci run -- composer install --prefer-dist -n --no-ansi
- run: wodby ci build
- run: wodby ci push
- run: wodby ci deploy
workflows:
deploy:
jobs:
- deploy:
filters:
branches:
only: main
Built-in Wodby CI
Prefer a pipeline that comes with the platform?
Start with Wodby CI and keep your builds and deployments together. Add a pipeline to your app service’s connected Git repository and run the same build, push, and deploy commands.
Choose Wodby CI for your app and connect its build source. Wodby provides the CLI and build ID, so you do not need the external-provider setup action or orb.
Explore built-in CI/CD →A Composer project with composer.lock and a PHP stack.
version: 0.1
workflows:
main:
jobs: [deploy]
jobs:
deploy:
steps:
- clone
- run: wodby ci init $WODBY_BUILD_ID
- run: wodby ci run -- composer install --prefer-dist -n --no-ansi
- run: wodby ci build
- run: wodby ci push
- run: wodby ci deploy
Another CI? Bring it along.
Use Custom CI with Wodby CLI from a runner with Docker. Your pipeline checks out the code, initializes the build, and runs the same release flow. Keep run controls in your CI provider; Custom CI does not poll provider APIs or trigger reruns.
Run a simple Bash script
Install Wodby CLI on a runner with Bash, Git, and access to Docker. Select Custom CI in Wodby and set WODBY_API_KEY as a CI secret and WODBY_APP_SERVICE_ID as the buildable app service ID. Map your provider’s run ID and build number to CI_BUILD_ID and CI_BUILD_NUMBER.
After checkout, run bash deploy.sh from the repository root. Configure your CI job to run only on your deployment branch.
A Composer project with composer.lock and a PHP stack.
#!/usr/bin/env bash
set -euo pipefail
# Run from your checked-out repository with Wodby CLI and Docker installed.
: "${WODBY_API_KEY:?Set WODBY_API_KEY in your CI secrets}"
: "${WODBY_APP_SERVICE_ID:?Set the buildable app service ID}"
: "${CI_BUILD_ID:?Set your CI run ID}"
: "${CI_BUILD_NUMBER:?Set your CI build number}"
wodby ci init \
--provider unknown \
--build-id "$CI_BUILD_ID" \
--build-num "$CI_BUILD_NUMBER" \
"$WODBY_APP_SERVICE_ID"
wodby ci run -- composer install --prefer-dist -n --no-ansi
wodby ci build
wodby ci push
wodby ci deploy