> ## Documentation Index > Fetch the complete documentation index at: https://docs.westyx.cloud/llms.txt > Use this file to discover all available pages before exploring further. # Glossary > Definitions for the core concepts and terms used throughout Nexus. ## Tenant A tenant is the top-level organisational unit in Nexus. It maps to a company, agency, or individual account and is the billing boundary - invoices are issued per tenant, and tier quotas apply to projects within it. Every user belongs to at least one tenant. Tenant-level roles control who can manage billing, invite members, and administer projects across the organisation. See also: [Architecture](/concepts/architecture#tenant) *** ## Project A project represents a single product or application. It has its own set of services, environments, members, and a **tier** that controls resource quotas (number of services, secrets, configs, flags, and audit history length). Every project belongs to one tenant. A tenant can have multiple projects. See also: [Architecture](/concepts/architecture#project) · [Plans & Tiers](https://nexus.westyx.dev/plans) · [How to create a project](/how-to/create-project) *** ## Service A service is the unit of work in Nexus. It represents a single deployable unit - a backend API, a worker, a frontend app - and is the scope for all secrets, configs, and feature flags. Every service has: * A **kind** (Backend or Frontend) - immutable after creation * A **slug-based API endpoint** * A primary and secondary **API key** for authentication and zero-downtime key rotation | Kind | Key type | Can store secrets | Notes | | -------- | ------------------- | ----------------- | -------------------------------------- | | Backend | Secret key (`wxs_`) | Yes | Supports WIF | | Frontend | Public key (`wxp_`) | No | Runs in browsers and untrusted clients | See also: [Architecture](/concepts/architecture#service) · [How to create a service](/how-to/create-service) *** ## Umbrella service An umbrella service is a backend or frontend service that acts as a shared data store for other services of the same kind. It has no API endpoint and no API keys of its own - it cannot be connected to directly. Services linked to an umbrella automatically inherit its secrets, configs, and flags. If a linked service defines a value with the same key as the umbrella, the service-level value takes precedence. **Example:** three backend microservices in the `production` environment all need the same database URL. Store it once on an umbrella service and link all three to it - no duplication, one place to update. Umbrella services are backend or frontend only - kind is still immutable, and a service can only be linked to an umbrella of the same kind. See also: [How to create a service](/how-to/create-service#optionally-enable-umbrella-mode) *** ## Environment An environment is a named deployment stage within a project (e.g. `develop`, `staging`, `production`). Each service belongs to exactly one environment. The environments available to a project depend on its tier. Developer environments are personal per-developer environments created automatically when a developer joins the project - they are separate from the project's shared environments. See also: [Architecture](/concepts/architecture#environments) *** ## Developer environment A developer environment is a personal environment automatically created for each developer when they join a project. It is isolated from the project's shared environments (`develop`, `staging`, `production`, etc.) and gives the developer full freedom to create and modify services without affecting others. The full `develop` environment can be imported into a developer environment as a starting point. Developer environments are hidden by default in the services list - toggle **Dev envs** to show them. See also: [How to create a service](/how-to/create-service#developer-environments) *** ## Secret A secret is an encrypted piece of sensitive data stored on a backend service - database passwords, API tokens, TLS certificates, and similar values. Secrets are encrypted at rest with AES-256-GCM and never appear in logs or SDK responses to frontend clients. Secrets are **versioned** - every value change creates a new version. The latest version is marked active and is what the SDK reads. Previous versions are retained and can be restored (restoring creates a new version with the old value, preserving the full history). Two types are supported: * `text` - strings and passwords * `file` - certificates and binary content Secrets are only available on backend services. If a service is linked to an [umbrella service](#umbrella-service), it inherits the umbrella's secrets automatically. A service-level secret with the same key takes precedence over the inherited one. See also: [How to create a secret](/how-to/create-secret) · [Secrets reference](/features/secrets) *** ## API key An API key authenticates an SDK client against a specific service. Each service has a **primary** and a **secondary** key to enable zero-downtime rotation. * Backend services use `wxs_...` keys * Frontend services use `wxp_...` keys Keys are shown only once at generation time. As an alternative to static API keys, backend services support [Workload Identity Federation](#workload-identity-federation-wif). *** ## Workload Identity Federation (WIF) WIF is a keyless authentication method for backend services. Instead of a static API key, the SDK obtains an OIDC token from the hosting environment (GCP, AWS, Azure, or Kubernetes) and exchanges it for a short-lived session token with Nexus. WIF eliminates the need to store static secrets in your deployment configuration. It requires the **L** or **XL** tier, or the **Security Add-On** (\$5 / project / month) on lower tiers. See also: [Architecture](/concepts/architecture#workload-identity-federation-wif) · [Go SDK - WIF setup](/sdks/go#workload-identity-federation)