Skip to content

Deployment options

Nomain runs in whichever cloud posture fits your security and data-residency needs. The product is the same in every case. What changes is where it runs and who operates the infrastructure.

There are four ways to run Nomain:

ModelWhere it runsWho operates itFoundation modelsBest for
Nomain CloudNomain's multi-tenant SaaS on AzureNomainAzure OpenAI (Nomain-managed)Fastest start, evaluations, teams without a cloud platform team
BYOC on AzureYour own Azure subscriptionYouAzure OpenAI (in your subscription)Risk-sensitive estates that must keep data in their own Azure tenant
BYOC on AWSYour own AWS accountYouAmazon Bedrock (in your account)AWS-first organizations; available through the AWS Marketplace
On-premiseYour own Kubernetes cluster (optionally Azure Arc managed)YouYour approved model endpointAir-gapped or on-premise estates that cannot use public cloud

Not sure which to pick?

A typical path is to start on Nomain Cloud for an evaluation, then move to BYOC for production if your data-residency or compliance requirements call for it. The product experience is identical across all four.

What "BYOC" means

BYOC stands for Bring Your Own Cloud. The entire Nomain application stack runs inside your own cloud account or cluster. There is no Nomain-operated data plane. Your source code, the analysis it produces (the abstract syntax trees and knowledge graph), your embeddings, and your chat content never leave your perimeter.

Three properties hold across every BYOC deployment:

  1. Your data never leaves your account. Databases, object storage, and model inference all stay inside the region and account you choose.
  2. No Nomain operator has runtime access. The initial deploy uses a principal you own. Nomain support receives logs or traces only on your request, through a controlled export.
  3. No static credentials. Every service authenticates with short-lived, automatically rotated identity tokens (Azure Workload Identity, or AWS IAM roles and IAM Database Authentication).

The only outbound calls to Nomain

A BYOC deployment makes a small number of metadata-only calls back to the Nomain Customers API, authenticated with a machine-to-machine ClientId and Secret issued at onboarding:

CallPurpose
License validationOn startup and at a refresh interval. Returns a signed JWT carrying your contract tier and expiry.
HeartbeatA small liveness signal so Nomain can tell that a deployment is healthy and reflect tenant state in the admin portal. Also carries an aggregate, content-free chat-health summary (no chat content or PII).
FeedbackWhen a user submits feedback from the webapp, it is sent so the product team can catch regressions. Opt-out per tenant.
Telemetry (Azure)Aggregated usage signals (job counts, latencies, error-rate buckets) for product analytics. Aggregates only.

Every one of these carries license, tenant, or aggregated-metric metadata only. No customer code, AST, embeddings, or chat content ever crosses this boundary. See Security & compliance for the full posture.

Sign-in is the same everywhere

In every model, end-user sign-in is delegated to your identity provider through WorkOS AuthKit, with WorkOS Connect bridging Okta, Microsoft Entra ID, Auth0, or Keycloak. There are no app-level integration changes, and your users keep their normal single sign-on experience. See Single sign-on.

Running a pilot

A typical pilot runs on two parallel tracks so nothing waits on anything else:

  • Deployment track (your cloud/IT team): line up the prerequisites for your chosen model ahead of the kick-off. Each deployment page below lists exactly what to provision.
  • Code track (your mainframe experts): gather the target system's source in Git, any relevant documentation (a glossary of standard variables, business-process notes), and the scheduler configuration (Control-M or equivalent).

Reviewing the relevant deployment page before kick-off lets both tracks line up their prerequisites in parallel.

Where to go next