Keeper for Secure Secrets in Go

Secrets are easy to scatter across config files, shell history, sidecar scripts, and half-documented vault adapters. Keeper takes a different path. It is an embedded cryptographic secret store for Go that keeps secrets in a local bbolt database, encrypts them at rest, and exposes them through a library, an HTTP handler, or a CLI depending on how your system is built.

What is Keeper?

Keeper is a Go library and toolset from AgberoHQ designed to act as a hardened secret layer inside an application. According to the project README, it uses Argon2id for master key derivation, XChaCha20-Poly1305 for authenticated encryption by default, and stores data in an embedded bbolt database. It supports four security levels, including password-only buckets, admin-wrapped buckets, HSM-backed buckets, and remote KMS-backed buckets.

That mix makes it interesting for operators. You can keep bootstrap secrets available at process start, require an additional admin credential for more sensitive buckets, or delegate wrapping and unwrapping to Vault Transit, AWS KMS, or GCP Cloud KMS.

Key Features

• Embedded by Design: Run secret storage inside your Go service instead of standing up a separate dependency for every internal tool.
• Multiple Security Levels: Choose between password-only, admin-wrapped, HSM, or remote KMS protection depending on the sensitivity of each bucket.
• HTTP Handler Included: x/keephandler mounts REST-style endpoints on a standard Go http.ServeMux with hooks and guards for policy control.
• Tamper-Evident Audit Chain: Keeper tracks audit events and encrypts structural metadata at rest.
• Operator-Friendly CLI: The bundled CLI is built for secret entry without shell-history leakage.

Installation

Install the CLI directly with Go:

go install github.com/agberohq/keeper/cmd/keeper@latest

To embed it in a service, add the module to your application:

go get github.com/agberohq/keeper

Usage

A simple service-level workflow is to initialize the store and unlock it from an injected passphrase:

store, err := keeper.New(keeper.Config{
    DBPath:           "/var/lib/myapp/keeper.db",
    AutoLockInterval: 30 * time.Minute,
    EnableAudit:      true,
})
if err != nil {
    log.Fatal(err)
}

if err := store.Unlock([]byte(os.Getenv("KEEPER_PASSPHRASE"))); err != nil {
    log.Fatal(err)
}

err = store.CreateBucket("vault", "system", keeper.LevelPasswordOnly, "init")
if err != nil {
    log.Fatal(err)
}

store.Set("vault://system/jwt_secret", []byte("supersecret"))

If you need an API instead of direct library calls, x/keephandler can mount unlock, lock, status, key, rotation, and backup endpoints on the standard library mux. That makes Keeper useful for internal control planes and maintenance tooling where bringing in a full external secret manager would be overkill.

Operational Tips

• Use the right bucket level: Keep startup-critical secrets in password-only buckets and reserve admin-wrapped or remote KMS buckets for high-value material.
• Wire in auto-lock: Short unlock windows reduce the blast radius on long-running admin sessions.
• Protect the passphrase path: Environment injection is convenient, but production systems should treat passphrase delivery as a first-class control.
• Use remote KMS for stronger boundaries: Vault Transit, AWS KMS, or GCP Cloud KMS integrations are a better fit when separation of duties matters.

Conclusion

Keeper looks like a strong option for teams that want secret management primitives inside Go services without giving up encryption, auditability, or upgrade paths to HSM and KMS-backed protection. If you build internal platforms, control planes, or operational tooling in Go, it is worth tracking early.

For efficient incident management and to prevent on-call burnout, consider using Akmatori. Akmatori automates incident response, reduces downtime, and simplifies troubleshooting.

Additionally, for reliable virtual machines and bare metal servers worldwide, check out Gcore.