Skip to content

Git repository

Start by creating a Git integration from a supported Git provider such as GitHub, GitLab, or Bitbucket. A connected build source inherits the app instance's Default CI. Under Wodby CI, its selected repository and ref are required. Under third-party CI, linking the repository in Wodby is optional because the CI provider performs the checkout. Public and cloned boilerplate sources use Wodby CI regardless of Default CI.

Repository authentication

Wodby CI clones connected Git-provider repositories over HTTPS and authenticates with the connected integration.

Wodby does not inject a shared SSH private key into builds. An SSH clone URL requires an app-service-specific private key named id_rsa; without that key, use the connected repository's HTTPS clone URL instead. Keys configured for one app service are not shared with other app services.

If you use Wodby CI, keep the pipeline definition in the repository itself:

  • .wodby/pipeline.yml
  • .wodby/post-deployment.yml (optional)

If you use third-party CI, keep the provider-native config in the repository root, for example:

  • .github/workflows/wodby.yml
  • .gitlab-ci.yml
  • .circleci/config.yml

In Wodby CI, the clone step checks out the repository configured as the build source. In third-party CI, the CI provider performs the checkout and Wodby CLI works from that existing workspace.

You can change the repository and the selected branch or tag for an existing app instance from the Build Source section of the app service when a repository is linked.

For example configurations, see the wodby/wodby-ci repository.