Console walkthrough: deploy an LLM gateway

The same result as the step-by-step guide - one OpenAI-compatible endpoint holding provider credentials server-side - built from the console instead of oc apply.

The console offers two routes, and only one works without an administrator

The gateway is an ordinary web workload, so both the Helm catalog and Import YAML can install it. The upstream chart does not start under OpenShift's default security policy, for reasons in The chart and the SCC below. This page takes the Import YAML route, which needs nothing granted to you.

Prerequisites

• A project - see Accounts & projects
• No GPU. The gateway holds no weights; it is a router, and these are ordinary web-service resources.

1. Create the secrets

The gateway reads its dashboard login and its at-rest encryption key from Secrets, so neither is ever written into a workload manifest.

Workloads > Secrets > Create > Key/value secret, twice - or one Import YAML with both. The step-by-step guide has the field names.

Losing the encryption key loses whatever the gateway has stored

Stored configuration is encrypted with it, and nothing recovers it. Put it in your secret manager before you go any further.

2. Create the gateway

Import YAML - the + in the masthead - takes the PersistentVolumeClaim, Deployment and Service in one submit:

The manifest is the one from step 5 of the guide. Three things about it differ from a chart install and are worth knowing before you paste it:

• Set no runAsUser or fsGroup. OpenShift assigns both per project. A manifest that names its own user is the single most common reason a working upstream image will not start here.
• The volume is what makes configuration survive a restart. Without it, a key or a provider added in the dashboard is gone the next time the pod moves.
• The credentials come in as environment variables from the Secrets in step 1, never as literals in the manifest.

3. Confirm it is running

Workloads > Deployments > gateway.

The pod's Logs tab reports what the gateway actually enabled, which is not always what you configured:

Read the plugin status lines. governance is what enforces budgets and rate limits, and logging is what gives per-key attribution - a gateway running without them answers requests perfectly while enforcing and recording nothing.

4. Verify

A gateway with no providers routes nothing, so the useful check is that it answers at all rather than that it returns a model.

Forward the Service and call it, as in Verify. /v1/models returning an empty list is the correct answer at this stage: the gateway is up, and has no backends yet.

Do not publish a Route until authentication is confirmed

Publishing makes anything that can reach the hostname able to spend against your providers. Some builds disable authentication on inference during a proof of concept, so a 200 proves the endpoint is reachable - not that a key was required. See Expose it.

The chart and the SCC

The console's Software Catalog can install Helm charts, and a chart repository can be added to your own project without an administrator - a ProjectHelmChartRepository object, created through Import YAML, puts its charts in the catalog for that project only.

The upstream gateway chart installs from there and then does not start.

unable to validate against any security context constraint, and zero pods

The chart's templates hardcode runAsUser: 1000 and fsGroup: 1000. OpenShift's restricted-v2 policy requires a UID from the range allocated to your project - a range like 1000790000/10000 - so the pod is refused before it is ever scheduled:

pods "…-0" is forbidden: unable to validate against any security context constraint:
  provider restricted-v2: .spec.securityContext.fsGroup: Invalid value: [1000]:
    1000 is not an allowed group
  provider restricted-v2: .containers[0].runAsUser: Invalid value: 1000:
    must be in the ranges: [1000790000, 1000799999]

Two details make this harder to spot than it should be. The values file cannot fix it - the numbers are in the templates, not in values.yaml, so overriding podSecurityContext changes nothing. And Helm still reports the release as Deployed, because the release installed correctly; it is the StatefulSet that cannot create a pod. The workload shows zero pods with no failure on the release itself.

Resolving it means an administrator granting the project's service account a SecurityContextConstraint that permits UID 1000. Deploying the same image from a manifest that sets no user, as in step 2, needs no exception at all.

Where the console differs from the CLI

	Console	oc
Creating the objects	Import YAML	oc apply -f
Chart repositories	added per project, then in the catalog	helm repo add
Installing the chart	Software Catalog, form or YAML	oc apply -k . --enable-helm
Editing configuration	Actions > Edit, or the YAML tab	edit the file, reapply
Rotating a credential	edit the Secret, then restart the pod	oc set data, oc rollout restart
Calling the endpoint	not possible in the browser	oc port-forward, then curl

Next

Add a model provider → - give the gateway something to route to, then issue a virtual key so callers can use it.