This guide defines the infrastructure, network, security and external-service prerequisites that must be provisioned and validated by the customer before the Cubyts Software Development and Governance platform can be deployed into the customer environment.

1.1  Intended Audience

Fulfilling these prerequisites typically requires coordination across several customer functions:

• Cloud Infrastructure – Kubernetes cluster provisioning, subscription/project setup, regional placement.

• Network – DNS, Application Gateway/ingress, NAT Gateway/egress, firewall and routing rules.

• Security – TLS certificates, secret management, allowlisting policy, logging standards.

• IAM – Access and permissions for the Cubyts deployment team, service identities and role assignments.

• Database – MongoDB Atlas provisioning, network access configuration and credentials.

• Application / SaaS Team – Email delivery configuration, LLM service enablement and business validation.

1.2  How to Use This Guide

Section 3 provides a consolidated summary suitable for tracking readiness. Section 4 explains each prerequisite in detail, including why Cubyts requires it and what must be validated. Section 7 provides a checklist to be completed before a deployment date is agreed. Section 8 lists the information the customer must hand over to the Cubyts deployment team.

Successful completion and validation of all mandatory prerequisites allows the Cubyts deployment team to proceed with the scheduled deployment.

2.  Deployment Architecture Overview

Cubyts is deployed as a containerised application into a customer-provided Kubernetes cluster. The customer owns and operates the surrounding platform — DNS, ingress, egress, certificates and external service subscriptions — while Cubyts owns the application workloads deployed onto that platform.

The expected end-to-end request flow is:

Internet / Users  →  DNS  →  Application Gateway / Ingress  →  Kubernetes Cluster  →  Cubyts Application Services  →  External Services (MongoDB Atlas, Model Provider, Email Provider)

Outbound application traffic from the Kubernetes environment should egress through the customer’s configured NAT Gateway where required, so that external service access originates from a known, stable public IP address. This is significant wherever the customer or the external provider enforces source-IP allowlisting.

3.  Prerequisites Summary

The table below summarises all prerequisites. Detailed requirements for each item are provided in Section 4. All items listed are mandatory unless explicitly stated otherwise.

4.  Detailed Infrastructure Prerequisites

Each prerequisite below is described in four parts: what must be provisioned or configured, why Cubyts requires it, key configuration requirements, and what must be validated before deployment.

4.1  Domain Names and DNS

What is required

Two publicly resolvable host names must be created under a customer-owned domain:

Why Cubyts requires it

The application and the authentication service are addressed independently. Users are redirected between the two during sign-in, so both host names must be resolvable and reachable by the same user population. Certificates, ingress routing and application configuration are all bound to these names, which is why they must be finalised before deployment rather than during it.

Configuration requirements

• Both records must resolve correctly from every network segment from which users will access Cubyts, including remote and VPN paths where applicable.

• Records should point to the Application Gateway or public endpoint that fronts the Kubernetes environment, in line with Section 4.3.

• All user-facing access must use HTTPS.

• DNS is customer-managed. Cubyts does not create, hold or delegate customer DNS records.

Pre-deployment validation

• Verify forward resolution of both names from a representative client network.

• Verify that resolved addresses correspond to the intended ingress endpoint.

4.2  Kubernetes Cluster

What is required

A Kubernetes cluster provisioned in the customer’s preferred or approved region, capable of running the Cubyts application workloads, with deployment access granted to the Cubyts deployment team.

Why Cubyts requires it

Cubyts is delivered as a set of containerised services. The Kubernetes cluster is the runtime platform for the entire application; no Cubyts component runs outside it apart from the external service dependencies described in Sections 4.5 to 4.8.

Configuration requirements

• The cluster should use a managed or autopilot operating mode where the selected Kubernetes platform supports one, so that node provisioning, patching and scaling remain the platform’s responsibility rather than an ongoing operational burden.

• Representative examples of such modes include Google Kubernetes Engine (GKE) Autopilot, Azure Kubernetes Service (AKS) Automatic, and Amazon Elastic Kubernetes Service (EKS) Auto Mode.

• Regional placement should satisfy the customer’s data residency requirements and should be chosen to minimise latency to MongoDB Atlas and the model provider endpoint.

• The cluster must permit the deployment of the Cubyts workloads under the customer’s admission control, image policy and pod security standards.

• Namespace, role bindings and deployment credentials for the Cubyts deployment team must be provisioned in advance, applying least privilege.

Pre-deployment validation

• Confirm the cluster is healthy and that workloads can be scheduled successfully.

• Confirm the Cubyts deployment team can authenticate to the cluster and deploy into the designated namespace.

• Confirm the cluster can pull container images from the agreed registry.

4.3  Application Gateway / Ingress

What is required

An Application Gateway configured as the external ingress layer for the Kubernetes environment, routing requests from the configured domains to the appropriate Kubernetes services.

Why Cubyts requires it

The Application Gateway is the single controlled entry point into the environment. It allows the customer to terminate TLS, apply perimeter security policy and expose only the intended services, while keeping the Kubernetes nodes themselves off the public internet.

Configuration requirements

The inbound ports supplied for this deployment are:

• Requests for both host names in Section 4.1 must be routed to the correct backend Kubernetes services.

• HTTPS/TLS termination should be configured at the Application Gateway in accordance with the customer’s security architecture, using the certificates described in Section 4.7.

• Health probes should be configured against the backend services so that the gateway removes unhealthy targets from rotation.

• Request and response timeout must be set to 600 seconds. A number of Cubyts APIs are long-running and will exceed the default gateway timeout, which on most Application Gateway implementations is between 20 and 60 seconds. Where the platform separates idle timeout from request timeout, the 600-second value applies to the request/response timeout on the backend setting or routing rule.

• The same timeout must be applied consistently across every layer in the request path — the gateway listener, the backend setting, any intervening load balancer or reverse proxy, and the Kubernetes ingress — since the shortest timeout in the chain governs.

• The gateway is customer-managed; the Kubernetes services it targets are application-managed.

Distinguishing external listener ports from backend service ports

Three distinct concerns are frequently conflated and should be recorded separately for this environment:

• External listener ports — the ports on which the Application Gateway accepts traffic from users. Standard browser access requires an HTTPS listener on TCP 443.

• Backend service ports — the ports on which the Kubernetes services accept traffic from the gateway. These are internal to the environment and need not match the listener ports. The Kubernetes cluster is exposed on port 80.

• TLS termination point — where the TLS session ends. Termination at the gateway is the common pattern; re-encryption to the backend may be required by the customer’s security standards.

Pre-deployment validation

• Confirm each configured listener accepts connections from a representative client network.

• Confirm a test request for each host name is routed through to the intended backend.

• Confirm TLS termination behaves as designed and presents the correct certificate.

• Confirm the 600-second timeout is applied and that a request exceeding the default timeout completes without the gateway returning a gateway-timeout error.

4.4  NAT Gateway / Egress

What is required

A NAT Gateway providing outbound connectivity for workloads running in the Kubernetes cluster, with application egress routed through it where required.

Why Cubyts requires it

Cubyts application services make outbound calls to external dependencies at runtime. Routing this traffic through a NAT Gateway gives those calls a stable, known source IP address, which is a prerequisite wherever external providers enforce source-IP allowlisting, and it avoids assigning public addresses to cluster nodes.

Outbound destinations include:

• Model provider endpoints (reasoning, LLM, SLM and embedding inference calls)

• MongoDB Atlas (database connectivity)

• Email provider endpoints (SMTP and SendGrid are supported as of now)

• Container registry and package sources required at deployment time

Configuration requirements

• Egress should be deterministic — the public IP address (or address set) used for outbound traffic must be known and stable.

• Sufficient NAT capacity should be allocated for the expected concurrent outbound connection volume, particularly for long-lived LLM and database connections.

• Egress firewall policy should permit the destinations listed above and in Section 5.

Pre-deployment validation

• Confirm outbound reachability to each external dependency from within the cluster.

4.5  MongoDB Atlas

What is required

A MongoDB Atlas cluster provisioned to the specification below in an approved region, with validated network connectivity between the Kubernetes cluster and the Atlas cluster.

Why Cubyts requires it

MongoDB Atlas is the primary datastore for the Cubyts application. The application cannot start successfully without authenticated, network-reachable database connectivity.

Configuration requirements

• Regional placement should satisfy data residency requirements and should be selected to keep latency between the cluster and Atlas low; co-location in the same region as the Kubernetes cluster is preferred.

• Network access must be configured using either IP allowlisting of the NAT Gateway public IP address or private connectivity (such as private endpoints or VPC/VNet peering), according to the customer’s architecture.

• A dedicated database user or service account must be created for the Cubyts application, scoped to the required databases with least-privilege roles.

• Backup, retention and restore policy remain customer-managed and should follow the customer’s data protection standards.

Pre-deployment validation

• Establish an authenticated TLS connection to the Atlas cluster from a pod running inside the Kubernetes cluster — not merely from an administrator workstation.

• Confirm the connection string, database name and user permissions are correct.

4.5.1  Voyage-3 Model API Key

What is required

A model API key for Voyage-3 must be created within MongoDB Atlas and the generated key details shared with the Cubyts deployment team.

Where to create it

In the MongoDB Atlas console, navigate to AI Models → Model API Keys and create a key for Voyage-3.

Why Cubyts requires it

Voyage-3 is used by Atlas-side AI capabilities within the Cubyts data layer. Without a valid model API key, those capabilities will not function even though the database connection itself is healthy.

Pre-deployment validation

• Confirm the Voyage-3 model API key has been generated and is active.

4.6  LLM and SLM Model Provider

What is required

A model provider endpoint accessible over HTTPS from the Kubernetes environment, with four model deployments provisioned: a reasoning model, a large language model (LLM), a small language model (SLM) and an embedding model.

The reasoning, LLM and SLM tiers depend on the cloud platform selected by the customer. The embedding tier does not:

Why Cubyts requires it

Cubyts routes different classes of request to different models. The reasoning model handles the most reasoning-intensive requests, the LLM handles general generation, the SLM handles lighter high-volume requests, and the embedding model generates vector representations used for retrieval. All four are required — provisioning only some of them will leave part of the product non-functional. On Azure the reasoning and LLM tiers resolve to the same deployment, so a single GPT-5.1 deployment serves both. The embedding tier is not platform-specific: text-embedding-3-small and Voyage are used on every platform, so both remain a dependency on GCP and AWS deployments.

Configuration requirements

• The model provider endpoint must be reachable over HTTPS from the Kubernetes environment.

• All model deployments must be provisioned before application configuration begins, as their deployment identifiers form part of the application configuration.

• Authentication credentials or identity configuration must be made available through the customer’s approved secret-management process.

• Network restrictions, firewall rules, private endpoints and allowlists must permit the required connectivity from the cluster egress path described in Section 4.4.

• The provider subscription, resource and model deployments are customer-managed; consumption of them is application-managed.

Pre-deployment validation

• Successfully invoke each of the model deployments from within the deployment environment and confirm a valid response is returned.

• Confirm the deployment names to be used in application configuration and record them for handover (Section 8).

4.6.1  Embedding Model Deployment Details

In addition to provisioning the embedding model deployment, the following details must be shared with the Cubyts deployment team:

4.7  SSL/TLS Certificates

What is required

Valid SSL/TLS certificates covering both host names:

• app-cubyts.<customer-domain>

• id-cubyts.<customer-domain>

Why Cubyts requires it

All user-facing traffic is served over HTTPS. Without valid certificates covering both names, users will encounter browser trust warnings and the sign-in redirect between the application and the authentication service will fail in most modern browsers.

Configuration requirements

• Certificates must cover both required DNS names, whether issued individually, as a multi-SAN certificate, or as a wildcard covering the parent domain.

• Certificates should be supplied in a format compatible with the selected Application Gateway or load-balancing solution, or provisioned through the customer’s standard certificate management process.

Pre-deployment validation

• Confirm the certificate chain validates cleanly in a standard browser with no warnings.

• Confirm the certificate covers both host names and record the expiry date.

• Confirm and document the owner responsible for certificate renewal, along with the renewal method and lead time.

4.8  Email Provider

What is required

One supported email delivery mechanism must be provided by the customer. Cubyts currently supports:

• SMTP

• SendGrid

Why Cubyts requires it

Cubyts sends transactional email such as account, authentication and notification messages. Without a configured delivery mechanism these messages cannot be sent and parts of the user journey — including account onboarding — will not complete.

4.8.1  SMTP configuration categories

The following configuration items must be supplied by the customer. Values are intentionally not stated in this document.

4.8.2  SendGrid configuration categories

• API access and authentication, provisioned with least-privilege send permissions.

• A verified sender identity or authenticated sending domain.

• Network connectivity from the Kubernetes cluster to the SendGrid API endpoints over HTTPS, permitted by egress policy.

Pre-deployment validation

• Send a test message through the chosen mechanism and confirm delivery to an internal recipient.

• Confirm the message is not classified as spam and that sender authentication passes.

5.  Network and Connectivity Requirements

The following flows must be permitted by the customer’s network and firewall policy. This table consolidates the connectivity implied by Section 4 and should be used as the reference when raising firewall change requests.

5.1  Note on HTTP (TCP 80)

Port 80 is listed because it appears in the supplied ingress requirements, but it should not be read as a requirement to serve application content over unencrypted HTTP. Two distinct patterns are possible, and the customer’s security architecture determines which applies:

• Redirect pattern — TCP 80 is exposed solely to issue an HTTP-to-HTTPS redirect. No application content is served over the unencrypted listener. This is the common enterprise pattern.

• HTTPS-only pattern — TCP 80 is not publicly exposed at all, and users are expected to reach the service over HTTPS directly. This is acceptable to Cubyts, provided users are directed to the HTTPS URLs.

In either case, application traffic itself is served over HTTPS. TCP 80 need not be exposed publicly.

5.2  Egress Considerations

• All outbound flows in the table above should traverse the NAT Gateway described in Section 4.4 where the customer’s architecture requires it.

• Where destination allowlisting is enforced by egress policy, the external service host names or address ranges must be permitted before connectivity testing.

• Where the external service enforces source-IP allowlisting, the NAT Gateway public IP must be registered with that service.

6.  Security Requirements

This section separates security items that are required for the deployment to function from those that are recommended enterprise practice. Recommended items should be assessed against the customer’s own security standards, which take precedence.

6.1  Required for Deployment

• TLS/HTTPS must be used for all external communication, both user-facing and outbound to external services.

• Secrets must not be stored in source code, configuration files committed to source control, or container images.

• Network access must be permitted for each flow documented in Section 5; otherwise the application will fail to start or will fail at runtime.

6.2  Recommended Practice

The following are recommended rather than deployment-blocking:

• Apply least-privilege access to service accounts, database users, cluster role bindings and model provider credentials.

• Restrict network access to the required destinations and ports only, rather than permitting broad egress.

• Avoid public exposure of Kubernetes nodes; expose the environment only through the Application Gateway.

• Use IP allowlisting or private connectivity for external services wherever the provider supports it.

• Enable audit logging and monitoring in line with the customer’s security standards, covering the ingress layer, the cluster and database access.

• Rotate credentials on a defined schedule and record ownership for each secret.

• Apply the customer’s standard vulnerability scanning and image policy to the deployed workloads.

7.  Pre-Deployment Validation Checklist

This checklist should be completed and returned to the Cubyts deployment team before a deployment date is scheduled.

8.  Information to Be Provided to the Cubyts Deployment Team

Once the prerequisites are complete, the following information should be provided to the Cubyts deployment team so that application configuration can be finalised.

9.  Deployment Readiness

Deployment can be scheduled once all mandatory prerequisites in Section 3 have been completed, the validation checklist in Section 7 has been returned, and the information in Section 8 has been provided to the Cubyts deployment team.

Any deviation from the architecture described in this document — including alternative ingress models, differing egress arrangements, substitution of external service providers, or changes to the agreed host names — should be reviewed with the Cubyts deployment and architecture team before implementation, so that the impact on configuration and deployment sequencing can be assessed.