# Provider access and lifecycle

Review dependencies, claims, organization ownership, and removal.

Source: https://faros.sh/docs/administration/providers/


## Enable a capability

Follow [Enable a provider](https://faros.sh/docs/use/workspaces/enable-provider/) in the target workspace. Review requested permission claims and dependencies before granting access. A provider running on the hub is not automatically enabled in every workspace.

## Organization-owned providers

An organization can register a provider it operates. Use the console’s **Providers → Self-Hosting** flow where available to obtain the provider workspace credential and generated installation instructions. An administrator must permit the organization operation; the runtime must be able to reach the advertised API endpoints.

Installing an existing provider belongs in [Self-hosting](https://faros.sh/docs/self-hosting/providers/). Writing one belongs in [Extend Faros](https://faros.sh/docs/extend/).

## Disable and remove

Identify resource owners and dependent applications first. Follow each provider’s cleanup instructions, then disable the workspace binding when its data and consumers no longer depend on it.

Deleting the platform Provider object tears down its provider workspace and can strand tenant bindings. Do not use this as a temporary disable operation. Coordinate removal with the operator and all affected workspaces.

## Verify and diagnose

After enabling a provider, use [API discovery and binding checks](https://faros.sh/docs/use/workspaces/enable-provider/#verify-enablement-from-the-cli) from its tenant workspace. For a registered provider whose service is unavailable, use the operator's separate [hosting-cluster diagnostics](https://faros.sh/docs/self-hosting/hub/operations/#inspect-the-hosting-cluster-from-the-cli). A running pod and a usable tenant API are distinct checks.