JernCloudStart with GitHubJern Cloud docs
Getting started.
From sign-in to a reviewed pull request in one sitting. Jern Cloud runs the open-source Jern agent in sessions on isolated machines against repositories you connect, under a policy the repository or your workspace defines, and delivers every result as a pull request.
1. Sign in with GitHub
Go to cloud.jern.ai and continue with GitHub. Jern Cloud reads your GitHub identity and nothing else at this point. A workspace is created for each GitHub organization or account where you install the App.
2. Install the GitHub App on the repositories you choose
The Jern Cloud App asks for the repositories it may work on. Pick only those; access is re-checked against GitHub on every read. Each installation becomes a workspace, and workspace admins manage members, controls, and keys.
3. Add a model provider key
Jern does not supply model usage. Under Settings › Provider add an Anthropic, OpenAI, Gemini, or Fireworks API key. It is validated once with the provider, stored encrypted, never shown again, and never reaches a machine: the gateway forwards requests on the agent's behalf and meters them. Tokens bill to your provider account. See Provider keys.
4. Open a session
From Sessions, pick a repository, a model, a machine, and a token cap per attempt, then describe the work. The session pins the repository revision, the policy, the environment revision, the model, the machine, and the cap for its whole life. If the repository has no protected policy baseline yet, the workspace's default profile applies; a baseline in the repository always wins. See Policy.
5. Watch the attempt
Each message becomes one attempt on a fresh isolated machine. The session shows live activity, the tokens spent against the cap, and the evidence as it is sealed. You can interrupt at any time; the machine is destroyed and the evidence captured so far is kept.
6. Review the pull request
Changes land on the session's own branch, jern/session-…, as one pull request that follow-up messages keep updating. Your branch protection and reviewers apply as they would to any contributor. Jern never merges. Every attempt puts its receipt on the pull request as a check named Jern receipt: the pinned policy digest, the model and its calls, tokens against the cap, estimated spend, files touched, services started, hosts contacted, and the sandbox, so reviewers see what the attempt was allowed to do and what it did without leaving GitHub.
7. Start work from GitHub
Once an admin enables triggers under Settings, Policy, work starts where it is asked for. A label (jern by default) on an issue opens a session with the issue as its first message. A comment beginning with /jern opens one with the comment as the task, or, on a session's own pull request, becomes that session's next turn. With the opt-in, a failed check on a session's pull request asks the session to fix it, at most three times. A trigger acts as the workspace member who added the label or wrote the comment, so they must have signed in and, for comments, be a collaborator on GitHub; approval, limits, and provider keys apply exactly as in the dashboard, and Jern Cloud answers on the issue with a link to the session.