Skip to main content
Manifests let you define Mixpeek resources in YAML files and apply them in a single operation. This enables version-controlled, reproducible infrastructure across environments.

Quick Start

# mixpeek.yaml
version: "1.0"
metadata:
  name: "video-search-env"

namespaces:
  - name: video_search
    feature_extractors:
      - name: multimodal_extractor
        version: v1

buckets:
  - name: raw_videos
    namespace: video_search
    schema:
      properties:
        video: { type: video }

collections:
  - name: video_index
    namespace: video_search
curl -X POST https://api.mixpeek.com/v1/manifest/apply \
  -H "Authorization: Bearer $API_KEY" \
  -F "[email protected]"

Core Operations

OperationDescription
ApplyCreate all resources defined in the manifest
ValidateCheck syntax, schema, and references without changes
ExportGenerate a manifest from existing resources
DiffCompare manifest against current state

Resource Types

Manifests support these resource types, applied in dependency order:
  1. Namespaces - Isolation boundaries with feature extractors
  2. Buckets - Object storage with schemas
  3. Collections - Document stores with indexing
  4. Taxonomies - Classification hierarchies
  5. Clusters - Grouping configurations
  6. Retrievers - Search pipelines

Secret References

Use ${{ secrets.NAME }} to reference organization secrets:
buckets:
  - name: external_data
    namespace: my_namespace
    sync:
      connection_id: ${{ secrets.S3_CONNECTION_ID }}
Secrets must exist before applying. Use the validate endpoint to check for missing secrets.

Dependency Resolution

Resources are created in topological order. The manifest engine:
  • Resolves cross-resource references automatically
  • Detects circular dependencies
  • Rolls back all changes if any creation fails

Workflows

Environment Replication

# Export from production
curl https://api.mixpeek.com/v1/manifest/export \
  -H "Authorization: Bearer $PROD_KEY" \
  -o prod-manifest.yaml

# Apply to staging
curl -X POST https://api.mixpeek.com/v1/manifest/apply \
  -H "Authorization: Bearer $STAGING_KEY" \
  -F "[email protected]"

Pre-deployment Validation

# Validate without applying
curl -X POST https://api.mixpeek.com/v1/manifest/validate \
  -H "Authorization: Bearer $API_KEY" \
  -F "[email protected]"

# Check what would change
curl -X POST https://api.mixpeek.com/v1/manifest/diff \
  -H "Authorization: Bearer $API_KEY" \
  -F "[email protected]"

CI/CD Integration

# GitHub Actions example
- name: Deploy Mixpeek Resources
  run: |
    curl -X POST https://api.mixpeek.com/v1/manifest/apply \
      -H "Authorization: Bearer ${{ secrets.MIXPEEK_API_KEY }}" \
      -F "[email protected]"

References