First sign-in

The first sign-in happens in the console, with no shell and no SQL after it. This page is for the platform administrator who installed Olympusx AI.

The first platform administrator

With the built-in identity service

The identity service creates one account when it first starts: the address you named as the first administrator (components.keycloakBootstrapUser on the resource, bootstrapUser in the identity service’s block of the chart values). The address is also the username. Unnamed, it is admin@olympusx.ai.

Its password is generated at install and stored in a Secret, under bootstrap-password:

kubectl -n olympus get secret olympus-keycloak \
  -o jsonpath='{.data.bootstrap-password}' | base64 -d

1. Open https://<console-host> and press Sign in.
2. Sign in with the administrator’s address and that password.
3. The sign-in page shows Set your password. Choose one of at least 12 characters with an upper-case letter, a lower-case letter, a digit and a symbol, which is not the username. From now on it is the platform administrator’s password; the one in the Secret no longer works.

The account holds the platform-admin role. Naming a different first administrator on a running install creates nobody: the realm is imported once.

With your own identity provider

The first platform administrator is any account in your provider whose token carries the platform-admin role. Sign in at https://<console-host>. Identity and sign-in lists the claims Olympusx AI reads.

The setup checklist

An empty platform opens on Welcome to Olympusx AI: what this install still needs, in order. Each step has a button to the page where it is done, and a Done mark once the platform counts it.

Step	What it means
Register a cluster	Olympusx AI serves from Kubernetes clusters you own. Done already on an operator install, and on a chart install with clusterRegistration.enabled, which register the cluster they run on
Put GPU nodes in the serving pool	Olympusx AI discovers every GPU node and puts none in the pool. Until one is in, no tenant can hold GPU capacity. A cluster with no GPUs serves on CPU nodes without this step
Create the first tenant	A tenant is an isolated customer of the platform: its own projects, keys, quotas and bill
Seed the model catalog	What goes in the catalog is your decision
Offer models as LLMaaS	Which models you sell per token is your decision
Grant a model to a tenant	Offering makes a model sellable; granting makes it reachable by one tenant’s keys
Serve a model	Deploy an offered model on a cluster, on GPU or CPU. A model a cloud provider serves needs no deployment
Issue an API key	A key belongs to a project and carries its budgets and rate limits. It is shown once
Publish a price book	Traffic is served without one but cannot be invoiced. The platform ships market rates as a draft; publishing them is your decision

Once a cloud provider serves a model in the catalog, the first two steps no longer block: an install that serves only through providers completes without a cluster.

The list reads its state from the platform, so closing the browser halfway loses nothing. Explore on my own leaves it; until setup is finished, the console’s home page shows This platform is not finished being set up with Finish setup, which opens it again.

On a cluster other than OpenShift, the cluster the install registered for itself is listed as an OpenShift cluster. Nothing depends on that label: version, platform and apps domain show as unknown, and namespaces, quotas and serving work.

Create the first tenant

1. Go to Customers › Tenants and press Create tenant.
2. Identity. Enter the Display name people will see, and the Slug: lowercase letters, digits and hyphens, 3 to 40 characters. The slug becomes the tenant identifier.
3. First project. Name the first project (default is fine) and choose its Environment: Production, Staging or Development. A project scopes keys and usage.
4. Capacity (optional). Grant the tenant a capacity envelope on a cluster: GPUs, CPU cores, memory and storage. A model served on CPU and a vector database need CPU cores and memory above 0; storage at 0 means no limit. Skip it to assign capacity later.
5. Review, then create the tenant.

Tenants covers capacity, budgets and the tenant’s page.

Invite the tenant’s first administrator

1. Go to Govern › Users, choose the tenant, and press Invite.
2. Enter the person’s email address, give them the Admin role, and press Send invitation.
3. The console says Invitation sent. The person receives an email with a link to set their own password, valid for 12 hours. Resend invitation in their row sends a new one.

If no mail relay is configured, or the relay refuses the message, the console says Added, but the email was not sent, with the reason. The person exists with their role. Set a temporary password in their row generates one and shows it to you once; hand it over yourself, and the person chooses their own at first sign-in. The value is stored nowhere, and the audit trail records who set it for whom.

A person’s username and email are one address. The person cannot change either; an administrator changes both together in the identity service’s administration console (Users and roles).

Add more platform administrators

With the built-in identity service, open its administration console at https://<console-host>/auth/admin/:

1. Read the administration password:

   kubectl -n olympus get secret olympus-keycloak \
     -o jsonpath='{.data.admin-password}' | base64 -d

2. Sign in as admin with that password.

3. Choose the realm olympus, then Users, the person, Role mapping, and assign the realm role platform-admin.

With your own identity provider, grant the role there.

Next

• Verify the installation
• Quickstart: a model, a key and a first call
• Clusters: the serving pool, GPUs and capacity