










Shifting background utility architecture away from resource-heavy Electron runtimes toward a highly efficient Tauri (Rust) + SvelteKit stack is a massive win for systemic performance. Clipboard managers must run persistently without introducing input latency, and Ortu achieves an incredibly light memory footprint by compiling into a tiny, native binary. Utilizing a local SQLite database equipped with FTS5 handles full-text indexing smoothly, allowing instantaneous historical queries over thousands of entries without spiking CPU cycles. The paste stack is the standout workflow unlock here—allowing developers to sequentially queue disparate code snippets or log paths and pipe them into a terminal one by one without endless window-switching friction. Furthermore, incorporating client-side AES-256-GCM encryption for automated secret masking solves the exact data-leak liability that typically prevents engineers from using clipboard history tools alongside production tokens and SSH keys.
While SQLite is an exceptional engine for indexing raw text and structured strings, handling binary objects—like high-resolution screenshots, clipboard image captures, or multi-megabyte file references—directly within the database file will inevitably cause database bloating and disk write fragmentation over months of heavy utilization. The tool needs a strict, automated vacuuming routine or an externalized blob storage model for media to prevent database degradation. Additionally, the smart auto-grouping heuristics can still struggle with ambiguous inputs, occasionally misclassifying mixed-syntax log outputs or raw CSV strings into the wrong category. Expanding the system to support custom regex-based filtering templates would allow developers to enforce exact structural routing definitions manually.
I’ve previously balanced platform-isolated utilities like Maccy on macOS and Ditto on Windows, alongside heavier cross-platform tools built on traditional web wrappers. While native Swift or Win32 utilities offer exceptional performance, they fragment your muscle memory and shortcut configurations the moment you switch operating systems between dev machines. On the other hand, traditional cross-platform options frequently introduce unnecessary cloud synchronization liabilities, mandatory account gates, or bloated RAM overhead. I chose Ortu because it delivers local-first, open-source transparency and a unified cross-platform interface without punishing system resources or compromising credential privacy.
tauri + sqlite fts5 + no electron is a good sign for something that's meant to sit quietly in the background all day. one question on the secret masking - since it's presumably detecting secrets by pattern (known token/key shapes) rather than a hardcoded list, what happens to an arbitrary sensitive string that doesn't match a recognized pattern, like a random internal password someone pastes that isn't formatted like an API key? does it fall back to encrypting everything at rest regardless of whether it was flagged as a secret, or is the AES-256 specifically reserved for things that got detected? the headline feature is "secret masking" so i'd want to know if there's a safety net under it.
@galdayan Great question, and worth being precise about: AES-256 is field-level, reserved for flagged items... it's not whole-database encryption. Two paths get an item encrypted + masked: (1) the classifier flags it (it's score-based structural detection, entropy, token shapes, key/value context... not a hardcoded regex list, so it catches more than just known API-key formats, but it's still heuristic), or (2) you mark any item sensitive manually, that's the safety net for the random internal password case. Manually-marked items get the same AES-256-GCM treatment, masked in the UI and revealed on demand.
So today, an arbitrary string the classifier misses and you don't mark stays plaintext in the local SQLite DB (which never leaves your machine). There's also a one-click pause-capture toggle for moments you don't want anything recorded. An opt-in "encrypt everything at rest" mode is a fair ask and it's on my radar, the design (per-field enc:v1: tagging with a local 0600 key file) was built so that can be layered on. Appreciate you pushing on the headline claim 🙏
@abhijith_p_subash that's the honest answer I was hoping for - plaintext-until-flagged is a real tradeoff, not a marketing gap. the pause-capture toggle is a good stopgap in the meantime, though it only helps if someone remembers to hit it before pasting the sensitive thing, which is exactly the moment people forget. the per-field enc:v1 tagging already being in the design is the part that matters, means the opt-in mode isn't a rewrite when you get to it.
@nimet3paw It stays snappy 🙂 Search isn't a table scan — it hits a SQLite FTS5 full-text index that's kept in sync by triggers on every insert/update/delete, with a fuzzy re-ranker on top of the match results. FTS5 handles tens of thousands of rows without breaking a sweat, so thousands of clips is well within comfortable territory. On top of that, retention is configurable (age-based or a max-items cap, pinned/grouped items always kept), so the DB stays bounded by default rather than growing forever. If you ever do feel a slowdown, that's a bug — file an issue and I'll dig in.
@douakrimdriss That's exactly the moment I hoped people would hit... it quietly working out what's code, links, colors, etc. without any tagging ceremony. And yeah, local-only with no account isn't a growth strategy, it's the whole point 😄 Thanks for giving it a real evening's use!
@ezgiirru "Found a snippet I'd lost weeks ago in seconds"... that's the exact use case that made me build the FTS5 search, so this comment made my day. And no random cloud, ever: everything stays in a local SQLite file on your machine. Thanks for trying it! 🙏