App Services

App Services can build from GitLab, 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.

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

Before you start

• 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 dFlow

1. Open Integrations (or Settings → Integrations).
2. Find GitLab, Bitbucket, Gitea, or Azure DevOps and click Connect (or equivalent).
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 (personal access token)

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, enter repository URL and branch, and paste the token if the repo is private.

Bitbucket (workspace or repository token)

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)

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)

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 Applications

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 fails

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

Related

• GitHub integration
• App services
• Security best practices