Jern Cloud docs

Execution environments and machines.

An environment is an immutable image with declared tools, a bounded setup command, and the hosts that setup may reach. A session pins one revision at creation and keeps it; a change to an environment is a new revision, never a surprise.

The catalog

Environment	Tools	Setup reaches	Recommended when
`python-node-native`	Python, Node.js, and native build prerequisites: the broad image, the platform default.	pypi.org, files.pythonhosted.org, registry.npmjs.org	The repository needs more than one toolchain, or nothing else fits.
`python`	Python, pip, venv, native build prerequisites.	pypi.org, files.pythonhosted.org	The root holds a `requirements.txt` or `pyproject.toml`.
`node`	Node.js and npm, native build prerequisites.	registry.npmjs.org	The root holds a `package.json`.
`dotnet`	The .NET 10 SDK and NuGet.	api.nuget.org	The root holds a solution, a project, or `global.json`.
`java`	Temurin JDK 21, Maven 3.9, Gradle 9.7.	repo.maven.apache.org, repo1.maven.org, plugins.gradle.org, services.gradle.org	The root holds a Maven or Gradle build file.

Every image runs on x86_64 and is pinned by digest. The Setup section of the repository page recommends an environment from what it finds at the root; a workspace admin assigns one there, and the assignment follows platform updates of the same environment unless the admin pins a revision. Rust and Go environments are next.

Setup and the dependency cache

Before the agent starts, the runner runs the environment's setup command, such as installing from the lockfile, with the network open only to the hosts listed above and only during setup. Setup holds none of the runner's credentials and runs before any repository secret is released, so nothing it leaves behind can read one. The result is kept in a dependency cache keyed by the environment revision, the setup command, and a digest of the lockfiles, so the next attempt on the same lockfiles restores it instead of downloading again. A cache never holds credentials, symlinks outside its root, devices, or unexpected executables; a cache hit or miss is on the receipt.

Network during the run

While the agent works, its network goes through the runner's proxy: under the Open profile to any public host, under a governed baseline only to the Jern gateway and the hosts it names. A baseline can also allow read-only access to named hosts, such as docs.python.org, through the fetch_page tool; the receipt counts every contact per host. See Policy for network_allow and declared services.

Machines

Machine	Size	Price per hour
`shared-2x`, the default	2 shared vCPU, 2 GB	$0.10
`performance-4x`	4 dedicated vCPU, 8 GB	$0.50
`performance-8x`	8 dedicated vCPU, 16 GB	$1.00

A session picks its machine when it opens and keeps it for life, like its model and its cap. Every attempt runs on a machine created for it and destroyed afterwards. Machine time is metered per size from start to destruction and priced per hour on top of the workspace fee; the usage report shows the hours. Service sidecars run on their own machines and are not metered separately.

Limits every attempt runs under

An attempt has a time limit, a workspace control under the plan's ceiling: 45 minutes on trial, four hours on paid plans. While it runs, the runner pushes checkpoints to the session's branch every few minutes, so a machine that dies leaves its work on GitHub. At the limit the runner publishes what the agent has, opens or updates the pull request, and marks the attempt timed out; the next message continues from there. Tokens are capped per attempt by the gateway, processes and egress are bounded inside the machine, and the FAQ lists the numbers.