Managed vs Self-Hosted

TAP can run as a managed service at toolsec.org or self-hosted on your own infrastructure. Both use the same proxy, the same admin API, and the same agent interface. This page covers the differences.

Managed Hosting (toolsec.org)

The managed service runs in Evervault hardware enclaves — isolated execution environments where encryption keys are generated inside the enclave and never leave it, even from Evervault or TAP operators.

• No infrastructure to manage — no Docker, no databases, no TLS certificates
• Encryption keys handled for you — generated and stored inside the hardware enclave, never exported
• Team collaboration — multiple admins per team, each with their own login
• Automatic updates — security patches and new features deployed without downtime
• Enclave attestation — cryptographic proof that the proxy code running matches the published source

Managed hosting is the more secure option for most users — individuals and teams alike. Encryption keys are generated and stored inside hardware enclaves and never leave, which eliminates the most common source of credential breaches: key mismanagement. In practice, self-managing encryption keys is hard to get right. Keys end up in .env files on laptops, in shell history, in CI logs, or on unencrypted disks. This is the same class of operational mistakes that causes the majority of crypto wallet hacks and API key leaks. The enclave model removes this entire category of risk.

On managed hosting, the dashboard provides a visual interface for managing credentials, agents, policies, and audit logs at a glance. The admin API is also fully available for automation.

When to Use Managed Hosting

• Most users, including individuals. Unless you have a specific reason to self-host, managed hosting is strictly more secure. You don’t need to be on a team to benefit from hardware enclaves — a solo developer with a personal API key has the same key management risks as a company
• Production workloads where uptime and automatic updates matter
• Regulated environments that benefit from enclave attestation
• Anyone building agents that access financial APIs, social media accounts, or other high-value credentials

Self-Hosted (Open Source)

The full TAP codebase is MIT licensed. Clone the repo, build with Docker Compose, and run on any infrastructure you control.

• Full control — your servers, your network, your rules
• No external dependencies — runs entirely on your infrastructure
• Same core proxy — identical Rust codebase, identical API surface
• Free forever — MIT license, no usage limits

When self-hosted, you manage credentials, agents, and policies via the built-in admin dashboard (at /dashboard on your proxy), curl, or the tap CLI. You are responsible for encryption key generation, TLS termination, database backups, and keeping the proxy up to date.

When to Use Self-Hosted

• Local development and experimentation before committing to a deployment
• Air-gapped or restricted environments with no external connectivity
• Custom integrations that need source-level modifications
• Organizations with a compliance requirement for on-premises data residency

Note: self-hosting shifts the security burden to you. You are responsible for generating strong encryption keys, storing them securely, configuring TLS, applying updates, and managing backups. If you are not confident in your ability to do these things correctly, managed hosting is the safer choice.

Feature Comparison

Agent Interface Is Identical

From the agent’s perspective, there is no difference. The same headers, the same request format, the same response format:

curl -X POST $PROXY_URL/forward \
  -H "X-TAP-Key: $AGENT_KEY" \
  -H "X-TAP-Credential: openai" \
  -H "X-TAP-Target: https://api.openai.com/v1/models" \
  -H "X-TAP-Method: GET"

The only difference is the proxy URL. Switching between managed and self-hosted requires changing one environment variable in your agent configuration.

Admin API Is Identical

The same admin endpoints work on both deployments. The Configuration page documents the full admin API — every example works against either https://api.toolsec.org or your self-hosted http://localhost:3100.

Migrating Between Deployments

There is no lock-in. Since both deployments use the same SQLite schema and the same API:

• Self-hosted to managed: Create a team on toolsec.org, re-add your credentials and agents via the admin API, update your agent’s proxy URL
• Managed to self-hosted: Clone the repo, set up Docker Compose, re-create your configuration via the admin API

Credential values need to be re-entered in either direction since they are encrypted at rest and never exported.