Good day,

I'm the author of the tool and thank you very much for all your comments so far. Let me address some points raised in the comments and put some context around the tool:

1) Why the tool was developed

The tool was actually developed for internal Cloudflare use. We use it to manage secrets and cryptographic keys on our stateless servers. The main problem it solves is how to make sure various cryptographic keys and credentials stay the same on an otherwise stateless server (which can be rebooted/wiped any time). We do use it exclusively with the "seed" mode.

It is just when we developed the tool, we saw it may be an alternative to a traditional password manager and follows the approach of some other existing "stateless" password managers, so decided to open source it. The main reason though we needed to develop our own tool instead of using an existing one is that we needed the ability not only to derive passwords from a seed, but also cryptographic keys (RSA, ECC, x25519). However, the tool does not intend to compete with existing established password managers.

For more details on how we use the tool internally check out my presentation from https://youtu.be/2RPcIbP2xsM. The presentation shows some nice secret rotation capabilities we get from using this approach.

2) "Vaultless" does not mean "stateless"

The tool actually somewhat explicitly calls itself "vaultless", but not "stateless" (unlike other similar password managers). After looking into similar solutions we do recognise that a fully stateless password manager would probably have a bad UX (because of all the points raised in the comments here and probably more). However, as some commenters rightfully noticed, managing state for this password manager would be somewhat different from managing a vault from a traditional password manager:

* you don't need "ongoing" seed replication unlike a traditional vault replication - in a multidevice scenario, if you add a password on one device, you would need to replicate vault to other devices after each new password added (before you can actually use the password on the other device). With this approach you would need to replicate the seed file once, and thus all your current (and future!) passwords will be automatically replicated

* if you do choose to store per account state (like password requirements, username etc) - this information is less critical from security point of view (but still critical from a privacy point of view). This file can still be encrypted with a key derived from the seed file though (before storing it on a public cloud for example). Also, if you lose access to your vault (your cloud provider suddenly has an outage) - you lose access to all your accounts. With this separate seed/account metadata approach - if you lose access to the metadata file, you can still reasonably get access to your accounts (although with a worse UX - as you would have to check the service password requirements, if any and remember your username). You would likely remember these for your often accessed (and critical) services, like primary email, bank account etc

3) Inconvenient UX

We do recognise that while we can talk about better UX by replicating a seed file or managing an account state/metadata file, the tool doesn't actually implement these. This is partially because of 1) (we don't need this at this point and we don't compete with password managers), however the code was structured in a way that it can be used as a library in other Go projects. Therefore, other user interfaces can be developed on top of it, which can also provide a GUI, seed replication and metadata management. Think of this code as a building block rather than a full-featured password manager and we would be happy to see more frontend applications developed based on it.