ForgeRelay
Security

Read your activity. Write only to the channels you choose.

ForgeRelay sits between systems you already trust, so the smaller its access the better. This page describes how it is designed, and is explicit about what has not been independently assessed.

ForgeRelay makes no claim of SOC 2, ISO 27001 or GDPR certification, and has not published an audit or penetration test. Items not yet implemented are labelled planned .

Principles

Four rules the product is built around.

  • Verify every inbound webhook signature before the payload is parsed
  • Request least-privilege permissions, and read-only wherever a write is not required
  • Encrypt tokens and secrets at rest, and never render them back into the interface
  • Record every delivery so a failure can be inspected and replayed rather than guessed at

Data flow

From provider webhook to chat delivery.

Nothing is relayed before verification, and nothing is relayed that a route policy did not select.

  1. 01

    Provider webhook

    GitHub sends an HMAC-signed body; GitLab sends a per-connection project-hook token.

  2. 02

    Verification

    GitHub verifies the raw body before parsing. GitLab reads only enough to find the connection, then verifies its token before persistence.

  3. 03

    Queue

    Accepted events are queued so a slow destination never drops one.

  4. 04

    Route policy

    Conditions and event selection decide whether it relays.

  5. 05

    Chat delivery

    The message posts, and the delivery is recorded.

Permissions

Exactly what each connection asks for.

Write access exists only on the chat side, and only to post the messages you routed. Forge permissions stay read-only.

GitHub app

  • Pull requests: read read Read title, author, reviewers, state and labels
  • Checks: read read Subscribe to check_run and check_suite so Live CI cards list each job, failure, duration and recovery
  • Actions: read read Subscribe to workflow_run so PR and Live CI cards refresh when a GitHub Actions workflow finishes (per-job detail still comes from check_run)
  • Contents: read read Subscribe to Push events and resolve compare or commit links for digests — not to browse or mirror the repo
  • Metadata: read read Resolve repository names for route pickers
  • Members: read read Suggest identity mappings for reviewers
  • Webhook: Check suite / Check run read Receive per-job CI updates for Live CI cards and failure/recovery pings
  • Webhook: Workflow run read Refresh CI status when an Actions workflow completes, even before every check_run has landed
  • Webhook: Push read Receive push payloads; ignored unless a Commits route matches

GitLab OAuth and project hooks

  • read_api read Read merge requests, approvals and pipeline metadata
  • read_repository read Resolve branch names, commit SHAs and support commit digests
  • Webhook: merge request events read Receive lifecycle changes
  • Webhook: pipeline events read Relay pipeline failure, recovery and suite-level snapshots for Live CI
  • Webhook: job events read Receive each Job Hook (build) so Live CI cards keep every parallel job — pipeline snapshots alone are not enough
  • Webhook: push events read Receive push hooks; digests only when a Commits route matches

Slack app

  • chat:write write Post the request message and thread updates
  • channels:read read List channels in the destination picker
  • users:read read Suggest identity mappings
  • chat:write.customize write Send as ForgeRelay with a consistent app identity
  • users:read.email read Match a verified forge email to a Slack user

Discord bot

  • Send Messages write Post the request message
  • Create Public Threads write Open one thread per request
  • Send Messages in Threads write Post later lifecycle updates
  • Read Message History read Attach updates to the correct thread

Push webhooks may arrive whenever the App is subscribed; ForgeRelay ignores them unless a Commits route matches. Existing installs may need to re-accept the GitHub App after Contents: read, Actions: read, or the Push / Workflow run subscriptions are added. GitLab project hooks always include pipeline and job events so Live CI can track parallel jobs.

Subprocessors

Services that may process customer data for ForgeRelay.

A provider is used only when its corresponding feature is configured. Customer-directed integrations such as GitHub, GitLab, Slack and Discord process data under their own terms.

  • Production infrastructure provider

    For all hosted workspaces

    Purpose

    Application, database, cache, queue, and encrypted storage hosting

    Data involved

    Account, workspace, encrypted connection credential, webhook, and delivery data

  • OpenPanel

    When analytics is enabled

    Purpose

    Product analytics and service-usage measurement

    Data involved

    Account and profile identifiers, page views, and product interaction events

  • Stripe

    When paid billing is used

    Purpose

    Subscription checkout, billing management, and payment status

    Data involved

    Billing contact, customer, and subscription identifiers; ForgeRelay does not store full card details

  • Resend

    When email notifications are sent

    Purpose

    Transactional email delivery

    Data involved

    Recipient email addresses and email content (invitations, authentication, and account notifications)

ForgeRelay reviews providers before enabling them and limits access to the data needed for the stated purpose. This list will be updated before a new subprocessor begins processing customer data, and material changes will be communicated where appropriate. Coolify is self-hosted deployment software and does not receive customer data from ForgeRelay.

Boundaries

What ForgeRelay does not need.

If a permission is not required to route an event or post a message, it is not requested.

  • No write access to code, branches, pull requests, merge requests or pipelines
  • No clone of your repositories, and no stored source tree
  • Commit metadata from push webhooks (message, author, SHA, optional path lists) is read only to relay digests you configured
  • No ability to approve, merge or close a request on your behalf
  • No reading of unrelated chat conversations or direct messages
  • No access to channels that no route names as a destination

Encryption and retention

What is stored, and for how long.

  • Connection credentials Encrypted at rest, including per-connection webhook secrets; never displayed after creation
  • Event payloads Retained with allowlisted headers for replay; signatures, tokens, cookies and authorisation headers are not stored
  • Delivery history window Free: 30 days. Team: owners and admins choose 30, 60, or 90 days
  • Identity mappings Stored as forge account to chat user pairs until removed or the workspace is deleted
  • Transport HTTPS is required by production readiness for inbound and outbound traffic

Deletion and replay

Disconnect, delete, or replay a failed delivery.

Removing a connection removes its stored token and stops its webhooks. Deleting a workspace removes its routes, mappings and delivery history.

delivery failed evt_8791 · rt_02 · #eng-reviews

A rejected delivery keeps its payload and error. Once the destination is healthy the same event can be replayed from the log, so a channel outage does not silently lose review activity.

See delivery history in the control panel

Reporting

Telling us about a vulnerability.

Use the platform-wide ForgeRelay address for responsible vulnerability reports.

Security contact
hello@forgerelay.dev
Incident updates
Status page — planned
Disclosure policy
Coordinated disclosure — planned

Least access, clearly explained.

Connect a forge and a channel, and see exactly what each connection can do.

Start free See integrations