A
admin token – the tokensfe org setup prints once, which lets sfe act as the first administrator. It expires after 7 days. Replace it with sfe org token rotate. See Create the first SeekrFlow administrator.
AI-Ready Data – the platform service that prepares datasets for fine-tuning. See Architecture.
Argo Workflows – the workflow engine the chart deploys into the argo-workflows namespace. Training and ingestion submit their jobs to it. See Architecture.
artifact registry – the container registry that holds the SeekrFlow chart and images. Seekr grants your account pull access, or you mirror the images into your own registry. See Create SeekrFlow secrets.
↑ Back to top
B
bootstrap endpoint – the Auth service endpoint that creates the first administrator. It is reachable only from inside the cluster and disables itself after first use. Distinct fromsfe bootstrap. See Create the first SeekrFlow administrator.
break-glass administrator – a password account, created by sfe org setup, that owns your organization and signs in when single sign-on is unavailable. See Create the first SeekrFlow administrator.
↑ Back to top
C
cloud identity – how SeekrFlow’s pods authenticate to your cloud provider’s services, using the provider’s workload identity mechanism, such as Amazon EKS Pod Identity. On-premises deployments use static keys instead. See Set up cloud identity. custom resource definition (CRD) – a Kubernetes extension that defines a new resource type. SeekrFlow’s CRDs include FlowService, FlowModel, and SeekrFlowEverywhere. Uninstalling SeekrFlow leaves them in place. See Uninstall SeekrFlow. ↑ Back to topD
data migration – the job that creates or upgrades SeekrFlow’s database schema on every install and upgrade. Services that own databases wait for it to finish. Rolling back a release doesn’t undo it. See Revert a SeekrFlow upgrade. ↑ Back to topE
etcd – the database where Kubernetes stores the cluster’s resources and configuration, including Kubernetes secrets. Encrypting it protects secrets at rest when you use Kubernetes secrets for secret management. See Security considerations. external model – a model served by Amazon Bedrock in your own cloud account rather than by a vLLM server in your cluster. Identified by anaws-bedrock: prefix, and turned on with global.modelPolicy.enableExternalModels. See Configure models.
External Secrets Operator – an open source Kubernetes operator that syncs secrets from a cloud secret store into Kubernetes secrets. Optional, and installed by you rather than by the chart. See Set up secret management.
↑ Back to top
F
FlowModel – the custom resource that defines one self-hosted model server: which model to run and the GPUs, memory, and CPU to give it. You define FlowModels underFlowModel.models in the values file. See Configure models.
FlowService – the custom resource the operator creates for each platform service, such as Auth or Serving. List them with kubectl get flowservices to confirm the operator is managing the deployment. See Verify the SeekrFlow deployment.
↑ Back to top
G
GPU node label – the Kubernetes labelseekr.io/gpu_type=<GPU type> that tells fine-tuning jobs which GPU nodes they can use, such as seekr.io/gpu_type=A10. See Create the SeekrFlow values file.
↑ Back to top
H
Helm chart – the versioned package that installs the operator, SeekrFlow’s CRDs, and the supporting components. See Architecture. Hugging Face token – an access token stored in thehf-token secret. Every deployment needs it, and model servers use it to download gated model weights, such as most Llama variants. See Create SeekrFlow secrets.
hybrid search pipeline – an OpenSearch search pipeline named hybrid_pipeline that retrieval-augmented generation depends on. Registered automatically when OpenSearch runs in the cluster. For AWS deployments, you register it yourself. See Provision OpenSearch.
↑ Back to top
I
image pull secret – the Kubernetes secret holding the registry credentials the cluster uses to pull SeekrFlow images. Without it, pods fail withImagePullBackOff. See Create SeekrFlow secrets.
ingress controller – the component that routes external traffic to SeekrFlow’s services by path, such as the Application Load Balancer on AWS or NGINX. See Set up networking and cluster policies.
↑ Back to top
K
Keycloak – an optional identity broker the chart can deploy to sign users in through your existing identity provider. Off by default. See Security considerations. ↑ Back to topL
license key – the signed token Seekr issues for your deployment. It carries your entitled services, an expiry date, and a GPU ceiling, and is stored in theseekrflow-license secret. See Create SeekrFlow secrets.
License service – the platform service that validates the license key and enforces its GPU ceiling. Other services do not report ready until it confirms a valid license. See Architecture.
↑ Back to top
M
mirror – to copy SeekrFlow’s images from Seekr’s registry into your own withsfe images mirror, when your cluster can’t reach Seekr’s registry or must pull only from yours. See Set up the sfe CLI.
MLflow – the experiment-tracking service the chart deploys to record fine-tuning runs. See Architecture.
model catalog – the list of models users can choose in the SeekrFlow interface. It ships with the chart, and SeekrFlow loads it into its database on every install and upgrade. Distinct from the FlowModels you run. See Configure models.
↑ Back to top
O
offline mode – theglobal.offlineMode setting, for clusters that can’t reach Hugging Face. Model servers load their weights from object storage instead, and tools that need the internet, such as web search, are turned off. See Configure models.
on-premises deployment – a deployment on a Kubernetes cluster in your own data center, with an S3-compatible object store such as MinIO. Set as on-prem in the values file. See What is SeekrFlow Self-Managed.
operator – the Kubernetes controller the chart installs. It reads your configuration and creates the platform’s workloads, and it owns most SeekrFlow pods. See Architecture.
↑ Back to top
P
preflight – thesfe preflight command, which checks your cluster and cloud prerequisites before you install or upgrade. sfe install and sfe upgrade do not run it for you. See Install SeekrFlow.
profile – a saved set of sfe defaults, such as kube-context, namespace, and values file, selected with -p. Profiles never store credentials. See Set up the sfe CLI.
↑ Back to top
R
release – a published version of SeekrFlow, supplied tosfe commands with -r. Also the Helm release, the installed instance of the chart in your cluster. See Upgrade a SeekrFlow deployment.
revision – a numbered snapshot of a Helm release, created by every install and upgrade. Rolling back returns the release to an earlier revision. See Revert a SeekrFlow upgrade.
root key – a key the Auth service uses to encrypt multi-factor authentication secrets and stored single sign-on tokens. Required for FIPS or single sign-on, and must stay stable for the life of the deployment. See Create SeekrFlow secrets.
↑ Back to top
S
SeekrFlowEverywhere – the single custom resource the chart creates to carry your configuration. The operator reads it and creates every other SeekrFlow resource. See Architecture.sfe – the SeekrFlow command-line interface (CLI) that generates your values file, sets up cloud identity and secrets, installs and upgrades the deployment, creates the first administrator, and helps you troubleshoot. See Set up the sfe CLI.
sfe bootstrap – the sfe command that writes a starter values file by asking questions. You add a few settings it leaves out. Distinct from the bootstrap endpoint. See Create the SeekrFlow values file.
shared file storage – a network file system mounted across GPU pods to cache model weights, such as Amazon EFS. See Provision storage.
↑ Back to top
V
Valkey – an optional cache the chart can deploy. Sign-in rate limiting and account lockout depend on it. Off by default. See Security considerations. values file – the YAML file,my-values.yaml, that holds every setting for your deployment. See Create the SeekrFlow values file.
vLLM – the open source inference engine that runs self-hosted models on your GPU nodes. Each FlowModel runs as its own vLLM server. See Architecture.
↑ Back to top