# Private components

Your private component registry, hosted and managed in Frontfriend.

Private components extend your Design System with source owned by your team. Frontfriend provides the cloud infrastructure for the private registry, authenticated access and version management, alongside the CLI workflows that connect your applications to the system.

Your team creates the components and controls their versions. Frontfriend hosts the registry and provides the delivery infrastructure. See the [CLI reference](/docs/cli-reference/) for project setup, component downloads and design-context sync.

## A clear home for custom code

A private component belongs to one Design System and is bound to its `ffId`. Its explicit address uses a `custom/...` namespace with categories chosen by the client. That address is separate from framework metadata and from the installation path chosen by the application.

## No invisible overrides

Private components do not automatically shadow canonical components. Installing private source over a canonical file must be explicit and confirmed. Sharing the same source with another Design System requires deliberate republication under that system’s identity.

## Immutable versions

A private component version is an immutable source bundle with an independent semantic version, Markdown changelog and declared npm/private dependencies. Releases pin exact versions and validate dependency closure.

## Who can publish

In Self-serve, members can publish to `base`. Members, admins and owners can promote snapshots along their custom workflows without an approval request. Managed workspaces consume releases while Frontfriend operates authoring, publication and approvals.

## Existing custom registries

Existing static v3 managed custom components remain readable until their separate migration. Use the explicit target and Design System identity for new private publication integrations.

Follow [Versions & releases](/docs/versioning/), [Plans and access](/docs/plans/) before planning a rollout.