Managed Upwarden. Zero infrastructure.

1 · Sign up

Create your organization in the Upwarden Cloud console. There's nothing to install — the firewall is provisioned behind your account.

Console: https://app.upwarden.io/

2 · Get a key

Every install authenticates with a vk_… project key, scoped to one project inside your organization. In the console:

• New organization → give it a slug + name.
• Open it → Projects → New project (usually one per repo or pipeline).
• Open the project → API keys → New key. The vk_… string is shown once — copy it into your secret store now.

Full walkthrough (UI and scriptable API): Create your first key.

3 · Point your package manager

One config line per ecosystem, pointed at the managed endpoint <eco>.pkg.upwarden.io. Drop your vk_… key into the matching environment variable. Every install from then on flows through the firewall.

registry=https://npm.pkg.upwarden.io/
//npm.pkg.upwarden.io/:_authToken=${VG_NPM_API_KEY}

$ export PIP_INDEX_URL=https://${VG_PYPI_API_KEY}@pypi.pkg.upwarden.io/simple/

# The env var name is derived from the REGISTRY NAME below. Rename the
# registry and this must change with it: CARGO_REGISTRIES_<NAME>_TOKEN,
# uppercased with hyphens turned into underscores (my-reg -> MY_REG).
[source.crates-io]
replace-with = "upwarden"

[registries.upwarden]
index = "sparse+https://crates.pkg.upwarden.io/index/"

$ export CARGO_REGISTRIES_UPWARDEN_TOKEN=${VG_CRATES_API_KEY}

The two names must match. Cargo derives the variable from the registry name in your config — call the registry something else and it becomes CARGO_REGISTRIES_<THAT>_TOKEN, uppercased with hyphens replaced by underscores — a registry named my-reg uses CARGO_REGISTRIES_MY_REG_TOKEN. Nothing on our side reads the variable; we only see the resulting header, so a mismatch looks exactly like a bad key.

A 401 after a working start is normal-looking and usually a typo. config.json is served anonymously on purpose, because cargo reads it before authenticating to discover whether auth is required. So a mistyped token gives you a successful bootstrap and then a 401 on the first real fetch — the registry is up; the credential is wrong.

bun is first-class — it reads the standard registry config, so it's covered exactly like npm. Private and scoped packages keep working: your existing upstream tokens pass straight through. Other ecosystems (Maven, NuGet, Go, RubyGems) follow the same <eco>.pkg.upwarden.io convention — see the full quickstart.

4 · Verify it works

Install anything. A safe package installs as usual — the only added latency is a single proxy hop. To watch the firewall act, request a version known to be blocked and see it roll back:

$ npm install lodash
upwarden › lodash@4.17.22 — BLOCKED (malware signature match)
upwarden › resolving to last safe version → 4.17.21
added 1 package — lodash@4.17.21  ✓ build green

Floating ranges roll back automatically; exact pins to a blocked version fail loudly with an actionable [UPWARDEN] message. More: Verify it's working and Troubleshooting.

What we can see — and what we can't

Upwarden Cloud is the managed path, so — unlike self-host — your install requests transit our managed infrastructure. We keep that honest:

• Isolated per tenant. Every organization's data is separated at the database row level; one tenant can never see another's.
• We see package coordinates, not your code. Upwarden is a registry proxy — it sees the dependency names and versions you request and the artifacts it serves, not your source.
• Your audit log, yours to query. Each install and block is recorded against your project; retention depends on your plan. We never sell or share it.
• Want nothing to leave your network at all? Self-host keeps every byte inside your perimeter with zero telemetry — the same product, your infrastructure.