Skip to main content
CoreWeave and Forge each have their own identity system. CoreWeave’s identity and access management (IAM) authenticates and authorizes access to platform resources. These resources include CoreWeave Kubernetes Service (CKS) clusters, virtual private clouds (VPCs), and CoreWeave AI Object Storage. Forge has its own identity layer, inherited from Weights & Biases, that governs organizations, teams, projects, and product access. The two systems stay separate. Each has its own sign-in page and admin console, so you administer each one separately. This page is for administrators who manage users and access on both platforms. It describes where each administrative task belongs and how the two systems relate. To choose which system governs a given resource, see Which access controls apply to your work.

Where to manage what

The following table shows where each task belongs: Each platform bills for its own products and has a separate billing page, so a Forge invoice doesn’t include CoreWeave infrastructure usage. For the full billing orientation, see CoreWeave Infrastructure and Forge billing.

How the two identities relate

Each platform authenticates its own users:
  • CoreWeave IAM authenticates users for platform resources and authorizes them through IAM Access Policies.
  • Forge authenticates users through its own identity layer. Forge and wandb.ai share one account and one user store, so a Weights & Biases user signs in to Forge with their existing account.
Sign-in is separate for each platform. Users sign in to Forge at id.coreweave.com/login and to the CoreWeave Cloud Console at console.coreweave.com. Sessions are per domain. A user signed in to the Cloud Console signs in again when they open Forge, and vice versa. The Cloud Console global navigation links to Forge, but that link doesn’t carry a Console session into Forge. A CoreWeave user who doesn’t already have Forge access reaches Forge by signing up at id.coreweave.com/signup. A Cloud Console sign-in doesn’t create a Forge account or place a user in a Forge organization. Nothing in Forge grants access on the CoreWeave platform. A Forge identity and a Forge role apply only within Forge.

Administer access in both systems

The following sections describe how administration works across the two systems. This behavior is subject to change.

Grant and revoke Forge access in Forge

You can view and assign Forge access in the Forge Console, including which Forge products a user can reach and what Forge roles they hold. CoreWeave IAM roles, including IAM Admin, govern the CoreWeave platform only and don’t grant a Forge role or Forge product access. To change a user’s Forge role, change it in Forge. You can block forge.coreweave.com on your network to prevent users on that network from reaching Forge.

Configure Forge authentication methods

Forge supports Security Assertion Markup Language (SAML), OpenID Connect (OIDC), and passwords, each configured inside Forge. CoreWeave IAM doesn’t govern any of them. SAML single sign-on (SSO) on the CoreWeave side covers the Cloud Console only. If you want one identity provider behind both platforms, configure it in each one. For the CoreWeave side, see SAML SSO and Login methods.

Manage programmatic access in each platform

Create and manage API keys and access tokens separately in each platform. Each credential is scoped to the platform that issued it. A CoreWeave API access token grants access on the CoreWeave platform, and a Forge API key grants access in Forge. Rotate and revoke each credential in the platform that issued it.

Review and deprovision in both systems

To review a person’s complete access, check both systems. Rotate a user’s credentials in both systems, and deprovision a departing user separately in each system.
When you remove a user from CoreWeave IAM, that doesn’t remove their Forge access. When you remove them from Forge, that doesn’t remove their CoreWeave access. When someone leaves your organization or changes roles, update their access in both systems.

Multi-tenant Forge deployments

This page describes multi-tenant Forge. W&B Dedicated and W&B Self-Managed deployments keep their existing identity configuration and sign-in pages. See Deployment options. The following pages cover related identity and access topics:
Last modified on September 30, 2026