Verify it's working

Three checks, in order: the server is up, your installs route through it, and it actually blocks an unsafe version.

1. The server is up

GET /healthz returns {"ok":true} with HTTP 200 on both the engine and dashboard:

curl -fsS https://npm.pkg.<your-domain>/healthz
# {"ok":true}

/-/ping is the canonical liveness probe; /healthz is the k8s-convention alias — identical shape.

2. Your installs route through Upwarden

Ecosystem	Confirm command	Expect
npm/Bun/pnpm/Yarn	npm config get registry	your proxy host
pip	pip install -v <pkg> 2>&1 | grep -i "looking in indexes"	proxy host
cargo	cargo install -v <crate> 2>&1 | grep -i upwarden	proxy source

A SAFE install behaves identically to a direct-to-registry install — same output, same lockfile.

3. It blocks an unsafe version (the real test)

The decisive proof is watching a block. Install a version Upwarden treats as non-safe (your operator will designate a canonical tripwire fixture for this purpose) and you should see an HTTP 403 with a [UPWARDEN]-prefixed body:

npm error code E403
npm error 403 {"error":"[UPWARDEN] Package 'demo-malware@1.2.3' is BLOCKED. Downgrade to known-safe version: 'demo-malware@1.2.2'."}

What each verdict looks like on the wire:

Verdict	HTTP	What you see
SAFE	200	normal install
QUARANTINED	403 (after up to FAST_PASS_TIMEOUT_MS, default 3s)	[UPWARDEN] Package '…' is currently QUARANTINED. Analysis in progress.
BLOCKED	403	[UPWARDEN] Package '…' is BLOCKED. Downgrade to known-safe version: '…'.

Silent rollback: a floating range (^1.2.0, ~=1.2) never sees a non-safe version — it’s stripped from the manifest and resolves to the highest safe version, so your build stays green. You only get a 403 when you pin exactly to a non-safe version.

4. Confirm it was recorded

Every install and every block writes an audit_log row scoped to your project, stamped with the apiKeyId. That row is the canonical “why did my install (not) go through” record. See Querying the audit log for the query patterns.