Secrets

A secret in Runjet is a name, never a value. The job says it needs DB_PASSWORD; the value is held by the agent on the host where the job will run, and the command is given it as an environment variable. Runjet never stores, sends or logs the value — and a compromised control plane cannot give up what it never had.

Names, not values

In the Secrets field on the job form you write names, separated by commas (DB_URL, API_TOKEN…). The form does no more than that, and it is deliberate: there is nowhere to type a value, so there is no way to entrust one to Runjet by mistake.

Only those names travel in the dispatch the agent receives. Before running the command the agent fills them in from what it holds — from its secrets file or from its own environment — and the command finds them in the environment like any other variable:

pg_dump "$DB_URL" | gzip > /var/lib/runjet-job/backup.sql.gz

How to get a value onto the host, what permissions the file should have, and what happens when one is missing, is on the secrets on the host page.

Separately on each agent

A job on three agents asks three hosts. Each fills in its own value for the same name — which is also how one job backs up three different databases — and a host that does not have the name does not run it: the run ends failed with the sentence this agent has no value for DB_URL. Substituting an empty string would be worse than an error: a backup written somewhere else, an API call without credentials, and a run reporting success.

Masking

The values a run asked for are replaced with *** by the agent in the output, before that output leaves the host — so a set -x in a script, a curl -v with an Authorization header, or a stack trace carrying a DSN does not end up in the run history with the password inside it.

It is a net for accidents, not a boundary. Values shorter than five characters are not masked, and echo $SECRET | base64 walks straight past it. What actually stops such a job is not the masking but that it cannot reach anything it was not given.

Changing and removing

Adding or removing a name on a job is an edit to the job and applies from the next run. Changing a value happens on the host, and the agent picks it up after a restart; Runjet does not know about it and has no way to. A removed name is no longer filled in by the agent, but the value on the host is not deleted — that is your work, on your machine.