Introduction

What SikkerKey is, how it works, and the mental model behind secrets, machines, and access.

SikkerKey is a secrets vault and management platform. You store your secrets in a vault, and your applications read them at runtime, each one proving which machine it is by signing the request. Access is tied to a machine you approved, not to a shared token that anyone with a copy could use.

This page is the one-read version of how the pieces fit together. For a hands-on start, go to Quickstart; to look up a single term or type, see Concepts.

The pieces

A vault is your encrypted storage, identified by an ID like vault_a1b2c3d4e5. Your secrets live in projects.

Projects come in two forms. An application is one service, and it always has the same three projects, created together: a prod, a staging, and a dev. A standalone project is not part of an application, and you give it whatever name fits.

Secrets are the values you store, and each belongs to one project. Machines are the servers, containers, and CI jobs that read them, each registered to the vault with its own identity. You add a machine to the projects it needs and grant it specific secrets there: a machine can read a secret only when you have granted it that exact one. Concepts has the full definitions.

How a secret gets used

You store a secret. You paste a value into the dashboard. SikkerKey encrypts it with AES-256-GCM under a fresh key.

You register a machine. Create a one-time bootstrap token in the dashboard and run it on the designated machine:

Running the one-time bootstrap command on the machine to register it with SikkerKey

The machine generates its own keypair and sends SikkerKey the public half. It shows up as pending; you approve it, add it to a project, and grant it the secrets it needs.

The machine reads the secret. Your code asks for a secret through an SDK or the CLI, which signs the request and hands back the plaintext:

val sk = SikkerKey("vault_a1b2c3d4e5")
val apiKey = sk.getSecret("sk_a1b2c3d4e5")

The SDKs cover Kotlin, Go, Python, Node.js, .NET, and PHP, and the CLI does the same from a shell or a CI job.

How access is decided

Every read is a signed request, and a few things have to hold before SikkerKey returns a value: the signature checks out, the machine is approved and added to the secret's project, and it holds a grant for that secret. You can tighten a secret further with a per-secret access policy that adds conditions like a time window, an IP allowlist, a read-rate cap, or a co-signer. The Security overview walks through the full check in order.

What else SikkerKey does

That covers the core path. SikkerKey builds more on top of it:

  • Secret types. Beyond a single value, a secret can hold structured fields, rotate on a schedule, act as a canary that freezes a project the instant it is read, or be a one-time share link for handing a credential to a person. See Concepts.
  • CI/CD and containers. Pipelines and containers get a machine identity at runtime and read secrets the same way everything else does. See CI/CD and Docker; serverless functions use an in-memory identity covered in the SDKs.
  • Teams. Convert a vault to an organization to add members, each scoped by a vault role and an access role, with single sign-on for enterprise.
  • AI clients. The MCP server lets tools like Claude Code and Cursor manage your vault without reading any secret's value.
  • Encryption and audit. Secrets are protected with layered envelope encryption, and every action lands in an append-only audit log you can stream live, email, or send to a webhook. The Security overview has the full cryptographic model.

Start here

Quickstart takes you from nothing to a machine reading a real secret in a few minutes.