DEV Community: Mohammed Tayeh

Kubernetes Secrets That Sync Themselves — the SnapEnv Operator, Auto-Reload, and Helm

Mohammed Tayeh — Tue, 15 Sep 2026 15:38:04 +0000

Part 3 of 3. Part 1 covers the dashboard and CLI; part 2 covers a bare Linux server with systemd. This one's for Kubernetes.

If your deployment story today is "someone runs kubectl create secret by hand, or a value gets base64-encoded into a values file that shouldn't really be in git" — the SnapEnv Kubernetes operator replaces that with a SnapEnvSecret custom resource that keeps a native Secret in sync automatically, and can roll the Deployments that use it the moment something changes.

What we're building

The operator installed cluster-wide, watching for SnapEnvSecret resources in any namespace
One SnapEnvSecret synced into a native Secret, wired into a Deployment via envFrom
That Deployment auto-restarting when the underlying variables change — no manual rollout
The same pattern generalized into a drop-in block for your own Helm chart

1. Install the operator

The operator is a single, small (32Mi request) controller — one manifest installs the CRD, RBAC, and the Deployment itself:

kubectl apply -f https://raw.githubusercontent.com/snapenv-io/operator/main/config/deploy/install.yaml

That creates a dedicated snapenv-operator namespace, a ClusterRole scoped to exactly what it needs (read SnapEnvSecret CRs, read/write Secrets, read/patch Deployments and StatefulSets for the restart feature, write Events), and a one-replica Deployment running ghcr.io/snapenv-io/operator:latest.

$ kubectl -n snapenv-operator get pods
NAME                                READY   STATUS    RESTARTS   AGE
snapenv-operator-669d6b9d54-gwcql   1/1     Running   0          16m

2. The SnapEnvSecret custom resource

apiVersion: snapenv.io/v1alpha1
kind: SnapEnvSecret
metadata:
  name: my-web-app-dev
  namespace: my-namespace
spec:
  tokenSecret: snapenv-token      # name of a Secret in this namespace holding the snp_live_ token
  project: ad12d532-0779-49fa-8045-eed069db8597
  env: dev
  target: my-web-app-secret       # the native Secret the operator will create/keep in sync
  syncInterval: 1m                # optional — default 30m, minimum 1m

Field	Required	Notes
`tokenSecret`	yes	Name of a `Secret` in the same namespace, containing the token under a `token` key (override with `tokenKey`)
`project`	yes	The SnapEnv project UUID
`env`	yes	Environment name (`prod`, `staging`, `dev`, …)
`target`	yes	The native `Secret` name the operator manages
`apiUrl`	no	Override the API base URL — must be `https://`, enforced by the CRD schema itself
`syncInterval`	no	Poll interval absent a webhook push. Default `30m`, clamps to a 1m minimum
`allowEmpty`	no	Off by default — a sync that returns zero variables won't overwrite a target that previously had data, since an empty response is far more likely to be a permissions/deploy mistake upstream than an intentional wipe

The token only ever needs read scope, pinned to the one project and environment it's syncing — exactly the same least-privilege instinct as the systemd guide's token.

Applying it against a real (disposable, demo) project:

$ kubectl create secret generic snapenv-token \
    --from-file=token=./token.txt -n my-namespace

$ kubectl apply -f snapenvsecret.yaml
snapenvsecret.snapenv.io/my-web-app-dev created

$ kubectl get snapenvsecret my-web-app-dev
NAME             PROJECT                                ENV   TARGET              READY   VARS   LAST SYNC
my-web-app-dev   ad12d532-0779-49fa-8045-eed069db8597   dev   my-web-app-secret   true    8       9s

$ kubectl describe secret my-web-app-secret
Name:         my-web-app-secret
Labels:       app.kubernetes.io/managed-by=snapenv-operator
              snapenv.io/env=dev
              snapenv.io/project=ad12d532-0779-49fa-8045-eed069db8597
Annotations:  snapenv.io/data-hash: W/"d2fb7d8f49100323"
              snapenv.io/last-sync-time: 2026-09-15T12:22:27Z
Type:  Opaque
Data
====
API_KEY:               28 bytes
DATABASE_URL:          39 bytes
LOG_LEVEL:             5 bytes
PORT:                  4 bytes
REDIS_URL:             24 bytes
SNAPENV_ENV:           3 bytes
SNAPENV_PROJECT:       36 bytes
SNAPENV_PROJECT_NAME:  10 bytes

Same three synthetic SNAPENV_* context variables the CLI injects on every pull show up here too — useful for a pod to introspect which project/env it's actually running against without you wiring that up separately.

3. Wire it into a Deployment

apiVersion: apps/v1
kind: Deployment
metadata:
  name: my-web-app
  namespace: my-namespace
spec:
  replicas: 2
  selector:
    matchLabels: { app: my-web-app }
  template:
    metadata:
      labels: { app: my-web-app }
      annotations:
        snapenv.io/sync-secret: my-web-app-secret   # see step 4
    spec:
      containers:
        - name: my-web-app
          image: ghcr.io/you/my-web-app:latest
          envFrom:
            - secretRef:
                name: my-web-app-secret

Nothing SnapEnv-specific in the container itself — it's a normal envFrom.secretRef, exactly like referencing any other Kubernetes Secret.

4. Auto-reload when secrets change

The snapenv.io/sync-secret: "<target-secret-name>" annotation above is what makes this self-driving. It can sit on the Deployment's own metadata or on its pod template (the operator checks both, since some Helm conventions put annotations in one place or the other) — when the operator resyncs and the secret's content actually changed, it patches kubectl.kubernetes.io/restartedAt onto the pod template of every Deployment/StatefulSet carrying that annotation. That's the same mechanism kubectl rollout restart uses — a normal, native rolling restart, not a hard delete.

Critically, it only restarts on an actual content change — the operator stores the API's ETag on the target Secret (snapenv.io/data-hash) and compares it before writing anything, so a poll that finds nothing new is a no-op (no restart, and if the API returns 304 Not Modified, not even a Secret write). That distinction matters: an earlier version of this exact operator had a bug where a broken ETag comparison made every poll look like a change, restart-looping every linked Deployment roughly once a minute. Diffing before you act — not "sync on every poll" — is the difference between a self-healing system and a self-DDoSing one.

5. Verify from the dashboard

Every sync the operator performs sends X-SnapEnv-Client: operator, which the dashboard's Integrations page uses to show a live "last synced" time per project — a quick way to confirm the operator is actually running against a given project without reaching for kubectl at all.

6. The Helm chart pattern

If you maintain your own chart, the pattern that works well is a snapenv block in values.yaml, mutually exclusive with however you currently inject secrets (a plain base64 Secret, Doppler, whatever):

# values.yaml
snapenv:
  enabled: false
  tokenSecret:
    create: true
    name: ""              # defaults to <app-name>-snapenv-token
    value: ""              # snp_live_... — pass via --set-string or a values overlay, never committed
  managedSecret:
    name: ""              # defaults to <app-name>-secret
  project: ""              # required when enabled
  env: prod
  apiUrl: ""
  syncInterval: 30m

# templates/snapenvsecret.yaml
{{- if .Values.snapenv.enabled }}
{{- if .Values.snapenv.tokenSecret.create }}
apiVersion: v1
kind: Secret
metadata:
  name: {{ .Values.snapenv.tokenSecret.name | default (printf "%s-snapenv-token" .Values.name) }}
type: Opaque
stringData:
  token: {{ .Values.snapenv.tokenSecret.value | quote }}
---
{{- end }}
apiVersion: snapenv.io/v1alpha1
kind: SnapEnvSecret
metadata:
  name: {{ .Values.name }}-snapenv
spec:
  tokenSecret: {{ .Values.snapenv.tokenSecret.name | default (printf "%s-snapenv-token" .Values.name) }}
  project: {{ .Values.snapenv.project | quote }}
  env: {{ .Values.snapenv.env | quote }}
  target: {{ .Values.snapenv.managedSecret.name | default (printf "%s-secret" .Values.name) }}
  {{- if .Values.snapenv.syncInterval }}
  syncInterval: {{ .Values.snapenv.syncInterval | quote }}
  {{- end }}
{{- end }}

Two helpers make this play nicely alongside whatever secret mode the chart already supports:

{{/* Fail the render early if more than one secret mode is enabled at once */}}
{{- define "mychart.validateSecrets" -}}
{{- $enabled := list }}
{{- if .Values.secret.enabled }}{{- $enabled = append $enabled "secret" }}{{- end }}
{{- if .Values.snapenv.enabled }}{{- $enabled = append $enabled "snapenv" }}{{- end }}
{{- if gt (len $enabled) 1 }}
{{- fail (printf "Enable exactly one secret mode, not: %s" (join ", " $enabled)) }}
{{- end }}
{{- end }}

{{/* One name to envFrom.secretRef against, regardless of which mode is active */}}
{{- define "mychart.secretName" -}}
{{- if .Values.snapenv.enabled }}
{{- .Values.snapenv.managedSecret.name | default (printf "%s-secret" .Values.name) }}
{{- else }}
{{- printf "%s-secret" .Values.name }}
{{- end }}
{{- end }}

Then every container's envFrom just references {{ include "mychart.secretName" . }} and doesn't care which mode produced it — flipping snapenv.enabled: true in an environment's values file is the entire migration.

Troubleshooting

kubectl logs on the operator is flooded with deployments.apps is forbidden. The ClusterRole is missing the apps apiGroup grant on deployments/statefulsets — required for the auto-restart feature (step 4), not for syncing itself, so secrets will keep updating fine while this silently breaks restarts. This is easy to end up with after a redeploy: if your pipeline only updates the operator's image tag and never re-applies its RBAC manifest, a ClusterRole edit that's sitting correctly in your repo can quietly drift out of sync with what's actually applied to the cluster. Worth an explicit check after any operator upgrade:

kubectl apply -f config/deploy/install.yaml   # idempotent — re-applies CRD + RBAC + Deployment
kubectl -n snapenv-operator logs deploy/snapenv-operator --tail=20 | grep -i forbidden

A SnapEnvSecret shows READY: false. kubectl describe snapenvsecret <name> — the Last Sync Error field in status has the real reason, almost always a token/project/env mismatch or an expired/revoked token.

A new status field you added to the CRD never shows up. Kubernetes' apiserver prunes any field not declared in the CRD's OpenAPI schema — silently, no error. If you're extending this operator yourself, any new field goes in the Go type and config/crd/snapenv.io_snapenvsecrets.yaml's status.properties, or it vanishes on every write.

Restarts happen on every sync, even with nothing changed. That means the ETag comparison is broken somewhere in the chain — check whether anything between the operator and the API (an ingress, a proxy) is rewriting the ETag/If-None-Match headers; a reverse proxy's gzip layer downgrading a strong ETag to a weak W/"..." one is a common culprit, and the comparison needs to tolerate that (RFC 9110 weak comparison), not do a byte-for-byte string match.

Wrap-up

That's all three parts of the series: dashboard + CLI for how your team works day to day, systemd for a plain VPS, and the operator here for Kubernetes — three different delivery mechanisms, one source of truth underneath all of them. Full reference docs at docs.snapenv.io.

🎉 Code HELLOSNAP gets you the Pro plan free for 3 months, first 100 redemptions — redeem it from Workspace → Plan & Billing at snapenv.io.

Running SnapEnv on a Bare Linux Server with systemd

Mohammed Tayeh — Tue, 15 Sep 2026 12:15:27 +0000

Part 2 of 3 — if you haven't already, part 1 covers creating a project and adding your first variables from the dashboard. This guide picks up from there and assumes a project already has variables in it.

Not every service runs in Kubernetes. Plenty of production workloads are still one Go binary (or Rails app, or whatever) running under systemd on a plain VPS — and that's exactly the case SnapEnv's CLI was built for first: no plaintext .env sitting on disk forever, no manually SSH-ing in to update a secret, and a full audit trail of every pull.

This guide sets up a systemd service that:

Pulls its secrets from SnapEnv into memory-backed storage (/run, tmpfs) — never written to persistent disk
Authenticates with a token scoped to exactly one project, one environment, read-only
Picks up changed secrets automatically on a timer, and only restarts when something actually changed

Why not just `scp` a `.env` file?

Because that .env file then sits on the server indefinitely, readable by anyone with access to the filesystem or a backup of it, with no record of who put which value there or when. SnapEnv's answer is the same one the CLI already gives you locally — snapenv pull — just wired into systemd's own primitives instead of a login shell.

1. Install the CLI on the server

The snapenv binary is a single static executable — no runtime dependencies, so it drops straight into a minimal server image:

# Auto-detects OS/arch, installs to ~/.local/bin/snapenv
curl -fsSL https://get.snapenv.io/install.sh | sh

# Or pin it to a system path directly, per architecture
curl -fsSL https://get.snapenv.io/cli/latest/snapenv-linux-amd64 \
  -o /usr/local/bin/snapenv && chmod +x /usr/local/bin/snapenv

# arm64 (Graviton, Ampere, etc.)
curl -fsSL https://get.snapenv.io/cli/latest/snapenv-linux-arm64 \
  -o /usr/local/bin/snapenv && chmod +x /usr/local/bin/snapenv

For a systemd-managed service, install to /usr/local/bin — ~/.local/bin only works if the service runs as a user with that directory on $PATH, which systemd units usually don't have.

2. Create a scoped, read-only token

This is the one place least-privilege actually matters most: a token living on a server is a token that could leak in a backup, a core dump, or a misconfigured log line. Scope it as tightly as the service needs and nothing more.

From Access Tokens → New token: read-only scope, pinned to this one project, and — critically — only the prod environment checked. This service has no business being able to read dev or staging:

I picked No expiry here deliberately — an expiring token on an unattended server is a token that silently breaks your deploy six months from now. If your org has a rotation policy, rotate on a schedule you control instead of letting an expiry date pick the moment for you.

prod is a protected environment by default, which is why it shows a 🔒 in the dashboard — this token still works because tokens carry their own scope independent of the creator's role, but it's worth understanding why prod is locked down for human accounts even while a scoped machine token can read it:

Copy the token — it's shown exactly once.

3. Store the token outside the unit file

Don't put Environment=SNAPENV_TOKEN=snp_live_... directly in the .service file — anyone who can run systemctl cat or systemctl show on the unit can read it back out. Put it in its own file instead, readable only by the user the service runs as:

sudo mkdir -p /etc/snapenv
sudo tee /etc/snapenv/token.env > /dev/null <<'EOF'
SNAPENV_TOKEN=snp_live_xxxxxxxxxxxxxxxxxxxx
SNAPENV_PROJECT=ad12d532-0779-49fa-8045-eed069db8597
SNAPENV_ENV=prod
EOF

sudo chown myapp:myapp /etc/snapenv/token.env
sudo chmod 600 /etc/snapenv/token.env

(Swap myapp for whichever system user your service runs as, and the project UUID for the one shown at the top of your own project's Variables page.)

Setting all three of SNAPENV_TOKEN, SNAPENV_PROJECT, and SNAPENV_ENV puts the CLI into non-interactive auto mode — no snapenv login, no config file, nothing written to ~/.config. Every snapenv command in the rest of this guide just picks these up from the environment.

4. Wire it into the systemd unit

The pattern: ExecStartPre pulls fresh secrets into a tmpfs-backed runtime directory, and a second EnvironmentFile= loads that pulled file straight into the service's own environment — no dotenv-parsing code needed in the app itself.

# /etc/systemd/system/myapp.service
[Unit]
Description=My App
After=network-online.target
Wants=network-online.target

[Service]
Type=simple
User=myapp
Group=myapp

# tmpfs-backed /run/myapp, owned by myapp:myapp, auto-cleaned on stop —
# the pulled secrets never touch persistent disk
RuntimeDirectory=myapp
RuntimeDirectoryMode=0700

# Token + project + env for the CLI itself
EnvironmentFile=/etc/snapenv/token.env

# Pull fresh secrets before every start/restart
ExecStartPre=/usr/local/bin/snapenv pull --file /run/myapp/env

# Load the pulled secrets into the service's own environment
EnvironmentFile=/run/myapp/env

ExecStart=/opt/myapp/bin/server

Restart=on-failure
RestartSec=5

[Install]
WantedBy=multi-user.target

sudo systemctl daemon-reload
sudo systemctl enable --now myapp.service
sudo systemctl status myapp.service

Two EnvironmentFile= lines is intentional and valid — systemd merges them in order, and each is re-read fresh at start time, which is exactly what makes ExecStartPre writing the second file before ExecStart reads it work.

5. Refresh secrets on a timer, restart only when something changed

A dumb "re-pull and restart every 5 minutes" timer works, but it also bounces your service every 5 minutes even when nothing changed — noisy, and needlessly disruptive if the process is mid-request. Use snapenv diff to gate the restart on there actually being a difference:

# /usr/local/bin/snapenv-refresh-myapp.sh
#!/bin/sh
set -e

ENV_FILE=/run/myapp/env

if snapenv diff --file "$ENV_FILE" --no-metadata; then
  # exit 0 = no differences — nothing to do
  exit 0
fi

snapenv pull --file "$ENV_FILE"
systemctl restart myapp.service

sudo chmod +x /usr/local/bin/snapenv-refresh-myapp.sh

# /etc/systemd/system/myapp-secrets-refresh.service
[Unit]
Description=Check SnapEnv for changed secrets, restart myapp if needed

[Service]
Type=oneshot
EnvironmentFile=/etc/snapenv/token.env
ExecStart=/usr/local/bin/snapenv-refresh-myapp.sh

# /etc/systemd/system/myapp-secrets-refresh.timer
[Unit]
Description=Run myapp-secrets-refresh every 5 minutes

[Timer]
OnUnitActiveSec=5min
OnBootSec=2min

[Install]
WantedBy=timers.target

sudo systemctl daemon-reload
sudo systemctl enable --now myapp-secrets-refresh.timer

Check it's actually running, and only touching myapp.service when it needs to:

$ systemctl list-timers myapp-secrets-refresh.timer
NEXT                        LEFT      LAST                         PASSED  UNIT
Thu 2026-09-17 14:05:00 UTC  4min left  Thu 2026-09-17 14:00:02 UTC  55s ago myapp-secrets-refresh.timer

$ journalctl -u myapp-secrets-refresh.service --since "1 hour ago"
-- no differences found, restart skipped --

6. Rotating the token

Rotate from Access Tokens → the rotate icon next to prod · systemd (VPS). Rotation issues a new token with the same name, scope, and permissions, and revokes the old one immediately — so update /etc/snapenv/token.env first, then rotate, or the old token stops working before the new one is in place:

sudo -u myapp tee /etc/snapenv/token.env > /dev/null <<'EOF'
SNAPENV_TOKEN=snp_live_<new-token>
SNAPENV_PROJECT=ad12d532-0779-49fa-8045-eed069db8597
SNAPENV_ENV=prod
EOF
sudo systemctl restart myapp-secrets-refresh.service

Then check the audit log — every pull shows up there, so a rotation followed by a burst of vars.pull events from the right token name is your confirmation it worked.

Troubleshooting

snapenv pull exits 1 with an auth error. The token was revoked (check if someone rotated it), expired (shouldn't happen here since we picked No expiry), or /etc/snapenv/token.env has the wrong project/env. Run the pull manually as the service user to see the real error: sudo -u myapp snapenv pull --file /tmp/test.env.

EnvironmentFile=/run/myapp/env — service fails with "No such file or directory". RuntimeDirectory= didn't get created, or ExecStartPre failed silently before writing the file. Check journalctl -u myapp.service -n 50 for the ExecStartPre failure — it blocks ExecStart from running at all, which is the correct behavior (better a failed start than a service running with stale or missing secrets).

Values look wrong / stale. EnvironmentFile= lines don't support export, quotes around values, or inline comments — if the app was previously loading a hand-written .env with any of that, the raw output from snapenv pull (plain KEY=value, no quoting) may parse differently. Run snapenv pull --stdout --env prod locally to inspect exactly what gets written.

The refresh timer runs but never restarts the service. That's snapenv diff correctly reporting no differences — check with snapenv diff --env prod --file /run/myapp/env by hand. If you know something changed and diff disagrees, confirm /run/myapp/env wasn't wiped by a reboot between pulls (it's tmpfs, so a reboot clears it — myapp.service's own ExecStartPre will repopulate it on next start, but the refresh timer diffs against whatever's currently there).

What's next

This is part 2 of 3:

Dashboard + CLI for developers
Linux server with systemd (this guide)
Kubernetes: the operator, auto-reload, and Helm — coming up next: syncing variables straight into native Secret objects, auto-restarting Deployments when they change (the same "diff before restart" idea from this guide, but as a Kubernetes controller), and a drop-in pattern for adding SnapEnv to your own Helm chart.

🎉 Code HELLOSNAP gets you the Pro plan free for 3 months, first 100 redemptions — redeem it from Workspace → Plan & Billing at snapenv.io.

From Slack-Pasted .env Files to SnapEnv — A 10-Minute Setup Guide

Mohammed Tayeh — Tue, 15 Sep 2026 11:55:19 +0000

If your team's secrets management process looks like this —

a .env.example file that's permanently out of date
the real .env living in three people's Slack DMs
nobody quite sure which value is actually live in production
"wait, who has the prod database password?"

— this guide walks through replacing it with SnapEnv in about 10 minutes: dashboard, CLI, and a scoped token for CI. No credit card, no sales call.

Part 1 of 3 — next up: running SnapEnv on a bare Linux server with systemd, then the Kubernetes operator with Helm.

🎉 Product Hunt readers: use code HELLOSNAP for the Pro plan free for 3 months — from Workspace → Plan & Billing, click Upgrade your plan, then redeem a coupon. No credit card needed. Limited to the first 100 redemptions, valid through Jan 1, 2027.

What we're building

By the end of this guide you'll have:

A project with dev, staging, and prod environments
Variables added two ways (one-by-one, and bulk-imported from an existing .env)
The snapenv CLI installed and pulling secrets into a local .env
A scoped access token, ready to hand to CI

1. Create your workspace

Every project here tracks its own set of environments and shows you, at a glance, how many variables exist and when something last changed.

2. Create a project

Click New project. Give it a name, an optional description, and pick which environments it needs. dev, staging, and prod are selected by default, and you can add more later:

Every project also gets a UUID (visible at the top of its Variables page) — that's the real identifier the API, the CLI's --project flag, and SNAPENV_PROJECT all use, not the display name.

prod is marked protected by default — more on why that matters in the team access section below.

3. Add your first variables

Open the project and you land on its Variables page, one tab per environment. There are two ways to get variables in:

One at a time, with the type explicitly set to Plain or Secret (secret values are masked in the UI and in every API response unless you explicitly reveal them):

Or bulk-imported — paste an existing .env file directly in, and SnapEnv parses it, auto-detects which keys look like secrets, and lets you pick which environments to add them to:

Either way, values are encrypted (AES-256-GCM, unique key per project) before they ever touch the database — SnapEnv's own team can't read them, and neither can anyone without explicit access to that environment. Here's the result:

Notice the CLI hint panel in the top right of every project page — it always shows the exact snapenv pull command for whichever environment tab you're looking at. That's your cue for the next step.

4. Install the CLI

The snapenv binary is a single static executable — no runtime, no dependencies:

curl -fsSL https://get.snapenv.io/install.sh | sh

That detects your OS/architecture and installs to ~/.local/bin/snapenv. It supports macOS (amd64/arm64) and Linux (amd64/arm64) out of the box.

5. Authenticate and pull

Grab an access token from Settings → Access tokens → New token (walked through in detail in step 7 below), then:

$ snapenv login --token snp_live_xxxxxxxxxxxxxxxxxxxx
✓ Logged in — credentials saved to ~/.config/snapenv/config.json

$ snapenv pull --env dev
✓ 5 variables written to .env

That's it — your local .env is populated, chmod 600, ready to load into whatever's running your app locally. Every project has its own UUID, so if you're juggling multiple services, pin the CLI to one with --project (or SNAPENV_PROJECT) instead of switching context every time.

6. Promote and compare environments

Once dev is in good shape, push it forward or diff it against what's already live:

# Push your local .env up to staging (additive — nothing gets deleted remotely)
$ snapenv push --env staging
✓ 3 created, 2 updated

# Check what would change before you push to prod
$ snapenv diff --env prod
~ DATABASE_URL   (value differs)
+ FEATURE_FLAG   (remote only — not in local file)
- DEBUG_MODE     (local only — not in remote)

diff exits non-zero when it finds a difference, which makes it a natural CI gate — wire it into a pipeline step and it'll fail the build the moment prod config drifts from what's in source control (or vice versa).

7. Invite your team — permissions that default to safe

SnapEnv enforces three layers of access control, and the defaults are deliberately conservative: a Developer role gets write on unprotected environments like dev/staging, but no default access to prod at all. An Admin or Owner has to explicitly grant a developer read or write on a protected environment — it's opt-in, not opt-out.

Invite teammates from Workspace → Team → Invite, then fine-tune each person's per-environment access from the project's Team & Access tab. Every invite, role change, and access grant is written to the audit log automatically — no separate setup required.

8. Create a scoped token for CI

Humans authenticate with GitHub OAuth or email; machines (CI, the Kubernetes operator, cron jobs) use snp_live_ access tokens instead. Create one from Access Tokens → New token:

Three things worth setting deliberately here, every time:

Scope — Read-only if this token only ever needs to pull. Save Read & write for anything that also pushes.
Project access — pin it to one project unless you genuinely need workspace-wide access.
Environment access — a CI token for staging deploys has no business being able to read prod.

The plaintext token is shown exactly once — copy it straight into your CI provider's secret store (GITHUB_TOKEN/repo secrets, etc.) or a Kubernetes Secret. If you ever lose it, rotate it; the old one is revoked the instant you do.

# .github/workflows/deploy.yml
- name: Pull secrets
  env:
    SNAPENV_TOKEN: ${{ secrets.SNAPENV_TOKEN }}
    SNAPENV_PROJECT: ${{ vars.SNAPENV_PROJECT }}
  run: snapenv pull --env prod
  # GITHUB_ACTIONS=true is already set by the runner, so every variable
  # is also appended to $GITHUB_ENV automatically — no extra wiring needed.

What's next

That's the core loop: dashboard for humans, CLI for machines, one source of truth for both. Full reference docs live at docs.snapenv.io if you want to go deeper on any step above.

This is part 1 of a 3-part series on running SnapEnv in production:

Dashboard + CLI for developers (this guide)
Running SnapEnv on a bare Linux server with systemd — coming up next: pulling secrets into a scoped EnvironmentFile and wiring a timer to pick up changes automatically, with no plaintext token in the unit file.
Kubernetes: the operator, auto-reload, and Helm — syncing variables straight into native Secret objects, auto-restarting Deployments when they change, and a drop-in pattern for adding SnapEnv as a secrets source in your own Helm chart.

🎉 One more reminder: code HELLOSNAP gets you the Pro plan free for 3 months, first 100 redemptions — snapenv.io

DEV Community: Mohammed Tayeh

Kubernetes Secrets That Sync Themselves — the SnapEnv Operator, Auto-Reload, and Helm

What we're building

1. Install the operator

2. The SnapEnvSecret custom resource

3. Wire it into a Deployment

4. Auto-reload when secrets change

5. Verify from the dashboard

6. The Helm chart pattern

Troubleshooting

Wrap-up

Running SnapEnv on a Bare Linux Server with systemd

Why not just scp a .env file?

1. Install the CLI on the server

2. Create a scoped, read-only token

3. Store the token outside the unit file

4. Wire it into the systemd unit

5. Refresh secrets on a timer, restart only when something changed

6. Rotating the token

Troubleshooting

What's next

From Slack-Pasted .env Files to SnapEnv — A 10-Minute Setup Guide

What we're building

1. Create your workspace

2. Create a project

3. Add your first variables

4. Install the CLI

5. Authenticate and pull

6. Promote and compare environments

7. Invite your team — permissions that default to safe

8. Create a scoped token for CI

What's next

Why not just `scp` a `.env` file?