API Connect

API Connect

Join this online group to communicate across IBM product users and experts by sharing advice and best practices with peers and staying up to date regarding product enhancements.


#API Connect
#Applicationintegration
#APIConnect
 View Only

Publishing AI Assets in IBM DataPower Interact Gateway: Inside the idig-broker

By Shreyas Raviprakash posted 08/07/26 10:29 AM

  

How a click on "Publish" in API Studio turns into running pods on Kubernetes — and the TLS plumbing that keeps every hop of that journey secure.

Authors: Shreyas Raviprakash Technical contributors: Michael O'Sullivan, Olajuwon Owoseni, Niraimathi Gunalan

Our teammates have already written about the AI View in API Studio, about LLM Provider, and about the IDIG Operator's two-tier architecture in the IBM DataPower Interact Gateway (IDIG) Standalone offering. Those posts cover the authoring experience and the cluster lifecycle end of things. This post fills in the piece that sits between them: what actually happens the moment someone hits Publish, and how an authored MCP server or LLM provider becomes a real, invokable workload sitting behind IDIG.

That "in-between" is owned by a small backend service we call idig-broker. It doesn't have a UI, nobody demos it, and it's the kind of service that's easy to take for granted. So consider this the broker's turn in the spotlight.

What actually gets published

When someone builds an MCP server or registers an LLM provider in the AI View, they're really authoring a small graph of related resources, not a single object. On the cluster, that graph is represented as a handful of Kubernetes custom resources:

  • Runtime — the parent Kubernetes resource, and the same kind regardless of what it's running. It doesn't do anything user-visible on its own; its job is to be the owner of an actual running asset and to represent "this thing, deployed."
  • MCPTools — nested under MCPServer's Runtime. These are the individual tool definitions an agent actually calls.
  • APIs — nested under LLMProvider's Runtime. These describe the operations exposed against the registered model provider.
  • HTTPRoute — the piece that tells the gateway how to reach the running workload.

The reason Runtime exists as its own object rather than folding that concept into MCPServer and LLMProvider directly is ownership. Both asset kinds need identical treatment once they're running — replicas, autoscaling behaviour, teardown when unpublished — and putting that shared behaviour on a common parent means the operator only has to reconcile one lifecycle, not two slightly different ones.

Ownership Tree

The publish flow: Studio to cluster

Here's how the call flow works if you trace it. The whole publish path is a chain of plain REST calls.

  1. An author hits Publish on an MCP server or LLM provider in API Studio.
  2. Studio calls idig-broker directly, which resolves the target runtime and builds the CR payloads for Runtime, APIs, MCPTools, and HTTPRoute.
  3. idig-broker talks to the Kubernetes API server to create or update those resources.
  4. The result — success or a validation error — travels back up the same chain to Studio.

idig-broker itself is beautifully boring: it's stateless, it holds no session or job state between requests, and every hop is a REST call that either succeeds or fails within the request. There's no eventual-consistency gap where Studio says "published" but the cluster hasn't caught up yet — by the time the response reaches the author, the CRs already exist (or the request already failed with a reason why).

Publish Sequence

From CR to running workload

Once the CRs land, it's the idig-gateway-operator that takes over. It watches Runtime, MCPTools, APIs, and HTTPRoute resources, and reconciles them into an actual Deployment and Service — sized according to a replica and autoscaling configuration.

That autoscaling configuration is itself bootstrapped as a custom resource, and the pattern the broker uses to set it up is worth calling out because it's a good example of writing idempotent Kubernetes automation: on startup, check whether a default autoscale configuration already exists; if it does, leave it alone; if it doesn't, create one.

Nothing exotic — a get, a 404 check, a create — but that's the whole point. Bootstrap logic that runs on every service start needs to be safe to run a thousand times, and "check, then create" is the simplest way to get there without a lock or a migration step.

Today, scaling is a straightforward replica count rather than request-driven scale-to-zero: a Runtime gets sized according to its autoscale config, and the operator keeps the Deployment converged to that spec.

Getting traffic to the pods

A running pod is only useful if something can reach it. That's where HTTPRoute comes in — a single route per Runtime that tells the Nano Gateway which Service backs the published asset and under which path or host to expose it, regardless of whether that Runtime is running an MCPServer or an LLMProvider. The idig-gateway-operator wires this up as part of reconciling the Runtime: once the workload exists, the matching HTTPRoute is created (or updated) so the gateway's routing table stays in lockstep with what's actually running.

This is a deliberate separation of concerns: the broker's job stops at "the CRs exist and describe what should run." Everything from that point — actually creating pods, keeping replicas healthy, keeping routes current — belongs to the operator, not the broker. The broker never talks to a pod directly.

Architecture

Trying it out: the Dev Portal path

Publishing gets an asset onto the cluster; the Developer Portal is how someone actually gets to use it. A developer (or an agent acting on someone's behalf) subscribes to a published MCP server or LLM provider through the portal, where they receive client ID and client secret that is generated by the idig-broker, scoped to that subscription. From there, invoking a tool or calling a model is just an authenticated call through the gateway using those credentials — the same path whether it's a person clicking "Try it" in the portal UI or an agent calling it unattended at 3 a.m.

Consume Sequence

Securing the wire: TLS server and client profiles

Every hop described above crosses a network boundary, and DataPower's answer to "how do we trust this connection" is a pair of profile resources:

  • TLS Server Profile — used wherever the gateway is the one being connected to. It bundles the server certificate and key the gateway presents, along with the trusted CA bundle used to validate any client certificates when mutual TLS is required. This is what protects the inbound side: consumers and agents calling in through the gateway to reach a runtime.
  • TLS Client Profile — used wherever the gateway is the one initiating a connection out. It holds the client certificate that the gateway presents when the remote end requires mutual TLS — for example, when calling an MCP server or an external LLM provider API that mandates mTLS from its callers. The profile also carries the CA bundle used to verify the remote endpoint's own certificate, so both ends of the connection are authenticated.

In practice, certificates back these profiles are typically issued and rotated through a standard cert-manager–based pipeline rather than handled by hand, and most internal paths run on plain server-side TLS, with mutual TLS reserved for the connections where verifying both ends actually matters. The profiles themselves are just Kubernetes resources like everything else here — which means they get versioned, reviewed, and reconciled the same way as the CRs they help secure.

Closing thoughts

None of the individual pieces here are exotic — a handful of REST calls, some custom resources, a controller reconciling them, a couple of TLS profiles. The interesting part is how little there is holding it together: idig-broker doesn't need to be stateful, doesn't need a queue, and doesn't need to know anything about pods, replicas, or routes. It builds the CRs and steps out of the way, and everything downstream — the operator, the gateway, the autoscaler — does its job independently. That kind of narrow, boring responsibility is exactly what makes it easy to reason about when something goes wrong, and easy to extend when a new asset kind shows up.

Thanks to Michael O'Sullivan, Olajuwon Owoseni, and Niraimathi Gunalan for their work on idig-broker and for reviewing this post.

0 comments
28 views

Permalink

https://community.ibm.com/community/user/blogs/shreyas-raviprakash/2026/08/07/publishing-ai-assets-in-ibm-idig