Use Cases

How developers, teams, and platform engineers use xenvsync to solve secret management — from a solo side project to an enterprise CI/CD pipeline with audit requirements.

Solo Developer

Local Development

Goal: Keep secrets out of Git history without cloud tooling or complicated setup. Get from zero to encrypted in under two minutes.

Common pain: Plaintext .env files accidentally committed to GitHub. No team, no cloud budget — just want to work safely.

Workflow Steps

1.Run xenvsync init to generate a local 256-bit key.
2.Run xenvsync push to encrypt .env → .env.vault.
3.Commit the vault file. The key stays out of Git via .gitignore.
4.Use xenvsync run to start the app with secrets injected in-memory.

Solo workflowbash

# First-time setup (30 seconds)
$ xenvsync init
# Generated .xenvsync.key — added to .gitignore
# Added .env to .gitignore

$ xenvsync push
# Encrypted .env → .env.vault

$ git add .env.vault
$ git commit -m "add encrypted vault"

# Start app — secrets injected in-memory, never written to disk
$ xenvsync run -- npm start

# On a new machine — restore from vault
$ xenvsync pull

Startup Team

Team Collaboration

Goal: Share staging and production secrets across 3–15 developers without a central vault service, a shared password, or a cloud subscription.

Common pain: Passing .env files over Slack or email. One person's local change silently diverging from what's in CI.

Workflow Steps

1.Each developer runs xenvsync keygen to get their own X25519 identity.
2.Share your public key (xenvsync whoami) with the maintainer.
3.Maintainer adds all keys to the roster and pushes a V2 vault.
4.Everyone pulls with their own private key — no secret ever shared.

Team onboardingbash

# Each developer (once per machine)
$ xenvsync keygen
$ xenvsync whoami
# Public key: base64url...  (share this with maintainer)

# Maintainer builds roster
$ xenvsync team add alice <alice-pubkey>
$ xenvsync team add bob <bob-pubkey>
$ xenvsync team add carol <carol-pubkey>
$ xenvsync team list

# Push V2 multi-key vault
$ xenvsync push --env staging
$ xenvsync push --env production
$ git add .env.staging.vault .env.production.vault .xenvsync-team.json
$ git commit -m "update encrypted vaults"

# Any team member pulls with their own identity
$ xenvsync pull --env staging

Enterprise Platform Team

Compliance & Auditability

Goal: Standardize secret handling across multiple services with cryptographic audit trails, enforced permissions, automated health checks, and instant access revocation.

Common pain: Scattered secret strategies per service. No way to audit who changed what, or to prove a departing employee's access was revoked.

Workflow Steps

1.Add xenvsync doctor and verify as mandatory CI gates.
2.Use xenvsync log to track vault change history per environment.
3.Run xenvsync rotate --revoke <name> immediately on offboarding.
4.Enforce XENVSYNC_KEY injection via secrets manager, never hardcoded.

Enterprise audit flowbash

# CI quality gates (add to every pipeline)
$ xenvsync doctor    # permissions, gitignore, key strength, identity
$ xenvsync verify    # structural check, GCM auth, staleness, duplicate keys

# Audit vault change history (key names only, no values)
$ xenvsync log --env production -n 50
$ xenvsync log --env staging

# Diff current .env against encrypted vault
$ xenvsync diff --env production

# Offboarding: revoke + rotate all relevant environments
$ xenvsync rotate --revoke former-engineer --env production
$ xenvsync rotate --revoke former-engineer --env staging
$ xenvsync push --env production
$ xenvsync push --env staging

Open-Source Maintainer

Release Credential Isolation

Goal: Keep release signing keys, npm tokens, and deployment credentials encrypted in the repo without exposing them to contributors or forks.

Common pain: Release credentials need to be somewhere, but contributors run the same CI and shouldn't see them.

Workflow Steps

1.Use separate named environments: dev for contributors, ci for releases.
2.The ci vault key is only known to maintainers and the release CI secret.
3.Contributors pull --env dev; release jobs inject the ci key at runtime.
4.xenvsync run injects release credentials in-memory with no disk artifact.

Release isolationbash

# Contributor environment (shared with team)
$ xenvsync push --env dev
$ git add .env.dev.vault

# Release-only environment (maintainer only)
$ xenvsync push --env ci
$ git add .env.ci.vault

# Contributors work normally
$ xenvsync pull --env dev
$ xenvsync run --env dev -- make test

# CI release job (key injected from repo secret)
- run: echo "$RELEASE_KEY" > .xenvsync.key && chmod 600 .xenvsync.key
- run: xenvsync run --env ci -- make release

How xenvsync Compares

Feature	xenvsync	dotenv-vault	sops
Cloud dependency	None — fully local	Required for sync	Optional (KMS)
Team key model	X25519 per member	Shared service key	PGP / KMS / age
In-memory run	Built-in xenvsync run	Limited	No native run mode
Git-native audit	xenvsync log	Service dashboard	Git history only
Setup time	< 2 minutes	Service registration	Key infra required
Single binary	Yes, no runtime deps	npm only	Yes

When to Choose xenvsync

✓ Local-first

No cloud account, no API calls, no subscription required.

✓ Per-member key access

X25519 team vaults — each person decrypts with their own key.

✓ In-memory injection

xenvsync run never writes plaintext to disk.

✓ Git-native audit

xenvsync log shows key-level diffs across commits.

✓ Multi-environment

Separate vaults for staging, production, ci in the same repo.

✓ Single binary

No runtime deps. Works identically on Linux, macOS, and Windows.

Note: Not sure if xenvsync fits your stack? Read the full tool comparison or check the FAQ.

Ready to Start?

Get Started Installation Guide Command Reference