Secrets Manager Overview

SyVault Secrets Manager is a centralized secrets vault purpose-built for infrastructure and application credentials. It stores API keys, database credentials, SSH keys, TLS certificates, tokens, and any other sensitive configuration your services need at runtime.

How It Differs from the Password Vault

The password vault is designed for humans: you log in, browse folders, copy a password. Secrets Manager is designed for machines. Every interaction is API-driven, authenticated with ECDSA-signed JWTs, and optimized for automated workflows like CI/CD pipelines, container orchestration, and server bootstrapping.

Capability	Password Vault	Secrets Manager
Primary consumer	People	Applications & services
Access method	Web vault, browser extension	REST API, CLI, SDKs
Authentication	Email + master password + 2FA	Client ID + ECDSA P-256 signed JWT
Credential rotation	Manual	Automated (time-based or event-driven)
Dynamic secrets	No	Yes (PostgreSQL, MySQL)
Notation references	No	Yes (sy://Folder/Title/field/name)

Architecture

Secrets Manager is organized around three concepts:

Application
  └── Client
        └── Folder Access (read-only grants to shared folders)

Applications represent a logical system boundary. You might create one called "Production API" and another called "Staging Environment."

Clients are individual credential sets that belong to an application. A single application may have several clients: one for your CI server, one for a developer laptop, one for a Kubernetes operator. Each client receives its own client_id and a one-time access token used during bootstrap.

Folder Access determines which shared folders a client can read. When you grant a client access to a folder, every secret inside that folder (including secrets added later) becomes available to that client. Access is read-only; clients cannot create or modify secrets through the API.

Zero-Knowledge Encryption

Secrets Manager inherits SyVault's zero-knowledge architecture. Secrets are encrypted client-side before they ever reach the server. Each client derives its own encryption key during the bootstrap handshake. The server stores only ciphertext and never has access to plaintext values.

The bootstrap flow works as follows:

1. An admin creates a client in the web vault and receives a one-time access token.
2. The client calls POST /api/sm/v1/bootstrap with that token.
3. The server returns the client's encrypted key material and the token is immediately invalidated.
4. All subsequent requests are authenticated with an ECDSA P-256 signed JWT, with the client_id as the JWT subject.

Cloud Sync

Secrets Manager can synchronize secrets to external cloud secret stores including AWS Secrets Manager, Azure Key Vault, and GCP Secret Manager. The sy sync command pushes secrets one-way from SyVault to the target provider, letting you use SyVault as the single source of truth while keeping your cloud-native tooling intact. See the Cloud Sync guide for setup instructions.

Automated Rotation

For supported infrastructure targets, Secrets Manager can automatically rotate credentials on a schedule. A lightweight Rotation Gateway deployed in your network handles the credential change, and the new value is encrypted and stored back in your vault without human intervention. PostgreSQL and MySQL are supported today. See the Rotation guide for architecture details and setup.

Dynamic Secrets

For supported databases, Secrets Manager can generate short-lived credentials on the fly. Instead of storing a static password that lives forever, you configure a connection to your PostgreSQL or MySQL instance, and Secrets Manager creates a temporary role each time a client requests the secret. When the lease expires, the role is dropped automatically. This eliminates the risk of long-lived database credentials leaking.

Getting Started

1. Create an application and client in the web vault (see Applications & Clients).
2. Install the CLI or an SDK.
3. Bootstrap the client with sy init.
4. Start fetching secrets.

# Bootstrap a new client
sy init --token vft_abc123 --server https://vault.example.com

# Fetch a secret by notation
sy secret notation "sy://Production/Database/field/password"

# Inject secrets into a process
sy exec --env DB_PASS=sy://Production/Database/field/password -- node server.js