System Architecture
TameFlare supports multiple deployment models depending on your team's size and security requirements:
| Managed Cloud | Hybrid (coming soon) | Source-available | |
|---|---|---|---|
| Best for | Individuals, small teams | Teams with compliance needs | Large orgs, air-gapped envs |
| Dashboard | Hosted at tameflare.com | Hosted at tameflare.com | You run from source |
| Gateway | Hosted at proxy.tameflare.com | You run on your infra | You run from source |
| Credentials | Encrypted in TameFlare vault | Stay in your environment | Your environment |
| Traffic | Transits cloud gateway | Stays in your network | Your network |
| Control plane | tameflare.com | tameflare.com (metadata + approvals) | Your infrastructure |
| CLI | npm i -g @tameflare/cli | Same | Same |
| Plan | All tiers | Team and Enterprise | ELv2 (no support) |
Managed Cloud (current default)
Sign up at tameflare.com, configure gateways in the dashboard, and run the CLI on your machine. There is nothing to deploy or install beyond the CLI. The cloud gateway at proxy.tameflare.com handles traffic interception, credential injection, and enforcement. This is the right choice for individuals and small teams who want governance without infrastructure overhead.
Hybrid: self-hosted gateway (coming soon for Team/Enterprise)
For teams where credentials and traffic must not leave the customer environment, TameFlare will offer a self-hosted gateway option. You run the gateway binary on your own infrastructure (server, VM, or container). The gateway connects to the TameFlare dashboard for configuration, approvals, and audit - but credentials stay in your environment and traffic never leaves your network. Only metadata (domain, action type, decision, latency) is sent to the dashboard.
This model is designed for mid-market teams and organizations with compliance requirements (SOC 2, GDPR, NIS2) where a cloud MITM proxy is not acceptable.
Source-available (ELv2)
The full TameFlare source code is available under the Elastic License v2. Organizations that need to run everything on their own infrastructure can build and deploy from source. This is a DIY option - TameFlare does not provide support for source-built deployments. See the Troubleshooting page for self-hosted migration guides.
The rest of this page describes the Managed Cloud architecture.
How it works
Your process → HTTPS_PROXY → proxy.tameflare.com (cloud gateway)
│
├── domain → connector → parse action
├── check permissions against dashboard config
├── inject credentials from encrypted vault
│
▼
External APIs (GitHub, Stripe, OpenAI, ...)
- Dashboard (hosted at tameflare.com) - configure gateways, connectors, permissions, credentials, and policies. View traffic logs, approve requests, manage your team.
- CLI (
npm i -g @tameflare/cli) - runs on your machine. SetsHTTPS_PROXYand spawns your process. No binary download needed. - Cloud gateway (proxy.tameflare.com) - transparent HTTP/HTTPS proxy. Intercepts outbound traffic, parses it via connectors, checks permissions, injects credentials, and logs everything.
The cloud gateway runs at proxy.tameflare.com. Configuration and audit data are stored in the hosted dashboard. Your API keys are encrypted at rest (AES-256-GCM).
Approval channels
TameFlare supports two approval modes:
Dashboard-only (default)
Approvals appear on the Approvals page in the dashboard. Admins and members can approve or deny directly from the UI. No external services required.
Slack integration
For teams that want approval notifications in Slack:
- Create a Slack app at api.slack.com/apps
- Add the
chat:writeandchat:readbot scopes - Install the app to your workspace
- Copy the Bot Token and Signing Secret to Settings → Integrations in the dashboard
- Set the channel ID where approval messages should be posted
Slack approval messages include approve/deny buttons that update the dashboard in real time.
Both modes work simultaneously - Slack notifications are additive, not a replacement for dashboard approvals.
Performance
| Operation | Typical latency | Notes |
|---|---|---|
| Policy evaluation | 1–5ms | In-memory, no DB calls during evaluation |
| Permission check + credential injection | 10–30ms | Cloud gateway, cached config (5-min TTL) |
| End-to-end (agent → external API) | 50–500ms | Depends on external API response time |
The gateway adds minimal overhead. It runs as a single Go binary using ~20–50 MB RAM.
Security model
- Deny-all default - no connector configured = no access
- Credential isolation - your process never sees real API keys
- Encrypted vault - AES-256-GCM encryption at rest
- Per-gateway permissions - fine-grained allow/deny per connector, per action type
- Kill switch - block all traffic instantly, scoped to a connector or gateway
- Audit trail - every request logged with gateway, action, decision, and latency
- Source-available - full source code at github.com/tameflare/tameflare under Elastic License v2