How do I connect OpenHands to GitHub Enterprise and Jira/Slack for a team rollout?

Most engineering orgs don’t fail at “trying agents.” They fail at connecting those agents cleanly to GitHub Enterprise, Jira, and Slack in a way security trusts, engineers adopt, and governance can audit. A team rollout of OpenHands isn’t just about turning on an LLM—it’s about wiring a cloud coding agent platform into your SDLC without introducing a new class of risk.

Quick Answer: Connect OpenHands to GitHub Enterprise and Jira/Slack by deploying it in a secure, sandboxed runtime (self-hosted or private cloud), configuring OAuth or app-based integrations to GitHub Enterprise, Jira, and Slack, and then delegating work from those systems into OpenHands via webhooks, APIs, or the Web GUI. For a team rollout, pair those integrations with SSO/RBAC, scoped credentials, and a clear “outer loop” playbook (issues → reviewable PRs) so engineers can inspect diffs, trace runs, and re-run tasks deterministically.

Why This Matters

If you’re serious about using autonomous coding agents in production, “copy-paste from a browser” doesn’t cut it. You need OpenHands wired directly into GitHub Enterprise, Jira, and Slack so agents can:

Pick up work from issues and tickets
Open and update pull requests
Report progress and results where engineers already work

Do this right and you turn backlog noise into reviewable PRs and test fixes that flow through your existing governance. Do it wrong and you get opaque bots, confused developers, and security revoking access.

Key Benefits:

Governed autonomy, not shadow tooling: Run OpenHands in a containerized sandbox runtime you control, with SSO/SAML and RBAC wrapped around every integration to GitHub Enterprise and Jira/Slack.
Frictionless team adoption: Engineers can trigger agents from GitHub, Jira, or Slack, then review PRs and diffs inside the tools they already use.
Scales from one team to the org: The same integration pattern that works for a pilot can scale to thousands of parallel agent runs across repos and projects.

Core Concepts & Key Points

Concept	Definition	Why it's important
Secure, sandboxed runtime	OpenHands runs agents inside isolated Docker or Kubernetes environments you control (self-hosted or private cloud), with strict boundaries for code execution and network access.	Lets you connect to GitHub Enterprise and Jira/Slack without letting agents “run wild” in your network; security can reason about where code runs and what it can touch.
Model-agnostic integration	OpenHands connects to your choice of LLM providers (Anthropic, OpenAI, Bedrock, etc.) while separately integrating with GitHub Enterprise, Jira, and Slack via APIs and webhooks.	You can change models without re-architecting your GitHub/Jira/Slack setup, and avoid vendor lock-in while keeping a stable integration surface for your teams.
Outer-loop orchestration	Using OpenHands to work on “outer loop” tasks—issues, PR feedback, test gaps, dependency upgrades, vulnerability backlogs—pulled from GitHub/Jira and reported into Slack.	This is where agentic platforms actually move the needle: converting tickets and alerts into reviewable PRs and artifacts that ship, not just answering questions in a chat window.

How It Works (Step-by-Step)

At a high level, a team rollout that connects OpenHands to GitHub Enterprise and Jira/Slack looks like:

Stand up OpenHands in a secure runtime (self-hosted or private cloud).
Connect GitHub Enterprise, Jira, and Slack with scoped credentials.
Define and test a few high-signal workflows (e.g., “Jira bug → PR,” “Slack command → test fix”) before scaling across teams.

1. Deploy OpenHands in a secure, sandboxed runtime

Before you touch GitHub Enterprise or Jira:

Choose a deployment model
- Self-hosted / on-prem: Run OpenHands in your own Kubernetes cluster or Docker-based environment, ideal for fully air-gapped GitHub Enterprise setups.
- Private cloud / VPC: Deploy into your cloud account for tight VPC control, peering to GitHub Enterprise and Jira/Slack endpoints as needed.
Use containerized isolation
- Run agent work inside containerized sandboxes (Docker or Kubernetes pods) with:
  - Scoped network egress (e.g., only GitHub Enterprise, Jira, Slack, artifact storage).
  - Limited credentials (no shared “god token” keys).
  - Runtime boundaries you can audit and monitor.
Wire up identity and access control
- Configure SSO/SAML so engineers authenticate via your IdP.
- Set up RBAC:
  - Which teams can trigger agents?
  - Which repos/projects can each role touch?
  - Who can approve or re-run agent tasks?

This foundation is what makes the later GitHub/Jira/Slack connections a governed platform instead of shadow IT.

2. Connect OpenHands to GitHub Enterprise

With the runtime in place, integrate OpenHands with GitHub Enterprise so agents can read, write, and comment via standard GitHub flows.

a. Decide the integration mode

Typical patterns:

GitHub App (recommended for enterprises):
- Install an OpenHands GitHub App scoped to specific orgs/repos.
- Use fine-grained repository permissions:
  - Read: code, issues, pull requests, checks.
  - Write: pull requests, checks, comments, statuses.
- Benefit: central admin control, easy auditing, and revocation by GitHub Enterprise admins.
PAT / OAuth (for pilots or constrained envs):
- Use a service account with a personal access token.
- Scope the token minimally (repo + workflow-specific scopes).
- Benefit: simple to start, but less granular than an App.

For a team rollout, a GitHub App is closer to how you already manage integrations.

b. Configure permissions and scopes

Follow least privilege:

Read-only where possible:
- contents: read (clone code, analyze).
- pull_requests: read (summaries, context).
- issues: read (convert issues to PRs).
Write only for “outer loop” artifacts:
- pull_requests: write (open/update PRs).
- issues: write (link back from PRs, update status).
- checks: write (report results of automated refactors/tests).
- statuses: write (signal agent progress to GitHub checks UI).

Limit installation to:

Pilot org(s) and repos first.
Only the repositories where you explicitly want agent work.

c. Connect OpenHands to GitHub Enterprise

From the OpenHands control plane (Web GUI or config):

Register your GitHub Enterprise hostname (e.g., https://github.mycompany.com).
Configure app credentials:
- App ID, private key, webhook secret (for GitHub App).
- Or PAT for a service account.
Set webhook endpoints:
- Point GitHub Enterprise webhooks to OpenHands for events like:
  - issues (new/updated issues).
  - pull_request (opened, labeled, review requested).
  - check_suite/check_run (for CI/CD hooks).

This is what lets OpenHands agents respond deterministically when a Jira ticket or Slack command ultimately becomes a GitHub event.

3. Connect OpenHands to Jira

Next, wire Jira into the same loop so tickets become concrete work for agents and results flow back visibly to project managers.

a. Choose your Jira environment

Jira Cloud: Use Atlassian’s OAuth and app frameworks.
Jira Data Center / Server: Use basic auth or OAuth plus your internal routing.

In both cases:

Create a Jira technical user or app with:
- Access limited to the projects where agents should operate.
- Permission to:
  - Read issues.
  - Comment on issues.
  - Transition workflow states (optional but powerful).

b. Configure Jira → OpenHands flows

Common entry points:

Issue labels or components:
- E.g., label issues as openhands or set Component = Agent-Automation.
- Use Jira automation to send a webhook to OpenHands on:
  - Issue created/updated with that label.
  - Status moved to “Agent Ready.”
Custom fields:
- Add a “Automation Type” field (e.g., “Bug fix,” “Test creation,” “Dependency upgrade”).
- Map that field to different OpenHands agent configurations.

The payload to OpenHands should include:

Issue key (e.g., ENG-1234).
Summary and description.
Repo identifier / path (if stored in custom fields).
Any constraints (e.g., “do not push directly,” “open PR against release/1.2”).

c. Configure OpenHands → Jira updates

Once agents run:

Post status comments on the Jira ticket:
- “OpenHands created PR repo#123 to fix this issue.”
- “Tests added: tests/test_bug_ENG_1234.py.”
Optionally transition workflow:
- Move from “Agent In Progress” → “In Review” when a PR is opened.
- This keeps humans in the loop while letting the agent drive the outer loop forward.

4. Connect OpenHands to Slack

Slack is where engineers sit all day. It’s the ideal surface for triggering OpenHands and monitoring runs without opening another dashboard.

a. Set up a Slack app and permissions

Create a Slack app dedicated to OpenHands:

Scopes (examples; fine-tune to your policies):
- chat:write to post messages.
- commands to define slash commands like /openhands.
- channels:history or groups:history if you want OpenHands to reply in thread context (optional).
Install the app to:
- A dedicated #openhands or #agent-automation channel.
- Team-specific channels (e.g., #team-payments-openhands) for scoped use.

Store the Bot User OAuth Token and signing secret in your OpenHands config or secret store.

b. Define Slack → OpenHands triggers

Patterns that work well in a rollout:

Slash commands:
- /openhands summarize-pr https://github.mycompany.com/org/repo/pull/123
- /openhands fix-tests ENG-1234 (maps to a Jira ticket + repo)
- /openhands upgrade-deps org/repo@main
Message actions:
- Right-click on a Slack message → “Send to OpenHands.”
- Useful for triaging incident chats into “create bug + open PR” flows.

These commands call OpenHands APIs, which:

Resolve the GitHub Enterprise repo/PR.
Optionally look up the associated Jira issue.
Launch a containerized agent run scoped to that repo and task.

c. OpenHands → Slack notifications

For visibility and trust:

Post run start and run finish updates:
- “Started: Fix failing tests in org/repo@branch from Jira ENG-1234.”
- “Completed: Opened PR repo#456. Click to review diff.”
Thread these under the original command where possible.
Include links to:
- The PR in GitHub Enterprise.
- The trace/run view in OpenHands (so engineers can see exactly what was executed).
- The Jira ticket, for full context.

This keeps autonomy auditable: every Slack-triggered change has a visible trace and diff.

5. Define and test your initial workflows

With GitHub Enterprise, Jira, and Slack wired in, the key is picking a small set of workflows that demonstrate value without risk.

Strong starting points:

Jira bug → OpenHands → GitHub PR
- Trigger: Jira bug labeled openhands.
- Agent task:
  - Reproduce the bug (if possible from logs/tests).
  - Implement a fix.
  - Add or update tests.
  - Open a PR with a summary referencing ENG-1234.
- Notifications:
  - Slack: pre-run + post-run updates.
  - Jira: comment with PR link and test status.
Slack command → PR summary & review help
- Trigger: /openhands summarize-pr <PR URL>.
- Agent task:
  - Generate a high-signal summary.
  - Highlight risk areas, test coverage, and potential regressions.
- Output:
  - Posted back into Slack.
  - Optionally as a PR comment for later traceability.
Dependency/security upgrades from Jira
- Trigger: Jira tickets created by security tooling (e.g., “Upgrade openssl to >=1.1.1x”).
- Agent task:
  - Run a repo-wide upgrade.
  - Fix broken tests.
  - Open batched PRs per service or repo.
- Governance:
  - Enforce human review via standard GitHub Enterprise branch rules.

Each workflow should be:

Constrained (scoped repos, branches, and actions).
Traceable (OpenHands run logs, GitHub PR history, Jira/Slack updates).
Re-runnable (same input → same artifact, for deterministic debug and auditing).

Common Mistakes to Avoid

Letting agents bypass existing guardrails:
- If OpenHands can merge directly to main without branch protections, you’ve created a governance blind spot.
- How to avoid it: Keep branch protections and code review policies in GitHub Enterprise. Let OpenHands open PRs, not merge them. Use required reviews and checks like usual.
Over-scoping credentials and integrations on day one:
- Giving a single token full org access across GitHub Enterprise and Jira/Slack is a recipe for security pushback.
- How to avoid it: Start with minimal perms and narrow repo/project scopes. Use GitHub Apps, separate Jira technical users, and Slack apps per workspace or team. Expand only when specific workflows demand it.

Real-World Example

At a regulated enterprise I worked with, we rolled out a cloud coding agent pattern almost identical to what OpenHands ships today. GitHub Enterprise housed all critical services, Jira drove prioritization, and Slack was where production incidents lived.

We started with a simple flow: Jira bug tickets in two non-critical services that were often stuck in “needs fix” purgatory. When a ticket hit “Agent Ready” and carried the openhands label, Jira fired a webhook into our agent platform. The agent cloned the appropriate GitHub Enterprise repo into a sandboxed Kubernetes pod, reproduced or localized the bug using the description and logs, proposed a code change, generated a targeted test, and opened a PR. Slack posted an update in #team-services-openhands with a link to both the PR and the Jira ticket.

The important bit wasn’t the autonomy itself; it was the visibility. Reviewers could see every diffs, click into the agent’s runtime logs, and re-run the job if they updated the prompt or configuration. Security was comfortable because they knew exactly which repos, branches, and APIs the agent could talk to. Within a month, “low-to-medium” priority bugs that usually lingered for weeks were being converted to reviewable PRs in hours—without adding a new dashboard or bypassing existing GitHub and Jira governance.

Pro Tip: Before you scale beyond a pilot, sit down with your GitHub Enterprise and Jira admins and agree on three things: (1) which repos/projects are in scope, (2) how branch protections and approvals will be enforced for agent-created PRs, and (3) how to audit every OpenHands run (logs, traces, and diffs) when an internal security review happens. Document this once and reuse it for every new team you onboard.

Summary

Connecting OpenHands to GitHub Enterprise and Jira/Slack for a team rollout is less about wiring APIs and more about aligning autonomy with your existing SDLC and governance. You deploy OpenHands in a secure, sandboxed runtime you control, integrate it with GitHub Enterprise using a constrained app or service account, connect Jira and Slack via webhooks and commands, and then define clear “outer loop” workflows that take issues and tickets through to reviewable PRs.

Done well, this gives your teams a transparent, auditable path from Jira tickets and Slack threads to GitHub PRs, using any LLM provider you choose, with the ability to inspect every agent run, review every diff, and re-run tasks deterministically. That’s how you turn “we tried an AI assistant” into an actual, production-grade agent platform.

Next Step

Get Started