Skip to main content

Kubernetes

Sync Envshed secrets into native Kubernetes Secret resources so your existing Deployments, Jobs, and StatefulSets can mount them as env vars or files — without anyone running kubectl create secret by hand.

On the roadmap — target Q1 2027

A first-party provider for External Secrets Operator (ESO) ships in Q1 2027. Until then, the init-container workaround covers the common case of "fetch secrets at pod start, mount them into the app container".

How it will work​

  • ESO SecretStore for Envshed — point ESO at an Envshed environment with a single SecretStore (or ClusterSecretStore) resource and a Kubernetes Secret holding your service token.
  • Declarative ExternalSecret resources — list the keys you want; ESO creates and keeps the Kubernetes Secret in sync, polled at the interval you configure.
  • Native Secret consumers — your existing envFrom: secretRef: and volumeMounts: keep working. No app changes.
  • Multi-tenant friendly — namespace-scoped SecretStore for app teams, ClusterSecretStore for platform teams.

Workaround today​

Two patterns work in production today: an init-container that materializes a .env file into a shared emptyDir, or a Job that creates a Kubernetes Secret before the app deploys.

Option 1 — init-container with envshed pull​

The init-container fetches secrets and writes them to a shared emptyDir volume. The app container reads from that file at startup.

apiVersion: apps/v1
kind: Deployment
metadata:
  name: api
spec:
  replicas: 2
  selector:
    matchLabels: { app: api }
  template:
    metadata:
      labels: { app: api }
    spec:
      volumes:
        - name: envshed
          emptyDir: { medium: Memory }
      initContainers:
        - name: envshed-pull
          image: node:22-slim
          command: ["sh", "-c"]
          args:
            - "npm install -g envshed && envshed pull -e production -o my-org -p api -f /envshed/.env --force"
          env:
            - name: ENVSHED_TOKEN
              valueFrom:
                secretKeyRef:
                  name: envshed-token
                  key: token
          volumeMounts:
            - name: envshed
              mountPath: /envshed
      containers:
        - name: api
          image: my-registry/api:latest
          command: ["sh", "-c"]
          args: ["set -a; . /envshed/.env; set +a; exec node server.js"]
          volumeMounts:
            - name: envshed
              mountPath: /envshed
              readOnly: true

Two notes on this pattern:

  • emptyDir: { medium: Memory } keeps the file in tmpfs so it never touches the node disk.
  • set -a; . /envshed/.env; set +a exports every KEY=VALUE from the file into the process environment before exec node server.js takes over — no envshed CLI needed in the app image.

Option 2 — Kubernetes Job creates the Secret before deploy​

A pre-deploy Job (Helm hook, ArgoCD PreSync, or plain kubectl apply) runs envshed pull and pipes the result into kubectl create secret generic. Your app then consumes a normal Kubernetes Secret via envFrom. This pattern is closer to what the ESO provider will give you and is a smaller migration when you switch.

Want this sooner?​

Kubernetes is on the public roadmap for Q1 2027 — it lands after the CI integrations because most teams asking for Kubernetes already have a CI workaround in place. If a native ESO provider would unblock your team, email hello@envshed.com with a line about which resources you sync today (Secret only, or also ConfigMap) and whether you run ESO already — that drives which capabilities we ship in v0.