Skip to main content
This page lists the minimal network flows to allow when you run Prisme.ai with Kubernetes NetworkPolicy resources, cloud security groups, or an equivalent firewall model. Start from default-deny ingress and egress, then open only the flows that match the services and products you deploy.
The examples below assume the default chart namespaces and release-style service names: core-... services in the core namespace and apps-... services in the apps namespace. Adjust names, namespaces, selectors, and external endpoint CIDRs to your installation.

Chart-backed ports and labels

The subcharts label pods with:
For example, the default runtime selector is:
Frontend naming. The active frontend is platform (the prisme.ai-platform image), deployed by the prismeai-console chart and exposed by the prismeai-console Service — so all frontend-related rules below use the prismeai-console selector. The chart name is kept for compatibility even though the image is now prisme.ai-platform. prismeai-pages is the legacy standalone pages frontend; it is disabled by default and slated for removal. Skip its rules unless you explicitly enable it.
The core chart has optional networkPolicy.enabled settings for core services, but those templates only create ingress policies for the selected service. They do not create a complete egress policy set. If you enforce default-deny egress, you must add the egress rules listed on this page.

Public ingress

Only public entrypoints should accept traffic from the ingress controller or load balancer. Do not expose workspaces, runtime, events, or apps services directly to the internet.

Core service flows

api-gateway

api-gateway proxies public API traffic to the internal backend services.

workspaces

workspaces stores DSUL, metadata, files, apps and page definitions.

runtime

runtime executes automations. This service needs the broadest egress because workspace products and user-authored automations run from it.
The fetch instruction drives runtime egress. Automations call arbitrary URLs through the runtime fetch instruction, so runtime must reach every endpoint your automations target — external LLM providers (chat and embeddings), SaaS APIs, internal services and webhooks. fetch honors the standard HTTP_PROXY / HTTPS_PROXY / NO_PROXY environment variables, so you can route all outbound automation traffic through a single forward proxy and restrict egress to that proxy’s address.LLM and embedding calls are executed by these automations: if you use external providers, allow runtime egress to their HTTPS endpoints.Vector store — two paths. Crawler-based AI Knowledge indexing/search goes through searchengine (runtimesearchengine on port 80, then searchengine → Elasticsearch or OpenSearch on 9200). In addition, the storage product queries the vector store directly from automations via its VectorElasticsearch / VectorOpensearch apps — a fetch call to the configured elasticsearch_host / opensearch_host. That direct path means runtime needs egress to the vector store on its database port (9200, or 443 for a managed HTTPS endpoint). If you scope fetch egress tightly (forward proxy or CIDR allow-list), include the vector store endpoint, since a broad 443-only rule will not cover an in-cluster 9200 store (see Databases overview).

events

events stores and streams platform events.

platform frontend (console chart)

The active frontend (platform) is a server-rendered Next.js app, deployed by the prismeai-console chart and reached through the prismeai-console Service.
prismeai-pages is disabled by default and slated for removal; if you enable it, apply the same flows as the table above (public ingress on 80, egress to api-gateway).

Apps namespace flows

Deploy these flows only for the AI Products services you enable.
prismeai-crawler can include an optional Splash sidecar listening on 8050, 8051, and 5023. The chart points SPLASH_URL to http://localhost:8050/, so this is same-pod traffic and does not require a separate inter-pod NetworkPolicy rule.

Datastore ingress

Restrict database ingress to only the services that need each datastore. Use separate Redis databases or separate Redis instances according to your sizing and isolation requirements. The Helm values expose distinct URLs for broker, sessions, runtime cache, and searchengines.

Baseline policies

Create a deny-all policy in each namespace where you enforce NetworkPolicy.
Also allow DNS egress from all application pods:

Example runtime egress

This example shows the shape of a runtime egress policy. Replace release labels, namespace names and external CIDRs with your own values.
Scope external egress as tightly as your environment allows. For managed databases, use private VPC CIDRs or private endpoints. For LLM providers and user-authored automations, prefer a controlled egress gateway or forward proxy instead of unrestricted 0.0.0.0/0 access.