Enterprise AI gateway · Pre-release
Self-hosted enterprise AI gateway for LLMs
Tygress is a self-hosted AI gateway for LLMs, MCP tools and AI agents. Apps keep the OpenAI or Anthropic SDK they already use: point it at the gateway and send the gateway key as x-api-key (in an OpenAI SDK, through default_headers). Chat Completions, Responses and Messages reach nine provider types, natively or bridged, and virtual keys, team budgets, guardrails and agent approvals run on the gateway that authenticates your API traffic.
Join the early-access waitlist
Beta availability and product updates. Tygress is pre-release: the gateway is built but not publicly available yet.
Just your email. No payment required. Unsubscribe anytime. Privacy
One enforcement point
AI governance belongs in the request path
Dashboards report what happened. Tygress decides what is allowed before a request reaches a provider, tool or agent: who can call it, what data may leave, how much it may cost, and whether a human must approve it.
Clients
- ServicesREST, gRPC, WebSocket
- AppsOpenAI & Anthropic SDKs
- AgentsMCP, A2A
- 1IdentityOIDC, JWT, mTLS, LDAP
- 2GuardrailsDLP, prompt guard
- 3LimitsRequests, tokens, USD
- 4RoutingBalancing, failover
Upstreams
Your services
- REST
- gRPC
- WebSocket
LLM providers
- OpenAI
- Anthropic
- Gemini
- Vertex AI
- Azure OpenAI
- Bedrock
- Mistral
- Groq
- OpenAI-compatible
Agents and tools
- MCP servers
- A2A agents
L4 passthrough: TCP, UDP and TLS traffic is forwarded outside the HTTP plugin chain.
Three LLM APIs on nine provider types
Clients call Chat Completions, Responses or Messages on any configured provider: native where the provider offers the API, bridged through chat completions elsewhere.
Keys, teams and budgets
Virtual keys keep provider credentials server-side. Teams share a USD budget alongside each member's own, and limits can key on identity-provider claims.
Guardrails on streamed replies
DLP and the prompt guard inspect prompts and, with reply scanning on, every chunk of a streamed reply. Each attempt is signed after redaction.
Routing and failover
Fallback, round-robin, weighted and semantic strategies, key pools that rest a key on 429, and a 502 that says why each target failed.
Agent actions held at the gateway
MCP tool allowlists, REST and OpenAPI as MCP tools, A2A routing, and human approvals that deny by default after 45 seconds.
GenAI telemetry
OpenTelemetry spans with GenAI conventions, Langfuse export, Prometheus metrics and a usage API for tokens and spend.
LLM API compatibility
Three client APIs on nine provider types
Clients written against OpenAI Chat Completions, OpenAI Responses or Anthropic Messages can reach any provider type Tygress supports. Where the provider offers the API, the request goes through natively. Everywhere else the gateway bridges it through chat completions, and it refuses what a bridge cannot carry instead of dropping it.
| Provider type | Chat Completions/v1/chat/completions | Responses/v1/responses | Messages/v1/messages | Embeddings/v1/embeddings |
|---|---|---|---|---|
| OpenAI | Native | Native | Bridged | Yes |
| Azure OpenAI | Native | Native | Bridged | Yes |
| Anthropic | Pass-throughTo Anthropic's OpenAI-compatible endpoint | Bridged | Native | Not supported |
| Google Gemini | Pass-throughTo Gemini's OpenAI-compatible endpoint | Bridged | Bridged | YesTranslated to Gemini's batch embeddings API |
| Google Vertex AIGemini models | Pass-throughTo Vertex's OpenAI-compatible endpoint | Bridged | Bridged | Not supported |
| AWS Bedrock | TranslatedTo the Converse API, or passed through to Bedrock's OpenAI-compatible endpoint, set per model | Bridged | Bridged | YesTitan and Cohere models |
| Mistral | Native | Bridged | Bridged | Yes |
| Groq | Native | Bridged | Bridged | Not supported |
| OpenAI-compatible endpoint | Native | Bridged | Bridged | Opt-inWith compat_embeddings enabled |
- Native
- The provider serves this API, and Tygress forwards the request in that format.
- Pass-through
- Tygress sends the Chat Completions request to the vendor's own OpenAI-compatible endpoint without translating it to the vendor's native API, so features that endpoint lacks are unavailable. Anthropic documents its compatibility endpoint as not production-ready, which makes /v1/messages the native path for Claude.
- Translated
- Tygress converts Chat Completions to Bedrock's Converse API and back, including tool calls and streaming. Models served on Bedrock's OpenAI-compatible endpoint pass through instead.
- Bridged
- Tygress translates the request down to chat completions and the reply back up, buffered or streaming, with function and tool calling. DLP and the prompt guard run on bridged traffic too.
What the bridges refuse
A bridged request that needs something chat completions cannot express gets a 400 that names the field, rather than an answer that pretends the feature ran. On a route with a selection strategy, the request first moves to a target that can serve it.
- Messages bridge refuses image and document blocks, extended thinking, vendor-executed tools and vendor-side MCP servers, and tool results that are not text.
- Responses bridge refuses stored conversations (previous_response_id, conversation, store: true), background mode, hosted tools such as web search, file search and code interpreter, reasoning items, and image or file input.
Embeddings and other endpoints
- Embeddings are served only where the provider has them: they are never bridged. Gemini embeddings and Cohere embeddings on Bedrock report no token counts, so they are not metered.
- Images, audio, moderations, files and batches reach the OpenAI provider type only, and are not cost-accounted. The OpenAI Realtime API returns 501.
- Any provider type can also sit behind a passthrough route: the client sends the provider's own request format, the gateway forwards it with the operator's provider credentials, and plugins such as DLP still run.
One route serves all three APIs
Providers and their keys live in the gateway’s config. Apps keep the OpenAI or Anthropic SDK they already use, pointed at the gateway and sending the gateway key as x-api-key.
- Anthropic SDK: set the base URL to the gateway and pass the gateway key as the API key; the SDK already sends it as
x-api-key. - OpenAI SDK: set
base_urlto the gateway’s/v1and send the gateway key asx-api-keythroughdefault_headers. key-auth reads that header, not the SDK’s Bearer token. - The model field picks the provider, whichever of the three APIs the client calls; provider keys never leave the gateway.
gateway: name: platform bind: [{ address: 0.0.0.0, port: 8080 }]ai: providers: - name: openai type: openai api_key: ${OPENAI_API_KEY} models: [gpt-4.1-mini] - name: claude type: anthropic api_key: ${ANTHROPIC_API_KEY} models: [claude-sonnet-4-5]routes: - name: llm match: { paths: ["/v1/*"], methods: [POST] } providers: [openai, claude] # the request's model picks one mode: unified plugins: - { name: key-auth, config: { header: x-api-key } } - name: ai_dlp config: enabled: [pii.email, secret.aws_key] rules: pii.email: { action: redact } secret.aws_key: { action: block }Cost governance
Keys, teams and budgets that follow your org structure
Spend is controlled where the request is admitted, by the same identity that authenticated it. Keys belong to consumers, consumers belong to teams, and limits can key on the consumer, the route or the person your identity provider signed in.
Token counts come from provider replies, including cached and reasoning tokens where the provider reports them. Usage is counted after each response, so the request that crosses a limit completes and the next one is refused.
teams: - name: search budget: limit: 2000000000 # $2,000 a month, shared period: calendar_monthconsumers: - name: alice # her own $500 a month team: search plugins: - name: ai-cost-budget config: cumulative: { limit: 500000000, period: calendar_month } alerts: { webhook_url: "${BUDGET_WEBHOOK_URL}" }- Virtual keys
- A consumer's gateway key is bound to provider keys the operator holds. Clients never see a provider credential, and upstream capacity is attributed to each consumer.
- Keys issued in one call
- One admin API call mints a key, shown once, with a USD budget that resets daily or monthly or runs for a lifetime, request and token limits per minute, allowed models, an expiry and a team.
- Teams with shared budgets
- A team carries a shared USD budget enforced alongside each member's own, so a request goes through only when both allow. Usage and spend roll up per team.
- Per-user limits from your IdP
- Verified JWT claims or forward-auth headers can key rate limits, token limits and budgets, so each person your identity provider signs in gets their own allowance without a gateway consumer per user.
- Windows, caps and alerts
- Token limits and USD budgets run over fixed, sliding, rolling-anchor or token-bucket windows, and their counters can be shared across replicas with Redis. Daily, monthly and lifetime caps per consumer and team persist in PostgreSQL when a database is configured. Slack-compatible webhooks fire at thresholds you set, 50, 80 and 95% by default.
- 80-model pricing catalog
- A bundled catalog prices 80 models per token, including cached-input rates where the vendor publishes them, so budgets work without hand-written pricing. Your own prices always take precedence.
- Semantic cache
- Answers a similar prompt from cache by embedding similarity above a cosine threshold, using an OpenAI-compatible embeddings endpoint or an opt-in local ONNX embedder, stored in memory, Redis or pgvector. Every lookup makes an embedding call, and streaming, tool-calling, image or file, and embeddings requests bypass the cache.
- Semantic routing
- Classifies each prompt into a complexity tier that can map to a cheaper model. It runs in shadow mode by default, serving the requested model and recording the choice it would have made and the projected saving.
Guardrails
Enterprise AI gateway security
Tygress enforces identity, data handling and prompt policy before a request reaches a model provider, and inspects what comes back. Because it runs on its own transport, those checks can cover every chunk of a streamed reply, and a signed retry, such as SigV4 to Bedrock, is signed over the redacted body.
- Identity before the model
- Authenticate callers with OIDC, JWT against remote JWKS, LDAP or Active Directory, mTLS, OAuth2 token introspection, JWE, HMAC or API keys, and authorize them with OPA or ACLs. Virtual keys bind each consumer to provider keys the operator holds, so clients never see a provider credential.
- Model allowlists
- Limit each consumer to an exact list of model ids. The check runs before the cache and budget plugins, and fails closed when the requested model cannot be determined.
- DLP for prompts and replies
- Built-in detectors cover email addresses, North American phone numbers, US Social Security numbers, card numbers (Luhn-checked), AWS access keys, JWTs and high-entropy bearer tokens, plus your own regex rules. A match in a prompt is redacted, blocked or audited. Replies, buffered or streamed, can be scanned too, and matches there are redacted; reply scanning is on when a block rule is enabled, otherwise opt-in.
- Prompt-injection guard
- Heuristic rules catch instruction overrides, role-play jailbreaks, system-prompt probes and encoded payloads, alongside your own patterns. The keyword rules also check a copy of each prompt with invisible characters removed and look-alike letters folded to ASCII. An optional external classifier lets requests through when it is unavailable, unless set to block. Replies, streams included, are checked for leaked system-prompt text.
- Every streamed chunk, each attempt translated
- With reply scanning on, DLP and the prompt guard read each chunk of a streamed SSE reply, not one buffered body. Provider translation and request signing run inside each retry and failover attempt, after plugins edit the body, so a signed request, such as SigV4 to Bedrock, covers the exact bytes that attempt sends, redactions included.
- Operator-owned prompts
- A prompt template lets a route own the prompt: callers send typed parameters, which are inserted as JSON values with length limits. A prompt decorator adds operator text before or after the conversation that callers cannot remove.
- Post-quantum key exchange
- Hybrid key exchange, ML-KEM-768 (NIST FIPS 203) combined with X25519, is offered first by default on listeners and upstream connections; classical-only peers fall back to classical key exchange. A
pqc_policycan require it per listener or upstream, and thepqc-guardplugin per route or consumer. Certificates and signatures stay classical. - One plugin chain
- These controls are plugins on the same chain that authenticates your API traffic, set per route, consumer, team or group.
tygress explain-chainprints the resolved order for any route before you deploy.
How to test these controls in an evaluation
See OWASP's prompt injection guidance (opens in a new tab) for the limits of prompt-based defenses.
- Issue a key per application or team, revoke one, and confirm that clients never receive provider credentials.
- Run DLP against samples of your own data, and include logs, traces, cached responses and streamed output in the review.
- Test the prompt guard with realistic attacks. Filtering cannot eliminate prompt injection, so restrict tools by consumer and require approval for sensitive actions as well.
- Exhaust a budget and a provider quota on purpose, and limit failover to models and regions that your data policy allows.
Reliability
Routing and failover across LLM providers
Each AI route chooses its targets by model or by strategy, and fails over across providers and keys when one is down or out of quota.
- Selection strategies
- Pick a provider by model, or give a route a fallback, round-robin, weighted or semantic strategy. Targets that cannot serve the requested API are excluded before selection.
- Provider key pools
- A provider can hold several API keys. A key that gets a 429 is rested. Quota-aware rotation reads rate-limit headers from OpenAI, Azure OpenAI, Anthropic and Groq, and from OpenAI-compatible endpoints when enabled; other providers rotate on status codes.
- Failover that explains itself
- Fail over on the status codes you list or on connect failures, and rest a failed provider for a cooldown. When every target fails, the 502 lists each one and why: its status, a connect failure or a refused body.
- Long completions
- Each provider gets its own response-header timeout, 600 seconds by default to match the official OpenAI and Anthropic SDKs, and transport timeouts return 504 rather than 502.
- Autopilot (opt-in)
- A control loop tunes weights across the targets you declare toward lower cost, lower latency or more resilience, within limits you set. By default each change waits for human approval; in auto mode it applies changes and rolls back on regression. It runs in the all-in-one role, not in a split control-plane and data-plane deployment.
- MCP tools in LLM requests
- A route can add an MCP toolset's tools to outgoing LLM requests. If a name collides, the client's own tool wins, and the client still executes the tool calls.
MCP and A2A
Agent actions held at the gateway
Models increasingly act through tools and other agents. Tygress puts those calls behind the same identity and policy as model traffic, and can hold a sensitive action until a person decides.
routes: - name: support-tools match: { paths: ["/mcp"] } mcp_server: support-mcp plugins: - name: key-auth - name: mcp-guard config: allowed_tools: [search_tickets, get_customer, refund_order] - name: mcp-approval config: requires_approval: [refund_order] approval_timeout: 45 # seconds, then default_action default_action: deny notify: { url: "${SLACK_WEBHOOK_URL}", format: slack }- MCP gateway
- Proxy upstream MCP servers through normal routes, with load balancing, health checks and TLS. The mcp-guard plugin allowlists tools/call per consumer, group or route, and exposes the method and tool name so rate limits and logs can key on them.
- MCP producer
- Serve REST upstreams as MCP tools, with the gateway answering initialize, tools/list and tools/call itself. Generate toolsets deterministically from OpenAPI 3.x specs, and merge several MCP servers into one endpoint with namespaced tools and per-consumer filtering.
- Human approvals
- MCP tool calls and A2A methods marked for approval wait until an operator approves or denies them through the admin API. The default timeout is 45 seconds and the default outcome is deny. Webhooks can notify Slack, Discord or Teams, and each decision is recorded in an append-only PostgreSQL table when a database is configured.
- A2A routing
- Register A2A agents, discover them through their Agent Cards, and serve one federated card with namespaced skills. Route by skill or round-robin, and keep follow-up task calls on the agent that created the task. Failover between agents is not wired yet.
- MCP authorization
- MCP routes can follow the 2025 MCP authorization pattern: RFC 9728 protected-resource metadata, token validation by the jwt or OAuth2 introspection plugin, and optional dynamic client registration proxied to your identity provider.
- Approvals across replicas
- The approval queue is shared across gateway replicas when Redis is configured, so an operator's decision reaches whichever replica holds the request.
Observability
LLM telemetry in the tools you already run
AI requests show up as LLM calls in GenAI-aware tracing tools, with tokens, cost and latency attached.
- GenAI OpenTelemetry spans
- With the OpenTelemetry plugin attached, each AI request gets a span with gen_ai.* attributes: provider, requested and resolved model, token counts including cached and reasoning tokens, finish reasons, time to first chunk and cost. Prompt and completion capture is opt-in, and redacted when the DLP plugin is attached.
- Langfuse export
- Each AI request produces one record with the model, each provider it tried, timing including time to first token, and, for metered calls, token counts and cost. The Langfuse plugin exports it as a trace and generation.
- Prometheus metrics
- Requests, tokens, cost, time to first token, failovers, key cooldowns, provider quota, semantic-cache lookups, and DLP and prompt-guard counters.
- Usage and spend API
- Admin endpoints report requests, tokens and realized cost per consumer, team, provider and model. With PostgreSQL, the data survives restarts and aggregates across data planes.
- LLM-as-judge
- Grade a deterministic sample of replies against a rubric with a judge model, after the response has been sent. It only observes and never blocks.
Shared operating model
One gateway, four teams, one policy model
- Developers
- Keep the OpenAI or Anthropic SDK, point it at one gateway endpoint and send a gateway key as
x-api-key. Provider credentials stay with the operator. - Platform teams
- Run model, API, MCP and A2A traffic through the same routes, plugins, deployment topology and telemetry.
- Security teams
- Enforce identity, DLP, prompt guards, tool allowlists and human approvals before a request leaves the network.
- FinOps teams
- Attribute tokens and spend to consumers, teams, providers and models, cap budgets in USD, and get alerts at thresholds you choose.
Deployment
Run a self-hosted AI gateway in your VPC
Tygress is built to run in a private VPC or on-premises. Self-hosting the gateway keeps routing and policy under your control, but it does not keep prompts local when the destination is a cloud model API: choose where inference runs as well.
- Topology
- One binary, or separate control-plane and data-plane roles that sync configuration over NATS. Redis shares counters, approval queues and provider quota state across replicas.
- Packaging
- The source includes a Dockerfile for a distroless, non-root image and a Docker Compose reference stack with NATS, a control plane and two data planes. No image is published yet, and there is no Helm chart.
- Optional PostgreSQL
- PostgreSQL keeps durable budgets and usage history, and append-only records of approval decisions, autopilot changes and, in control-plane mode, config revisions. It is not the config store, and the gateway runs without it.
- Operations
- Linux and macOS. Zero-downtime binary upgrades hand the listening sockets to the new process. On SIGTERM,
/healthzreturns 503 so load balancers deregister the node before in-flight work drains.
Where inference runs
- Private VPC with external providers
- Host the gateway in your cloud account and allow only the provider endpoints you approve. Requests routed to an external model still leave your network; review provider retention, processing region and logging settings.
- On-premises with local inference
- Route to an OpenAI-compatible model endpoint on your own infrastructure, and keep inference, gateway logs, caches and telemetry inside the same approved boundary.
- Fully air-gapped
- Keep model serving, identity, dependencies and observability reachable locally; the model pricing catalog can load from a file. External model APIs cannot be used from an environment with no outbound connectivity.
Note
The gateway runs on tygress-proxy, its own async transport written in Rust, with hyper for HTTP framing and rustls for TLS. No benchmarks are published yet, so measure latency with your own streaming, guardrail and logging settings enabled.
Status
What is built, and what is not yet
Tygress is pre-release. The gateway is built and in active pre-1.0 development, but it is not publicly available yet. Join the early-access waitlist for beta availability and product updates.
Not yet supported
- A published container image, Helm chart or Kubernetes manifest. The operator console and the local ONNX embedder are opt-in builds.
- The OpenAI Realtime API, which returns 501.
- Images, audio, moderations, files and batches on provider types other than OpenAI, and cost accounting for those endpoints.
- Embeddings on Anthropic, Groq or Vertex AI. Vertex AI covers Gemini models, not Claude on Vertex.
- Image, file or document input through the Responses and Messages bridges. Bedrock models served through Converse receive text and tool calls only.
- Failover between A2A agents.
- Aggregating MCP servers that need sessions or SSE. Aggregation supports stateless JSON-mode Streamable HTTP servers only.
- SAML sign-in, or running the gateway on Windows.
- A stable configuration schema and admin API: both may change before 1.0.
Recent changes
- AI gateway
Failover errors that explain themselves
- AI gatewayAgents & MCP
Function calling on /v1/responses, on every provider
Multi-turn function calling over /v1/responses, buffered or streaming, on every provider whose model supports tools, natively or bridged.
- SecurityAI gateway
Prompt guard catches look-alike-letter injections
More than an LLM gateway
The same gateway runs your APIs
Tygress is also a full API gateway: HTTP/1.1 and HTTP/2, gRPC with JSON transcoding, WebSocket, TCP/UDP/TLS passthrough, ACME certificates and 60+ built-in plugins, in the same binary as the AI gateway.
There are no enterprise-only gateway features. Planned pricing puts every gateway capability, identity and AI governance included, in the $0 tier; paid plans are services such as managed hosting and support. An open-source core is planned at launch. Release and license details will be published with the release.
- Read about the self-hosted enterprise API gateway
Protocols, identity, traffic control and high availability for REST and gRPC.
- AI gateway vs API gateway: do you need both?
What an AI gateway adds, where the two overlap, and when one gateway can do both jobs.
- LiteLLM alternative: Tygress vs LiteLLM
Model routing, budgets and guardrails, plus a full API gateway in the same binary.
- Kong AI Gateway alternative: Tygress vs Kong
Identity, plugins, LLM routing, MCP and A2A, and when Kong is the better choice.
- Tygress changelog
40 dated updates since June 2026, newest first.
FAQ
Enterprise AI gateway questions
- Related guide: AI gateway vs API gateway
- Comparing LLM gateways? Tygress vs LiteLLM
What is an enterprise AI gateway?
An enterprise AI gateway is the policy layer between applications and AI systems. It holds provider credentials, routes and fails over model requests, meters tokens and spend, enforces budgets, screens prompts and replies for sensitive data and injection attempts, records telemetry, and governs the tools and agents that models call. Tygress runs those controls in the same self-hosted gateway that handles REST, gRPC and WebSocket traffic, so one identity and rate-limit model covers both.
How is an AI gateway different from an LLM proxy?
The terms overlap, and many products use both. An LLM proxy usually means a service that normalizes model APIs and forwards requests to providers. An AI gateway adds organizational controls around that path: identity from your identity provider, per-team budgets, data-loss prevention, prompt-injection screening, tool and agent policy, human approvals, and telemetry your platform team already uses. Tygress also carries REST, gRPC and WebSocket traffic, so the same gateway can stand in for a separate API gateway.
Is Tygress an enterprise LLM gateway?
Yes. Tygress routes LLM traffic to nine provider types, keeps provider keys server-side behind virtual keys, rotates key pools, fails over between providers, and enforces token limits and USD budgets for consumers and teams. It goes further than an LLM gateway in two ways: it governs MCP tools and A2A agents, and it is a full API gateway with OIDC, LDAP, mTLS, gRPC transcoding and 60+ built-in plugins. Tygress is pre-release and not yet publicly available.
Which LLM APIs can clients use with Tygress?
Clients can call OpenAI Chat Completions, OpenAI Responses or Anthropic Messages on any of the nine provider types. Responses is native on OpenAI and Azure OpenAI, Messages is native on Anthropic, and the gateway bridges both through chat completions elsewhere, including streaming and tool calling. Bridges refuse what they cannot carry, such as stored conversations, hosted tools, extended thinking or image input, with a 400 that names the field instead of silently dropping it.
How do teams and budgets work in Tygress?
Each consumer can belong to one team. A team carries a shared USD budget that resets daily or monthly or runs for a lifetime, enforced alongside the member's own budget, so a request goes through only when both allow. Windowed budgets can also be keyed per route or per end user from verified JWT claims. Spend is priced from a bundled 80-model catalog or your own prices, kept across restarts with PostgreSQL, and webhook alerts fire at thresholds you set.
Does Tygress inspect streamed LLM replies?
Yes. Because Tygress runs on its own transport, the DLP plugin and the prompt guard see every chunk of a streamed server-sent-events reply rather than one buffered body. DLP redacts matches in replies, buffered or streamed; reply scanning is on whenever a block rule is enabled and can be switched on otherwise. The prompt guard checks replies for leaked system-prompt text. DLP uses regex detectors with Luhn and entropy checks, and the prompt guard uses heuristic rules plus an optional external classifier.
Can Tygress govern MCP servers and AI agents?
Yes. Tygress can proxy MCP servers with per-consumer tool allowlists, serve REST APIs as MCP tools, generate toolsets from OpenAPI 3.x specs, and merge several MCP servers into one endpoint with namespaced tools. It routes A2A calls by skill with Agent Card discovery. Sensitive MCP tool calls and A2A methods can wait for a human decision, with a 45-second default timeout that denies when no one answers. Failover between A2A agents is not wired yet.
Can the AI gateway be self-hosted or air-gapped?
Tygress is built to run in a private VPC or on-premises, as one binary or as separate control-plane and data-plane roles. A fully air-gapped deployment also needs local model endpoints, identity services and other dependencies inside the boundary; the model pricing catalog can load from a file. Requests routed to external model APIs leave your network even when the gateway is self-hosted, so pair it with approved endpoints and data-handling policies.
Pre-release
Get early access to the Tygress AI gateway
Join the waitlist for beta availability, deployment guidance and build updates.
- Beta availability updates
- No payment required
- Unsubscribe anytime
We email you about the beta and launch. See the Privacy Policy.