Configure

Organization administration

The active organization is the tenant boundary for repositories, runs, values, billing, MCP, integrations, keys, and audit events. Roles should match each member’s operational responsibility.

Roles and permissions

Authorization uses an ordered minimum-role model: viewer, member, admin, owner.

Role	Intended access
Viewer	Read organization resources, workflows, runs, usage, settings summaries, logs, and artifacts.
Member	Viewer access plus manual/repository dispatch, run cancellation, and reruns.
Admin	Member access plus repositories/provider setup, secrets/variables/environments, worker runtime limits, migration, MCP credentials, Slack, and Entire credential rotation.
Owner	Admin access plus subscription checkout/portal/spend controls and workspace-key rotation.

Environment decisions are policy-specific

Required reviewer selection, self-review rules, and admin bypass settings can make an otherwise privileged member ineligible for a particular deployment decision.

Members

Organization settings lists each member’s display name, email, and role. Environment reviewer lists are drawn from these memberships.

Current membership boundary

The current customer API exposes organization creation/listing and activation, but not a public invite or role-mutation endpoint. Do not build automation against internal database records. Use the supported identity/onboarding process or contact support for membership changes until lifecycle controls are exposed.

Before removing or downgrading an administrator, transfer any external authority they own: GitHub App administration, Entire tokens, Slack workspace approval, billing access, incident contacts, and secrets in third-party systems.

Switch organizations safely

The dashboard stores the selected organization in an HTTP-only organization cookie and every customer query combines resource identity with that organization ID.

1
Open the organization switcher
Choose only an organization where your authenticated user has a current membership.
2
Activate the destination
Runnable updates the runnable-organization cookie after verifying membership.
3
Reopen the resource
Repository, run, token, and settings IDs from another organization intentionally return not found or forbidden.

MCP credentials are also organization-scoped; switching the dashboard does not change the organization attached to an already-issued MCP token.

Set the worker runtime ceiling

Every organization starts with a 30-minute maximum worker runtime. Admins and owners can raise it to one hour or more, up to the platform’s six-hour workflow limit.

The organization ceiling is applied when Runnable provisions the worker, builds the agent assignment, reserves billable capacity, and reconciles overdue attempts. If a workflow declares a shorter timeout-minutes, the shorter workflow value takes precedence.

Use the smallest safe ceiling

Choose enough time for the organization’s longest legitimate job. A bounded ceiling stops stuck workers, limits unexpected usage, and records the resulting job as timed out.

Audit history

Organization settings shows recent immutable security and operations events with action, resource, actor, and timestamp.

Event family	Examples
Provider	GitHub installation linked, Entire repository linked, checkout provider updated, relay rotated.
Configuration	Secret/variable created or deleted, environment created/updated/deleted, workspace key created/rotated.
Operations	Environment decision, MCP log read, MCP dispatch/rerun/cancel.
Commercial	Checkout created, billing controls updated, Stripe subscription lifecycle, budget alert.
Integration	Slack connected, preferences updated, test sent, disconnected, or uninstalled.

Audit metadata deliberately records identifiers and operational context, not decrypted secret values or webhook credentials.

Rotate the workspace encryption key

Each organization has one active versioned 256-bit workspace key wrapped by a root key held outside the database. Owners can rotate it from Organization settings.

1
Confirm root-key availability
The deployment must retain the current root key and previous root key versions required to decrypt older workspace keys.
2
Rotate
Runnable serializes rotation, retires the previous active workspace key, and creates the new active version.
3
Use the new version
New or updated secrets and integration credentials wrap their data keys with the new workspace key. Existing ciphertext remains readable through its retired key version.
4
Do not destroy early
A retired key can still be referenced by existing encrypted records. Destroy only after every dependency is rewrapped or deleted and recovery requirements are satisfied.

Rotation is not credential rotation

Rotating the workspace key changes encryption-at-rest wrapping. It does not replace the GitHub installation, Entire token, relay bearer, Slack webhook, MCP token, or any customer secret at its external authority.

Credential ownership checklist

Assign a human owner and a backup for every authority that can stop builds or expose production data.

Credential	Runnable storage	Who should own rotation
GitHub App installation	Installation identity; short-lived tokens minted on demand.	GitHub organization owner plus Runnable admin backup.
Entire access token	Encrypted repository secret named ENTIRE_TOKEN.	Entire project admin plus Runnable admin backup.
Entire relay bearer	Only SHA-256 hash; cleartext held by relay sender.	Relay operator.
Slack channel webhook	Encrypted integration credential; never exposed to runners.	Runnable admin and Slack workspace admin.
MCP token	Only SHA-256 hash; cleartext held by the client.	Named automation owner; revoke when ownership changes.
Billing	Stripe customer/subscription identifiers, not payment details.	Runnable organization owner.

NextIntegrationsConfigure Slack delivery and operate the Entire relay.