Skip to main content
Running Cynative against a locally hosted model means your prompts, tool outputs, and security findings never leave your environment. No data is sent to an external API, no third-party retention policies apply, and your cloud-credential context stays entirely within your control.
Running Cynative on an instance in the same cloud it audits, pointed at cloud-managed inference (e.g. a vLLM deployment on the same VPC), means nothing leaves your environment — not the infrastructure data Cynative reads, and not the model calls it makes.
Cynative supports three local/self-hosted providers through the Bifrost SDK: Ollama (the simplest path for local laptops and dev machines), vLLM (high-throughput GPU inference), and SGLang (SGLang server). All three require no API key by default.

Ollama

Ollama is the easiest way to run open-weight models locally. It manages model downloads, quantization, and the inference server in a single binary.

Prerequisites

  1. Install Ollama: follow the instructions at ollama.ai.
  2. Pull a model: ollama pull llama3.3 (or any model from the Ollama library).
  3. Ensure the Ollama server is running: ollama serve (it starts automatically on most installs).

Quick start

No ~/.cynative/config.yaml file is required.
Ollama takes its endpoint from CYNATIVE_LLM_OLLAMA_URL (which maps to ollama_key_config.url), not from the generic CYNATIVE_LLM_NETWORK_CONFIG_BASE_URL. Setting CYNATIVE_LLM_NETWORK_CONFIG_BASE_URL for the Ollama provider fails at startup with “provider has no keys configured: ollama”.

YAML configuration

Environment variable reference


vLLM

vLLM is a high-throughput LLM inference server designed for GPU-accelerated deployments. It exposes an OpenAI-compatible API. Use it when you need to serve larger models, handle multiple concurrent requests, or run inference on a dedicated GPU host.

Quick start

No ~/.cynative/config.yaml file is required. CYNATIVE_LLM_VLLM_URL maps directly to vllm_key_config.url. CYNATIVE_LLM_VLLM_MODEL_NAME is also accepted for per-key model routing.

YAML configuration

Authentication

vLLM runs unauthenticated by default. If you launched it with --api-key <token>, supply the token in one of two ways:
  • YAML path (keys[]): Put the token in the key’s value: field as shown above.
  • Env-only path (no YAML): Set CYNATIVE_LLM_API_KEY alongside CYNATIVE_LLM_VLLM_URL. This path uses no keys[], so there is no conflict.
Do not combine a top-level api_key / CYNATIVE_LLM_API_KEY with a keys[] block — Cynative rejects that combination at startup.

Environment variable reference


SGLang

SGLang is a fast LLM inference and serving framework. Its Cynative provider id is sgl.

Quick start

No ~/.cynative/config.yaml file is required. CYNATIVE_LLM_SGL_URL maps directly to sgl_key_config.url.

YAML configuration

Authentication

SGLang servers are typically unauthenticated. If you’ve put SGLang behind an auth proxy, supply the proxy token in one of two ways:
  • YAML path (keys[]): Put the token in the key’s value: field as shown above.
  • Env-only path: Set CYNATIVE_LLM_API_KEY alongside CYNATIVE_LLM_SGL_URL, with no keys[] block.

Environment variable reference


Other self-hosted and OpenAI-compatible endpoints

Any inference server that speaks the OpenAI Chat Completions API can be used with the openai provider and a custom base_url. This covers LiteLLM proxies, custom gateways, and most other OpenAI-compatible servers that don’t have a dedicated Bifrost provider:
Or via environment variables:
See the OpenAI provider guide for the base URL caveat (don’t include a trailing /v1).