Git source integrations

App Services can build from Bitbucket, Gitea, and Azure DevOps when you connect the provider under Integrations and supply the token or credentials the dashboard asks for. GitHub uses the GitHub App path (see GitHub integration under Integrations in the sidebar). GitLab uses OAuth for connected accounts (see GitLab integration under Integrations in the sidebar).

Shared prerequisites and permission patterns are in Integration permissions and prerequisites.

Before you startCopy Anchor Link

• You can create or view personal access tokens (or equivalent) in the Git host.
• You have the clone URL (HTTPS) or project path the dFlow UI expects, and the correct branch name.
• Private repos need a token with at least read access to repository contents. Write scope is only needed if your workflow pushes from dFlow (uncommon for deploy-only use).

Connect the provider in dFlowCopy Anchor Link

1. Open Integrations (or Settings → Integrations).
2. Find Bitbucket, Gitea, or Azure DevOps and click Connect (or equivalent). For GitLab, see GitLab integration under Integrations in the sidebar.
3. Paste the token or complete OAuth if offered, using a label that identifies this connection (for example environment or team name).

Expected outcome: The provider appears connected and App Service wizards offer that source type.

GitLab (manual PAT only)Copy Anchor Link

For connected GitLab accounts (OAuth, push webhooks, repository pickers), see GitLab integration under Integrations in the sidebar.

For manual deploys with a repository URL only:

1. In GitLab: Edit profile → Access tokens (or Preferences → Access Tokens, depending on GitLab version).
2. Create a token with a descriptive name and expiry.
3. Scopes: use at least read_repository for clone-only deploys. Add read_api if your GitLab version and the dFlow UI require API access for listing. Add write_repository only if you need push from automation.

In dFlow, create or edit an App Service, open the GitLab tab, choose Manual deployment, enter repository URL and branch, and paste the token if the repo is private.

Bitbucket (workspace or repository token)Copy Anchor Link

Bitbucket offers workspace access tokens and repository access tokens. Availability and labels depend on your Bitbucket plan and product edition.

1. For a workspace token: workspace Settings → Access management → Workspace access tokens (or the equivalent in your UI).
2. For a repository token: Repository settings → Access management → Access tokens.

Grant repository:read (or equivalent read access) for deploys; add write only if required.

If workspace-level tokens are not available on your plan, use a repository access token per repo or another method the Bitbucket UI exposes.

Gitea (personal access token)Copy Anchor Link

1. Settings → Applications → Manage access tokens.
2. Generate a token with at least read:repository; add write:repository only if needed.

Use the Gitea tab on the App Service with repository URL, branch, and token for private repos.

Azure DevOps (Git credentials)Copy Anchor Link

1. Open your Project → Repos.
2. Use Generate Git credentials (or personal access token with Code (read) scope, depending on your org policy).
3. Copy username and password (token) as shown.

Paste into the Azure DevOps fields on the App Service. Treat the password as a secret; rotate on schedule.

Map sources to ApplicationsCopy Anchor Link

Each Service belongs to one Environment inside an Application. Use staging Environments before production, and keep branch names explicit so automatic deploy rules (where supported) do not surprise you. See Environments overview under Environments in the sidebar.

If something failsCopy Anchor Link

• Integration troubleshooting
• Integration issues under Troubleshooting in the sidebar
• Deployment issues under Troubleshooting in the sidebar

RelatedCopy Anchor Link

• GitHub integration
• GitLab integration
• App services
• Security best practices