CI/CD
CI/CD that fits the stack your team is already shipping
Build and deploy through Wodby CI or plug the platform into your existing automation without recreating the release workflow from scratch.
Release automation works better when it understands the application stack underneath it. Wodby connects Git providers, build pipelines, registries, release steps, and deployment targets in one workflow so teams can move faster with fewer manual release steps and less platform glue code.
Reduce release friction before you add more tooling
The biggest CI/CD gains often come from removing repeated manual setup and keeping environments consistent.
- Reduce the time spent wiring pipelines to infrastructure by hand.
- Keep development, testing, and production closer to the same release model.
- Make deployments safer because the process becomes repeatable.
Connect Git providers directly to the release workflow
Repositories should be easy to attach to the platform so builds and environments can react to changes quickly.
Wodby integrates with supported Git providers so teams can connect repositories, create applications, and start using build and deployment automation without stitching together separate identity and repository handoffs.
Use built-in Wodby CI when you want the fastest path to working pipelines
Some teams want automation quickly without building the CI foundation themselves.
Wodby CI provides ready-to-use build pipelines that understand the platform model. Many services include templates in .wodby/pipeline.yml, which shortens setup time and keeps the release workflow aligned with how the application is actually deployed.
Pipelines run the same app-aware flow used by external CI: initialize the build, build service images, release them to the configured registry, and deploy the released images. Teams can also define .wodby/post-deployment.yml scripts that run after deployments complete.
Teams can also start from public examples in the wodby/wodby-ci repository and adapt them to their own delivery process.
- Start from stack-aware templates instead of assembling pipelines from scratch.
- Trigger builds from Git activity and keep release automation closer to the app workflow.
- Run post-deployment scripts after the application deployment finishes.
Bring your existing CI system if that is already where your team works
Wodby does not force a full CI migration just to use the platform.
Teams can keep their existing GitHub Actions, GitLab CI, CircleCI, or other CI workflows and deploy into Wodby using Wodby CLI. The CLI reads stack information and runs the same init, build, release, and deploy flow, which makes it easier to adopt the platform incrementally without breaking established automation or retraining every team all at once.
- Use
WODBY_API_KEYandWODBY_APP_SERVICE_IDto authenticate third-party CI jobs. - Let the CLI detect Git and build metadata automatically in GitHub Actions, GitLab CI, and CircleCI.
- Prefer VM-style runners when Docker image builds need simpler access to Docker.
- Keep provider-specific setup in CI while Wodby handles release and deployment state.
Handle container images and rollbacks inside the same release model
Reliable delivery depends on how images are stored, pulled, and reversed when a release goes wrong.
Wodby Registry is the default registry path for teams that want an integrated image store, while external registries remain available when existing compliance, security, or tooling requirements make that the better choice.
Deployments use the released images from the current build, and deployment history stays attached to the app instance. Deployments are transactional by default, so Wodby can roll back the whole deployment when one service fails.
- Use Wodby Registry by default or bring Docker Hub or another compatible registry.
- Keep image delivery tied to the same deployment workflow used by the platform.
- Keep deployment history and rollback behavior connected to app instance deploys.
Next step
Automate releases without disconnecting CI from the rest of the platform
Use Wodby CI when you want a ready-to-go path, or keep your existing CI system and still deploy cleanly into the same application workflow.