Security
How ConfigSync protects your configurations, secrets, and environment variables
Zero-Knowledge Architecture
ConfigSync is designed so that we never have access to your plaintext data. All encryption and decryption happens on your local machine using your master password. Our servers store only encrypted blobs that we cannot read — even with full database access, your data remains protected.
Encryption
Master Password & Key Derivation
When you initialize ConfigSync, you set a master password. This password is never stored or transmitted. Instead, a cryptographic key is derived from it using:
- Algorithm: PBKDF2 with SHA-256
- Iterations: 100,000 (resistant to brute-force attacks)
- Salt: Cryptographically random 32 bytes, unique per installation
- Output: 32-byte key used for AES-256-GCM encryption
The derived key stays in memory only while the CLI is running. It is never written to disk in plaintext.
Data Encryption
All sensitive data is encrypted using AES-256-GCM, which provides:
- Cipher: AES-256 in GCM mode (256-bit key)
- Authentication: Built-in GCM authentication tag (prevents tampering)
- IV: Unique random 12-byte initialization vector per encryption operation
- Wire format: [IV (12 bytes)][Auth Tag (16 bytes)][Ciphertext]
AES-256-GCM is an authenticated encryption standard provided by Node.js's built-in node:crypto module. It guarantees that data encrypted with it cannot be read or altered without the key.
Individual Secret Protection
Secrets stored via configsync secret set receive an additional layer of protection:
- Each secret is salted with a SHA-256 hash derived from its key name
- The salted value is encrypted with AES-256-GCM
- The entire secrets vault (
secrets.enc) is then encrypted again with the master key - File permissions are restricted to owner-only (0600)
This double-encryption means even if an attacker obtains the encrypted vault file, they need both the master key and the individual secret name to recover any value.
How Data Flows
Push (Upload)
- The CLI collects your tracked configs, env files, and repo metadata
- Everything is serialized to JSON locally
- The JSON is encrypted with your master password-derived key
- The ciphertext is base64-encoded and sent to our API
- Our server stores the opaque blob in Cloudflare R2 storage
Pull (Download)
- The CLI requests the latest encrypted state from our API
- Our server returns the encrypted blob (it cannot read it)
- The CLI decrypts the blob locally using your master password
- Configs and env files are restored to their original locations
# What your data looks like on our servers:
{
"encrypted_state": "gAAAAABn1k...a4F8=",
"timestamp": "2026-03-15T12:00:00Z",
"machine_id": "a1b2c3d4e5f67890"
}
# We see the timestamp and machine ID.
# The actual configs, secrets, and env vars? Unreadable ciphertext.
Secret Storage Providers
ConfigSync supports multiple backends for storing individual secrets. You choose where your secrets live:
Built-in Encrypted Vault
Default provider
Secrets are double-encrypted and stored in ~/.configsync/secrets.enc. Protected by your master password. Works everywhere, no external dependencies.
OS Keychain
macOS Keychain, GNOME Keyring, Windows Credential Manager
Delegates secret storage to your operating system's native credential manager. Secrets are protected by your OS login and hardware security features.
1Password
Via 1Password CLI
Store secrets directly in your 1Password vault. Requires the op CLI to be installed and authenticated.
Bitwarden
Coming soon
Integration with the Bitwarden CLI for teams and individuals already using Bitwarden for password management.
Server-Side Security
Infrastructure
- Hosting: Cloudflare Workers (edge computing, no persistent servers to compromise)
- Database: Cloudflare D1 (encrypted at rest by Cloudflare)
- Storage: Cloudflare R2 (encrypted at rest, stores only your ciphertext)
- Transport: TLS 1.3 enforced on all connections
Authentication
- Passwords: Hashed with bcrypt (cost factor 10) — never stored in plaintext
- Sessions: JWT tokens in httpOnly, secure, sameSite cookies (7-day expiry)
- API tokens: SHA-256 hashed before storage — we store only the hash, not the raw token
- CLI auth: Bearer tokens prefixed with
cs_for easy identification and rotation
What We Can and Cannot See
We Cannot See
- Your configuration file contents
- Your environment variables or .env files
- Your secrets, API keys, or passwords
- Your SSH keys or certificates
- Your git repository contents
- Your master password
- Your raw API tokens
We Can See
- Your email address and account name
- Machine names, platforms, and architectures
- When you last synced (timestamps)
- Encrypted state blob sizes
- API token names and usage timestamps
Open Source & Auditable
The ConfigSync CLI is open source. You can audit exactly how encryption works, verify that data is encrypted before transmission, and confirm that no plaintext ever leaves your machine.
Found a Security Issue?
If you discover a security vulnerability, please report it responsibly.
security@configsync.dev