Log in

One command signs you in and links the local registry endpoints the platform needs. Exact put, npm, Go, and OCI credentials are short-lived and acquired later for a named owner workspace and package.

Authentication uses the OAuth 2.0 device authorization flow: the CLI prints a URL and a code, you approve in a browser, and the CLI stores a short-lived token locally. You do not paste secrets into the terminal.

Sign in

putnami cloud login

The CLI opens the verification URL in your browser (use --no-open to print it instead), waits for approval, then stores your session. On success it also writes the per-registry endpoint index. It does not mint a host-wide registry key or write a token recipe that lacks package coordinates.

Want to… Do this
Print the URL instead of opening a browser putnami cloud login --no-open
Use a non-default OAuth client putnami cloud login --client-id <id>
Request specific scopes putnami cloud login --scope "openid profile email apikeys:write"

The default scope includes apikeys:write for workspace machine-token management. Registry access is not part of this session: a registry token is minted separately per registry, and what it reaches is decided by your workspace membership at request time.

Check who you are

putnami cloud whoami

Add --output=jsonl for machine-readable output.

Tokens for scripts and CI

Interactive login is for humans. For automation, mint a bearer for a specific purpose and pass it to the tool that needs it. Each call emits a fresh, bare token on stdout — nothing else — so it is safe to capture.

The cache form is least-privilege: it carries only cache.read and cache.write for the linked workspace, and its short-lived backing credential is revoked immediately after the bearer is minted.

A registry form takes the registry kind and nothing else. The bearer carries one scope — the kind — which names the registry it is for and authorizes nothing on its own. The registry then decides per namespace from your workspace membership. putnami cloud registry-token --host <host> is the same thing addressed by host, for tools that know a URL rather than a kind.

putnami cloud token --for cache   # remote build cache
putnami cloud token --for npm     # npm registry
putnami cloud token --for go      # Go module proxy
putnami cloud token --for oci     # OCI images
putnami cloud token --for put     # Putnami-native packages
putnami cloud token --global --output=json  # fresh unscoped human bearer; operator authority is resolved by the API

To inspect or clean the local registry endpoint/compatibility state:

putnami cloud registries          # set up / show status
putnami cloud registries --output=jsonl   # machine-readable status

Identity & access

Your session is an OIDC identity issued by auth.putnami.cloud. Access is scoped, not global:

  • Scopes on your token bound what a session may do (for example, apikeys:write to mint registry tokens).
  • Registry access rides exact, at-most-five-minute Distribution leases. Dependency operations default to read; publish/promote must be explicit.
  • Workspace access is granted per workspace; you operate the workspaces your identity is entitled to.

Workloads validate these tokens offline against the auth server's JWKS and fail closed on anything they cannot verify.

Sign out

putnami cloud logout

This revokes the server-side registry tokens it can reach and removes the local credentials. Run it from a session that is still valid so the remote tokens are revoked, not just the local files.

Next