JernCloud Start with GitHub

Jern Cloud for engineering teams

A coding agent your team can approve once.

Developers on your team can already try Jern on a repository of their own. When it is time to bring it to the organization, the question changes from "does it work" to "what can it do, what can it reach, and what can we prove afterwards". This page answers that question. Everything on it is enforced by the runtime or the control plane and written on the receipt, not promised in a policy document.

Start with GitHub Read the security page first

$19 a month per workspace, any number of repositories and up to 10 members, on your own provider key at list price. Larger workspaces and support commitments: hello@jern.ai.

A Jern Cloud session: the guarantees pinned for the session, the conversation with the agent, and an attempt that stopped to ask a question before writing code.
Pinned for the sessionRevision, policy digest, environment, model, and cap. None can change once the session opens.
Every attempt, on the recordTokens metered by the gateway, files changed, the receipt check, and encrypted evidence a click away.
Approval before it runsOptionally, every attempt waits for a workspace admin before a machine is created.

What you approve once

Guarantees you approve once, not actions you supervise all day.

Every one of these is enforced by the runtime or the control plane and shown inside the session, where a reviewer forms trust.

Policy pinned by digest

The repository's baseline decides which paths can change and which commands run without asking. The runner verifies its digest before the agent starts, and it cannot change for the life of the session. Your reviewers protect the file like any other.

No GitHub token or model key in the agent

Checkout, evidence upload, checkpoints, and publication each use a separate short-lived credential held by the runner, out of the agent's sight; model calls carry a token scoped to the run, and the gateway holds the key. A repository secret reaches the agent only when an administrator stores one. A governed baseline can narrow its network to named hosts, or to the inference gateway alone.

Hard caps, metered where it counts

Tokens are counted by the gateway from the provider's own response, not by the agent; every call is kept with the provider's request id. Wall clock, process count, output size, attempts per task, and spend per attempt and per month are capped too.

Encrypted evidence for every attempt

The exact trace is encrypted with AES-256-GCM before it reaches a database. Open it from any attempt. Retention is yours to set and is enforced automatically.

Immutable environment

The image and setup command are pinned by revision per session. A change to the environment is a new revision, never a surprise mid-session.

Review is the only exit

Work ends on an isolated branch as a pull request with a receipt, or as a labelled failure. Jern never merges. Optionally, every attempt waits for a human approval before it runs.

The boundary is the product

Isolate execution. Centralize control.

Each attempt runs on a machine created for it and destroyed afterwards. The agent lives in a private network namespace whose only way out is a proxy that, under a governed baseline, admits the Jern gateway and the hosts the baseline names. The gateway holds the provider key, enforces the cap, and meters usage. Publication happens outside the agent, after policy and secret checks.

Read the data flow and honest limits →
Your repositorySource at a pinned revisionProtected policy baselineBranch protection and reviewersThe pull request
Isolated machine + Jern CloudAgent with no GitHub token or model keyGateway holds the model keyCap enforced and meteredEvidence encrypted, then the machine is destroyed

Rolling it out

From one developer's trial to a governed workspace.

  1. 1

    Install on the repositories you choose

    The GitHub App asks for the repositories, not the organization. Setup opens a pull request with a policy baseline for each; nothing runs until it is merged and protected.

  2. 2

    Set the workspace's limits

    A cap per attempt and per month in tokens and in dollars, a time limit, which models triggers may use, and whether every attempt waits for an admin's approval.

  3. 3

    Bring your own key

    Attach the organization's Anthropic, OpenAI, Gemini, or Fireworks credential. It is stored write-only and encrypted; the agent never sees it. Model usage bills to your account at list price, and every call is listed with the provider's request id.

  4. 4

    Read what came of it

    Per repository and month: pull requests opened, merged, and reverted, time to merge, review rounds, and the cost of each merged pull request, beside the spend report and its CSVs.

An inspectable foundation

Trust starts in the open.

Policy enforcement, receipt derivation, trace formats, and replay live in the Apache-2.0 Jern repository. The control plane does not reinterpret what the runtime recorded, and the same runtime runs on a developer's laptop.

Security and data flowWhat runs where, what is encrypted, and what we do not defend against. The policy referenceEvery key of the baseline, what setup writes for you, and how the runtime enforces it. Runtime security modelThe claim, the boundary, and its limits, in the code's own words.

Approve once, review every pull request

Put a coding agent to work without giving up control.

Start with GitHub Talk to us