Docker

SikkerKey provisions a complete machine identity for each container straight from the dashboard. You pick the project and the secrets the container should access, download the resulting bundle, mount it into the container, and the SDK or CLI picks it up automatically. No bootstrapping inside the image, no private keys in environment variables, no scripts that reassemble an identity at startup.

How It Works

1. From the dashboard, go to Integrations and expand Docker
2. Click Create Container
3. Fill in the provisioning form:
   • Machine Name. Optional. Auto-generated if left blank.
   • Project. The project whose secrets the container should access.
   • Secrets. Tick the secrets you want this container to read. Select all if the container needs every secret in the project.
4. Click Provision. SikkerKey generates an Ed25519 keypair server-side, approves the machine, links it to the project, and grants access to each selected secret.
5. Click Download .sikkerkey. You receive a ZIP containing identity.json, private.pem, and cli.json. This download is single-use and expires after 15 minutes. Keep the files in a secure location on your host.

The machine appears on the Machines page like any other machine. You can rename it, disable it, revoke its access, or delete it from there.

Using the Bundle

Extract the ZIP into a directory on your host, then mount that directory into the container at /etc/sikkerkey/. Set the SIKKERKEY_IDENTITY environment variable so the SDK finds the identity file.

docker run

docker run \
  -e SIKKERKEY_IDENTITY=/etc/sikkerkey/identity.json \
  -v /path/to/my-container:/etc/sikkerkey:ro \
  myapp:latest

docker-compose

services:
  app:
    image: myapp:latest
    environment:
      SIKKERKEY_IDENTITY: /etc/sikkerkey/identity.json
    volumes:
      - ./my-container:/etc/sikkerkey:ro

The mount is read-only so the container cannot modify the identity at runtime.

Reading Secrets

With an SDK

Install the SikkerKey SDK for your language. With SIKKERKEY_IDENTITY set, the SDK loads the identity automatically:

from sikkerkey import SikkerKey

sk = SikkerKey()
db_url = sk.get_secret("sk_database_url")
api_key = sk.get_field("sk_stripe_keys", "secret_key")

import { SikkerKey } from '@sikkerkey/sdk'

const sk = new SikkerKey()
const dbUrl = await sk.getSecret('sk_database_url')

The SDK signs every request with the machine's Ed25519 private key. Secret values are fetched on demand and decrypted in memory. Nothing is cached to disk.

With the CLI

The bundle includes cli.json, so the CLI works inside the container without running connect or unlock. Install it in your image and use it directly:

FROM node:20-slim
RUN npm install -g @sikkerkey/cli
WORKDIR /app
COPY . .
ENTRYPOINT ["sikkerkey", "run", "--all", "--"]
CMD ["node", "server.js"]

sikkerkey run --all fetches every granted secret, exports them as environment variables, and executes the command. Your application reads process.env.DATABASE_URL and similar without knowing SikkerKey is involved.

Multiple Containers

Each container should have its own provisioned machine identity. Provision a separate container from the dashboard for each deployment target and mount each bundle into the corresponding container. This gives you per-container access control and per-container audit trails.

Sharing a single identity across multiple containers works technically, but every secret read appears under the same machine in the audit log, and revoking access for one container revokes it for all of them. The per-container pattern is stronger.

Revocation

To revoke a container's access, go to the Machines page, find the provisioned machine, and either disable it or delete it. Disabling stops signature verification immediately. Deleting removes the machine row and all its secret grants.

Deleting the container in your Docker environment does not automatically revoke its SikkerKey access. The identity file can still be used from anywhere until you disable or delete the machine in SikkerKey.

Lost Identity Files

If you lose the downloaded identity.json and private.pem, the machine cannot be recovered. Revoke the machine on the Machines page and provision a new container. This is an intentional security property. SikkerKey never stores the private key after download, and there is no regeneration endpoint.

Team Member Provisioning

Team members can provision containers for projects they have the Manage Provisioned Machines permission on. Grant the permission from the team member's project settings. Provisioned machines are owned by the team member who created them and follow the same lifecycle as their manually attached machines. When a team member is removed from the vault, SikkerKey prunes their machines' project links and secret grants.

Security

• Server-generated keypair. The Ed25519 private key is generated on SikkerKey's servers, encrypted at rest, and delivered once via a single-use download link. Once downloaded, the encrypted copy is deleted from SikkerKey.
• Short download window. Download links expire 15 minutes after provisioning. Expired links are removed from the database automatically.
• Read-only mount. The example mounts the identity directory with :ro so a compromised container cannot tamper with the keys it holds.
• Audit logged. Provisioning, download, and every secret read are recorded in the audit log with timestamps, source IPs, and actor information.
• Per-request signing. Every secret request is signed with the container's Ed25519 key and verified with a fresh timestamp and nonce. Replayed requests are rejected.
• Revocation is immediate. Disabling or deleting the machine from the Machines page stops all future secret reads the next time the machine authenticates.

Requirements

• Docker 20.10 or newer, Docker Compose v2 or newer
• A SikkerKey SDK or the SikkerKey CLI inside the container
• Sufficient machine quota on your plan to provision the container
• For team members: the Manage Provisioned Machines permission on the target project