Skip to main content

​
Why integrate Devin with GitHub?

Integrating Devin with your GitHub organization enables Devin to create pull requests, respond to PR comments, and collaborate directly within your repositories. This allows Devin to function as a full contributor on your engineering team. To get started, navigate to app.devin.ai > Settings > Integrations > GitHub, click Add Connection, and follow the prompts. You will select which repositories Devin can access and review the required permissions.
Using GitHub Enterprise Server? See the GitHub Enterprise Server Integration guide for setup instructions using personal access tokens.

​
Setting up the Integration

You must be an admin of your GitHub organization to create and manage the Devin integration. Having trouble? Check out our Common Issues.
  1. In your Devin account at app.devin.ai, navigate to Settings > Integrations > GitHub and click Add Connection.
Devin
  1. If you are not already logged in to GitHub, you will be prompted to authenticate.
Devin
  1. Select the GitHub organization you want to connect to Devin.
Devin
  1. Choose whether to grant Devin access to All repositories or Select repositories to control which repositories Devin can access.
Devin
  1. After completing the GitHub authorization, you will be redirected to Devin settings where you can confirm the integration is active.
Devin
We recommend enabling branch protection rules on your main branch to ensure all required checks pass before Devin can merge changes.

​
Using Devin with the GitHub Integration

​
For Core and Teams users

Once the integration is configured, you can @mention repositories directly in your prompts within the Devin web application.

​
For Enterprise users

Once the integration is configured, you can delegate repositories to specific organizations from Enterprise Settings > Repository Permissions.
Devin
If you are working with a repository for the first time, we recommend completing the development environment setup in the onboarding flow to ensure Devin has accurate, up-to-date information about your codebase. Devin automatically responds to PR comments as long as the session has not been archived.

​
Managing Devin’s Permissions in GitHub

During setup, you can grant Devin access to all repositories in your organization or limit access to specific repositories. You can adjust repository access at any time through GitHub’s settings:
  1. Navigate to your GitHub organization’s Settings > GitHub Apps (e.g., https://github.com/organizations/<org_name>/settings/installations)
  2. Select Configure for the Devin.ai integration
  3. Under Repository access, choose to grant access to all repositories or select specific repositories
  4. Click Save to apply your changes
Devin
Devin requires the following permissions: Read access to:
PermissionDescription
dependabot alertsAllows Devin to resolve dependabot alerts on your behalf (i.e. bumping dependency versions)
actionsAllows Devin to view the actions configured for a repository in order to understand if Devin’s changes pass CI
deploymentsAllow Devin to view which versions of a repository were deployed
metadataAllow Devin to view crucial metadata about a repository such as who owns it
packagesAllow Devin to view which versions of a repository were shipped as a package
pagesAllow Devin to consult pages associated with a repository, e.g. to view documentation
repository security advisoriesAllow Devin to view security advisories related to a repo in order to help fix security issues
membersAllow Devin to view members of an organization
webhooksAllow Devin to view the hooks configured for a repository, e.g. linting and type checking
Read and write access to:
PermissionDescription
checksAllows Devin to view and report check results for a repository in order to understand and communicate if Devin’s changes pass CI
commit statusesAllow Devin to view and set commit statuses to indicate if a commit passes CI
contentsAllow Devin to contribute to the codebase
discussionsAllow Devin to contribute to discussions
issuesAllow Devin to open new issues
pull requestsAllow Devin to create new PRs
projectsAllow Devin to view and manage projects associated with a repository, e.g. to retrieve information about a task
workflowsAllow Devin to set up new workflows, e.g. to help configure CI/CD
These permissions enable Devin to work in your repositories as a regular contributor—pushing branches, opening pull requests, and participating in PR discussions.

​
Pull Request Templates

When Devin creates a pull request, it uses a template from your repository to structure the PR description. If you provide a template, Devin follows its format when submitting PRs to GitHub. You can provide Devin with its own template without modifying your default human-facing template by adding a file named devin_pr_template.md in one of the supported PULL_REQUEST_TEMPLATE locations below. This is useful if you want Devin to include additional context, such as a reviewer checklist or a Mermaid diagram of modified files.

​
Template search order

Devin searches for templates in the following order and uses the first match:
  1. PULL_REQUEST_TEMPLATE/devin_pr_template.md
  2. docs/PULL_REQUEST_TEMPLATE/devin_pr_template.md
  3. .github/PULL_REQUEST_TEMPLATE/devin_pr_template.md
  4. pull_request_template.md
  5. docs/pull_request_template.md
  6. .github/pull_request_template.md
If no template is found, Devin uses its default PR description format.
If you want Devin to use your existing pull_request_template.md, copy or symlink it to one of the devin_pr_template.md paths listed above.
For more on GitHub pull request templates (supported locations, multiple templates, query parameters, etc.), see the GitHub Docs: Creating a pull request template for your repository.

​
Commit Signing

To sign Devin’s commits with GPG, configure the key in your environment so it persists across sessions. Generating the key in a session terminal will not work — every Devin session boots from a fresh copy of the machine image, so any keys created mid-session are discarded when the session ends.
GPG signing via environment config only produces Verified commits when Devin is the commit author. GitHub verifies signatures against the author identity, but in any Commit authoring mode where the author is the requesting user (e.g., “Co-authored”, “User only”, “User as author, Devin as committer”), Devin overrides user.email per-session with each user’s own email — which won’t match a single shared GPG key. Set your org’s Commit authoring mode to “Devin only” or “Devin as author, user as committer” before relying on this setup.
Set this up at the org-wide layer (or enterprise layer, if all of your orgs need it) so that every repo gets a signed-commit configuration:
  1. Create (or pick) a dedicated GitHub user account that will own both the commit author identity and the credentials Devin pushes with — e.g., devin@company.com. Using one account for both makes the signing setup straightforward; using two splits the configuration described below across both.
  2. Generate a GPG key locally with that account’s email as the UID, following GitHub’s instructions.
  3. Upload the public key to the GitHub account whose verified email matches the GPG UID, under GitHub Settings > SSH and GPG keys. GitHub verifies signatures against the commit author identity, not the pushing identity — the public key must live on the account that owns the email in user.email. (If that’s the same dedicated account you’re pushing as, you only need to do this once.)
  4. Export the private key, base64-encode it, and add it (along with the matching GIT_USER_NAME / GIT_USER_EMAIL) as secrets in Settings > Secrets.
  5. In your org-wide environment config, import the key and enable signing on every session start. See the copy-paste GPG commit signing example for the full YAML.
The committer email (user.email) must match a UID on the GPG key, and that same email must be a verified email on the GitHub account where you uploaded the public key. If any of these three don’t match, GitHub will show the commit as Unverified even though the signature itself is valid.

​
Security Considerations

  • Branch protection: We recommend enabling branch protection rules on your main branch to ensure all required checks pass before Devin can merge changes.
  • Organization-level permissions: Devin uses the permissions granted at the organization level, not the permissions of the individual user running a session.
  • Consistent access: All users with access to both the GitHub and Devin organizations share the same Devin integration permissions.
  • Repository creation: Devin cannot create new repositories in your GitHub account.

​
IP Allowlisting

If your organization requires IP allowlisting for GitHub access, add the following IP addresses:
  • 100.20.50.251
  • 44.238.19.62
  • 52.10.84.81
  • 52.183.72.253
  • 20.172.46.235
  • 52.159.232.99
  • 4.204.199.103
These IP addresses may change in future updates. We recommend monitoring our release notes for any changes.

​
Troubleshooting: GitHub organization connected to the wrong Devin organization

If your GitHub organization is already connected to a Devin organization you don’t have access to, a GitHub org admin can remove the existing installation and reinstall it under a different Devin organization.
We recommend confirming with the owner of the current Devin organization before removing the installation.
  1. Go to github.com/settings/installations and click Configure next to Devin.ai Integration. If needed, switch to the correct GitHub organization context using the Go to settings page dropdown in the top right.
    Switch GitHub settings context
  2. On the installation page, scroll to the Danger zone section and click Uninstall to remove the Devin.ai Integration from the GitHub organization.
    Uninstall Devin.ai Integration
  3. Return to app.devin.ai and refresh the page. You can now reinstall the GitHub integration under your Devin organization.

​
GitHub Integration FAQs

Yes, you can connect either a GitHub Organization or a personal GitHub account to your Devin organization. However, we recommend connecting the account that has the appropriate permissions for Devin to access the repositories your team needs.
Only users who are members of the organization that installed the GitHub integration can use it in their Devin sessions. Devin inherits access to the GitHub integration based on the user’s organization membership.
Encryption keys are managed by AWS KMS and rotated periodically.