Skip to main content
Prowler is a monorepo composed of several runtime components — Prowler Local Server (the web user interface), Prowler API (the backend), Prowler SDK, and Prowler MCP Server (Model Context Protocol) — that frequently share a single .env file. To keep that shared configuration unambiguous, each component namespaces its environment variables with a component-specific prefix.

​
Component Prefixes

Each component owns a dedicated prefix for the environment variables it reads:

​
Why Component Prefixes Matter

Component prefixes solve three concrete problems in a shared configuration file:
  • Collisions in a shared .env: Several components historically read identically named variables. The API base URL, for example, is consumed by more than one component, so a single unprefixed name is ambiguous. A component prefix removes that ambiguity.
  • Explicit ownership: A prefix states, at a glance, which component consumes a variable.
  • Reduced accidental exposure: For Prowler Local Server, scoping browser-facing configuration under one intentional prefix prevents server-only values from leaking into the client bundle.

​
Prowler Local Server

Prowler Local Server has adopted the UI_ prefix. Its public configuration is resolved from the container environment at runtime rather than inlined at build time, so a single pre-built image serves any deployment. For the operational details on changing these values without rebuilding the image, see Troubleshooting. The former build-time variables map to the new runtime variables as follows: UI_CLOUD_ENABLED is a plain runtime boolean flag that enables Prowler Cloud behavior when set to the exact string "true" and defaults to off; unlike the other renamed variables it has no legacy fallback, so NEXT_PUBLIC_IS_CLOUD_ENV is no longer read. UI_SELF_REGISTRATION_ENABLED is a runtime opt-out flag that Prowler Local Server reads only when UI_CLOUD_ENABLED is "true". It defaults to on and turns off when set to "false", matched case-insensitively so the same value can be shared with a backend setting written False. When it is off, the sign-up page only opens with an invitation token, the sign-in page drops its “Sign up” link, and the profile hides “Create organization”; invited users can still complete their registration. Outside a Prowler Cloud deployment the flag is ignored and account creation stays open.

​
Registry UI Rollout and Rollback

UI_REGISTRY_ENABLED is an optional runtime flag for Prowler Cloud and Private Cloud. Registry is eligible only when both UI_CLOUD_ENABLED and UI_REGISTRY_ENABLED are the exact string "true" and the current user has the backend-authorized manage_registry permission. Unset, "false", or malformed values fail closed. The flag defaults to off and is not a replacement for backend authorization. Registry access is independent of billing; Private Cloud can use it with CLOUD_BILLING_ENABLED=false. Roll out Registry only after the Registry backend dependency is deployed, intended roles have manage_registry, and acceptance with real credentials has exercised installation, provider account creation, credentials, connection, and scan launch. Deploy the UI with UI_REGISTRY_ENABLED unset or "false"; set it to "true" only in the prepared process environment, then restart or otherwise apply the environment update required by the platform. A Registry key must belong to the configured Registry environment; a production key does not authenticate against a development Registry. The catalog displays all artifacts, including built-ins and packages containing only checks or compliance frameworks. Only external provider artifacts support Add. After confirmed installation, open Providers and select the option labeled Registry to configure an account. Creating accounts and running scans also require the corresponding provider and scan permissions. Removing an artifact keeps existing provider accounts, but future connections or scans can fail until the artifact is installed again. To roll back, set UI_REGISTRY_ENABLED=false or remove it and apply the environment update. Proxy, page, and action checks deny on their next request. Navigation refreshes from server-authorized access when the page is requested again. Rollback does not delete Registry credentials, tenant artifact records, or provider accounts. The build-time-only Sentry variables used for source-map upload — SENTRY_ORG, SENTRY_PROJECT, SENTRY_AUTH_TOKEN, and SENTRY_RELEASE — keep their names, as they are not part of Prowler Local Server’s runtime configuration.

​
Enabling Third-Party Integrations

Prowler Local Server gates each optional third-party integration behind an explicit enable flag. When an integration is configured through its new UI_* variables, it loads only when its flag is set to the exact string "true"; any other value, including unset, leaves it off. This default-off behavior keeps a deployment free of third-party egress unless it opts in. Deployments still using the deprecated legacy variable names keep loading without the flag, for backward compatibility (see Deprecated Names). When an integration is enabled but its required configuration is missing, Prowler Local Server fails fast at server startup with a clear error, so a misconfigured container never starts silently. A new UI_* value set while its enable flag is not "true" is ignored, and the server logs a one-time startup warning noting that the integration will not load. Legacy names follow the backward-compatible rule described in Deprecated Names. PostHog support is currently limited to configuration validation: Prowler Local Server reads and validates the PostHog variables but does not yet load a PostHog client.
Configuring an integration through the new UI_* variables now requires its enable flag. A deployment that adopted UI_SENTRY_DSN or UI_GOOGLE_TAG_MANAGER_ID must also set UI_SENTRY_ENABLED=true or UI_GOOGLE_TAG_MANAGER_ENABLED=true to keep the integration active. Deployments still using the legacy names (NEXT_PUBLIC_*, or POSTHOG_KEY and POSTHOG_HOST) keep working without the flag.

​
Upcoming Breaking Change

Adopting the API_, SDK_, and MCP_ prefixes for Prowler API, Prowler SDK, and Prowler MCP Server is a planned breaking change in a future release. Migrate environment configuration to the new names when upgrading.
Prowler API, Prowler SDK, and Prowler MCP Server have not yet adopted the convention. In a future release, the variables each of these components reads will be namespaced under API_, SDK_, and MCP_ respectively. The per-component mapping from current to prefixed names will be documented when each change is released.

​
Deprecated Names

  • Prowler Local Server: The bare server-side SENTRY_DSN and SENTRY_ENVIRONMENT are no longer read; the server and edge runtimes now read UI_SENTRY_DSN and UI_SENTRY_ENVIRONMENT. The former NEXT_PUBLIC_* names — and, for PostHog, the unprefixed POSTHOG_KEY and POSTHOG_HOST — are deprecated but stay backward compatible: they are read at runtime regardless of the enable flag, so an existing deployment keeps its integration active without opting in. The new UI_* names, by contrast, load only when the matching enable flag is set to "true". These legacy names will be removed in a future release, so migrate to the UI_* runtime variables — and set the enable flag — on the running container.
  • Prowler API, Prowler SDK, and Prowler MCP Server: The current, unprefixed variable names are deprecated. They continue to work today and will be removed once the prefixed convention is adopted for each component, as described in Upcoming Breaking Change.