GitLab quickstart

Sebastion AI supports GitLab SaaS with a self-serve connect flow.

If you are on GitHub, use the standard quickstart. If your team runs on GitLab, follow the flow below.

Before you start

You need:

1. A Foundation Machines workspace (the workspace that will be billed).
2. A GitLab project path, like group/project or group/subgroup/project.
3. A GitLab token with api scope from a user who can manage project hooks.

Step 1, Create a GitLab token

1. In GitLab, open User Settings → Access tokens.
2. Create a token with at least the api scope.
3. Copy the token once and store it safely (GitLab will not show it again).

You can use a project access token if your org prefers project-scoped credentials, but it still needs permissions that allow webhook setup and MR access.

Your token is stored encrypted at rest (AES-GCM) by the Sebastion review service so it can fetch your merge-request diffs and post review comments on your behalf. It is never persisted by the Foundation Machines web app. If you rotate or revoke the token in GitLab, re-run the connect flow to register the new one.

Step 2, Connect from Foundation Machines

1. Open app.foundationmachines.ai/connect/gitlab.
2. Select the workspace that should be billed.
3. Enter your GitLab project path.
4. Paste your GitLab token.
5. Click Connect GitLab project.

On success, Foundation Machines confirms the linkage and configures the GitLab webhook for that project.

Step 3, Verify webhook + linkage

In GitLab, open Project Settings → Webhooks and confirm the Sebastion webhook is present.

In Foundation Machines, open the billing workspace and confirm this is the workspace you want usage attributed to.

Step 4, Run your first MR test

1. Create a branch and push a small change.
2. Open a merge request in the connected project.
3. Wait for Sebastion to post:
   • inline findings/notes on the MR, and
   • a review status/check signal.
4. Confirm usage appears in the selected workspace billing surface.

If those three signals appear (webhook active, MR review output, billing usage), your integration is working end-to-end.

What works in v1

GitLab support today covers merge-request security reviews:

• Triggers on MR open / update / reopen (Draft/WIP MRs and bot authors are skipped).
• Posts inline discussions on changed lines, plus a summary note on the MR.
• Sets a commit status (sebastion/review) — failed when there are blocking findings, otherwise success.

Making reviews block a merge

The commit status is advisory by default. To make a failing Sebastion review actually prevent merging, configure a required check in GitLab:

• Add an approval rule for the project, or
• Mark the sebastion/review commit status as required to merge (Project Settings → Merge requests / Merge checks).

Without that, the status is informational and merges are still allowed.

Not yet in v1

These are on the roadmap and not active for GitLab yet: @sebastion chat replies on MR comments, pipeline-aware gating, repository walkthroughs, pre-merge checks, SARIF upload, automated fixes, and self-managed GitLab.

Billing behavior (GitHub + GitLab)

There is no separate GitLab SKU. Billing is workspace-based across hosts:

• Pro is a single-developer subscription for private-repo use in that workspace.
• Team is pay-as-you-go credits with unlimited users and repos.
• Spend cap and auto-recharge are shared at workspace level.

See billing and credits for full plan details.

Troubleshooting

• GitLab project lookup failed (400/404): check project path and token scope.
• Failed to configure GitLab webhook: token lacks permissions to manage hooks.
• Failed to link billing tenant: verify you selected a workspace you own/manage.