Overview

What a source integration is

A source integration is a one-to-one binding between a Git provider account and a single MCP server. The credential you connect — OAuth or Personal Access Token — is scoped to that server. Repository files flow into the same content table that hand-typed records and direct file uploads land in, so once they are imported the MCP server treats them like any other content row.

Three providers at a glance

Provider	Connection methods	Token shape
GitHub	OAuth or classic Personal Access Token	Single opaque string
Bitbucket	OAuth consumer or App Password	username:app_password (PAT) or single OAuth token
GitLab	OAuth application or Personal Access Token (gitlab.com only)	glpat- prefix routes PATs differently from OAuth bearers

The pipeline

Every provider, every connection method, follows the same four stages:

authentication  ->  repository picker  ->  file list  ->  content import

Authentication validates the token against the provider's "current user" endpoint before any database row is written. The repository picker lists what the credential can see. The file list traverses the selected branch (with optional path filter). The import materialises each text blob as a content row on the MCP server.

Two connection paths

Each provider supports a "Connect with {Provider}" OAuth button and a Personal Access Token paste field. The choice is operational, not technical:

• OAuth — best for human operators connecting their own account. The provider handles the token lifecycle, including revocation.
• Personal Access Token / App Password — best for service accounts, environments where OAuth is not configured, or long-lived integrations on Bitbucket and GitLab where OAuth tokens currently expire after two hours.

What gets imported

• Text files in the selected branch (and optional path filter) become content rows. Slug and human-readable name are derived deterministically from the file path.
• Directory structure is preserved as part of the slug, so docs/guides/intro.md becomes the slug docs-guides-intro-md.
• Imported files are stored in the same contents table as typed and uploaded entries — no separate "imported content" entity exists.

What is not imported

• Issues, pull requests, CI configuration, and other repository metadata. Vectoralix only reads source files.
• Binary blobs (detected by a null-byte sniff on the first 8 KB) and files larger than 10 MB.
• Submodules and Git LFS pointer entries.
• Write access of any kind. The pipeline is strictly read-only — Vectoralix never pushes a commit or opens a pull request.

Where integrations live in the UI

Source integrations have two entry points that share the same form and table. Both render the same fields, the same provider buttons, and the same access-token field:

• A top-level "Sources" resource under the MCP navigation group.
• A "Sources" tab on the MCP server edit page, scoped to that server's integrations.

Validation at connection time

Tokens are validated before the integration row is persisted. The backend calls the provider's "current user" endpoint with the credential you supplied; on rejection — bad token, wrong scopes, network failure — you see a field-level form error rather than a stack trace, and nothing is written to the database.

Security posture

• Tokens are encrypted at rest using your application key.
• They are scrubbed from logs, exception traces, debug dumps, and serialised payloads.
• They never appear in API responses or Filament table columns.
• On the edit form, the access-token field is blank by default — leaving it blank preserves the stored value, typing a new value rotates it.

Where to go next

I want to…	Go to
connect a GitHub repository	GitHub
connect a Bitbucket Cloud repository	Bitbucket
connect a gitlab.com repository	GitLab
understand re-imports, refresh, and what stale content means	Sync & Updates