Skip to Content
CLI Referencenkapp export

nkapp export

Eject your project to other formats. Two targets are supported: Kubernetes manifests (export k8s) and a Helm chart (export helm).

nkapp export k8s [options]
nkapp export helm [options]

export k8s

Translates nanokit.yml into standard Kubernetes manifests — offline, no cluster or cloud credentials needed. The output contains Deployment, Service, Ingress (or a Contour HTTPProxy — see Ingress routing mode), ConfigMap, and HorizontalPodAutoscaler resources derived from your services, hosts, env blocks, and scaling settings.

Options

FlagTypeDefaultDescription
-e, --env <env>stringlocalEnvironment to translate (applies that environment’s overrides)
-o, --output <path>string.nanokit/k8s/<env>.yamlWrite manifests to this file
--stdoutbooleanfalsePrint manifests to stdout instead of writing a file

Examples

# Write production manifests to the default path (.nanokit/k8s/production.yaml)
nkapp export k8s -e production
 
# Write to a custom file
nkapp export k8s -e stage -o ./k8s/stage.yaml
 
# Pipe straight into kubectl
nkapp export k8s -e production --stdout | kubectl apply -f -

Applying the manifests

The generated YAML is plain Kubernetes — apply it with kubectl or commit it to a GitOps repository (Argo CD, Flux). If you want a packaged, configurable chart instead of flat manifests, use export helm:

kubectl apply -f .nanokit/k8s/production.yaml

[!IMPORTANT] export k8s is the offline path. For a live Kubernetes deploy you do not use export — set infra.target: kubernetes in nanokit.yml and run the standard nkapp up / nkapp deploy. Those route through the KubernetesExecutionEngine (EKS / GKE / AKS / DOKS) instead of the Docker engine. Use export k8s only when you manage your own GitOps / Helm / kubectl pipeline and want manifests rather than a Nanokit-driven apply. See the Kubernetes deploy guide.

Live deploy vs offline export

infra.target: kubernetes + nkapp up/deploynkapp export k8s
ModeLive — Nanokit applies to the clusterOffline — writes manifests only
Cluster neededYes (EKS / GKE / AKS / DOKS)No
EngineKubernetesExecutionEngineTranslation layer (@nkapp/runtime-k8s)
Use whenYou want Nanokit to own the rolloutYou run your own GitOps/Helm/kubectl pipeline

Ingress routing mode (nginx / Contour)

Both export k8s and export helm honor the routing mode set on infra.kubernetes.ingress (default nginx):

infra.kubernetes.ingressWhat gets emitted for a service with a host
nginx (default)a bare networking.k8s.io/v1 Ingress (one object, multi-host rules)
contoura Contour projectcontour.io/v1 HTTPProxy (one per host) instead of the Ingress
infra:
  target: kubernetes
  kubernetes:
    ingress: contour   # default 'nginx'

For export helm, the mode is baked into values.global.routing, so you can also flip it at render time: helm template ./chart --set global.routing=contour. The matching live deploy (infra.target: kubernetes + nkapp up) installs the controller for you — ingress-nginx for nginx, Project Contour for contour.

export helm

Ejects nanokit.yml into a real, parameterized Helm chart — also offline, no cluster or cloud credentials needed. Where export k8s writes flat, already-rendered manifests, export helm produces a proper chart directory (Chart.yaml, values.yaml, and templates/) whose every knob is surfaced in values.yaml, so you can reconfigure it per release with helm install -f. The rendered output is logically equivalent to export k8s (identical resource names, labels, and kinds).

nkapp export helm [options]

Options

FlagTypeDefaultDescription
-e, --env <env>stringlocalEnvironment to translate (applies that environment’s overrides)
-o, --output <dir>string.nanokit/helm/<env>/<chart>/Directory to write the generated chart into

What’s in values.yaml

The chart exposes a configurable value per service and per local database:

  • Per service: image.repository / image.tag, replicas, port, env, secretEnv, command, ingress.enabled / ingress.hosts, and autoscaling (enabled, minReplicas, maxReplicas, targetCPUUtilizationPercentage).
  • Per local database (postgres / mysql / mariadb / mongo / redis): image, port, storage, secretEnv / plainEnv, and dataPath. Managed engines (Neon, Turso) and mode: cloud databases emit no workload.
  • Global: global.routing (nginx (default) / contour) — selects whether the *-ingress.yaml (bare Ingress) or the *-httpproxy.yaml (Contour HTTPProxy) template renders for host-bound services. See Ingress routing mode.

Examples

# Generate the production chart at the default path (.nanokit/helm/production/<chart>/)
nkapp export helm -e production
 
# Generate into a custom directory
nkapp export helm -e stage -o ./charts/myapp
 
# Lint, then install / template it with Helm
helm lint ./charts/myapp
helm install myapp ./charts/myapp -n my-namespace --create-namespace
 
# Override values at install time
helm install myapp ./charts/myapp \
  --set services.web.replicas=3 \
  --set services.web.image.tag=v2.1.0

[!TIP] Use export helm when your team already standardizes on Helm (chart registries, helm diff, value overlays per environment). Use export k8s when you just want plain manifests for kubectl/GitOps, and infra.target: kubernetes + nkapp up when you want Nanokit to own the live rollout.

Kubernetes as input (bring your own infra)

Live deploy to a Nanokit-provisioned cluster (infra.target: kubernetes) already ships. The complementary input directions ship too, so existing Kubernetes users can adopt Nanokit by bringing what they already have:

  • nkapp import k8s — the reverse of export k8s: ingest your existing Deployment/Service/Ingress/HTTPProxy/ConfigMap/HPA/StatefulSet manifests and scaffold the equivalent nanokit.yml. See import.
  • BYO cluster — set infra.cluster.byo: true (+ kubeconfig/context) to deploy into a cluster you already operate. Nanokit provisions nothing and manages only its nk-<project>-<env> namespace; teardown never touches the cluster.
nkapp envnkapp expose