.env.example

# Nebula provider credentials — SECRETS.
#
# Copy to .env and fill in real values. .env is gitignored — never commit tokens.
# Consumed by hack/deploy.sh (make deploy-all), which turns the credentials into one
# Kubernetes Secret PER PROVIDER. Static non-secret config (image, namespace, Kind
# cluster) is NOT here — pass it as make variables, e.g.
#   make deploy-all IMG=myrepo/nebula:v1 DEPLOY_KIND_CLUSTER=nebula-test-e2e
#
#   cp .env.example .env
#   # edit .env
#   make deploy-all

# --- Modal provider --------------------------------------------------------
# From `modal token new`. Leave blank to skip creating the Modal secret (the
# provider is then skipped at registration — not fatal).
MODAL_TOKEN_ID=
MODAL_TOKEN_SECRET=

# --- AWS provider ----------------------------------------------------------
# SECRETS ONLY — the PROVISIONING identity (the AWS account that launches GPU
# instances). This is a SEPARATE identity from the one that talks to the cluster
# you deploy into (e.g. an EKS control plane in a different account).
#
# These use the standard AWS_ACCESS_KEY_ID / AWS_SECRET_ACCESS_KEY names — the
# same names `aws eks get-token` (kubectl's EKS auth plugin) reads — yet they do
# NOT collide with cluster auth: deploy.sh PARSES this file into a private array
# rather than sourcing/exporting it, so these values reach the provider Secret but
# never enter the environment of kubectl or any other child process. Your own
# ambient AWS credentials keep talking to the cluster.
#
# In production prefer IRSA / instance role and leave these blank (the SDK's
# default credential chain finds the role) — the AWS secret is then skipped, which
# is fine. Set them only for local/dev without a role. Both required together;
# leave both blank to skip.
AWS_ACCESS_KEY_ID=
AWS_SECRET_ACCESS_KEY=

# --- Additional providers (add as adapters land) ---------------------------
# Each provider gets its OWN secret (see hack/deploy.sh PROVIDER_SECRETS), e.g.:
# RUNPOD_API_KEY=