Runtime host setup

Evals use the Crux Runtime already selected by the project. There is no separate Eval runtime, host array, profile, capability router, or fallback. Exactly one deployment is active for an invocation.

Connection discovery

Explicit Crux variables take precedence:

CRUX_EVAL_HOST_URL=https://runtime.example.com
CRUX_EVAL_HOST_DEPLOYMENT_ID=production-eu
CRUX_EVAL_HOST_TOKEN=...

The selected adapter may infer the two non-secret values from its standard environment. The Convex adapter reads CONVEX_SITE_URL and CONVEX_DEPLOYMENT. The bearer is never inferred: it comes only from CRUX_EVAL_HOST_TOKEN.

Keep the token in the environment or platform secret store. Never put it in crux.config.ts, generated registries, command arguments, logs, plans, errors, or fingerprints. Crux authenticates the Runtime manifest and then requires its deployment id and capabilities to match local expectations.

Convex

Configure the project with the existing Convex Runtime adapter and deploy the generated Runtime entry using the normal Convex workflow. In a standard Convex environment, set only CRUX_EVAL_HOST_TOKEN; the adapter infers URL and deployment id. Explicit Crux URL and deployment variables override that inference.

crux runtime generate writes the Convex control entry, the Node target/Eval entry, and an HTTP route helper. When the app has no router, it also creates convex/http.ts. The HTTP router mounts the authenticated Eval protocol at /manifest, /jobs, and /jobs/:id on CONVEX_SITE_URL. The target entry imports the exact default-exported Evals and embeds validated Case and Variant identities; it never serializes prompts, models, functions, or credentials.

The generated registry also binds the normalized observability.redactPaths policy. Its authenticated manifest reveals only a secret-free fingerprint. The CLI requires that fingerprint to match before remote execution, and includes it in exact evidence identity; changing the policy therefore cannot reuse evidence or a deployment generated with the old policy. Run crux runtime generate and redeploy after a policy change.

If the app already calls crux.bridge(http, cruxConfig) on its exported router, Crux preserves the file byte-for-byte and the bridge registers these routes; no manual edit is needed.

For a custom router that does not use crux.bridge, Crux preserves the file and generates the composable helper at convex/_crux/http.ts. Register it once:

import { httpRouter } from "convex/server";
import { registerCruxEvalRoutes } from "./_crux/http";

const http = registerCruxEvalRoutes(httpRouter());
// Register the app's other routes on `http` as usual.
export default http;

Use either crux.bridge(...) or registerCruxEvalRoutes(...) for the Runtime Eval routes on a router, not both.

Convex advertises record-store only when a deployed Eval requires it and the request context can bind the component service. Unsupported requirements such as vector-store and asset-store remain visible in the Eval manifest but absent from host capabilities, so readiness fails before inference instead of claiming a service that is not present.

Next.js and other serverless functions

For a serverless() Runtime, crux runtime generate writes a Next-compatible handler that serves Runtime wakes and the authenticated Eval protocol from one catch-all route. Re-export GET, POST, and DELETE from that route. The generated module requires CRUX_EVAL_HOST_DEPLOYMENT_ID and CRUX_EVAL_HOST_TOKEN when it contains deployed Evals, and refuses process-memory-only storage.

Signed Runtime wake POSTs are handled by the same Eval-aware Runtime instance as job admission. A serverless invocation can therefore admit a job, end, and later execute the exact generated Eval when the queue delivers its wake.

export { GET, POST, DELETE } from "../../../../crux.generated/next";

The selected Runtime store must implement durable result storage. Model work is never kept alive by a function-local promise or waitUntil() equivalent.

Cloudflare Workers

Run crux runtime generate to create cloudflare/_crux/generated.ts, then pass its deployedEvals and runtimeTargets exports to createCloudflareEvalHost(). Export the returned Durable Object, bind the namespace in Wrangler, and store the execute bearer as a Worker secret. Durable Object storage holds canonical chunked results and alarms recover jobs; waitUntil() is not the correctness path.

The local CLI cannot infer Cloudflare connection values. Set all three explicit Crux environment variables for the selected deployment.

Other serverless hosts

A custom Runtime host must implement the authenticated manifest and Eval job protocol, durable reservation/job/result storage, wake recovery, and content-addressed result references. Generated registries contain identities, not functions, prompts, models, module paths, or credentials.

--plan may make one authenticated read-only manifest request when remote work is required. Missing credentials produce an unverified plan with exact setup remedies. --offline, including --offline --plan, never accesses the network, imports crux.config.*, or invokes adapter inference.

Remote hosts never silently redact task output because that could change Eval semantics. If output or response evidence contains a configured path or an always-sensitive key, the host fails before durable result storage with EVAL_RESULT_REDACTION_REQUIRED. Change the Eval to return a safe projection, or remove sensitive data before it reaches the task result.