https://gateway.truefoundry.ai.
gateway.truefoundry.ai is the unified endpoint for both the AI Model Gateway and the MCP Gateway.Whether you are routing LLM inference requests (OpenAI-compatible API, etc.) or connecting to MCP (Model Context Protocol) servers, all traffic goes through the same globally distributed infrastructure. This means MCP Gateway deployments benefit from the same multi-region, multi-cloud availability described on this page.
Features
- Globally Distributed: Deployed across more than 12 regions around the globe and across 3 multiple cloud providers for maximum availability while minimizing latency.
- Automated Failover: All traffic is routed to the nearest gateway for minimum latency. In case of regional downtime, traffic is automatically routed to closest healthy regions ensuring uninterrupted service.
- Multi-Cloud Deployment: Distributed across multiple cloud providers to be tolerant to cloud provider-specific disruptions.
- Data Encryption: Data is encrypted at rest and in transit.
- Compliance: Truefoundry Infrastructure is SOC2, ISO27001, GDPR, and HIPAA compliant
Architecture
The SAAS global deployment follows the same Gateway Plane Architecture used across all Truefoundry deployments. It consists of two key components:- Control Plane — Manages all gateway configuration including models, users, teams, virtual accounts, rate-limiting, and routing configs. The SAAS control plane is hosted in Ireland (Europe).
- Gateway Planes — Stateless, horizontally scalable gateway instances that handle all production traffic (LLM requests, MCP requests, etc.). These are deployed across the regions listed in the Regional Deployments section below.
The specific regions and locations where gateway planes are deployed are subject to change based on Truefoundry’s internal infrastructure needs. Regions may be added, removed, or relocated without prior notice.
Global Deployment
For most use cases, we recommend using the global endpoint which automatically routes to the nearest healthy gateway:| Deployment | Global Endpoint |
|---|---|
| Global (Auto-routed) | https://gateway.truefoundry.ai |
Regional Deployments
Each gateway region has its own URL and associated metadata. Every request routed through the SaaS gateway is automatically enriched with thetfy_gateway_region and tfy_gateway_zone metadata keys that identify which gateway region and zone handled the request. The Region and Zone columns in the table below show the values these keys will contain.
| Physical Location | Cloud Provider | Region | Zone | Regional Endpoint |
|---|---|---|---|---|
| North Virginia, United States (ORF) | AWS | US | ORF | https://orf.gateway.truefoundry.ai |
| San Francisco, United States (SFO) | Azure | US | SFO | https://sfo.gateway.truefoundry.ai |
| Dallas, Texas, United States (DFW) | GCP | US | DFW | https://dfw.gateway.truefoundry.ai |
| Toronto, Canada (YYZ) | GCP | CA | YYZ | https://yyz.gateway.truefoundry.ai |
| Sao Paulo, Brazil (GRU) | GCP | SA | GRU | https://gru.gateway.truefoundry.ai |
| London, United Kingdom (LHR) | AWS | EU | LHR | https://lhr.gateway.truefoundry.ai |
| Madrid, Spain (MAD) | GCP | EU | MAD | https://mad.gateway.truefoundry.ai |
| Gavle, Sweden (GVX) | Azure | EU | GVX | https://gvx.gateway.truefoundry.ai |
| Cape Town, South Africa (CPT) | AWS | AF | CPT | https://cpt.gateway.truefoundry.ai |
| Doha, Qatar (DIA) | GCP | US | DIA | https://dia.gateway.truefoundry.ai |
| Mumbai, India (BOM) | AWS | IN | BOM | https://bom.gateway.truefoundry.ai |
| Singapore, Singapore (SIN) | AWS | AP | SIN | https://sin.gateway.truefoundry.ai |
| Melbourne, Australia (MEL) | AWS | AU | MEL | https://mel.gateway.truefoundry.ai |
| Sydney, Australia (SYD) | AWS | AU | SYD | https://syd.gateway.truefoundry.ai |
Multi-regional Deployments
Multi-regional endpoints automatically route your requests to the closest healthy gateway within a specific geographic region. If all regional locations are unavailable, traffic is routed to the designated fallback regions.| Region | Multi-regional Endpoint | Primary Locations | Fallback Locations |
|---|---|---|---|
| United States | https://us.gateway.truefoundry.ai | North Virginia (ORF), San Francisco (SFO), Dallas (DFW) | Toronto, Canada (YYZ) |
| Europe | https://eu.gateway.truefoundry.ai | London (LHR), Madrid (MAD), Gavle (GVX) | Doha, Qatar (DIA) |
| Australia | https://au.gateway.truefoundry.ai | Sydney (SYD), Melbourne (MEL) | Singapore (SIN) |
Gateway Status Monitoring
To track the status of each gateway deployment and receive real-time updates on service availability, visit our status page: Gateway Status Page: status.truefoundry.com You can expand the AI Gateway section to see per-region uptime:
Subscribe to Status Updates
Stay informed about gateway availability by subscribing to status notifications:- Visit the Gateway Status Page
- Click the Get Updates button in the top right
- Choose your preferred notification method:
- Email notifications
- RSS Feed
- On a custom webhook
Connecting Your Private Models or MCP Servers to the Gateway
When you use the SAAS gateway to proxy requests to models or MCP servers hosted within your own infrastructure (e.g. inside a VPC), the gateway needs a network path to reach those endpoints. Depending on your security requirements and infrastructure setup, there are several approaches to establish this connectivity.Option 1: Reverse Tunnel Agent
Option 1: Reverse Tunnel Agent
Instead of exposing your model or MCP server publicly, you can run Setup flow
cloudflared inside your infrastructure and establish an outbound tunnel to a Truefoundry-managed public domain. This avoids opening inbound ports while still allowing the gateway to reach your private services.This is only available as part of our higher tier enterprise plans.
-
Raise a request with the Truefoundry team with the following details:
private_service_url: The URL of the private service that hosts your MCP server or model. You can also setup a load balancer in front of multiple MCP servers or models to route traffic as needed. Eg - For an mcp server running within the same kubernetes cluster as cloudflared, it would be something likehttp://mcp-server.default.svc.cluster.local:8080.
-
Truefoundry shares the following with you:
public_domain- The public domain that you can use to access your private service. For example<tenant-name>.private-endpoints.truefoundry.ai.auth_token- The token that you can use to runcloudflaredin your environment.
-
Run
cloudflaredin your environment:- VM
- Kubernetes (Helm)
-
You can now create the remote MCP server using
https://<tenant-name>.private-endpoints.truefoundry.ai/mcp. For detailed MCP server setup instructions, see Getting started with MCP servers.
Option 2: Private Link
Option 2: Private Link
For organizations that require fully private network connectivity with no public internet exposure, you can establish a Private Link connection between the Truefoundry gateway and your VPC. This creates a private, direct network path that never traverses the public internet.
Tradeoffs:
Private Link connections are region-specific. You will need to set up a Private Link in each cloud region where you need private connectivity to the gateway. Refer to the Regional Deployments table above to identify the regions and cloud providers available, then contact the Truefoundry team to get the specific service endpoint names for your selected regions.This is only available as part of our higher tier enterprise plans.
AWS PrivateLink
AWS PrivateLink
AWS PrivateLink allows you to privately connect your VPC to the Truefoundry gateway without exposing traffic to the public internet.Prerequisites:
- An AWS account with a VPC in a supported gateway region
- Appropriate IAM permissions to create VPC endpoints
- Contact the Truefoundry team to get the VPC Endpoint Service Name for your desired region.
- In the AWS Console, navigate to VPC → Endpoints → Create Endpoint.
- Select Find service by name and enter the service name provided by Truefoundry.
- Select the VPC and subnets where your model or MCP server is running.
- Attach a security group that allows traffic on the required ports.
- Create the endpoint and wait for the connection to be accepted by Truefoundry.
- Once active, use the VPC endpoint DNS name as the target for your model or MCP server configuration in the gateway.
GCP Private Service Connect
GCP Private Service Connect
GCP Private Service Connect enables private connectivity from your VPC to the Truefoundry gateway.Prerequisites:
- A GCP project with a VPC in a supported gateway region
- Appropriate IAM permissions to create Private Service Connect endpoints
- Contact the Truefoundry team to get the Service Attachment URI for your desired region.
- In the GCP Console, navigate to Network Services → Private Service Connect.
- Click Create Endpoint and select Published service.
- Enter the service attachment URI provided by Truefoundry.
- Select the VPC network and subnetwork where your model or MCP server is running.
- Assign an internal IP address for the endpoint.
- Create the endpoint and wait for the connection to be accepted by Truefoundry.
- Use the assigned internal IP address or configure a DNS entry to route traffic through the Private Service Connect endpoint.
Azure Private Link
Azure Private Link
Azure Private Link provides private connectivity from your VNet to the Truefoundry gateway.Prerequisites:
- An Azure subscription with a VNet in a supported gateway region
- Appropriate permissions to create private endpoints
- Contact the Truefoundry team to get the Private Link Service Resource ID for your desired region.
- In the Azure Portal, navigate to Private Link Center → Private Endpoints → Create.
- Select your subscription, resource group, and region.
- Under Resource, select Connect to an Azure resource by resource ID or alias and enter the resource ID provided by Truefoundry.
- Select the VNet and subnet where your model or MCP server is running.
- Configure DNS integration to automatically create a private DNS zone (recommended).
- Create the private endpoint and wait for the connection to be approved by Truefoundry.
- Use the private endpoint’s IP address or DNS name to route traffic.
- Most secure option — traffic never leaves the cloud provider’s private network.
- Requires setup in each region where you need connectivity.
- Involves coordination with the Truefoundry team for service endpoint provisioning.
- May incur additional cloud provider charges for Private Link / Private Service Connect endpoints and data transfer.
Option 3: Self-Host the Gateway
Option 3: Self-Host the Gateway
If none of the above options meet your requirements, you can self-host the Truefoundry gateway plane within your own infrastructure. In this setup, the gateway runs inside your VPC and has direct network access to your models and MCP servers — eliminating any need for public exposure or cross-network connectivity. Read more about self-hosting the gateway plane.
FAQ
What is the round trip latency to the SAAS gateway?
What is the round trip latency to the SAAS gateway?
Your client is automatically routed to the closest gateway region, so the round trip time (RTT) from your application to the gateway typically ranges from 20–50ms.If you are seeing higher latencies, please let us know and we will be happy to add another region closer to your use case.If you are self-hosting the gateway within your own infrastructure, the RTT from your application to the gateway will be on the order of ~1ms when both are running in the same cluster.