Documentation

1. Open the app and Sign in with GitHub using OAuth.
2. On the GitHub authorization screen, authorize the Sift application so we can associate your account and show your profile and settings.

From your profile, use Configurenext to Installation ID (or your onboarding flow) to open GitHub's App installation UI.

• Choose All repositories or only Selected repositories / org-wide access, depending on where you want Sift to run.
• Required GitHub App permissions typically include: Contents (read) for code and diffs, Pull requests (read/write as needed for review comments), and Metadata (read). Approve the permission screen GitHub shows for your installation.

If you manage the GitHub OAuth App for your own deployment, register these details in your OAuth App settings on GitHub:

• OAuth scopes — Grant the scopes requested by the Sift app so it can verify identity and complete installation flows (exact scopes are shown during authorization).
• Authorization callback URL— Set to your deployment's callback route (for example https://<your-app>/api/auth/github/callback). This must match the URL configured in your environment.

Open Profileafter signing in. The page is organized into the same areas you'll use in production:

• Authentication — Copy your API key for programmatic access; keep it secret.
• LLM configuration — Choose an LLM model and enter your LLM API key. Keys are not stored on our servers, they are pushed to repository secrets when you save.
• Installation — Confirm your Installation ID after installing the GitHub App. Download the sample workflows from GitHub Actions workflow and add them under .github/workflows/. Set Database URL (PostgreSQL) if required. Pick a Docker image variant (Slim vs Full) for the runner image size/feature set.
• Target repositories — Choose which repositories under your installation should receive Sift configuration (including secret injection when you save). If you leave none selected, configuration applies to all repositories in the installation by default.
• Feature flags — Toggle Smart routing, Vector DB (with embedding model, API base, and dimension when enabled).
• Tools — Enable Semgrep and/or CodeQL when you want those analyses in the pipeline.

Click Save Configuration on your profile. The backend updates your settings and, for each repository covered by your GitHub App installation, injects or updates GitHub Actions secrets (such as API keys, model name, database URL, installation ID, and related values) via the GitHub API so workflows can read them without you pasting secrets into each repo by hand.

Verify — Commit the workflow files to your default or configured branch, then open a pull request (or push updates) on that branch. In the Actions tab you should see the Sift workflow runs and on the PR you should see review output from Sift.

Pull the Sift image from GitHub Container Registry:

docker pull ghcr.io/sahilsaleem2907/sift:slim 
docker pull ghcr.io/sahilsaleem2907/sift:full

The slim tag pulls a lightweight version of the Sift service, including just the core service features and basic linters suited for faster startup and lower resource usage. This is ideal for most users who want efficient automated reviews without extra analysis overhead.

If your team needs advanced security analysis or all supported linters, use the full tag. This image comes with CodeQL and Sift’s full suite of recommended linter scripts preinstalled, providing deep code analysis in addition to the standard checks. Choose full if you require comprehensive code scanning or must satisfy strict policy requirements.

Self-hosted runs need the same logical configuration as the managed UI, supplied by you. Typical variables include:

• SIFT_API_KEY — Your Sift application API key
• SIFT_LLM_MODEL, SIFT_LLM_API_KEY
• SIFT_DATABASE_URL — PostgreSQL connection string
• SIFT_INSTALLATION_ID — GitHub App installation ID
• Optional: SIFT_EMBEDDING_*, feature flags, backend base URL, etc., matching your workflow

Example .env (adjust names to match your deployment):

SIFT_API_KEY=sk-...
SIFT_LLM_MODEL=gpt-4o
SIFT_LLM_API_KEY=sk-...
SIFT_DATABASE_URL=postgresql://user:pass@host:5432/db
SIFT_INSTALLATION_ID=12345678
# Optional
# SIFT_EMBEDDING_MODEL=text-embedding-3-small
# SIFT_EMBEDDING_API_BASE=https://api.openai.com/v1
# SIFT_EMBEDDING_DIMENSION=1536
# SWIFT_API_BACKEND_BASE_URL=https://api.example.com

Run the container with env vars from a file or your shell:

docker run --rm -it \
  --env-file .env \
  -p 8080:8080 \
  ghcr.io/sahilsaleem2907/sift:slim

Docker Compose example:

services:
  sift:
    image: ghcr.io/sahilsaleem2907/sift:slim
    env_file: .env
    ports:
      - "8080:8080"
    restart: unless-stopped

Add sift-review-workflow.yml (or sift-feedback-workflow.yml) under .github/workflows/ in each repository. Base it on the downloaded workflows.

Point the workflow at your self-hosted image or API: set the image reference, secrets, and any SWIFT_API_BACKEND_BASE_URL(or equivalent) to your infrastructure. Add the same secret names in each repo's GitHub Settings → Secrets and variables → Actions manually, since automatic injection is tied to the managed app flow.

Add sift-feedback-workflow.yml under .github/workflows/ when you want Sift to ingest signals after a pull request finishes. It complements the review workflow when the PR closes (merged or not), so reactions, slash commands, and outcome line up with the end of the thread.

Sift can record several kinds of feedback tied to a review:

• PR lifecycle — whether the pull request was closed and whether it was merged.
• Reactions — emoji reactions on Sift's summary comment and on inline review comments (see Emoji reactions).
• Slash feedback commands — structured /feedback lines in the relevant thread (see Slash commands). Captured alongside reactions.

GitHub lets anyone add emoji reactions to issue and pull-request comments.

The feedback workflow records reactions on both the top-level summary comment (overall review) and each inline comment (file/line findings). Each event keeps which reaction was added or removed, which comment it belongs to, and runs alongside slash commands and PR outcome.

Those signals roll into the same repository-level aggregates and prompt conditioning as other feedback: 👍 reactions nudge “helpful”, 👎 nudge “not helpful”.

Pattern: /feedback, followed by whitespace and then a single verb consisting of word characters and hyphens. Parsing is case-insensitive.

Examples: /feedback helpful, /FEEDBACK not-helpful.

Verbs that map to helpful

• helpful
• good
• yes

Verbs that map to not_helpful

• not-helpful — hyphenated form is normalized to not_helpful
• not_helpful
• bad
• no

Ingested events are stored with deduplication so duplicate deliveries or retried workflow runs do not skew counts. Each signal carries metadata (for example which comment or thread it belongs to) so aggregates stay tied to the right context.

Over time, Sift builds repository-level aggregates from this feedback and derives a simple quality score. Those summaries are fed back into later review prompts and prompt conditioning so new reviews can reflect how prior output landed with your team, without you managing a separate analytics pipeline.