Bring any pipeline
Use self-managed runners, unsupported CI systems, or known CI systems such as GitHub Actions, GitLab CI, and CircleCI without granting Wodby provider API access.
Integration
Custom CI integrations on Wodby
Use Custom CI when builds run in an external pipeline that Wodby does not need to connect to directly. It works for unsupported CI systems, self-managed runners, or known systems such as GitHub Actions, GitLab CI, and CircleCI when you do not want to connect the provider integration. Wodby CLI creates builds from the app service ID, sends git and build metadata, releases images, and deploys them while the CI system remains outside Wodby provider API control.
CI
Repository link optional
The external pipeline checks out the code, and Wodby CLI sends commit, ref, author, message, build ID, and build number metadata.
Deployment stays explicit
The CI job must call the Wodby CLI deploy step after release because Wodby does not poll, trigger, or rerun Custom CI provider jobs.
Supported workflows
How Custom CI fits into Wodby
Each supported integration kind maps Custom CI into a specific part of the delivery workflow, whether that means pulling source code, running pipelines, relaying email, connecting managed services, or injecting provider credentials into workloads.
CI
Custom CI
Use Custom CI with Wodby CLI when an external pipeline builds, releases, and deploys without provider API access from Wodby.
- Works with unsupported CI systems, self-managed runners, and GitHub Actions, GitLab CI, or CircleCI pipelines where Wodby should not call provider APIs.
- Accepts the provider value detected or supplied by Wodby CLI, including generic values such as unknown.
- Requires the external CI job to run the build, release, and deploy commands because Wodby cannot poll, trigger, or rerun provider jobs.
Related features
Explore the surrounding workflow
This provider usually sits next to stack-based delivery, backup workflows, managed databases, or integration-backed configuration. These pages cover the product surfaces most relevant to Custom CI.
Stack fit
Stacks that commonly pair with Custom CI
Wodby does not treat integrations as isolated setup screens. They become part of stack delivery, so the strongest matches are the stacks where this provider solves a repeated operational problem.
Next.js
Stack
Next.js application stack for frontend and full-stack projects that need a reusable deployment setup.
Next.js is a common fit when pipelines build once and promote the same artifacts through environments.
View stackNode.js
Stack
Node.js application stack for APIs, workers, and custom services with a repeatable runtime setup.
Node.js services often already have test and release logic in CI, with Wodby handling the runtime target.
View stackLaravel
Stack
Laravel application stack for teams that want a reusable setup for web, worker, and queue-based PHP projects.
Laravel teams can keep existing CI while still adopting a reusable stack model on Wodby.
View stack
Compare providers or keep reading
Use the catalog to compare other providers with the same integration kind, or read the broader feature pages to understand how integrations fit into Wodby stacks, CI/CD, backups, and managed services.