Frappe Vault: Managing Secrets and Passwords

Yogesh Purohit Avatar
frappe-vault-featured-image

Frappe has slowly become a bigger part of how we run things at Lubus. We use it across different parts of our own operations, and we also use it for client work where ERP, HR, sales, support, and internal workflows need something more structured than scattered tools and spreadsheets.

That has been one of the things we have enjoyed about Frappe. It gives us a strong base to work from, but it also leaves enough room to shape things around how a team actually works. We use many first-party Frappe apps, and in places where the default flow is not enough, we build small custom layers on top.

The Problem

One area that kept coming back to us was access management. As a service and technology team, we deal with a lot of credentials, passwords, API keys, SSH keys, certificates, project notes, and client-specific access details. Some of this was managed in a central tool, some lived with individual teams, some sat inside documents, and some was frankly in places where it should not have been. It worked until it did not.

Why Visibility Matters

The problem was not just storing credentials. The bigger problem was visibility. Who has access to what? Which credentials belong to which client or project? What needs to be handed over when someone leaves a project? What should be shared with the client, and what should stay internal? These questions sound simple, but when information is fragmented, the answers are rarely clean. We wanted something that felt closer to how we already work.

Bringing Secrets Into Frappe

Since Frappe is becoming our internal business OS, it made sense to bring this layer into Frappe too. We did not want another disconnected place where secrets live. We wanted something that could sit next to our projects, clients, users, roles, and future workflows. Something simple to start with, but flexible enough to grow as our own needs and client needs become clearer.

That led us to build Frappe Vault.

What is Frappe Vault?

Frappe Vault is an open-source secrets and password management app for Frappe. It gives teams a centralized place to store, organize, share, and manage sensitive project information inside their Frappe/ERPNext setup.

At the moment, it supports storing different types of secrets such as passwords, API keys, SSH keys, certificates, and secure notes. Secrets can be organized into folders, shared with specific users or roles, and tracked through access logs. The app also includes a dashboard and REST API support, which gives us room to connect it with other tools and workflows over time.

Why It Matters Where It Lives

For us, the important part is not just the feature list. The important part is where it sits. When credentials live inside the same system where our team, clients, projects, and operations are already moving, handovers become easier. Client-specific access can be grouped better. Team access can be reviewed with more context. Internal and external sharing can become more intentional instead of depending on random documents, chats, or memory.

Built from Real Usage

We are currently using Frappe Vault internally and shaping it around real usage. Like many of our open-source tools, it started because we needed it ourselves. We had a messy problem in our own workflow, and instead of adding one more external layer, we decided to build something that fits into the stack we are already investing in.

What’s Next

It is still early, and we expect it to evolve as we use it across more projects and client situations. There are many directions this can grow into, especially around better handovers, browser integrations, client access workflows, stronger reporting, and deeper links with project or support systems inside Frappe.

The app is open source and available on GitHub for anyone to fork, customize, and use. If you are using Frappe internally and have faced similar issues around managing credentials, access, and handovers, feel free to explore it, open issues, suggest improvements, or send a pull request.

We are building this slowly, in the open, and from real operational pain.Tools we use. Tools we build.