Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
78 changes: 78 additions & 0 deletions docs/docs/references/personas.md
Original file line number Diff line number Diff line change
@@ -0,0 +1,78 @@
# Personas

Nebari Kubernetes Platform (NKP) is designed around three primary roles. Understanding these roles clarifies who is responsible for each layer of the platform and what each group needs to be successful.

---

## Platform admin

**Who they are:**

- Infrastructure engineers, DevOps practitioners, or IT administrators responsible for standing up and maintaining the platform
- Comfortable with Kubernetes, cloud providers, and infrastructure-as-code tooling such as OpenTofu or Terraform
- May work within a central platform team or provide services to multiple internal teams

**What they do:**

- Provision clusters across cloud providers (AWS, GCP, Azure, Hetzner) or on-premises using the `nic` CLI
- Manage the foundational services bundled with every deployment: identity (Keycloak), API gateway (Envoy), observability, and GitOps (ArgoCD)
- Install, update, and remove software packs to extend the platform's capabilities
- Control user access, quotas, and security policies
- Monitor cluster health, costs, and resource utilization

**What they need:**

- Declarative, repeatable tooling that abstracts cloud provider differences
- Reliable upgrade paths with minimal manual intervention
- Clear visibility into cluster health, resource consumption, and costs
- Fine-grained access controls and policy enforcement
- The ability to integrate packs with foundational services such as SSO, routing, and observability without manual configuration

---

## Pack developer

**Who they are:**

- Software engineers or platform specialists who build and publish reusable capabilities for the platform
- Familiar with Kubernetes custom resources, Helm charts, and how the Nebari Operator works
- May be internal to an organization building proprietary tooling, or open-source contributors publishing packs for the broader community

**What they do:**

- Author `NebariApp` custom resources that define a software pack's components, dependencies, and configuration
- Package tools (notebook environments, model serving, experiment tracking, dashboards) so they integrate automatically with SSO, TLS, routing, and telemetry
- Test packs against different cluster configurations and platform versions
- Publish packs to a registry for platform admins to discover and install

**What they need:**

- Well-defined contracts for how packs integrate with the platform's SSO, routing, TLS, and telemetry layers
- A reliable operator reconciliation model they can test against
- Clear versioning and compatibility guarantees
- A publishing mechanism that makes packs discoverable and installable without requiring platform admin intervention in the development loop

---

## End user

Copy link
Copy Markdown
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I wonder if this I have been too narrow on who the end user is? Should it include more business type users rather then just engineering type users?


**Who they are:**

- Data scientists, ML engineers, researchers, and analysts who use the tools and environments the platform provides
- Proficient in Python or R, working daily with Jupyter notebooks, ML frameworks, and data pipelines
- Generally not responsible for infrastructure and expect the platform to simply work

**What they do:**

- Log in through the platform landing page and launch notebook environments or other deployed tools
- Run experiments, train models, and analyze data using pre-configured environments
- Collaborate with colleagues by sharing notebooks, dashboards, and results
- Scale computation to cluster resources without managing infrastructure themselves

**What they need:**

- Immediate access to pre-configured, stable environments without installation friction
- Scalable compute that can be requested on demand without involving infrastructure teams
- Reliable collaboration and sharing mechanisms
- Reproducible environments across sessions and teammates
- Clear paths to escalate when something isn't working
2 changes: 1 addition & 1 deletion docs/sidebars.js
Original file line number Diff line number Diff line change
Expand Up @@ -68,7 +68,7 @@ module.exports = {
label: "References",
link: { type: "doc", id: "references/index" },
items: [
// Add reference docs here
"references/personas",
],
},
{
Expand Down
Loading