Proxy Your Existing MCP Server

You already have an MCP server running on your infrastructure. Aerostack becomes the gateway in front of it — handling encrypted secrets, access control, and per-user analytics. Your team connects to the Aerostack workspace URL. They never see or touch your production API keys.

This is the external_url mode. Aerostack proxies requests to your server, injecting secrets as headers on every call.

The Enterprise Problem

Without Aerostack, sharing an MCP server with your team looks like this:

Concern	Without Aerostack	With Aerostack Proxy
API keys	Shared via Slack, `.env` files, or password managers. Every developer has the raw key.	Stored AES-GCM encrypted. Injected at request time. Developers never see the key.
Access control	Everyone uses the same credentials. No way to revoke one person.	Per-member workspace tokens (`mwt_`). Revoke one token without rotating production keys.
Audit trail	No visibility into who called what.	Every tool call logged per user via Cloudflare Analytics Engine.
Key rotation	Update the key, notify 30 engineers, wait for everyone to update `.env`.	Update once in Aerostack. Every team member gets the new key automatically.
Offboarding	Rotate every key the departing engineer had access to.	Revoke their `mwt_` token. Done.

The pitch: 30 engineers using Cursor. One workspace URL. Zero API keys on laptops. Full audit trail of every tool call. Revoke one person without rotating production keys.

How It Works

Key points:

The team member authenticates with their personal workspace token
The gateway decrypts the stored secrets for this MCP server
Secrets are injected as HTTP headers before forwarding to your server
The call is logged with the team member’s identity for analytics

Step-by-Step Setup

Register your MCP server

Go to the Admin dashboard
Navigate to MCP Servers in the sidebar
Click Add External MCP
Fill in:
- Name: Your MCP Server
- Slug: my-api (used in tool namespacing: my-api__tool_name)
- External URL: https://mcp.yourcompany.com/sse
Click Create

Store your API keys as secrets

Secrets are stored AES-GCM encrypted. They are injected as HTTP headers on every request to your MCP server.

# Store an API key
aerostack secrets set my-api API_KEY "sk-prod-xxxxxxxxxxxx"
 
# Store a Bearer token
aerostack secrets set my-api AUTH_TOKEN "Bearer sk-prod-xxxxxxxxxxxx"
 
# Store multiple secrets
aerostack secrets set my-api DATABASE_URL "postgres://user:pass@host/db"
aerostack secrets set my-api STRIPE_KEY "sk_live_xxxxxxxxxxxx"

Secrets are scoped per MCP server. The my-api server’s secrets are never sent to other MCP servers in the same workspace. See Secrets and Security for the full encryption model.

Configure secret injection

Tell Aerostack how to inject each secret into requests. By default, secrets are injected as HTTP headers with the secret name as the header key.

# Inject as a custom header
aerostack secrets inject my-api API_KEY --header "X-API-Key"
 
# Inject as Bearer auth
aerostack secrets inject my-api AUTH_TOKEN --header "Authorization"
 
# Inject as a query parameter (less common)
aerostack secrets inject my-api API_KEY --query "api_key"

Or configure via the Admin dashboard under MCP Servers > my-api > Secrets > Injection Rules.

Add to your workspace

aerostack mcp install my-api --workspace engineering

Issue tokens for team members

Each team member gets their own workspace token:

aerostack workspace token create engineering --name "Alice Chen"
# -> mwt_alice_xxxxxxxx
 
aerostack workspace token create engineering --name "Bob Singh"
# -> mwt_bob_xxxxxxxx
 
aerostack workspace token create engineering --name "Carol Wu"
# -> mwt_carol_xxxxxxxx

Share each token individually. The token is the only credential the team member needs.

Team members configure their editor

Each member adds the workspace gateway to their editor. This is a one-time setup:

~/.cursor/mcp.json:

{
  "mcpServers": {
    "engineering": {
      "url": "https://gateway.aerostack.dev/ws/engineering/sse",
      "headers": { "Authorization": "Bearer mwt_alice_xxxxxxxx" }
    }
  }
}

claude_desktop_config.json:

{
  "mcpServers": {
    "engineering": {
      "type": "sse",
      "url": "https://gateway.aerostack.dev/ws/engineering/sse",
      "headers": { "Authorization": "Bearer mwt_alice_xxxxxxxx" }
    }
  }
}

.vscode/mcp.json:

{
  "mcpServers": {
    "engineering": {
      "url": "https://gateway.aerostack.dev/ws/engineering/sse",
      "headers": { "Authorization": "Bearer mwt_alice_xxxxxxxx" }
    }
  }
}

Before vs. After

Before: Direct MCP Access

Developer Laptop                     Your MCP Server
┌─────────────────┐                 ┌─────────────────┐
│ Cursor           │    direct      │ mcp.company.com  │
│ API_KEY=sk-prod  │ ──────────────>│                  │
│ DB_URL=postgres  │                │                  │
│ STRIPE=sk_live   │                │                  │
└─────────────────┘                 └─────────────────┘

Problems:
- Production keys on every laptop
- No audit trail
- Can't revoke one person
- Key rotation = notify everyone

After: Proxied Through Aerostack

Developer Laptop                  Aerostack Gateway              Your MCP Server
┌─────────────────┐              ┌─────────────────┐            ┌─────────────────┐
│ Cursor           │  mwt_ token │ Decrypt secrets  │  injected │ mcp.company.com  │
│ Only has:        │ ──────────> │ Inject headers   │ ────────> │                  │
│   mwt_alice_xxx  │             │ Log analytics    │           │                  │
│                  │             │ Enforce access   │           │                  │
└─────────────────┘              └─────────────────┘            └─────────────────┘

Benefits:
- Zero production keys on laptops
- Full per-user audit trail
- Revoke one token, done
- Rotate key once in Aerostack

Real-World Scenarios

Scenario 1: Engineering Team with Multiple MCP Servers

Your company runs MCP servers for your internal API, a Postgres database, and a deployment pipeline:

# Register all three
aerostack mcp register --name "Internal API" --slug internal-api --url "https://mcp.api.yourco.com/sse"
aerostack mcp register --name "Database" --slug db --url "https://mcp.db.yourco.com/sse"
aerostack mcp register --name "Deploy Pipeline" --slug deploy --url "https://mcp.deploy.yourco.com/sse"
 
# Store secrets for each (scoped per server)
aerostack secrets set internal-api API_KEY "sk-internal-xxx"
aerostack secrets set db DATABASE_URL "postgres://prod:pass@host/db"
aerostack secrets set deploy DEPLOY_TOKEN "dp-xxx"
 
# Add all to the engineering workspace
aerostack mcp install internal-api --workspace engineering
aerostack mcp install db --workspace engineering
aerostack mcp install deploy --workspace engineering

Now every engineer sees:

internal-api__query_users
internal-api__create_user
db__run_query
db__list_tables
deploy__trigger_deploy
deploy__rollback

One workspace URL. Six tools. Zero production keys on laptops.

Scenario 2: Different Access Levels

Create separate workspaces for different teams:

# Full access for senior engineers
aerostack workspace create senior-eng
aerostack mcp install internal-api --workspace senior-eng
aerostack mcp install db --workspace senior-eng
aerostack mcp install deploy --workspace senior-eng
 
# Read-only for junior engineers (only install the read-only MCP servers)
aerostack workspace create junior-eng
aerostack mcp install internal-api --workspace junior-eng
aerostack mcp install db --workspace junior-eng
# deploy NOT installed — juniors can't trigger deploys

Scenario 3: Client-Specific Workspaces

Agencies or consultants can create per-client workspaces:

aerostack workspace create client-acme
aerostack mcp register --name "Acme API" --slug acme-api --url "https://mcp.acme.com/sse"
aerostack secrets set acme-api API_KEY "acme-key-xxx"
aerostack mcp install acme-api --workspace client-acme
 
aerostack workspace create client-globex
aerostack mcp register --name "Globex API" --slug globex-api --url "https://mcp.globex.com/sse"
aerostack secrets set globex-api API_KEY "globex-key-xxx"
aerostack mcp install globex-api --workspace client-globex

Each client’s secrets are isolated. Team members assigned to Acme only get the client-acme workspace token.

Requirements for Your MCP Server

Your existing MCP server must:

Be accessible via HTTPS — Aerostack connects to the external_url you register
Support SSE transport — the standard MCP-over-HTTP transport (most MCP SDKs support this)
Accept injected headers — secrets are sent as HTTP headers on each request

If your server currently requires API keys in the request body or as environment variables, you may need a thin middleware layer to read them from headers instead.

Your MCP server does not need any Aerostack SDK or dependency. It is a standard MCP server. Aerostack is transparent — it proxies requests and injects headers.

Monitoring Proxied Servers

View analytics for your proxied server:

aerostack analytics --workspace engineering --server my-api --period 7d
# USER           TOOL                    CALLS    LAST USED
# [email protected]   my-api__query_users     142      2 min ago
# [email protected]     my-api__create_user     38       1 hr ago
# [email protected]   my-api__query_users     94       15 min ago

Or view in the Admin dashboard under MCP Servers > my-api > Analytics.

Next Steps

Secrets and security deep dive
Team management and access control
Host an MCP server on Aerostack instead of proxying
Use with any LLM (OpenAI, Gemini, Claude)

Host on Aerostack Secrets & Security