This guide takes you from an empty vault to an application reading its first secret. You will create a project, store a secret in it, enroll the machine that needs it, and read the value back from both the command line and your code. The whole path takes about five minutes, and you never create an API key or paste a token into a config file along the way.

A SikkerKey secret is bound to a machine identity. It can be read only by a specific machine that proves who it is by signing each request with a private key it never shares. There is no shared token in the loop, so there is nothing to copy into a config file or leak in a log. That is why reading a secret starts with giving a machine an identity, which is the part this walkthrough spends the most time on.

What you'll need

Access to your SikkerKey dashboard.
A machine you want to read the secret from: a laptop, a server, a CI runner, or a container. Linux, macOS, and Windows all work.
About five minutes.

Step 1: Create a project

Projects are how SikkerKey groups secrets and decides which machines can read them. Every secret lives inside one project, so you always start by making a project.

From the dashboard, open the Projects panel and click the plus icon.

Give the project a name such as Production or Billing API, add an optional description, and click Create Project.

You now have an empty project ready for its first secret.

Step 2: Create your first secret

Open the project, go to its Secrets tab, and click the plus icon. SikkerKey offers a few secret types:

Secret for a single value such as an API key or a connection string.
Structured Secret for a value with multiple fields, like a full set of database credentials.
Managed Secret for a value SikkerKey rotates on a schedule.
TTL Secret for a value that expires on its own after a set time.
Canary Secret for a decoy that stays unused and alerts you the moment anything reads it.

For your first secret, choose Secret. Give it a name, paste the value, add a note if you want a reminder of what it is for, and click Create Secret.

The value is encrypted the instant you save it, with a unique key for that secret.

Your secret appears in the project at version v1 with a Last Read of Never. Nothing has read it yet, because nothing is allowed to.

Save this secret ID. Each secret has an ID that looks like sk_i4asd90ff6, shown next to its name with a copy icon. You will pass that ID to the CLI and the SDK in the steps below to read the value, so copy it somewhere handy now.

Step 3: Give a machine an identity

Before anything can read your secret, you enroll the machine that needs it. The machine creates its own keypair, keeps the private half, and registers only the public half with SikkerKey. From then on it authenticates by signing its requests, so there is no key for you to hand out or store.

Go to Machines in the vault sidebar, click the plus icon, and choose Machine.

Pick your platform (Linux, macOS, or Windows) and run the one-line bootstrap command it gives you. On Linux and macOS it looks like this:

curl -sSL https://api.sikkerkey.com/v1/bootstrap/<enrollment-token> | sh

The script generates an Ed25519 keypair on the machine and stores the identity under your home directory at ~/.sikkerkey/. The private key never leaves the machine. On Windows you get the equivalent PowerShell command from the same screen.

When it finishes, the machine is registered and waiting for approval.

Step 4: Approve the machine

A machine that has just enrolled starts in a pending state and can do nothing until you approve it. Anyone with an enrollment token can register a machine, but it stays inert until you approve it, so approval is your checkpoint.

Go back to Machines, find the machine you just enrolled, and click the approve button. It moves to an active state.

Step 5: Add the machine to the project and grant the secret

Approval lets the machine exist in your vault. It still cannot see a single secret until you do two more things: add it to the project, then grant it the specific secret.

First, open your project's Machines tab, click the plus icon, find your machine under Available, and click Add. The machine joins the project.

Then, in the project's machine list, open that machine's access settings with the gear icon.

The secret you created shows up under Available. Click Grant, then Save.

This two-step grant is deliberate. A machine can read only the exact secrets you hand it, and nothing else in the vault, including other secrets in the same project. Access is something you give on purpose, one secret at a time.

Step 6: Read the secret from the command line

The machine is now allowed to read the secret, and you can confirm it in a few seconds. The SikkerKey CLI uses the identity you just enrolled, so you never pass it a key or even a vault name:

sikkerkey list projects
sikkerkey list secrets
sikkerkey get sk_i4asd90ff6

list projects shows the projects this machine can reach, list secrets shows the secrets it has been granted, and get takes the secret ID you saved and returns the value. Every call is signed with the machine's private key. SikkerKey verifies the signature, checks the grant, and returns the plaintext. Back in the dashboard, the secret's Last Read updates to just now.

Read the secret from your application

In production your application reads the secret at runtime instead of a person running a command. The SDK uses the same machine identity, so there are still no keys in your code or your environment variables. Here it is in Node.js:

import { SikkerKey } from '@sikkerkey/sdk'

const sk = SikkerKey.create()        // auto-detects the machine's vault
const dbUrl = await sk.getSecret('sk_i4asd90ff6')

And the same thing in Python:

from sikkerkey import SikkerKey

sk = SikkerKey()                      # auto-detects the machine's vault
db_url = sk.get_secret("sk_i4asd90ff6")

SikkerKey ships official SDKs for Node.js, Python, Go, .NET, Kotlin/JVM, and PHP, all with the same shape: construct the client, call get with the secret ID, receive the value. The client signs every request with the machine's key and pulls the secret fresh at runtime, so the value never has to be written to disk.

What you just set up

Look at what protects your secret now. It is bound to a machine identity, so it can be read only by a machine you enrolled and approved by hand, and only for the one secret you granted it. Every read is signed and written to the audit log, and if a machine is ever lost or retired you revoke its access in a single click without touching the secret itself.

That is the shape of every secret in SikkerKey: the thing reading it has a name, and you decide what that name is allowed to see.

Where to go next

Run your app with a project's secrets injected straight into its environment, no code changes required: sikkerkey run --all -- your-app.
Turn on automatic rotation so a value changes on a schedule and your machines always read the current one.
Add an access policy to cap how often, or from which addresses, a secret can be read.

You now have the full loop: a secret created, a machine that can prove who it is, and a grant that connects the two. Everything else in SikkerKey builds on these same pieces.