
How do I sign up for OpenHands Cloud with GitHub and run it on my first repo?
Most teams reach the “How do I sign up and point this at a real repo?” stage the moment OpenHands Cloud clicks for them. The good news: connecting GitHub and running OpenHands on your first repository is a short, deterministic path—not a week-long rollout project.
Quick Answer: To sign up for OpenHands Cloud with GitHub, you authenticate using your GitHub account, grant repo access, and let OpenHands index the codebase in a secure, sandboxed runtime. From there, you can run your first task—like summarizing open PRs or fixing failing tests—directly against that repo via the Web GUI, while keeping every agent action visible and reviewable.
Why This Matters
Connecting OpenHands Cloud to GitHub is the bridge between “AI that talks” and “agents that ship code.” Once your repo is wired in, you can delegate real SDLC work—PR summaries, refactors, dependency upgrades, and bug fixes—to agents running in a controlled, auditable environment. Instead of manually grinding through outer-loop tasks, your team gets a repeatable, observable automation layer that can scale from a single PR to thousands of parallel runs across many services.
Key Benefits:
- Faster delivery without black-box risk: Agents generate diffs, tests, and PRs you can inspect, trace, and re-run—no invisible changes, no blind trust.
- Real leverage on outer-loop work: Clear backlogs of flaky tests, vulnerability fixes, and dependency upgrades by running agents on your repos instead of burning engineer cycles.
- Scales with your stack and your models: Use OpenHands as a model-agnostic platform that grows from one repo to many, works with your GitHub org, and respects your governance (SSO, RBAC, audit trails).
Core Concepts & Key Points
| Concept | Definition | Why it's important |
|---|---|---|
| OpenHands Cloud signup with GitHub | The process of creating an OpenHands Cloud account by authenticating via GitHub and granting access to your repositories. | This is how you securely connect your source of truth (GitHub) so agents can read and write code under your control. |
| Secure, sandboxed runtime | A containerized environment (e.g., isolated Docker or Kubernetes) where OpenHands agents run with scoped access to your repo and tools. | It keeps agent activity isolated, auditable, and replayable, so you can adopt autonomy without handing over the keys to production. |
| First repo task run | The initial agent run against a specific GitHub repository, such as summarizing PRs, fixing tests, or proposing code changes. | This is where value shows up: concrete artifacts like diffs, PRs, and test updates you can review in GitHub and in the OpenHands UI. |
How It Works (Step-by-Step)
At a high level, getting from “no account” to “first agent run on a repo” follows a straightforward path:
- Sign up for OpenHands Cloud using GitHub.
- Connect your GitHub repos with the right scopes.
- Run your first task on a selected repo from the Web GUI.
Below is a more detailed walkthrough you can follow end-to-end.
1. Sign Up for OpenHands Cloud with GitHub
-
Navigate to OpenHands Cloud
- Go to
https://openhands.devand follow the path to the Cloud product (e.g., “Get Started” or “Try it live”). - Choose the Cloud option (as opposed to the open source local deployment).
- Go to
-
Choose “Sign up with GitHub”
- On the signup screen, select GitHub as your auth provider.
- This uses OAuth, so OpenHands never sees your password; GitHub handles authentication.
-
Authorize the OpenHands GitHub App
- GitHub will show a consent screen describing what OpenHands can access (e.g., repos, pull requests, issues).
- Recommended for trials: authorize at the organization level only for the specific org and repos you want OpenHands to see. Avoid “all repos” if your org has strict data boundaries.
- Confirm authorization to finish account creation.
Once this is complete, you’ll land in the OpenHands Cloud Web GUI—your control plane for agent runs.
2. Connect and Scope Your First GitHub Repository
-
Select or add your GitHub organization
- In the OpenHands Web GUI, go to the section where you manage connected code hosts or integrations.
- You should see your GitHub account/orgs associated with your OAuth authorization.
- If your target org isn’t visible, you might need to:
- Re-open the GitHub app settings, and
- Grant OpenHands access to that org and specific repos.
-
Choose the first repo to connect
- Pick a repo with:
- Clear tests (e.g.,
pytest,Jest,Go test), - A CI pipeline (even basic),
- Or an active PR/issues queue.
- Clear tests (e.g.,
- In OpenHands, select Connect Repository (or similar) and choose this repo from the GitHub list.
- Pick a repo with:
-
Confirm permissions and indexing
- OpenHands will typically:
- Pull the repo metadata and current default branch, and
- Prepare a view for agents to work on that codebase.
- This happens in a secure, sandboxed runtime you control when self-hosted; in Cloud, it runs in an isolated environment with full auditability of what agents do.
- OpenHands will typically:
-
Set basic policies (if available)
- Before the first run, configure:
- Allowed operations: read-only vs read+write (e.g., can the agent push branches or open PRs).
- Branch protections: restrict agents to feature branches, never main.
- Access control: ensure only the right team members can trigger runs on that repo via RBAC/SSO/SAML where configured.
- Before the first run, configure:
3. Run OpenHands on Your First Repo
With the repo connected, you’re ready to run a real task.
-
Open a new task in the Web GUI
- Go to the main dashboard or workspace.
- Click New task or the equivalent to start a run.
- Select the GitHub repository you just connected and, if prompted, the branch (usually the default branch for analysis, feature branch for changes).
-
Choose a starter workflow For a first run, pick something that produces immediately inspectable artifacts:
- PR summarization:
- “Summarize all open PRs in this repo, including risks, missing tests, and suggested follow-ups.”
- Test triage:
- “Identify failing tests from the latest CI run for this repo and propose fixes with diffs.”
- Dependency audit (read-only):
- “Scan this repo’s dependencies and list outdated libraries and known vulnerabilities, but don’t change code yet.”
OpenHands will:
- Clone or mount the repo into its sandbox,
- Call your configured LLM (OpenHands is model-agnostic: BYOK via providers like Anthropic, OpenAI, or Bedrock),
- And begin generating outputs tied to this codebase.
- PR summarization:
-
Review artifacts and diffs
- In the Web GUI, you’ll see:
- Logs of each step the agent takes,
- Generated diffs, test files, or documentation,
- Links back to GitHub for opened branches or PRs.
- You can inspect every change the agent proposes before any merge happens—trust requires visibility.
- In the Web GUI, you’ll see:
-
Approve and push changes (if enabled)
- If your policy allows write operations:
- Approve the proposed changes in the OpenHands UI,
- Let OpenHands push a branch and open a PR in GitHub.
- Your reviewers can then treat this like any other PR:
- Review diffs,
- Run CI,
- Merge once it clears your checks.
- If your policy allows write operations:
From here, you can iterate: run more tasks on the same repo, expand to other services, or wire OpenHands into CI/CD or Slack for “headless” or chat-triggered runs.
Common Mistakes to Avoid
-
Granting overly broad GitHub access on day one:
Avoid authorizing OpenHands for every repo across your org until you’ve validated governance. Start with a pilot org or a subset of repos, then expand once RBAC, audit logs, and policies are dialed in. -
Letting agents push directly to main branches:
Keep agents constrained to feature branches and PR-based workflows. Configure branch protections in GitHub and matching policies in OpenHands so every change is reviewable and can be rolled back via normal Git flows. -
Skipping observability in favor of “magic”:
Don’t treat OpenHands like a black-box assistant. Always review the task log, inspect diffs, and re-run tasks deterministically when needed. If you can’t trace what happened, it’s not production-grade.
Real-World Example
Imagine you’re responsible for a monorepo that’s carrying a backlog of flaky tests and minor bug tickets. You sign up for OpenHands Cloud with your GitHub identity, authorize only the engineering org, and connect just the monorepo as a first step. In the Web GUI, you trigger a task:
“Scan the existing test suite for flaky tests based on recent CI runs, propose fixes, and open PRs grouped by service.”
OpenHands clones the repo into a secure, sandboxed runtime. It inspects recent CI artifacts, identifies tests with intermittent failures, and proposes code changes to stabilize them. Each proposed fix shows up as a PR with a clear description, linked issues, and updated tests. You can:
- Inspect the diff for every file change.
- Re-run the task against a different branch or subset of directories.
- Use your normal GitHub review workflow to gate merges.
What used to be a multi-week chore gets compressed into a set of reviewable PRs generated in hours—without bypassing your existing controls.
Pro Tip: For your first repo, pick a clearly scoped problem—like “summarize and triage open PRs” or “fix failing tests in a specific service”—rather than asking OpenHands to “optimize the whole codebase.” Small, auditable wins build trust and help you tune permissions before you scale out to more repos.
Summary
Signing up for OpenHands Cloud with GitHub and running it on your first repo is a straightforward way to move from AI experiments to concrete engineering outputs. You authenticate via GitHub, scope access to the right repos, and let agents operate in a secure, sandboxed runtime that keeps every action visible and replayable. Once that first repo is connected, you can delegate recurring outer-loop work—PR triage, test fixes, dependency upgrades, vulnerability remediation—to a model-agnostic agent platform that scales from a single task to thousands of parallel runs across your stack.