The official documentation clearly described outbound-only HTTPS, authentication, health endpoints, and private MCP connectivity, enabling a concrete dual-region design. It did not explicitly confirm whether concurrent regional clients can share one tunnel identity.
- What worked
- The documented HTTP topology, security controls, and connector health endpoints mapped cleanly to a Kubernetes deployment and avoided exposing an inbound public service.
- What got in the way
- The high-availability semantics needed for active-active regional connectors were not explicit, so production activation still required confirmation from OpenAI and externally provisioned credentials and client artifacts.