Jern 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.

All guides

SessionsWhat a session pins, how attempts work, and what each part of the session screen means.PolicyThe baseline the repository owns, the paths and commands it allows, services, network, and how the runner checks it before the agent starts.Start work from GitHubA label on an issue, a /jern comment, or a failed check opens or continues a session, as the member who asked.Run a session on a scheduleA cron on a repository opens a session on the clock, as the member who set it, with a cap, and ends in a pull request.Skills: playbooks the agent reads when a task matchesKeep playbooks under .jern/skills; the agent carries their names on its prompt and reads one when the task calls for it.Execution environments and machinesThe Python, Node, .NET, and Java images, their setup and dependency cache, the machine sizes, and the limits every attempt runs under.The browserA headless browser on the attempt's machine: the agent drives the application it started, reads pages as text, and takes screenshots kept as evidence.Repository memoryWhat the agent writes to itself about a repository, kept encrypted between sessions, visible and editable on the repository page.Repository knowledgeClaims people hold about a repository, with evidence and the paths they govern; held claims ride on every task, and only a person holds one.Receipts and evidenceWhat every attempt leaves behind: the receipt on the pull request, the encrypted trace, and the blast radius against its limits.Spend, caps, and usageToken caps, dollar caps, machine time, the usage report, and spend by repository with the part that schedules started.Provider keysBring your own Anthropic, OpenAI, Gemini, or Fireworks key; it is validated once, stored encrypted, and never enters a machine.SettingsMembers, plan, and usage; policy profiles, controls, and triggers; provider keys and API tokens; evidence retention and the audit log; and the notifications that lead to a session.MCP serverOpen and follow sessions from an editor or another agent through the outward MCP server, with a scoped API token, idempotent calls, cancellation, and a signed callback when the work has settled.RecipesReal sessions on the public demo repository: the policy, the message or schedule, the pull request that came back, and its receipt.FAQ and limitsThe limits every attempt runs under, and the questions people ask before the first session.

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 keys 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 › Triggers, work starts where it is asked for, and a schedule starts it on the clock. 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.

Trial. Every new workspace has the full product free for 30 days on its own provider key. When the trial ends, sessions stay readable and new work pauses until a plan is agreed. Write to hello@jern.ai.