midPilot Deployment Examples

Deployment examples for the midPilot open-source components:

• smart-integration - AI-assisted schema matching, mapping, delineation and correlation microservice (FastAPI). Kustomize.

• connector-gen - connector generation pipeline microservice (FastAPI + PostgreSQL). Kustomize.

• integration-catalog - connector publication and distribution application (Spring Boot + Angular + PostgreSQL). Kustomize.

• midpilot-llm - the LLM backend (vLLM model server + LiteLLM OpenAI-compatible proxy) that the two AI services call. Helm chart (needs a GPU for vLLM).

The three AI/catalog components are self-contained Kustomize projects, each with a base/ and an overlay/demo/ overlay and its own README.adoc. midpilot-llm is a Helm chart.

These examples are intentionally generic. They use upstream container images built from the public source repositories, in-cluster PostgreSQL where needed, and rely on cluster defaults for storage class and ingress class so they run on any conformant Kubernetes. They were tested on minikube.

Source components

The manifests are derived from the public upstream repositories:

• https://github.com/Evolveum/midpilot-smart-integration

• https://github.com/Evolveum/midpilot-connector-gen

• https://github.com/Evolveum/integration-catalog

Layout

<component>/
  base/                 # Deployment, Service, PostgreSQL (where needed), ...
  overlay/demo/         # namespace, demo config/secrets, Ingress

The demo overlay deploys each component into its own namespace following the midpilot-<component>-demo pattern:

Component	Namespace
smart-integration	midpilot-smart-integration-demo
connector-gen	midpilot-connector-gen-demo
integration-catalog	midpilot-integration-catalog-demo
midpilot-llm	midpilot-llm-demo

LLM backend options

smart-integration and connector-gen talk to any OpenAI-compatible API, configured by two values in their overlay/demo/kustomization.yaml: LLM__OPENAI_API_BASE and LLM__OPENAI_API_KEY. There are two equivalent ways to provide the backend:

1. Self-hosted (own GPU) - deploy the midpilot-llm chart (vLLM behind the LiteLLM proxy). The two services are already pre-wired to its in-cluster Service (http://litellm.midpilot-llm-demo.svc.cluster.local:4000/v1) and ship the same fixed demo key as midpilot-llm/scripts/create-secrets.sh, so the chain works out of the box. vLLM needs a GPU - without one the request reaches LiteLLM but fails at the vLLM backend. Replace the demo key with a real LiteLLM virtual key for anything beyond a local demo.

2. External cloud provider - point LLM__OPENAI_API_BASE at a hosted OpenAI-compatible API (e.g. https://openrouter.ai/api/v1) and set LLM__OPENAI_API_KEY to that provider’s key. No GPU, no midpilot-llm needed.

Either way the services start and serve their own API even before the backend is reachable; only the LLM-backed calls need it. integration-catalog uses no LLM at all.

Prerequisites

• A local Kubernetes cluster - tested with minikube

• kubectl and kustomize (or kubectl -k)

• Docker - to build the component images

Quick start on minikube

# 1. Start a cluster and enable Ingress
minikube start --driver=docker
minikube addons enable ingress

# 2. Build the component images directly into the cluster.
#    Run each from the corresponding source repository checkout.
minikube image build -t midpilot-smart-integration:demo .          # in midpilot-smart-integration
minikube image build -t midpilot-connector-gen:demo .              # in midpilot-connector-gen
minikube image build -t integration-catalog:demo -f docker/Dockerfile .   # in integration-catalog

# 3. Deploy a component
kubectl apply -k smart-integration/overlay/demo
kubectl apply -k connector-gen/overlay/demo
kubectl apply -k integration-catalog/overlay/demo

The LLM backend (midpilot-llm) is a Helm chart deployed separately; see midpilot-llm/README.adoc. Deploy it first if you want smart-integration / connector-gen to reach an LLM (its vLLM pod needs a GPU; the rest of the chain works without one).

The Deployments use imagePullPolicy: IfNotPresent and unqualified image names (e.g. midpilot-smart-integration:demo), so they pick up the locally built images without a registry.

Accessing the services

The simplest option is a port-forward, for example:

kubectl -n midpilot-smart-integration-demo port-forward svc/smart-integration 8090:8090

Each overlay also defines an Ingress (host <component>.demo.local, default ingress class). To use it on minikube, minikube tunnel exposes the ingress controller on 127.0.0.1 but does not provide DNS, so map the hosts yourself:

minikube tunnel        # in a separate terminal
# then map the hosts to 127.0.0.1 in /etc/hosts:
#   127.0.0.1 smart-integration.demo.local connector-gen.demo.local integration-catalog.demo.local

Verify the deployment

Each component’s README.adoc has a detailed Verify section. A quick smoke test per component (run after the rollout completes):

# smart-integration: OpenAPI UI served (200). /health returns 503 until the LLM
# backend is reachable (vLLM needs a GPU); the service itself is up.
kubectl -n midpilot-smart-integration-demo port-forward svc/smart-integration 8090:8090 &
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8090/docs

# connector-gen: migrations applied by the init container, health OK
kubectl -n midpilot-connector-gen-demo logs deploy/connector-gen -c db-migrate | tail
kubectl -n midpilot-connector-gen-demo port-forward svc/connector-gen 8091:8090 &
curl -s http://127.0.0.1:8091/health        # -> {"message":"OK"}

# integration-catalog: frontend (200) and seeded API data
kubectl -n midpilot-integration-catalog-demo port-forward svc/integration-catalog 8081:8080 &
curl -s -o /dev/null -w "%{http_code}\n" http://127.0.0.1:8081/
curl -s http://127.0.0.1:8081/api/applications

Check that all pods are ready and their logs are clean:

kubectl get pods -A | grep midpilot-

Note

The overlays ship a fixed demo key that matches the midpilot-llm chart, so the LLM call authenticates against LiteLLM. Without a GPU it then fails at the vLLM backend, so smart-integration’s `/health returns 503 by design - the service itself is up. Use an external provider (or a GPU) for working inference.

Notes

• LLM endpoint: smart-integration and connector-gen call an OpenAI-compatible LLM API. Their overlays point at the in-cluster LiteLLM proxy from the midpilot-llm chart by default and ship the matching fixed demo key, so the wiring works out of the box; replace it with a LiteLLM virtual key (or repoint LLM__OPENAI_API_BASE at an external provider) for real use. The services start and serve their API regardless - only the LLM-backed calls need a reachable backend.

• midPoint is not required. These services are standalone. midPoint is the client that calls smart-integration and connector-gen; integration-catalog is a standalone application. midPoint is only needed for the full end-to-end onboarding workflow.

• The demo secrets contain placeholder values and are meant for local testing only.