Administer a private deployment

Brief can run in a customer-controlled AWS environment. A managed installation uses a customer-hosted runner to install a qualified release; a qualified customer-operated release uses the manual installation path. Choose the path, identity provider, AI provider, integration credentials, and maintenance responsibilities with Brief before installation. Your deployment operator receives the installation and ongoing operations runbooks for its release.

The application and its data stores run in the customer account. A private deployment can use the customer's Amazon Bedrock access or customer-owned provider keys, and can use OIDC identity or a customer-owned local bootstrap administrator. Customer-owned secrets stay in the customer's secret storage. Each installation has its own address; use that address for sign-in, callbacks, and API requests instead of the shared Brief app address. See the API reference for routes and authentication.

Prepare and install

Before scheduling an installation, the customer operator checks AWS region and capacity, network ranges, outbound access, domain and certificate plans, AI model access, identity settings, and the selected integrations. Bedrock requires model access in the deployment region; the customer-key option requires a compatible embedding provider and its key. The customer reviews the release package and infrastructure permissions before provisioning. The managed path then runs its post-install database and runtime checks; the customer-operated path follows the corresponding release runbook. Complete a browser sign-in and workspace check before handoff.

After installation, use the release's customer operations runbook for health checks, backups, secret rotation, upgrades, recovery checks, and support bundles. A configuration or support operation should run in the customer environment under its approved role. Do not send secrets or raw customer data in support requests; use a customer-approved redacted support bundle when one is needed.

Configure the deployment

The customer-owned configuration process supports validation, a change preview, application, replay, and drift checks. Start with a versioned configuration packet and the customer-reviewed access template for the target deployment and release. Run validate, then preview. Review the proposed changes and approve that preview before apply; applying or replaying requires an approval reference. Run apply again and check that it reports no change. Use drift to detect differences from the accepted configuration and replay after a qualified release deployment. The supported settings and release are checked against the deployment before changes are applied.

For a managed installation, the customer operator uses these named actions on the install's Actions page:

1. Upload the configuration packet and reviewed access template to the deployment's customer-owned storage using the paths in the release runbook.
2. Run private-configuration-validate, then private-configuration-preview. Review the preview and its digest.
3. Record approval for that preview, upload the approval record, and run private-configuration-apply. Repeat apply to confirm the accepted configuration is unchanged.
4. Run private-configuration-drift for later checks. After a release change, use private-configuration-replay with an approval reference when the accepted settings must be reapplied.

For a customer-operated release, ask Brief for the release's installation and ongoing operations instructions. A customer-operated package is issued only for designated releases. If validation fails, correct the packet or target release before previewing. If drift is reported, inspect the difference and use a reviewed configuration change or approved replay; do not treat a drift result as a successful apply.

Connect customer-owned apps

In a private deployment, a workspace administrator can open Integrations → Connect a Tool Into Brief → Customer-owned provider apps → Manage provider apps…. Choose the Slack, GitHub, or Microsoft Teams tab to get setup artifacts for a customer-owned app. The artifacts reflect that deployment's address and release and contain registration values and manual steps, without secret values.

Use Configure to open the provider's setup page, then follow the displayed steps. Download manifest is available for Slack, Download registration values for GitHub, and Download package for Microsoft Teams when its app ID passes validation. To change app credentials, select Rotate credentials and follow the displayed steps: create new versions of the named secrets in the customer Secrets Manager, reload every web and worker task, run validation, and retire the old versions after the validation window. Validate checks the generated artifact; View required changes shows checks and differences. To compare an existing provider configuration, choose Compare current configuration… and select its JSON export. A validation error means setup did not complete; check the deployment configuration and retry. The Microsoft Teams artifact is for a private deployment administrator and does not provide public self-service tenant setup. See Connecting your tools for other integration options.

Map identity-provider groups

When the private deployment uses OIDC, workspace administrators can open Settings → Identity Mappings. Choose Add Mapping…, enter the Provider issuer and Provider tenant, and select Membership authority. Use OIDC sign-in claims, or SCIM directory when that directory mode is configured. Enter the Stable external group ID, or choose an existing mapped SCIM group when available. Select the Brief workspace and Mapped role (Member or Administrator), then choose Preview Change. Review affected grants in Review Mapping Change and select Apply Change. Group display names are labels and do not grant access.

Use the mapping table to edit or remove a mapping, with the same preview and apply step. A preview that would remove your current administrator access cannot be applied; preserve an administrator mapping or switch workspaces first. If the page cannot load, refresh it. If Identity Mappings is absent, ask the deployment operator whether private OIDC group mappings are configured.

The Identity Mappings navigation item appears only when group mappings are supported by the deployment. Mapping changes require an administrator's human session and are checked against the workspaces they administer. See Workspace administration for other workspace settings.

Operator access

Private setup-operator access is a separate, limited role for deployment setup. Your organization controls its time-limited grants and approval through its identity-provider and access process. It can inspect deployment capabilities without receiving ordinary workspace access; it cannot be assigned with the Mapped role control above.

Deployment operators can export audit evidence for configuration changes and temporary operator access. In installations with an Actions page, run private-audit-export. Customer operators can also run the export command in their deployment. The export saves an audit manifest in the deployment's storage, returns an evidence reference, and reports any audit policy alerts.

Run the export as part of handoff and after temporary support access is revoked. Review any alert before accepting the handoff. For a routine problem, ask the customer operator to run the release's health check or produce a redacted support bundle; recovery and restore follow the qualified release's customer-approved procedure.