Private endpoints are a specialized deployment choice
Oracle Visual Builder can be configured with private endpoint access only, placing the instance in a private subnet in your Virtual Cloud Network (VCN). In that configuration, the instance accepts connections from the specified private VCN, peered VCNs, and on-premises networks connected to that VCN. This is valuable when every consumer and dependent service is intentionally designed to operate through private networking.
Private endpoints should not be the default choice for every security requirement. They introduce important constraints on scalability, regional resilience, networking, and operational change. They also change how developers, end users, integrations, DNS, and operations teams reach the instance. Before choosing this model, confirm that private-only reachability is a genuine requirement and that the networking team can own the required configuration and ongoing operations.
For many use cases, a publicly reachable Visual Builder instance with access restricted to approved IP addresses and VCNs is simpler to operate while still applying network controls. Evaluate that option first when the goal is controlled access—not complete private-only connectivity.
Confirm that private endpoints are supported for your service type
This article applies to standalone Oracle Visual Builder instances that support private-endpoint access. Private endpoints are not currently supported for Visual Builder instances enabled in Oracle Integration 3. If you use embedded Visual Builder in Oracle Integration 3, do not plan on enabling or converting the instance to private-endpoint access.
Before planning a private-endpoint deployment, confirm whether your instance is standalone Oracle Visual Builder or Visual Builder enabled in Oracle Integration 3, and review the network-access options supported for that service. A disabled or unavailable private-endpoint option can indicate that the configuration is not supported, rather than a setting that should be enabled.
What to plan before enabling a private endpoint
Private endpoint access is a networking design, not simply an instance setting. It requires coordination across application, cloud networking, and DevOps teams. Before provisioning or converting an instance, plan for:
- A VCN in the relevant region and a private subnet that uses the required DHCP configuration.
- Ensure that the administrator configuring the private endpoint has the required OCI IAM permissions for the Visual Builder instance, VCN, subnet, private IPs, VNICs, and any network security groups. See IAM Policies Required to Manage Private Endpoints.
- Outbound connectivity: configure a NAT Gateway so the private subnet can access
static.oracle.com, which Visual Builder requires when you stage, publish, or use applications. Also allow the Component Exchange URL shown on the Visual Builder instance’s Tenant Administration page; this is required for staging and publishing. Configure the required Service Gateway access to the identity service. - DNS, security-list, and network-security-group (NSG) ownership. NSG and security-list rules combine to control ingress and egress.
- How developers, users, integrations, and any on-premises callers will reach the VCN.
- Whether every external service accessed through a Service Connection is reachable from the private subnet.
- Every required network flow and address range. Do not assume that allowing only the displayed private endpoint IP will cover all required inbound and outbound traffic. Confirm the complete allowlist and egress requirements with your cloud networking or support team before implementation.
Treat these as cross-team implementation requirements. Involve your cloud networking and DevOps teams before committing an environment to private-only access.
Limitations that affect the decision
The following limitations affect the lifecycle of a private-endpoint-enabled Visual Builder instance:
- The private IP address cannot be changed after provisioning, whether it was assigned automatically or specified during setup.
- You can attach up to five NSGs. The NSG configuration can be changed after provisioning.
- You cannot change the node count for a private-endpoint-enabled instance. This configuration does not support node-count changes.
- When converting an existing public instance, the instance cannot have more than one node. An instance created in an IDCS domain also cannot be converted if the IDCS domain’s home region differs from the currently selected region.
- Changing network access cannot be combined with other instance updates.
- Accessing an ATP database in the same VCN and subnet is supported. For a database in a different VCN, private DNS views must be configured in the VCNs.
- Oracle Visual Builder Studio (VBS) operates in the public IP space and does not support private-endpoint access. However, VBS can deploy to a Visual Builder instance in a private network, and builds or CI/CD can run from compute resources in a private network. When private infrastructure interacts with VBS, allow the VBS service IP address for the region where the VBS instance is hosted.
- A private-endpoint Visual Builder instance cannot be configured for high availability or disaster recovery (HA/DR) with another region. For example, a private-endpoint instance in Ashburn cannot be paired with an instance in Phoenix for cross-region HA/DR.
- A private-endpoint instance can be created only in the home region of its Identity Domain. For example, if the Identity Domain’s home region is Phoenix, create the instance while working in the Phoenix region.
- The private subnet needs a NAT Gateway and the required Service Gateway connectivity; these are mandatory network dependencies, not optional hardening measures.
Taken together, these restrictions can make a private endpoint a poor fit when you need node-count changes, cross-region resilience, simple client connectivity, or frequent infrastructure changes. Private endpoints are best suited to deployments where private-only access is essential and the network topology, regional strategy, and operational constraints have been agreed in advance.
Consider alternatives that meet the actual requirement
Restrict a public endpoint with an allowlist
If the requirement is to limit who can reach Visual Builder, rather than to make the service private-only, consider Secure access from allowed IPs and VCNs only. This option restricts access to specified IP addresses and VCNs, and can avoid the operational overhead of making every client path privately reachable.
Confirm that the proposed allowlist covers all legitimate developer, user, automation, and integration traffic, including disaster-recovery and support scenarios.
Do not use a public load balancer to work around private-only access
Oracle documentation describes a load-balancer pattern in front of a private endpoint. However, this is not a recommended general alternative: placing a public load balancer in front of the instance defeats the purpose of choosing private-only access.
If your requirement includes a publicly reachable entry point, evaluate allowlisted public access instead of using private-endpoint access as a workaround. Discuss exceptional architectures with your cloud networking and DevOps teams.
Decision guide: start with the simplest secure access model
Use a private endpoint only when all of the following are true:
- Private-only network access is a hard requirement.
- The VCN, DNS, routing, egress, and security controls are ready.
- The operational limits on IP changes, scaling, HA/DR, and conversion are acceptable.
- Networking and DevOps owners are available for initial setup and future changes.
Otherwise, prefer allowlisted public access when you need controlled access but do not need every connection path to remain private.
Before you proceed
Do not choose private-endpoint access solely because it appears to be the most restrictive network option. Review the current Oracle documentation, assess the limitations above, and engage your cloud networking and DevOps teams early. They can help determine whether private-only access or allowlisted public access best matches your connectivity, security, resilience, and operational requirements.