Integrations
Connect organization-owned providers once, then choose the capabilities each project needs.
Connect organization-owned providers
Organization admins connect Braintrust, PostHog, Sentry, and Linear from Organization Settings > Integrations. Crucible verifies credentials before saving them, never returns stored secret values, and keeps connection management separate from project access.
- Braintrust: Create an organization-owner service token and identify the service account that should own generated project tokens.
- PostHog: Create a personal API key with Organization read and Project write scopes, scoped to the one organization where Crucible should create projects.
- Sentry: Create an internal-integration token and choose the default team slug for new projects.
- Linear: Create one private OAuth application for the organization, enable the
client credentialsgrant, and give it access to the destination team. Enter its client ID, client secret, and uppercase team key.
Updating an organization's Linear connection takes effect in Crucible without re-adding Linear Feedback to projects. If the destination team changed, first move each existing Linear project to the new team in Linear.
Targets with Linear Feedback receive only Crucible routing values (CRUCIBLE_API_URL, CRUCIBLE_FEEDBACK_ENVIRONMENT, and CRUCIBLE_API_KEY), never Linear credentials. Crucible files feedback in Linear with the organization's current connection.
Choose integrations per project
Project admins manage a project's integrations in its Settings tab, under Integrations. Select Add integration and pick from the menu; each integration can be added once. Ciridae-managed integrations need no organization credential and are always listed. Organization-owned providers are listed only while their organization connection is connected and enabled.
The Applies to column shows which deployments and development surfaces each integration reaches. Crucible defines those targets per integration; project admins choose membership, not targets. Optional integrations can be removed from the same table, while required ones, such as Linear Feedback once added, stay attached so they keep working across environments.
Modal chat sandboxes
Projects created from the Agents template receive Modal as a required integration. Crucible provisions one restricted Modal Environment per project and a scoped service token for each deployment, workspace, and local setup. Backends and workers call Modal directly, with no runtime proxy or organization credential.
Each target receives MODAL_ENVIRONMENT plus a MODAL_TOKEN_ID and MODAL_TOKEN_SECRET pair with access only to the project's Environment. Modal reveals a token secret once, so Crucible caches the pair and reuses it on retries. If provisioning needs operator reauthentication, existing runtime tokens keep working.
Ciridae MCP
Ciridae MCP is the project-tools gateway: agents connect to it over the Model Context Protocol and operate the project through tools instead of hand-built API plumbing. It is Ciridae-managed, and adding it is the whole setup. Crucible mints a key for each eligible environment, and the project's tooling calls the gateway without anyone creating or distributing credentials.
The gateway dispatches tool calls to the project's own backend. It reaches only environments that serve one at an address Crucible can name: full deployments through their domain, and lite deployments and workspaces through their subdomain. Local development is out of scope. Adding the integration provisions only the environments that qualify at that moment. Add it once the environments you want covered are serving.
For each provisionable target, Crucible mints a key in the Ciridae MCP service carrying the target's backend URL and auth realm, then mounts it as CIRIDAE_MCP_PROJECT_ENDPOINT_SCOPED_MANAGEMENT_KEY alongside CIRIDAE_MCP_ENDPOINT, the gateway endpoint. The template's project tools read both variables to call the gateway. A target without a resolvable backend origin cannot receive a key: a workspace or lite deployment created without a subdomain is skipped, and a full deployment with no domain to derive one from fails provisioning explicitly.
Set new-project defaults in templates
A template's project.yaml is the only source of integration defaults for projects created from it. Connecting a provider to an organization does not add it to every project, and existing projects keep their own integrations.
Ownership
| Decision | Owner | Outcome |
|---|---|---|
| Connect, reconnect, enable or disable, and disconnect provider credentials | Organization admin | The organization controls its provider accounts and stored credentials. |
| Add an integration or remove an optional integration for one project | Project admin | The project receives only the capabilities its team selected. |
| Choose integrations for future projects | Template project.yaml | New projects inherit template.default_standard_api_integrations from the selected template. |
| Define supported provisioning targets | Crucible | Targets stay consistent and cannot be changed by frontend requests. |