Connect integrations (owners and admins, on Integrations)

• Cloud & Operations (Sentry, Grafana Cloud): Connect Sentry / Connect Grafana Cloud sends you to the provider to sign in; no keys are pasted. When you come back, the card shows how the tools were sorted: lookups (searching issues, reading dashboards, logs and alerts) run freely; anything that changes something (resolving an issue, editing a dashboard, silencing an alert) needs an admin's approval every time, in Slack. Asked in a portal chat, the engineer posts the approval card to your Slack approval channel and waits (the chat shows "Waiting for an admin to approve this in Slack"); in a delivery the card goes to its thread, and the owner of the step it's on (or of the approval step before it, e.g. Deploy approval) can approve as well as admins. Undecided approvals are turned down after 30 minutes. Tools nobody could sort count as changes. Tools are re-read daily, and Re-read tools does it now; Disconnect removes it from every engineer. "Sign in again" means the provider revoked or expired the sign-in.
• Cloudflare: Connect Cloudflare. Engineers can read zones, DNS, Workers and logs, and deploy Workers. Cloudflare's tools can't be told apart as lookups or changes, so every Cloudflare action asks for approval.
• AWS: pick the region closest to you (it's where AWS's sign-in runs; engineers can still reach resources in any region), then Connect AWS and sign in with AWS. Whoever signs in needs the AWS managed policy AWSMCPSignInOAuthAccessPolicy, and engineers get that person's AWS permissions, so sign in with a role limited to what engineers should do. Every AWS action (deploys, reading logs, inspecting resources) asks for an admin's approval; AWS's documentation lookups don't. AWS sign-ins last up to 12 hours: the card shows until when, and Slack is told when it ends so someone can sign in again.
  • Long-running access (no sign-in), on the AWS card: create an IAM role in your AWS account using the trust policy the card shows (it trusts the platform, only with your workspace's External ID), attach AWSMCPSignInOAuthAccessPolicy plus only what engineers should be able to do, and paste the role's ARN. Engineers then keep AWS until you delete the role or change its trust; approvals still apply to every action.
• Netlify, Render: Connect and sign in. Engineers read sites/services, deploys and logs, and can deploy (each deploy needs approval). PagerDuty: pick US or EU (where your PagerDuty account lives), then Connect. Engineers read incidents, on-call and services, and can acknowledge or resolve with approval. A card marked Coming soon can't be connected yet: the platform is finishing its setup with that provider.
• What connecting unlocks: with Sentry, Grafana Cloud or PagerDuty connected you can hire the Site Reliability Engineer, and a delivery's Verify step runs (the SRE checks errors, metrics and logs after the deploy, reading only). With AWS, Cloudflare, Netlify or Render connected the DevOps Engineer can deploy, and a delivery's Deploy step runs (whether a deploy asks first follows How freely engineers act in Settings). Without them those steps wait for a person.
• Environments (staged deploys): say where each environment a delivery deploys to lives, e.g. staging = "Netlify site acme-staging", production = "Netlify site acme", with optional notes (a URL to check, a deploy freeze). Save environments. The Full delivery workflow deploys to staging, the SRE checks it, a person approves Production deploy approval, then exactly the same build goes to production and is checked again. A Deploy step for an environment that isn't described here waits for a person instead of guessing. If the production check finds a regression, the needs-help channel is told straight away, since a rollback may be needed.
• Databases (engineers read data, never write it):
  • Supabase, Neon: Connect and sign in. Always connected read-only (the provider enforces it), so queries run without approval. PlanetScale, MotherDuck: connect the same way; each query asks for approval.
  • Your databases (Postgres or MySQL): a name, the connection string for a read-only database user (ideally on a read replica) and its password, TLS, and optional notes. Connect database tests it first. Allow our servers' addresses (shown on the card) in your database firewall; private network addresses can't be reached.
  • Engineers can list tables, describe a table and run one read-only query at a time (30-second limit, at most 200 rows). Every query is in the audit log. Engineers see whatever that user can see, so choose its access with care. Changes to data or schema always go in a migration in a pull request.
  • Connecting a database makes the Data Engineer fully available.
• Custom MCP server: a name and the server's https address. Leave the token empty to sign in with OAuth if the server supports it, or paste its access token. Only connect servers you trust. Private-network addresses are refused. How many you can connect depends on the plan (Starter 1, Growth 5, Team the most); the same goes for your own databases. After a downgrade the newest ones beyond the limit are paused (kept, but engineers can't use them) until you upgrade or disconnect some.
• GitHub: Connect GitHub installs the YourEngineers GitHub App on your organisation; choose the repos. Engineers clone repos and open PRs. Manage GitHub changes it later.
• GitLab: Connect with GitLab (sign in, no token needed). Engineers clone and open merge requests.
• Bitbucket: Connect with Bitbucket (sign in, no token). Repo access and the webhook are set up for you.
• With any code host, engineers can see the CI checks on a pull request or branch and read why one failed (the failing job's log). On GitHub, job logs need the App's Actions: read permission; without it engineers still see each check's result and the file and line of each problem.
• Slack: Connect Slack installs the YourEngineers app. Invite it to the channels you want engineers in. Use Reconnect Slack if the Members page asks for the email permission.
• Jira: Connect with Atlassian. Then set where delivery issues go: Default project, Per repo rows (Add a repo), Per Slack channel rows (Add a channel, by channel ID: open the channel's details in Slack and copy the ID from the bottom). Save Jira settings. Unknown project keys are refused. With Jira connected, engineers can search and read issues, comment, create issues and move them between statuses, and groom them: set the assignee, priority, labels, parent epic, sprint and due date, and link issues ("blocks", "relates to"…). They never delete issues, rewrite someone's summary or description, or change many issues at once. Each change leaves a comment saying which engineer made it and is in the audit log. So that moving an issue to Done in Jira carries on a delivery waiting on it, use Make the webhook URL under Updates from Jira and add it in Jira (Settings → System → WebHooks, event Issue updated). It's shown once; making a new one stops the old one working.
• Confluence: Connect with Atlassian. One sign-in gives both "read & publish" and live read tools (search and open pages mid-conversation). Engineers can also update existing pages: each update is a new page version whose note names the engineer, so the page history shows who changed what and any earlier version can be restored. You can turn the read tools off; that stays off until you turn it back on.
• Google Drive: Connect Google Drive (one Google sign-in). Engineers publish documents (runbooks, ADRs, specs, notes) as Google Docs. Searching Drive mid-task isn't available yet.
• Notion: Connect with Notion, then pick the pages to share on Notion's consent screen; engineers only see those. Optionally set a default parent page ID for new pages. Engineers can add to the end of an existing page (under a line naming them), but not change or remove what's there.
• Figma: Connect with Figma. Optionally set a default team ID (from the figma.com/files/team/… URL) to enable search. Engineers read frames, text and colour tokens.

After connecting, existing engineers are updated to use the new tool.