Bring your own CI
Keep your runners, tests, and approval steps. Use Wodby CLI to build your stack and deploy from your existing workflow.
Connect your pipeline →CI/CD
Your pipeline. From commit to running app.
Use built-in Wodby CI or keep the CI your team already knows. Build, push, and deploy your application stack, then follow every deployment in Wodby.
- Choose built-in CI or connect your existing pipeline
- Build and deploy services together as an application stack
- Track deployments and restore eligible previous builds
Two ways to build. One place to deploy.
Choose the setup that fits your team and keep deployment history in Wodby.
Use built-in Wodby CI
Start from a Wodby boilerplate or add a pipeline to your repository. Run builds without setting up a separate CI provider.
Explore Wodby CI →Build. Push. Deploy.
The same stack-aware workflow powers built-in and external CI.
Build
wodby ci buildBuild service images from your source using stack configuration or your own Dockerfile.
Push
wodby ci pushUpload your images to Wodby Registry or a compatible external registry.
Deploy
wodby ci deployRoll out the build to your target environment, for all services or selected services.
Keep the CI your team already uses
Use an official setup tool, then add Wodby build, push, and deploy commands to your pipeline.
GitHub Actions
wodby/actions/setup-wodby-cli@v1CircleCIwodby/setup-wodby-cli@1GitLab CIwodby/wodby-cli:2.0Using another provider or a self-managed runner? Use Custom CI with a Bash script →
See setup tools and pipeline examples →Start with CI built into Wodby
Keep your pipeline in Git and your build history alongside the app.
Use a pipeline from a Wodby boilerplate or define your own in .wodby/pipeline.yml. Wodby provides the build environment and CLI so your pipeline can install dependencies, build images, push, and deploy.
- Start from pipeline examples for your application stack.
- Run application commands and tests as part of the build.
- Use pipeline cache steps to reuse downloaded dependencies.
- Review build history from your application in Wodby.
Connect the source you already work with
Use GitHub, GitLab, or Bitbucket as a build source for Wodby CI.
Drop us a line at hello at wodby dot com and tell us more!didn't find your integration?
With external CI, your pipeline checks out the code. Wodby CLI reads Git metadata from that checkout, so you can build without separately linking the repository in Wodby.
Automate the work after deployment
Keep application-specific follow-up tasks with the code they belong to.
Define scripts in .wodby/post-deployment.yml to run after an eligible successful rollout. Use them with Wodby CI or external CI, and review their logs as a separate task.
A script failure appears as a post-deployment warning. It does not mark the application deployment as failed or trigger rollback, and you can retry the task without redeploying.
Configure post-deployment scripts →See what changed. Recover when needed.
Follow deployment outcomes and choose an eligible previous build when an application image needs to be restored.
- See which services were deployed and how the deployment finished.
- Deploy only the services included in your change.
- Restore eligible previous builds per service.
- Review compatibility warnings for builds from older stack revisions.
When an app service upgrade fails workload health checks, automatic rollback makes a best-effort attempt to restore that service to its latest successful release. Services that already deployed successfully are not reverted.
Build rollback restores application images. It does not downgrade the stack or restore databases, configuration, secrets, volumes, or other persistent data. Use backups for data recovery.
Review rollback behavior →Next step
Connect your pipeline. Deploy your next change.
Choose your CI provider and app type to find a concise pipeline you can adapt to your project.