RunJob
streamed: accepted -> state -> logs -> result
Authorization
BearerAuth A namespace-scoped API key (cpk_…) for machines, or a Xeonr Auth OIDC
token for humans. The key's namespace and role are pinned server-side.
In: header
Header Parameters
Define the version of the Connect protocol
1Define the timeout, in ms
Request Body
application/connect+json
argv-only; empty => image entrypoint
fer fast path (CodeGeneratorRequest), agent-piped
byteruntime phase; default MODE_NONE
Resources is the compute envelope for a sandbox or job. Maps onto k8s requests==limits and the Docker resource knobs.
warm-pool routing; inert if no pool configured
optional scoped-JWT reporting to the caller's control plane
Deprecated: use workspaces. Treated as a single read-write mount at
/workspace when set. Setting both is an error rather than a merge.
user-defined display name (console-required)
Environment for the WORKLOAD container. Lands in the pod spec, so it is
readable by anything with pods/describe in the runner namespace — NOT a
secret channel; use secrets for anything sensitive. Names the platform
owns (CP_*, HTTP_PROXY/HTTPS_PROXY/NO_PROXY and lowercase variants,
JAVA_TOOL_OPTIONS) are rejected rather than silently overridden.
Optional second, operator-trusted container in the pod (a product adapter —
e.g. upl-im's credential broker). Its image is resolved from an operator
allowlist by key; a caller can never name an image. See DESIGN §4, §5.3.
Secret material for this job, delivered as files (mode 0400) to the ADAPTER container only — never the workload, never the pod spec, never persisted in the job record. Written to a k8s Secret owned by the pod and GC'd with it.
The filesystems this job sees. There is no implicit /work any more — a job
that wants a working directory declares one, and
{ephemeral: true, mount_path: "/work"} is the idiom that reproduces the
old behaviour while also making the directory readable through the file API
after the job exits.
inputs and outputs stage through the first read-write mount, so
declaring either with no writable mount is an error.
Where the workload starts. Absolute; empty selects the default, which differs by primitive on purpose:
sandbox the first read-write mount — an interactive user has to land somewhere writable job the first read-write mount — inputs are already staged there app the IMAGE'S OWN WORKDIR. An App runs an image built elsewhere and that WORKDIR is part of its contract, so the platform does not override it just because the version happens to declare a writable mount.
Set it explicitly when the default is wrong: a monorepo mounted at /workspace whose build runs in /workspace/apps/web has no other way to say so, and relying on the default couples the working directory to the ORDER of the mount list, which is not something a caller expects to matter.
Serve FilesystemService against this job's container while it runs.
Opt-in rather than always-on because it is not free: it forces the agent sidecar (a job with no egress, no read-write mount and no outputs would otherwise run without one, and the sidecar is what the api dials) and it forces the workload under the supervisor that hosts the handler. Most jobs never need it and should not pay for it.
A job's filesystem is reachable only while it is RUNNING — the pod is torn
down at completion. For files that must outlive the run, use outputs.
Response Body
application/connect+json
application/connect+json
curl -X POST "https://containers.xeonr.io/containers.api.v1.JobService/RunJob" \ -H "Connect-Protocol-Version: 1" \ -H "Content-Type: application/connect+json" \ -d ''{
"accepted": {
"jobId": "string",
"atUnix": 0
}
}{
"code": "not_found",
"message": "string",
"details": [
{
"type": "string",
"value": "string",
"debug": {}
}
]
}