Connecting Visual Builder Studio to a Private ORDS Endpoint

Introduction

Visual Builder Studio needs an HTTPS endpoint when it creates a service connection. That requirement is simple enough until the service it needs to call is deliberately private.

In many customer environments, Oracle REST Data Services (ORDS) is deployed behind private networking. That is usually the right posture. ORDS may front database APIs, application data, or internal integration services. Making that endpoint public just because VBS needs HTTPS is not the answer.

The practical pattern is to keep ORDS private and place a controlled public HTTPS ingress layer in front of it. In OCI, that ingress layer is usually one of two things: an API Gateway or a Load Balancer.

This post describes the pattern, when each option fits, and where the real-world project friction tends to appear.

The Problem

VBS needs to call an HTTPS endpoint. A private ORDS endpoint is not directly reachable from VBS. That creates a gap between the public URL VBS expects and the private network boundary around ORDS.

There are two important constraints to hold at the same time:

• VBS needs a reachable HTTPS URL.
• ORDS should remain private.

The job of the ingress layer is to satisfy the first constraint without violating the second.

The Pattern

Put a public HTTPS front door in front of the private ORDS endpoint. VBS calls the public HTTPS URL. The ingress layer forwards the request to ORDS over private network paths.

The public component is the proxying layer, not ORDS itself.

Two Practical Options

In the customer projects that drove this pattern, the answer came down to the customer network shape and operational requirements.

• API Gateway: cleaner when the customer has a compatible regional subnet and can use the generated API Gateway HTTPS hostname.
• Load Balancer: more flexible when the customer needs custom DNS, customer-managed certificates, or has legacy subnet constraints.

The choice is usually not architectural taste. It is the shape of the customer environment.

Why This Is Better Than Making ORDS Public

This pattern does not eliminate public exposure. It moves public exposure to a component that is designed to be a public ingress point.

That distinction matters. A bare ORDS endpoint, MCP server, or internal service is usually built to serve application traffic, not to be the customer’s public security control plane. API Gateway and Load Balancer are better places to terminate HTTPS, enforce routing policy, centralize observability, and limit what the internet can actually reach.

The security goal is not simply “make something public.” The goal is to expose the smallest useful HTTPS surface and keep the backend service private.

At minimum, the public listener should be treated as a security boundary and designed accordingly:

• Terminate HTTPS with a certificate that matches the public hostname.
• Expose only the paths that VBS or the consuming client actually requires.
• Forward only to the intended private backend and port.
• Use network security groups, security lists, or firewall policy so ORDS is reachable from the ingress layer, not from the public internet.
• Enable logging and monitoring at the ingress layer so access patterns and failures are visible.
• Apply authentication, authorization, request validation, rate limiting, or WAF policy where the customer security model requires it.

For the VBS-to-ORDS case, one useful control is source IP restriction. Oracle publishes the public IP addresses for VB Studio by OCI data center. A customer can use that documented regional source address as part of the security policy at the API Gateway, Load Balancer, WAF, firewall, or network layer so the ORDS-facing endpoint only accepts traffic from the expected VB Studio source.

The same idea applies to other private services and backends. If the consuming system has a documented and stable source range, use the ingress layer to enforce that restriction. Do not rely on a bare ORDS or MCP server to be the only public-facing control point when a purpose-built gateway, load balancer, or edge policy can narrow the exposed surface first.

Because published source addresses can change, treat the documentation as an operational dependency. Validate the current address for the relevant region before creating or troubleshooting allowlist rules.

In other words, API Gateway or Load Balancer does not make the backend risk disappear. It gives the customer a more appropriate place to manage that risk than the ORDS or MCP server itself.

Option 1: API Gateway

API Gateway is the cleanest path when the OCI networking requirements fit. It provides a public HTTPS endpoint out of the box, using an OCI-generated gateway hostname. If that hostname is acceptable to the customer and the backend route can reach private ORDS, this can be a quick solution.

When to use API Gateway

• The customer has a regional subnet available for API Gateway.
• The generated API Gateway HTTPS hostname is acceptable.
• The ORDS backend is reachable from the gateway route.
• The requirement is straightforward HTTP request routing to ORDS.

High-level steps

1. Create a public API Gateway in a regional subnet.
2. Create a deployment path, for example /ords.
3. Add a route that forwards to the private ORDS backend.
4. Confirm the gateway can reach ORDS over the private network path.
5. Use the generated API Gateway HTTPS URL in the VBS service connection.

The API Gateway URL becomes the VBS service connection target, while the gateway route points to the private ORDS backend.

What this looked like in one customer project

In the easier customer case, the environment supported API Gateway. We created the backend route to ORDS, passed the request through, tested the endpoint from VBS, and the pattern worked as expected.

That is the happy path: route it through, test it, move on.

The API Gateway Catch

API Gateway requires a regional subnet. That detail matters in older OCI environments.

One customer was using a legacy subnet design where subnets were availability-domain-specific rather than regional. That older subnet shape was not compatible with API Gateway. In that environment, the clean API Gateway option was blocked unless the customer changed the network design.

At that point, the architecture decision was made by the network. The team needed a different public HTTPS front door.

Option 2: Load Balancer

A public Load Balancer gives more flexibility. It can support customer-owned DNS names, customer certificate processes, and network layouts where API Gateway does not fit.

The tradeoff is that the customer owns more of the setup.

When to use Load Balancer

• API Gateway subnet requirements do not fit the customer environment.
• The customer requires a custom public DNS name.
• The customer must use an internally approved HTTPS certificate process.
• The customer wants more direct control over listeners, backend sets, or ingress review.

High-level steps

1. Create a public Load Balancer.
2. Add ORDS as a private backend.
3. Create an HTTPS listener on port 443.
4. Attach a certificate that matches the public DNS name.
5. Point DNS at the Load Balancer.
6. Use the DNS-backed HTTPS URL in the VBS service connection.

The customer DNS name becomes the VBS service connection target, while the Load Balancer listener forwards to the private ORDS backend set.

What this looked like in one customer project

For the customer with legacy AD-specific subnets, Load Balancer was the practical path. The routing itself was not the difficult part. The real work was organizational: obtaining a DNS entry, getting the associated HTTPS certificate, and moving the request through the right internal review paths.

Sometimes the routing is easy and the process is the project.

Where the Work Really Shows Up

The technical pattern is simple enough to describe. The customer execution can still take time because the public HTTPS entry point crosses team boundaries.

• Who can create the public DNS record?
• Who can issue or approve the HTTPS certificate?
• Who owns review of the public ingress path?
• Which team updates network security groups, route rules, or firewalls?
• Who validates that only the gateway or load balancer is public, while ORDS remains private?

Those questions are worth asking early. They often determine which pattern is feasible on the project timeline.

Beyond ORDS

This is not only an ORDS pattern. It is a general way to give controlled public HTTPS access to private services.

• Private REST services
• Internal integration endpoints
• Private MCP servers

The MCP case has one important caveat. MCP over HTTP commonly relies on Streamable HTTP or HTTP plus Server-Sent Events. That can work through an ingress layer, but long-running calls need to keep the response stream active.

For API Gateway, test streaming behavior explicitly. If an MCP call may remain idle for a long time, send progress or keepalive events regularly, or consider a Load Balancer configuration where idle timeout behavior can be tuned for the use case.

Decision Guide

Start with API Gateway when:

• A regional subnet is available.
• The generated API Gateway hostname is acceptable.
• Simple HTTPS pass-through routing is enough.

Use Load Balancer when:

• API Gateway subnet requirements do not fit.
• The customer requires custom DNS.
• The customer has a required certificate process.
• The ingress path needs more operational control.

In both cases, the principle is the same: expose a controlled HTTPS front door, not the private ORDS service.

Final Thoughts

VBS needing HTTPS does not mean ORDS should become public.

Keep ORDS private. Put a controlled HTTPS ingress layer in front of it. Choose API Gateway when the customer network lets you, especially for a quick public HTTPS endpoint to a private backend. Choose Load Balancer when DNS, certificates, or legacy network constraints require more flexibility.

The pattern is simple. The useful part is knowing where it stops being a routing problem and starts being a customer environment problem.