An organization already using Tailscale Aperture has a place to configure its model providers, credentials, and access policy. Connecting an application platform should not require copying those provider keys into another system.

We have implemented support for Tailscale Aperture as an upstream provider in the Anchras AI gateway. Applications continue to call Anchras with their scoped application keys. Anchras sends their model requests to Aperture over the tailnet, and provider credentials stay in Aperture.

The connection now supports agent routing on customer-owned tailnets. An enrolled Anchras agent on your tailnet connects to Aperture for the hosted gateway, so the hosted Anchras server does not need to join your tailnet.

Follow one request

On a customer-owned tailnet, the request follows this path:

FOLLOW THE REQUESTOne entry point. Your choice of model.
01 / REQUEST Application Your app or agent Scoped application key
02 / GATEWAY AI gateway Application routes
Guardrails & usage Application-level control
03 / YOUR TAILNET Egress agent Enrolled Anchras agent
Reverse tunnel Agent’s Tailscale identity
04 / MODEL ACCESS Model routing Provider connections
Model access policy Access granted to the agent
05 / LOCAL INFERENCE Local AI Ollama · vLLM · llama.cpp Your hardware. Your runtime.
05 / HOSTED INFERENCE Hosted models Approved external provider Provider keys stay in Aperture.
EXAMPLE ROUTE

An internal knowledge assistant requests a local model. Anchras forwards through the egress agent to Aperture, which sends it to the configured runtime on your hardware.

Customer-owned tailnet: the gateway reaches Aperture through an enrolled egress agent. On managed tailnets or a self-hosted control plane with tailnet access, it can connect directly using the server’s identity. Aperture selects the provider by model name; this diagram does not imply automatic content classification. Responses return through the same route.

The gateway opens a reverse tunnel through an enrolled agent on the same tailnet as Aperture. That agent acts as the egress point and connects through its own Tailscale node. Model discovery uses this path too. On a managed tailnet, or a self-hosted control plane with tailnet access, the server can connect directly.

Anchras remains the application-facing entry point for model routes, application keys, guardrails, and usage attribution. Aperture handles the next hop using the providers and access rules configured there. Tailscale documents how Aperture identifies the connecting device and selects a provider from the requested model name in its architecture guide.

This gives a team a practical division of responsibility: manage its application routes in Anchras and maintain the underlying provider connections in Aperture. A provider key rotated in Aperture does not need to be redistributed to the applications or stored in Anchras for this connection.

Local AI belongs in the same flow

A local model can be the destination behind Aperture. Tailscale supports self-hosted runtimes with an OpenAI-compatible Chat Completions API, including Ollama, vLLM, and llama.cpp. Configure the runtime’s endpoint and model names in Aperture, make it reachable from the Aperture host, and register the corresponding model route in Anchras. See Tailscale’s self-hosted model guide.

For example, a team can configure its internal knowledge assistant to use a local model, while allowing a separate public-content assistant to use an approved hosted model. Both applications use Anchras as their entry point. The operator defines the permitted models and routes; this integration does not decide which prompts are safe to send outside the organization.

Local describes where inference runs. Requests still pass through Anchras and Aperture, so their deployment locations, access, and retention settings remain part of the data path. This connection does not deploy a local runtime for you. Our guide to local AI with Anchras explores the wider infrastructure and operating model.

Whose identity does Aperture see?

Aperture sees the Tailscale identity of the node that connects to it. On a customer-owned tailnet, that is the egress agent's node. On the direct path, it is the Anchras server's node. It does not automatically receive the identity of each Anchras user or application; Anchras retains application-level attribution in its own gateway records.

Grant the connecting node, or its tag, the model access it needs in Aperture. Agent selection happens per connection, so authorize all eligible egress agents or their shared tag. Continue using scoped application keys and policy in Anchras for application-level restrictions.

For agent routing, keep an enrolled agent online on the same tailnet as the Aperture node and run a release that supports Aperture peer tunnels. Older agents reject the tunnel command. Aperture must be a separate peer node; this route does not connect back to the agent itself or through a subnet router. The integration does not configure Aperture or create a separate Tailscale identity for each application.

Add the provider

In the AI gateway, choose Tailscale Aperture under On your tailnet and select the Aperture node. Anchras lists nodes from your connected tailnet provider and derives the URL from the selected node’s MagicDNS name. You can also enter the URL manually. Leave provider credentials out of the setup. The preset uses the provider slug tailscale-aperture. Keep that slug: it selects the integration's identity authentication and restricted network transport.

The CLI can list the nodes and their reach path before you create the provider:

anchras ai providers aperture-nodes

anchras ai providers create \
  --slug tailscale-aperture \
  --name 'Tailscale Aperture' \
  --base-url 'http://aperture.your-tailnet.ts.net/v1'

anchras ai providers discover --id PROVIDER_ID

Replace the example hostname with your Aperture hostname and PROVIDER_ID with the returned provider ID. Discovery lists models without registering them. Choose the models to register and configure their routes, or use the dashboard's optional automatic import. The AI gateway guide contains the API equivalents and route setup commands.

Saving the provider imports the selected node into your organization’s tailnet device inventory and checks the route prerequisites. A missing inventoried device or a customer-owned tailnet without an egress agent produces a named error. Discovery reads that inventory; if the node’s address changes, import it again to refresh the record.

Both an origin URL and a URL ending in /v1 work. The server sends neither a provider bearer token nor an API key to Aperture. New credential bindings are rejected for this provider, and old bindings are ignored. Configure any required model-provider key in Aperture itself, following Tailscale's setup guide.

Match the model to the request format

This integration uses the Anchras gateway's existing OpenAI-compatible upstream paths. Chat Completions requires a model whose Aperture provider supports openai_chat. The Anchras Messages adapter also translates requests into that upstream format. A model appearing in discovery is not proof that it supports the format your application sends. Check the Aperture compatibility reference.

The gateway does not expose Responses or native Anthropic, Gemini, or Bedrock forwarding through this integration. Embedding support needs separate verification. The integration does not manage Aperture’s configuration or connect its MCP tools. Existing gateway response buffering also remains in effect.

Keep the entire route under review

The Aperture connection is restricted to Tailscale addresses in your organization’s device inventory. On the direct path, DNS and ownership are checked for each connection. On the agent path, the server fixes the destination to the inventoried address and the agent connects through its own Tailscale node, without falling back to the host network. Environment HTTP proxies are bypassed and redirects are rejected. Public endpoints, loopback bridges, and subnet-routed private addresses are outside this integration's supported connection path.

That private connection does not determine where the final model processes data. Review the selected model provider alongside both gateways. Anchras payload-retention settings do not configure Aperture's retention; each system needs its own review.

Finally, if Aperture is required to govern every request, keep it in every permitted route. An Anchras fallback that calls a model provider directly can bypass Aperture. Test model discovery, model access, a denied request, and loss of the egress agent before enabling the route for applications.