Skip to content
Since 2009

About the project

Teampass is a long-lived open-source project with a small core team. Here is who builds it, how it is funded, and what that means for you.

What it is

Teampass is a collaborative password manager you install on your own servers. It started in 2009 as a way to stop a team sharing credentials through documents and email, and it has been developed continuously since then — currently in the 3.2 line, with authenticated encryption and access governance features that would have sounded absurd for the original version.

It is released under GPL-3.0. The source is public, the issue tracker is public, and the security advisories are public. You can verify every claim on this website by reading the code.

Who builds it

Teampass was created by Nils Laumaillé, who still writes most of it, answers most of the discussions and handles the security reports. Contributions come from users through pull requests, bug reports and translations.

That is worth being straight about: this is not a venture-funded company with a support desk. It is a small project that has shipped for fifteen years. The upside is that the person answering your question wrote the code. The downside is that there is a limit to how many questions one person can answer — which is exactly why the commercial options exist.

How it is funded

The server is free and stays free. The browser extension is a paid add-on, and that revenue — along with sponsored development and GitHub Sponsors — is what pays for the time that goes into the open-source server.

The alternative model, where the interesting features get held back for a paid edition, was deliberately avoided. Encryption, access control, recertification, compliance export, SSO and the API are all in the free server. If that arrangement matters to you, the most useful thing you can do is sponsor it.

How security is handled

Vulnerabilities are reported through the security policy, fixed in a release, and published as GitHub Security Advisories. Nine were published with 3.2.1.1 alone. Making that history public is a deliberate choice — see the security page for the reasoning and the full model.

Contributing

Pull requests, bug reports, translations and documentation improvements are all welcome on GitHub. If you are planning something substantial, open a discussion first — it is a faster route to a merged change than a large surprise pull request.

Fifteen years, still shipping.

The best way to support the project is to use it, report what breaks, and tell people it exists.