Private Does Not Mean Effortless

For the private Opencode and quantized-GLM configuration, the central question is what “inside the network” actually protects and what responsibilities it creates. The value of self-hosting is stronger control over code, prompts, and inference state; the cost is that the organization must secure shared resources, operate the serving path, and maintain enough capacity for the workload. This distinction lets a decision-maker judge sovereignty and speed as operating properties rather than as slogans.

A cloud API and a private cluster move different risks across the boundary. The cloud path places inference behind a vendor endpoint and transfers some operational responsibility outward. The private path brings the model and serving engine inside the corporate environment, but it does not make every internal process trustworthy by default. Once several developers or departments share a private resource, the organization has an internal security problem to solve as well as an infrastructure problem.

The trust boundary moves inward

The cloud configuration sends source code, database schemas, logs, repository context, and prompts to the provider’s service as part of the agent loop. The enterprise may have contractual, technical, or regulatory controls around that transfer, but the inference data crosses an external boundary. The provider manages the service’s physical hardware and much of its serving operation. The enterprise retains responsibility for deciding what data is sent, how access is authorized, and whether the arrangement satisfies its governance requirements.

The private configuration keeps inference traffic within the corporate intranet. That can be decisive for proprietary software or sensitive schemas, because the organization does not need to transmit those materials to a third-party model endpoint for every agent turn. It also removes dependence on vendor request and token quotas up to the serving capacity the organization has provisioned. These are real advantages, but they describe the location and ownership of the boundary, not an automatic guarantee of confidentiality or availability.

A shared private cluster has its own paths for information to persist or cross tenants. Model requests can leave traces in host logs. Key-value prefixes can be reused by the serving system for performance, which means the isolation boundary must include cached context as well as the original request. Multiple departments may share GPU memory and host infrastructure. If authentication identifies only the cluster rather than the developer, an operator may be unable to establish which tenant may retrieve or inspect a piece of state. The private network can therefore reduce external exposure while increasing the importance of internal separation.

The controls described for the evaluated deployment operate at several layers. Hardware-level isolation separates compute and memory resources. Network and container isolation place workloads in dedicated namespaces with restrictive traffic policies. Mutual TLS protects and authenticates connections in transit. Developer-specific tokens and role-based access control constrain which caller can submit or access a request. Together, these controls aim to keep the performance mechanisms of shared serving—cache reuse, persistent logs, and common endpoints—from becoming accidental data channels.