Scandrix

Self-hosted / Deployment guide

Run code review inside your boundary.

ScanDrix deploys as a set of services you operate: in a private VPC, on-prem, or in a network you have prepared without an internet path. The product surface is the same you use on our hosted plan — dashboard, Kody rules, Dry Runs, CLI, and Cockpit metrics.

A private deployment means the services run inside your network while a small set of egress paths — your Git provider, and either an internal model endpoint or an allow-listed provider — remain permitted. An air-gapped deployment removes that last dependency: no request in the review path needs to leave the network, which also means the Git host, the inference endpoint, and the release artifacts all have to exist inside it.

  • Docker Compose or Helm
  • Linux runtime
  • Source content not persisted
Deployment boundaryReview request path, end to end
  1. Git provider

    Edge of your boundary

    Your existing host delivers a signed webhook. ScanDrix reaches it outbound to fetch diffs and post results.

    • POST /api/webhooks/<provider>
    • Outbound API calls to the provider
  2. webhooksigned, fire-and-forget
    Then webhook — signed, fire-and-forget.
  3. ScanDrix review services

    Inside your boundary

    Ingest validates the signature and writes an outbox record, the relay publishes to RabbitMQ, and workers run the review and post it back.

    • api · relay · worker · web
    • PostgreSQL · MongoDB · object storage
  4. promptcontext pack, not a repo dump
    Then prompt — context pack, not a repo dump.
  5. Model endpoint

    You choose the endpoint

    An internal vLLM or Ollama server keeps inference in the same network. An approved external provider works too, if your egress policy allows it.

    • LLM_BASE_URL → internal inference
    • Or BYOK against a contracted provider

Marked stage runs where you control the host

Egress exists only where you configure it

01Choose your boundary

Three ways to draw the line.

The mode changes what you operate, not what the product does. Each one assumes the same six services and the same prerequisites below.

Private VPC

AWS, GCP, or Azure

Services run in your cloud network next to the databases, queues, and storage you already operate.

ScanDrix provides

  • Versioned container images for the API, relay, worker, and web services, plus a Helm chart.
  • Sizing, networking, and upgrade-sequencing guidance for a first production install.

You provide

  • A Kubernetes cluster or Docker host, with PostgreSQL 15+, MongoDB 6+, RabbitMQ 3.12+ (delayed-message exchange), and S3-compatible storage.
  • Network rules permitting your Git provider and a model endpoint — internal, or an external provider you have allow-listed.
On-prem

Your data centre or host environment

Services run on hardware and a network you control, with no dependency on our infrastructure.

ScanDrix provides

  • The same images and chart, delivered as a release bundle you can install without a public registry.
  • Offline license validation, so activation does not require a call home.

You provide

  • Container-capable Linux hosts able to carry the documented baseline of 4 vCPU and 8 GB RAM across API, worker, and web.
  • An internal Git host, since the review path needs to reach a provider you operate.
Air-gapped

A prepared network with no internet path

Nothing in the review path needs internet reachability — which moves most of the integration work onto your team.

ScanDrix provides

  • Release artifacts, container images, and a CLI binary that can be mirrored into your internal registry.
  • Offline license validation, and telemetry that can be switched off entirely.

You provide

  • Internal Git, an internal inference endpoint (vLLM or Ollama), and a mirror for every image and binary the stack pulls.
  • A license file, plus a release and upgrade process that works without outbound access.

No mode removes configuration work. The difference is who performs it and how much of it sits inside your own change-control process.

02What runs where

Three hops, one of them yours.

Every review starts at a Git provider, runs through your deployment, and reaches a model endpoint you chose. Understanding those three positions is enough to reason about the data path.

The request path

  1. 01Git provider

    Edge of your boundary

    Your existing host delivers a signed webhook. ScanDrix reaches it outbound to fetch diffs and post results.

    • POST /api/webhooks/<provider>
    • Outbound API calls to the provider
  2. 02ScanDrix review services

    Inside your boundary

    Ingest validates the signature and writes an outbox record, the relay publishes to RabbitMQ, and workers run the review and post it back.

    • api · relay · worker · web
    • PostgreSQL · MongoDB · object storage
  3. 03Model endpoint

    You choose the endpoint

    An internal vLLM or Ollama server keeps inference in the same network. An approved external provider works too, if your egress policy allows it.

    • LLM_BASE_URL → internal inference
    • Or BYOK against a contracted provider

What is handled, and what is stored

Source content
Diffs are processed in ephemeral analysis environments that are destroyed when the review finishes. The review flow does not persist source-code content, and code is never used to train a model.
Finding metadata
Rule identifiers, file paths, and severities are retained so the dashboard can show history and so audit logs are meaningful. That metadata lives in your MongoDB, under your retention policy.
Prompts
Before anything reaches a model, entropy scanning and token-pattern detection replace suspected credentials with stable placeholders — so a finding about a leaked secret can be reported without the literal value leaving the process.
Model endpoint
Pointing LLM_BASE_URL at an internal vLLM or Ollama server keeps inference inside your network, which avoids adding an external model provider as a subprocessor for that traffic. It is not a statement that the environment has no subprocessors at all.

03Deployment paths

Two supported starting points.

Both paths run the same six services: api, worker, relay, web, and the PostgreSQL, MongoDB, and RabbitMQ instances they need. Choose the one that matches the environment you already operate.

Commands below are an illustrative starting point, not a substitute for the guide — version tags, hostnames, and secrets are yours to set.

Read the full deployment guide

Illustrative starting point

Docker Compose

Unpack the release bundle, set the environment file, and bring the stack up on one Linux host.

Terminal

release-bundle

# 1. Unpack the release bundle
tar -xzf scandrix-selfhosted-<version>.tar.gz && cd scandrix

# 2. Configure
cp .env.example .env
$EDITOR .env   # set SCANDRIX_SECRET, DATABASE_URL, LLM_BASE_URL...

# 3. Start the stack
docker compose up -d

# 4. Create the first admin
docker compose exec api scandrix bootstrap-admin --email admin@example.com
Dashboard
The dashboard is served on port 8080. Terminate TLS in front of it rather than exposing that port directly.
Secrets
The .env file holds real credentials. Keep it out of version control and load it from your platform's secret manager in production.
Upgrades
docker compose pull && docker compose up -d — schema migrations run at startup, one minor version at a time.

Showing the Docker Compose path.

Reverse proxy & TLS

04Operational requirements

Who owns what, line by line.

A self-hosted install is a long-lived service with a real runbook. This is the split we are asking you to accept before anything is installed.

Linux runtime
Customer environment
Container-capable Linux hosts or a cluster for the API, relay, worker, and web services. The documented starting point is 4 vCPU and 8 GB RAM.
Container images
Customer environment
Images must be reachable by the runtime. In restricted networks, mirror the service images and the CLI binary into an internal registry first.
Internal model endpoint
ScanDrix + customer
We ship the provider adapters. You supply a reachable endpoint: an internal vLLM or Ollama server via LLM_BASE_URL, or an external provider you have already contracted.
Git connectivity
Customer environment
Inbound delivery to the webhook ingress path and outbound API access to the provider both have to be permitted, including any proxy in the path.
Release mirroring & upgrades
ScanDrix + customer
Releases are versioned and schema migrations are backward-compatible for one minor version. You mirror the artifacts and upgrade one minor at a time, with a database backup beforehand.
Health checks
ScanDrix provides
GET /healthz for liveness, GET /readyz for readiness across database and queue, and /metrics for Prometheus scraping. Wiring them into your monitoring is your side of the boundary.
Backups & retention
Customer environment
PostgreSQL holds configuration and state, MongoDB holds review artifact metadata. Backup schedule, retention window, and restore testing sit with your platform team.

05Security & compliance boundary

Deployment supports your controls. It does not replace them.

Running ScanDrix inside your environment lets your existing identity, network, logging, and retention controls apply to it directly. That is useful for regulated environments — but it is an enabler, not an attestation.

What the boundary gives you

  • Your own identity provider and secret management, rather than credentials held on our side.
  • Logs, findings, and review metadata that stay in systems your own platform team already monitors and backs up.
  • A network path you can restrict, inspect, and evidence with your existing controls.

What we do not claim

  • A deployment location is one input to a compliance programme, not a certification. Whether an environment satisfies a given framework depends on the whole system, the process around it, your contracts, and the scope of any assessment.
  • An internal model endpoint removes an external model provider from the inference path. It does not remove your Git provider, your own infrastructure, or any service you have separately contracted.
  • Egress is defined by your firewall and allow-list. Where you leave a path open, a request can use it.

SOC 2 alignment documentation, the current subprocessor list, and a DPA are available under NDA. Security questions and vulnerability reports go to security@scandrix.dev.

06Next step

Bring us your constraints and we will size it with you.

A deployment review covers your network, the inference endpoint you intend to use, and the requirements your own auditors will ask about.