BYOC (Bring Your Own Cloud)

BYOC deployments allow you to run Slim.io’s scanning engine inside your own cloud infrastructure. Data never leaves your VPC — only scan metadata and findings are communicated back to the Slim.io control plane.

Why BYOC

BYOC addresses requirements that the SaaS model cannot satisfy:

• Data residency — Regulated industries that prohibit data transfer outside the organization’s boundary
• Network restrictions — Environments where storage buckets are not accessible from the public internet
• Compliance mandates — Frameworks that require all data processing to occur within the organization’s infrastructure
• Latency optimization — Scanning large volumes of data co-located with the compute reduces transfer time

Architecture

Customer VPC                          Slim.io Control Plane
┌─────────────────────┐              ┌──────────────────────┐
│  Storage Buckets    │              │  Coordinator API     │
│       ↓             │              │       ↓              │
│  Scanner Workers    │  ──────→     │  Findings Database   │
│  (containers)       │  metadata    │       ↓              │
│       ↓             │  only        │  Dashboard / API     │
│  Local Findings DB  │              │                      │
│  (optional)         │              │                      │
└─────────────────────┘              └──────────────────────┘

What Stays in Your VPC

• All file content — files are read and processed locally
• Scanning containers — workers run on your compute
• LLM inference (if client-hosted LLM Assist is enabled)
• Optionally, a local findings database for air-gapped deployments

What Leaves Your VPC

• Scan metadata — File paths, finding categories, confidence scores, risk scores
• Worker heartbeats — Progress reports from workers to the coordinator
• No file content — Original data values are never transmitted unless tokenization is configured to store tokens in Slim.io

Deployment Options

Docker Compose

For development and small-scale deployments. Choose the scanner profile that matches your data sources:

services:
  slim-scanner:
    image: slimio/scanner:1.0.0-full  # or 1.0.0-cloud-storage, 1.0.0-database, 1.0.0-saas
    env_file: .env
    volumes:
      - scanner-wal:/var/lib/slim-wal
    deploy:
      resources:
        limits:
          memory: 4G
          cpus: '2'
    restart: unless-stopped
    healthcheck:
      test: ["CMD", "python", "-c", "import scanner.config; print('ok')"]
      interval: 30s
      timeout: 5s
      retries: 3
volumes:
  scanner-wal:

Create a .env file alongside the compose file (add to .gitignore):

SLIM_REGISTRATION_TOKEN=slim_reg_xxxxxxxxxxxx
SLIM_CONTROL_PLANE_URL=https://api.slim.io
SLIM_SCANNER_GROUPS=default
SLIM_SCANNER_NAME=my-scanner
SLIM_MAX_CONCURRENT_JOBS=4

Kubernetes

For production deployments on EKS, GKE, or AKS. Apply this single manifest:

apiVersion: v1
kind: Secret
metadata:
  name: slim-scanner-auth
type: Opaque
stringData:
  SLIM_REGISTRATION_TOKEN: "slim_reg_xxxxxxxxxxxx"
  SLIM_CONTROL_PLANE_URL: "https://api.slim.io"
---
apiVersion: v1
kind: PersistentVolumeClaim
metadata:
  name: slim-scanner-wal
spec:
  accessModes: ["ReadWriteOnce"]
  resources:
    requests:
      storage: 1Gi
---
apiVersion: apps/v1
kind: Deployment
metadata:
  name: slim-scanner
spec:
  replicas: 1
  selector:
    matchLabels:
      app: slim-scanner
  template:
    metadata:
      labels:
        app: slim-scanner
    spec:
      containers:
      - name: scanner
        image: slimio/scanner:1.0.0-full
        envFrom:
        - secretRef:
            name: slim-scanner-auth
        env:
        - name: SLIM_SCANNER_GROUPS
          value: "default"
        - name: SLIM_MAX_CONCURRENT_JOBS
          value: "4"
        resources:
          limits:
            memory: "4Gi"
            cpu: "2"
        volumeMounts:
        - name: wal
          mountPath: /var/lib/slim-wal
      volumes:
      - name: wal
        persistentVolumeClaim:
          claimName: slim-scanner-wal

kubectl apply -f scanner.yaml

AWS Lambda

For serverless scanning in AWS environments:

1. Deploy the Slim.io scanner Lambda function from the provided SAM template.
2. Configure the function with your connector credentials and Slim.io API key.
3. Set up S3 event notifications to trigger the Lambda on file uploads.
4. The Lambda processes each file and reports findings to the Slim.io control plane.

Google Cloud Run

For serverless scanning in GCP environments:

gcloud run deploy slim-scanner \
  --image slimio/scanner:1.0.0-full \
  --set-env-vars SLIM_REGISTRATION_TOKEN=slim_reg_xxxx,SLIM_CONTROL_PLANE_URL=https://api.slim.io \
  --memory 4Gi \
  --cpu 2 \
  --region us-central1 \
  --min-instances 1

Azure Container Apps

For serverless scanning in Azure environments:

az containerapp create \
  --name slim-scanner \
  --resource-group slim-io-rg \
  --image slimio/scanner:1.0.0-full \
  --env-vars SLIM_REGISTRATION_TOKEN=slim_reg_xxxx SLIM_CONTROL_PLANE_URL=https://api.slim.io \
  --cpu 2 --memory 4Gi

Agent Configuration

The BYOC scanner agent supports the following environment variables:

Verifying the Agent

After deployment, verify the agent is communicating with the control plane:

1. Navigate to the connector in the Customer Dashboard.
2. Check for a Heartbeat indicator showing the agent’s last check-in time.
3. Trigger a test scan and verify findings appear in the Data Catalog.

Local-Only Mode

For fully air-gapped deployments where no data can leave the customer’s network:

1. Deploy the scanner agent with SLIM_MODE=local.
2. Findings are written to a local PostgreSQL or SQLite database.
3. Dashboards and APIs are not available (no control plane connection).
4. Export findings as JSON or CSV for offline analysis.

Updating the Scanner

Scanner images are published to Docker Hub at slimio/scanner. To update:

1. Check the Scanner Fleet page for an Update Available badge showing the new version.
2. Pull the new image: docker pull slimio/scanner:1.1.0-full (replace with your profile and the target version).
3. Update your docker-compose.yml or Kubernetes manifest with the new image tag.
4. Restart — the scanner finishes any active jobs before shutting down, then starts the new version.
5. The scanner re-registers with the control plane automatically using its existing identity.