Skip to main content

​
NomadicML on GCP

This page describes how the video analysis platform is deployed in Google Cloud, how data moves through it on the read and write paths, and how client applications reach it privately over Private Service Connect.
Looking to run the whole stack inside your own project instead? See Self-Hosted VPC Setup, which is available today for both GCP and AWS. For the AWS equivalent of this page, see NomadicML on AWS.

​
General Architecture

The platform runs inside a NomadicML-managed VPC network. Client applications never reach it over the public internet. They create a Private Service Connect endpoint in their own VPC, which resolves to an internal IP address and connects to a service attachment we publish. Everything behind that service attachment (load balancer, application tier, storage and inference) runs in private subnets with no external IP address.

​
Key Components

Service attachment

The published service a client connects to. It carries a consumer accept list naming which projects may connect, and a dedicated NAT subnet that translates consumer traffic inside our network.

Internal load balancer

No external IP. Fronts the application tier and is the backend the service attachment targets.

Application tier

Compute Engine backends in managed instance groups. The API service handles authentication, upload and result retrieval. Analysis workers claim queued jobs on a lease and run the analysis out of band.

Data services

Cloud Storage for video and derived artifacts, Firestore for job and analysis metadata, Memorystore for progress streams, Vertex AI for model inference. Reached over private paths, so no traffic traverses the public internet.

​
Read Path

A client asks for job status, analysis results, or the media behind them. The request enters through the PSC endpoint and is served from the two data stores inside the VPC network.

​
Read Path Flow

  1. Client application sends the request to the PSC endpoint in its own subnet, reached by an internal IP address and the DNS name created in its Cloud DNS zone.
  2. Service attachment accepts the connection from a project on the accept list and forwards it to the internal load balancer.
  3. API service authenticates the API key and resolves what was asked for: job status, an analysis document, or media.
  4. Firestore and Cloud Storage return the analysis document and the video or derived artifacts behind it. Results travel back on the connection the client already opened.

​
Write Path

Upload and analysis are decoupled, so a long-running analysis never holds a client connection open.

​
Write Path Flow

The API service writes video to Cloud Storage synchronously and records a job document in Firestore, then returns. The upload is complete at that point. Analysis workers claim the queued job on a lease, marking it in progress so no two workers take the same job, and call Vertex AI for inference. As they run they publish progress events to a Memorystore stream, which the API service relays to the client as server-sent events. Finished results are written back to Firestore and derived artifacts to Cloud Storage, where the read path picks them up.

​
Private Connectivity

Private Service Connect is two resources, one in each project. NomadicML publishes the service attachment; the client creates an endpoint in their own VPC network. Traffic between them stays on Google’s network.
  • The connection is one-way. The client initiates. NomadicML cannot reach back into the client network, so exposure is limited to the single published service rather than a route between two networks.
  • Consumption is controlled by an accept list. The service attachment names which consumer projects may connect. With manual acceptance, each connection request is approved individually.
  • No address-space coordination. A dedicated NAT subnet in our network translates consumer traffic, so the two networks are IP independent and overlapping ranges are irrelevant.
  • DNS is created for you. Where we publish a DNS domain with the attachment, the endpoint’s DNS records are created automatically in your Cloud DNS zone, so your SDK resolves it without configuration changes.
  • Nothing needs an external IP. Your side needs no Cloud NAT or external address for this path, and our load balancer is internal.
The equivalent primitive on AWS is PrivateLink and on Azure is Private Link Service. All three follow the same publish-and-consume shape.
The managed platform runs in Google Cloud today. What is still in development is publishing it as a Private Service Connect service attachment, so the private connectivity path described above is not yet available for self-service. Talk to us about timelines. The self-hosted VPC deployment is available now.

​
Deployment Models

Three options, differing in whose project holds the application and whose holds the data.

Fully managed

NomadicML runs both the application and the data services in our GCP project. Clients connect over Private Service Connect. Lowest operational burden.

In your VPC

The entire stack deploys into your GCP project, with Compute Engine backends, private subnets, and no public ingress. Video never leaves your project and we hold no credentials into it.

Hybrid

We run the application; you supply the Cloud Storage buckets. Access is granted by workload identity federation rather than stored service account keys.
Setup steps for the in-VPC model are covered in Self-Hosted VPC Setup.

​
What You Provide

For a Private Service Connect connection to the managed service, the client side needs very little.
Deployments are configured per customer. Contact your NomadicML representative with your GCP project ID, target region, and preferred deployment model, and we will publish the service attachment and share its URI.