Hello dev.to — DevOps engineer building in public

Shivsai Anantwar — Wed, 24 Jun 2026 06:48:56 +0000

Hey everyone,

I'm Shivsai — a DevOps engineer working across cloud
infrastructure, pipelines, and SDLC tooling.

I've been working with client teams for a while now and
recently started building in public. My first project is
Tokenly — a local-only encrypted credential vault for
developers and DevOps teams. Built it after watching every
dev team I worked with store PATs and API keys in Notepad.

Stack I work with: Tauri, Rust, React, TypeScript,
and pretty much anything in the DevOps/cloud space.

Planning to write about:

Things I learn building Tokenly in public
DevOps patterns and anti-patterns from real client work
Security decisions and trade-offs in developer tooling

Glad to be here. Looking forward to reading and contributing.

github.com/MeShivsai/Tokenly
bitsandbooks.in

I built a local-only credential vault because every dev team I worked with stored PATs in Notepad

Shivsai Anantwar — Wed, 24 Jun 2026 06:39:18 +0000

The Problem I Kept Seeing

Over the past year working across multiple client teams on
DevOps and pipeline work, I kept noticing the same thing.

Developers storing GitHub PATs in Notepad.
QA engineers keeping API keys in a text file on the desktop.
DevOps folks with database passwords in a sticky note app.

During screen shares — sprint reviews, debugging sessions,
pair programming, recorded demos — those credentials were
just sitting there. Visible to everyone in the call.

Nobody said anything. It just kept happening.

Why Existing Tools Didn't Fit

I looked for something simple that solved this. Here's what
I found and why none of it quite worked:

Password managers (1Password, Bitwarden)
Good tools. But they're built around cloud sync, browser
extensions, and team sharing. For an individual developer
who just wants somewhere safe to keep a PAT — overkill.
Also: corporate IT policies often block installation of
cloud-synced password managers on work machines.

Secret managers (HashiCorp Vault, AWS Secrets Manager)
These are infrastructure tools, not personal workflow tools.
Setting up Vault for an individual developer's PAT collection
is like using a forklift to move a chair.

OS keystores (Windows Credential Manager, macOS Keychain)
Actually decent for storage. But no UI built for this
workflow, no copy-to-clipboard, and they don't solve the
screen-exposure problem at all.

The gap: Something simple, local, and designed around
the moment of use — not just storage.

So I Built Tokenly

Tokenly is a local-only desktop credential vault. The core
design principle is simple:

Credential values are never shown on screen.

You copy them to clipboard. That's the only way to use them.
The clipboard auto-clears after 30 seconds.

If you need to visually verify a value — press and hold a
button. Release it, the value hides immediately. Not a
toggle — a hold. Toggles get forgotten. Holds don't.

Technical Decisions Worth Explaining

Why Tauri over Electron

Tauri uses the operating system's existing WebView (Edge
WebView2 on Windows, WKWebView on macOS) rather than
bundling an entire Chromium browser. The result:

Installer under 10MB vs 150MB+ for Electron apps
Rust backend with explicit permissions — nothing the React frontend can do reaches the system without a registered Tauri command
Memory-safe backend by design

For a security tool, the permission model matters. Electron's
Node.js backend has broad filesystem access by default.
That's the wrong posture for a vault application.

Why AES-256-GCM specifically

AES-256-GCM is authenticated encryption — it doesn't just
encrypt, it detects tampering. Every encrypted blob includes
a 128-bit authentication tag. Wrong password or modified
file, the tag fails before any data is returned.

This means:

let plaintext = cipher
    .decrypt(nonce, ciphertext)
    .map_err(|_| "Wrong password or corrupted vault".to_string())?;

If decryption succeeds — the password was correct. If it
fails — wrong password or tampered file. No password
comparison ever happens. The encrypted data itself is
the verification mechanism.

Why Argon2id for key derivation

The master password is never stored anywhere. Instead,
Argon2id derives a 256-bit encryption key from the
password + a random salt:

DEV Community: Shivsai Anantwar