What Runjet is

Runjet is a scheduler: it says when something should run, and remembers how it went. Running it is left to agents — small processes on your own machines, where the commands belong. You watch one dashboard; the commands run where their data, their credentials and their network are.

Two halves

The control plane is app.runjet.dev and api.runjet.dev: the dashboard, a cron engine for each workspace, the run history, accounts, email and billing. It holds the job definitions and everything you know about a run.

The agent is a single static binary on each machine where something has to run. It calls outwards — no open port, so it works behind NAT — waits for work, runs it under an account of its own, and sends back the output and the exit status. It trusts only instructions signed with your workspace's key. How exactly and how to install one are in the Agents chapter.

The workspace

Everything you have in Runjet lives in one workspace: jobs, agents, runs, people's accounts, the plan. It comes into being at registration, has an address of its own (app.runjet.dev/your-slug) and a database of its own — nothing in one workspace is visible from another, and an agent enrolled in one refuses an instruction from another, because it is signed with a different key. What a workspace may do is its plan; what becomes of it over time is its life.

Runjet does not run your code

The control plane's image has no shell. This is not a rule the code keeps but a property the image has: Runjet cannot run your command, even if something asked it to. For you it means your code, your secrets and your data stay on your machines; Runjet sees the command, its output and its result, and nothing of what the command reaches for.

The same property decides what Runjet does not know about a run: it cannot stop one on a clock (why), and it does not know the values of your secrets — only their names.

What next

Quick start is one pass from registration to a first run; concepts is the vocabulary on one page.