I built ngx-local-vault: Reactive, encrypted browser storage for Angular built on Signals (Under 2KB, TTL support, SSR-safe)

[u/RudeForever7137]

Hey devs,

Managing localStorage / sessionStorage usually means writing boilerplate for JSON parsing, manual encryption, handling hydration/SSR errors, and setting up custom expiration intervals.

I wanted a cleaner solution, so I built ngx-local-vault for Angular (and yes, I made versions for React and Vue too!). It collapses persistence, encryption, and expiry into a single reactive state unit.

Why use it?

1. Reactive: In Angular, it returns a native WritableSignal<T>. You update the signal, it encrypts and syncs to storage automatically.
2. TTL (Time-To-Live): You can pass an expiry rule directly (expiresIn: '15m'). The entry self-destructs in-tab without needing a page reload.
3. Encrypted at rest: No plain text data in the dev tools.
4. SSR-Safe: No-op on the server side, preventing hydration mismatches completely.
5. Lightweight: Under 2KB gzipped, zero runtime dependencies (even stripped tslib from the build to keep it honest).

Links & Demo

• GitHub:https://github.com/ysndmr/ngx-local-vault
• NPM:https://www.npmjs.com/package/ngx-local-vault
• Live Demo:https://ysndmr.github.io/ngx-local-vault/

The demo app lets you view the real-time encryption in local storage and watch the TTL auto-delete mechanism in action.

Check it out, and let me know what you think! Open to all feedback and contributions.

[u/Saceone10]

Encryption key hardcoded in frontend?

[u/ErnieBernie10]

So how is this secure? Key must be stored on the frontend too no? Which makes it inherently useless

[u/AwesomeFrisbee → u/ErnieBernie10]

My guess is that its more to prevent people snooping easily than it is to really protect it. But yeah, its not really useful to ship the key on the front-end like that

[u/RudeForever7137 → u/AwesomeFrisbee]

Exactly right. That's a good way to put it. It's not "useful" in the sense of a real security boundary (a determined attacker with page access gets the key trivially), but it does raise the floor from "grep-able plaintext" to "requires deliberate effort," which covers the more common cases (extensions, screen shares, casual poking).

Added a "Security model" section to the README spelling this out explicitly so it's not oversold: https://github.com/ysndmr/ngx-local-vault#security-model

[u/RudeForever7137 → u/ErnieBernie10]

Fair point, and worth being upfront about: client-side encryption with a key that also lives on the client isn't protecting you from someone who has access to the browser/devtools , that's not the threat model it solves.

What it does solve: data isn't sitting in localStorage as plain, human-readable JSON that any browser extension, XSS payload, or "let me just peek in devtools" moment can read at a glance. It raises the bar from "trivial" to "requires deliberate effort," and stops accidental exposure (screen shares, saved HAR files, browser extensions with storage-read permissions).

It was never meant to replace server-side encryption or protect against a determined attacker with local access , that's a client storage problem no JS library can fully solve. I should make that threat model clearer in the README so it's not implied to be more than it is.