Platform · Config

KERNSTACK Secrets

Secrets on KERNSTACK are declared like everything else: a resources.secrets entry either generates its value on deploy or receives one from deploy-time sources, after which the stored canonical stack replaces the value with a ref-secret:// reference. Code refers to secrets by indirection — {{ref-secret-stack://name}} in environment variables — so the repository, the plan, and the review never carry a credential.

Secrets Store

Talk to us Read Secrets Docs → Software Lifecycle Cloud →

Why teams replace assembled cloud services with KERNSTACK Secrets

Teams otherwise scatter secrets across CI settings, a vault product, and .env files on laptops, with rotation meaning a scavenger hunt. On KERNSTACK the set of secrets a project needs is enumerable from its manifest, and their values never appear in it.

Where values come from

Three honest sources: generate: true for platform-minted values; a literal value in stack.json only for non-sensitive configuration-shaped secrets (the deploy replaces it with a reference); and the gitignored .stack.env file (with per-profile overlays) referenced as {{ref-env-file://KEY}} for values that must never touch git. Missing keys fail the deploy loudly rather than starting a worker with a blank credential.

Rotation and scope

A secret belongs to the project and its environment target; previews and agent environments hold their own values, so a leaked demo credential is a demo incident. Inside deployed functions and workers, platform credentials arrive as injected environment variables (KERNSTACK_ACCESS_KEY_ID, KERNSTACK_ACCESS_KEY_SECRET, KERNSTACK_DZONE) — code reads them from the environment, never from source.

The canonical stack stores ref-secret:// — post-deploy files are safe to show in a review
Gateway API keys are their own declared objects with rotation on the route
Reference material under reference/ stays out of deploys by contract, secrets included

SDKs & Language Integration

Every KERNSTACK environment vendors typed SDK packages into .kernstack/ so both engineers and coding agents in Agent Sandboxes can call Secrets without external credentials:

Go SDK: github.com/coding-berlin/kernstack-sdk-go/sdk_secrets
Node.js SDK: kernstack-sdk
Python SDK: kernstack_sdk
PHP SDK: Kernstack\Secrets

Secrets in the Project Graph

Declarestack.jsonsecrets

RunSecretscode

MeterOne credit balanceEU zone

stack.json — secrets configuration plan · deploy

{
  "resources": {
    "secrets": [
      { "name": "signing-key", "generate": true },
      { "name": "partner-api-token", "value": "{{ref-env-file://PARTNER_API_TOKEN}}" }
    ],
    "workers": [{ "name": "hooks", "runtime": "nodejs",
      "env_vars": { "PARTNER_TOKEN": "{{ref-secret-stack://partner-api-token}}" } }]
  }
}

Metering · compute, storage, or network 1 Shared Balance

Usage draws from the same credit balance as compute (0.01 credits/GiB-s), storage (0.04 credits/GB-hour), and egress (9.00 credits/GiB).

Replaces: AWS Secrets Manager · no native equivalent · no direct equivalent

FAQ

Frequently asked questions

Should secret values be committed to stack.json?

No. Declare the secret, supply the value at deploy time from .stack.env or generation, and let the platform store the ref-secret reference. The committed file proves which secrets exist without containing any.

How does rotation work?

Change the supplied value (or regenerate) and deploy; consumers resolve the reference at runtime. Gateway keys rotate by declaration on their route with the new raw key printed once.

Can agents see secrets?

Agents see that secrets exist — the manifest is the map they plan against — but values resolve inside the platform. An agent’s plan can add a secret declaration; it cannot print a production credential into a diff.

Connected in the Project Graph

Related capabilities, architectures, and comparisons

Ship your stack on the Software Lifecycle Cloud.

Closed preview on dedicated European infrastructure. Bring a repository or start from a blueprint.

Talk to us See pricing & credits →