Kitchen Sink

This page contains every content block the docs theme supports. Use this to verify typography, spacing, and color tokens across components.

Overview

Authentication in Nebari is handled by Keycloak, the identity service bundled with every deployment. When a user visits the hub, unauthenticated requests are redirected to the configured provider, and the returned identity is mapped onto Nebari roles and groups.

Note

Provider changes take effect after you run nebari deploy. Existing user sessions are preserved, but new logins use the updated configuration.

Configure a provider

Set the provider under security.authentication.type and supply its credentials in your nebari-config.yaml file.

A tabbed frame with an OUTPUT frame joined directly beneath it — authored as two adjacent blocks with no blank-line-separated content between them:

lang1

print("Hello World!")

lang2

console.log('Hello World!');

OUTPUT

Hello World!

A titled frame with terminal chrome — frame="terminal" plus a title:

nebari-config.yaml

nebari init aws --project nebari-demo --domain nebari.quansight.dev
nebari deploy --config nebari-config.yaml
nebari destroy --config nebari-config.yaml

A plain frame, no title:

# GitHub OAuth provider
security:
  authentication:
    type: GitHub
    config:
      client_id: "Iv1.a1b2c3d4e5f6"
      client_secret: "${GITHUB_CLIENT_SECRET}"
      # callback URL is generated by Nebari

Supported providers

Nebari ships with adapters for the most common identity providers. Password auth is available for local testing but not recommended in production.

Provider	Protocol	Status
GitHub	OAuth 2.0	Available
Auth0	OIDC	Available
Google	OAuth 2.0	Available
Password	Local	Testing only

Callouts & tabs

Tip

Use nebari validate before deploying — it catches most configuration mistakes locally.

Caution

Changing the authentication type logs out all users. Schedule provider migrations outside working hours.

Danger

Deleting the Keycloak realm removes all users, groups, and client secrets. This cannot be undone.

AWS

Deploying to AWS requires credentials with EKS, VPC, and S3 permissions. Set your region before running nebari init.

GCP

Deploying to GCP requires a service account with GKE and Cloud Storage roles.

Azure

Deploying to Azure requires a subscription with AKS and Blob Storage enabled.

Local

Local deployments run on kind and need no cloud credentials.

Media & lists

Markdown images do not emit a <figure>, so captioned figures are authored as literal HTML in .mdx:

Figure 1 — Keycloak brokers identity for JupyterHub and every Nebari service.

• Cloud providers
  • AWS — full support, including GPU node groups
  • GCP — full support
  • Azure — full support
• Existing Kubernetes clusters
• Local (kind) — testing and development only

1. Install the CLI: pip install nebari
2. Generate a config: nebari init
3. Deploy: nebari deploy -c nebari-config.yaml

Steps

1. Import the component into your MDX file:

   import { Steps } from '@astrojs/starlight/components';

2. Wrap <Steps> around your ordered list items.

Aside with a component title

Heads up

Asides accept a custom title. The title bar keeps the variant tint; only the label changes.