JernCloudStart with GitHubCompare
Jern Cloud vs Cursor Cloud Agents.
Both run an agent on an isolated machine in the cloud and hand back a pull request for a person to review. They differ on where the rules live, what the agent can reach while it works, and what the reviewer is given. This page is written from Cursor's public documentation as of September 8, 2026 and from ours; if we have something wrong, tell us and we will fix it.
Side by side
| Jern Cloud | Cursor Cloud Agents | |
|---|---|---|
| Where the agent runs | One machine per attempt, created for it and destroyed afterwards, with Linux namespaces and seccomp inside the guest boundary. Machine time is metered per size. | A dedicated Firecracker microVM per agent in a separate AWS account, holding the cloned repository, installed dependencies, and configured secrets. Hibernated and deleted on lifecycle timers; VM snapshots kept for 90 days of inactivity. |
| What starts work | The dashboard, an issue label, a /jern comment, a failed check on the session's pull request, a schedule, or the MCP server from an editor. | The Cursor desktop app, web, iOS, CLI, API, Slack, Linear, or an @cursor comment on a GitHub, GitLab, or Bitbucket issue or pull request. Automations run agents on a schedule or on source control, Slack, Linear, and webhook events. |
| Where the rules live | A file in the repository, protected by your reviewers and pinned by digest for the session. The runtime enforces it at every tool call: paths that may change, a blast radius in files and lines, protected paths, the shell commands that run without asking, services, and hosts. | In Cursor: rules files and hooks for the agent, network egress modes and secret types for the VM, set per team. The agent auto-runs terminal commands inside the VM. There is no file-level edit boundary or blast radius enforced against the model. |
| Network while it works | During the run, one route: a relay to the Jern gateway. Named hosts from the baseline are readable through a tool that counts every contact on the receipt. Package indexes are reachable during setup only. | Internet access is on by default. Admins can restrict egress to a default set plus an allowlist, or to the allowlist only, and lock the policy org-wide. |
| Credentials the agent holds | None. Checkout, evidence upload, checkpoints, and publication each use a short-lived credential the runner holds outside the agent process. The gateway holds your model key. | Secrets you configure are loaded into the VM as environment variables. Runtime secrets are redacted from the transcript, tool output, and commits, but remain visible to anyone using the environment's terminal. OIDC tokens are available for short-lived cloud access. |
| What the reviewer gets | A receipt on every pull request as a check: tokens against cap, files against the blast radius, policy decisions, hosts contacted, the sandbox. Behind it, the exact trace, encrypted before it reaches a database. | A draft pull request with signed, attributed commits, and the transcript and run events available to team admins from the dashboard and the Cursor Cloud MCP. |
| Can it merge? | Never. One pull request per session on an isolated branch; your branch protection and reviewers apply. | No. Agents open draft pull requests; a person merges. A separate approval agent can approve low-risk pull requests when configured. |
| Models and billing | Your own Anthropic, OpenAI, Gemini, or Fireworks key; tokens bill to your provider account and the gateway meters them from the provider's usage report. $19 per workspace per month plus machine hours, after 30 days free. | Cursor's model catalog, charged at API pricing for the selected model through your Cursor plan, plus the context window you choose. No customer key. |
| Self-hosted | Jern's cloud only. Self-hosted runners are on the roadmap. | Yes. A self-hosted runtime can federate a VM into AWS, GCP, Azure, or a custom environment. |
| Breadth | GitHub only. Python, Node, .NET, and Java environments. No browser or desktop control. The runtime is open source, Apache-2.0. The agent that runs in a session is the one you can read and run on a laptop. | GitHub, GitLab, and Bitbucket. Multi-repository workspaces, MCP servers, browser and desktop control, mobile, Slack and Linear, a review bot and security agents. Closed source. |
Which to choose
Choose Cursor Cloud Agents when the agent needs the breadth: several repositories at once, a browser, MCP servers, Slack, GitLab or Bitbucket, or your own cloud. Its isolation and egress controls are real, and its automations cover the same events ours do. Choose Jern Cloud when the question is not what the agent can do but what it was allowed to do and what it did: a policy your reviewers own and the runtime enforces, an agent that holds no secret at all, and a receipt on the pull request that says so. Jern is the smaller product with the stricter boundary.
What Jern does not do
No browser, no desktop, no Slack, no GitLab or Bitbucket, no self-hosted runners yet, and four language environments. Our isolation relies on Fly.io's guest boundary plus namespaces and seccomp inside it, and an independent test of that boundary is planned and not yet published. Your messages and the agent's replies are stored in plaintext so the dashboard can show them; evidence is encrypted, conversation text is not. The security page lists what is not defended against.
See it
The recipes are real sessions on the public demo repository with their pull requests and receipts. A session on your own repository takes a sign-in with GitHub and a provider key; the first 30 days are free.
Sources
Read on September 8, 2026. Products change; the sources are linked so you can check the current state.