NEW v1.0.0-RC is live — a release candidate, not a candidate for your weekend

Secrets management,
without the ceremony.

Rune is an open-source secrets manager for people who'd rather ship than babysit a vault cluster. Encrypted storage, seal/unseal, namespaces, token RBAC, audit logs, automated rotation and versioning — from the CLI, the Web UI, or straight into your Spring Boot app.

$ curl -fsSL https://raw.githubusercontent.com/runelock-io/rune/main/scripts/install.sh | sh

Try it in your browser Read the docs

licenseopen source
shipsrune + rune-server
sdkjava · maven
ceremony0 ms

FIG. 01anatomy of a secretSEALED

pathproduction/db-password

namespaceproduction

versionv1v2v3

tokenci-deploy → production:read,rotate

payload

encrypted at rest·versioned·scoped

No unseal ceremony. No quorum. No candles. Vault is a lifestyle. Rune is a binary. Your .env file called. It wants to retire. Shamir's Secret Sharing is great at parties. Overkill for one DB password. Zero clusters were harmed in the making of this vault. We seal the vault so you can unseal your weekend. A Slack DM is not a secrets manager. HCL not required. Feelings optional. Rotate secrets, not on-call engineers. RBAC without a 40-page policy doc. Audit logs: because "who did that?" deserves an answer. Tokens expire. Unlike that one API key from 2019.

01 / live demo

Don't read about it. Type it.

A simulated Rune vault running entirely in this tab, logged in with the root token. It starts sealed — because of course it does. Click through the commands or type your own: create a read-only token, log in with it, and watch RBAC say no. Nothing leaves your browser.

~/projects/api — rune — 96×28

try →

02 / spec sheet

Everything you need.
Nothing you'll explain at a postmortem.

Encrypted secrets

Encrypted before they touch disk. At rest, by default, without a flag you'll forget.

at-rest

Seal & unseal

Lock the vault when secrets shouldn't be reachable. Explicitly. Every time. No vibes-based security.

rune seal

Namespaces

Isolate secrets by environment, app or team. Production stays production.

-n production

Token RBAC

read, write, delete, rotate — granted per namespace, per token. Least privilege, most chill.

-n production:read,write

Token expiration

Tokens that end. Unlike that one API key from 2019 that's still in a CI variable somewhere.

expiry

Audit logging

Who read what, when, with which token. Because "who did that?" deserves an answer.

audit

Rotation, manual or automated

One command, or on a schedule. The old value stays encrypted in history, not in your clipboard.

rune rotate

Secret versioning

Every rotation keeps an encrypted version you can inspect and fetch later.

rune history

Version-aware deletion

Delete a secret and its whole history goes with it. Nothing lingers. No ghosts.

rune delete

App & service identities

Your services get their own identity — not a human's token copy-pasted into a deployment.

system tokens

Java SDK

A Spring Boot starter that resolves ${rune.db-password} before your beans wake up.

maven

CLI first. Web UI too.

Native in a terminal — with a browser UI for the days you'd rather click.

rune · rune-server

03 / versioning & rotation

Your secrets have a history.
Unlike your DMs, it's encrypted.

terminalhistory.sh

$ rune rotate db-password -n production

  SECRET ROTATED
  ──────────────────────────────────────
  Namespace:   production
  Key:         db-password
  New Value:   q7W!xR2m…
  ──────────────────────────────────────
✔ Secret rotated successfully

$ rune history db-password -n production
  VERSION   CREATED                ROTATED
  1         2026-10-02T09:12:04Z   -
  2         2026-10-02T09:12:04Z   2026-10-09T14:03:51Z
  3         2026-10-02T09:12:04Z   2026-10-21T08:41:17Z
  4         2026-10-02T09:12:04Z   2026-11-01T10:30:42Z

04 / token rbac

Not every token deserves
the keys to the kingdom.

Token RBAC, one flag at a time: read, write, delete, rotate — per namespace, per token. Give tokens an expiry, give services their own identity, and let the audit log remember who did what. No 40-line policy file required.

terminalrbac.sh

$ rune token create ci-deploy -n production:read,rotate
✔ Token created successfully

  Name:        ci-deploy
  production   read, rotate

  Token: 9f3c…e1a7

$ rune login 9f3c…e1a7
✔ Token saved successfully

$ rune put stripe-key sk_live_… -n production
✖ [AUTHORIZATION DENIED]: Token cannot write to this namespace

05 / web ui

Prefer clicking?
There's a Web UI for that.

rune-server serves a Web UI right next to the API — no installer, no app store, no Electron was summoned. Unseal, browse namespaces, reveal and rotate secrets, manage tokens, read the audit log. It's wired to the same demo vault as the terminal above: do something there, watch it land here.

/ui/

namespaces / production

0 secrets

Vault is sealed.
Secrets are encrypted and unreachable — exactly as advertised.

start itserver.sh

$ 

  rune  local-first secrets vault

  ➜  api    
  ➜  ui     /ui/

  ⬡ vault sealed — run rune unseal

Browse namespaces and the secrets inside them
Reveal, create & rotate secrets without a terminal
Inspect versions of anything you've rotated
Manage tokens, their permissions and expiry
Read the audit log — every read, write and rotate
Seal status at a glance — and a button to fix it
Runs anywhere a browser does. Mac, Linux, that ThinkPad.

06 / java sdk

Secrets in your Spring app.
Not in application.yml.

The Rune Spring Boot starter pulls a namespace's secrets at startup and hands them to Spring as plain properties — ${rune.db-password} resolves before your beans wake up. Need more control? Inject RuneClient and ask directly. Zero extra HTTP dependencies.

<dependency>
  <groupId>io.rune</groupId>
  <artifactId>rune-spring-boot-starter</artifactId>
  <version>0.1.0</version>
</dependency>

dependencies {
    implementation 'io.rune:rune-spring-boot-starter:0.1.0'
}

rune:
  url: http://localhost:2710
  token: ${RUNE_TOKEN}        # a scoped, read-only token. please.
  namespace: production
  fail-fast: true             # no secrets, no boot

// property injection — resolved at startup
@Value("${rune.db-password}")
private String dbPassword;

// or ask at runtime
private final RuneClient rune;

String key = rune.getSecret("production", "stripe-key");
List<String> keys = rune.listKeys("production");

java 17+spring boot 3no jackson neededfail-fast

01 · bootSpring loads application.ymlrune.url · rune.token · rune.namespace
02 · fetchStarter calls rune-serverGET /secret/list → /secret/get, bearer token
03 · injectSecrets become propertieshighest-precedence source · ${rune.<key>}
04 · runYour beans start, secrets in handnothing on disk, nothing in git

Spring Boot starter docs →

07 / ceremony index

A vault,
minus the ceremony.

We like HashiCorp Vault. It solves org-scale problems for org-sized teams. Rune is for when you have secrets, not a platform team.

Running a full Vault Rune

First secret stored Pick a storage backend, write config, init, distribute key shares, enable an engine, write a policy… then put. curl | sh → rune-server → rune login → rune put. Done.

Unsealing Gather a quorum of key holders. Hope one isn't on a flight. rune unseal

Access policies HCL, paths, capabilities, a second coffee. -n production:read

Who runs it Usually a platform team. Sometimes a rotation. You. Between commits.

GUI Web UI. Web UI. (We agree on this one.)

Ceremony

08 / roadmap

Shipped, shipping, scheming.

Available 16

Secret CRUD
Encryption
Seal / unseal
Token authentication
Namespace management
Namespace-bound tokens
Secret rotation
Secret versioning
Version-aware deletion
CLI installation
Token RBAC
Audit logging
Token expiration
Automated rotation
Application / service identities
Java SDK (Maven)

Next release 4

Kubernetes secret mapping
Auto secrets injector
Secret rollback
Rotation policies

sneak peek

Map Rune namespaces to Kubernetes, and let the injector hand secrets to your pods. Your YAML will never know what it was missing.

Future 3

Dynamic secrets
Remote storage
High availability

09 / install

Up and running
before your coffee cools.

curl -fsSL https://raw.githubusercontent.com/runelock-io/rune/main/scripts/install.sh | sh

Detected OS: darwin
Detected ARCH: arm64
Downloading Rune...
Installing Rune...

Rune installed successfully

Run:
  rune --version     # rune v1.0.0-RC
  rune-server        # api + web ui on :2710

# OS: darwin | linux   ARCH: amd64 | arm64
VERSION=v1.0.0-RC OS=darwin ARCH=arm64
BASE=https://github.com/runelock-io/rune/releases/download/$VERSION

curl -L $BASE/rune_${OS}_${ARCH} -o rune
curl -L $BASE/rune-server_${OS}_${ARCH} -o rune-server
chmod +x rune rune-server
sudo mv rune rune-server /usr/local/bin/

# needs Go + Node (for the web ui build)
git clone https://github.com/runelock-io/rune.git
cd rune
make install

<!-- pom.xml -->
<dependency>
  <groupId>io.rune</groupId>
  <artifactId>rune-spring-boot-starter</artifactId>
  <version>0.1.0</version>
</dependency>

# brew install rune
# ...not yet. it's still brewing.
# use the install script for now — it's one line.

1rune-serverset a passphrase, copy the root token (shown once)
2rune login <root-token>saves it for the CLI
3rune unsealthen put, get, rotate — or open :2710/ui/

Full install guide in the docs →

open sourceself-hostedno accountno sales call

10 / philosophy

Security should be understandable.

You should know where your secrets live, how they're encrypted and who can read them. No black boxes. No unnecessary infrastructure. No vendor lock-in.

Read the source → Open an issue