Secure password vault and credential management tools for teams to store, share, and organise login information safely. All available with one-click installation on 365i web hosting.
A team password manager is a shared vault: one place where a small business, an agency or an IT department keeps the credentials that more than one person needs. Server logins, client control panel accounts, the FTP details for a site nobody has touched in three years. The commercial market here is crowded and good. Bitwarden charges US$4 per user per month on Teams and $6 on Enterprise, both billed annually. 1Password Business is $8.99 per user per month. Keeper and LastPass sell to the same buyers. All of them run the service for you, and for most teams that is the right answer.
Self-hosting is the other route, and it's narrower than it looks. Bitwarden's own server software is a container stack rather than a PHP application. Passbolt needs the PHP gnupg extension and an OpenPGP keyring sitting in the web server user's home directory, which rules out ordinary shared hosting before you start. TeamPass, the application in this category, is plain PHP and MySQL. That's exactly why it turns up on shared hosting when the others don't, and exactly why it deserves more scrutiny than a blog or a wiki would get.
What follows isn't a sales pitch. Putting a credential vault on the same server as your website changes your threat model, and we'd rather you understood that before you install it than afterwards.
Situations we see often. If one of these sounds like you, this category is worth a look.
Somebody keeps a workbook of admin logins on a network drive and everyone knows the file name. A vault with per-folder permissions and an audit trail is a large improvement on that, and it costs nothing per seat.
Offboarding is where shared credentials go wrong, because a leaver walks out still knowing passwords nobody thinks to rotate. Revoking one vault account and rotating the items that person could see is a defined task rather than a memory exercise.
Some public sector, legal and clinical buyers have procurement rules that will not clear a US-headquartered subscription vault, or need to name the infrastructure their data sits on. A UK-hosted install with a signed data processing agreement answers that in a way a subscription rarely does.
Staging logins and third-party API keys currently live in chat messages and forwarded emails, which is worse than any vault. A self-hosted vault behind HTTPS and two-factor authentication is a clear step up, provided the keys that matter most go somewhere better.
Password managers are attractive targets in themselves. They've been successfully attacked in the past, and realistically they will be again. So all your passwords could get stolen in one go.
The NCSC still says use one. The caution is about concentration: a vault turns a lot of small risks into one large one, whichever product you pick. Self-hosting doesn't remove that risk, it moves it onto your server and your patching discipline. Decide honestly whether you'll keep up with the updates before you commit.
if a hacker gets access to your database, he will not be able to decrypt the passwords as the saltkey is not accessible
Read that carefully, because it describes the scenario the design defends against and, by omission, the one it doesn't. Database access alone is survivable. Filesystem access alongside it isn't, since the key file lives on the same server. Put that file above the web root as the docs instruct, and keep the hosting account itself tightly locked down.
Self-hosted password managers should be boring and reliable, and that is what we tune for. We enforce SSL on every endpoint at install, recommend two-factor authentication on the admin user from day one, and make sure file permissions are tight. Daily backups are non-negotiable. We also set the application behind a strong cron-driven session expiry and remind clients that the master password is the one secret we genuinely cannot recover for them.
Maintenance status, plainly. TeamPass is actively developed. Version 3.2.1.7 shipped on 18 August 2026, with six releases in the three weeks before it, several of them security fixes for stored cross-site scripting and authorisation bypasses. That cuts both ways: an application receiving frequent security releases is one you have to keep updated. Its CVE history is real, including CVE-2024-50703, scored 9.3, where a user could act with another user's privileges, fixed in 3.1.3.1. None of that is unusual for a PHP application of this age. A vault just isn't a blog.
What it asks of the server. PHP 8.2 or newer with bcmath, gd, iconv, mbstring, mysqli, openssl and xml, plus an InnoDB database. All standard on our web hosting plans, with the PHP version selectable per package in the My365i control panel. The installer asks where to store its encryption key file, and the answer is always a directory above the web root.
Not for you if the vault would hold credentials whose loss would end the organisation, or if nobody owns the job of applying updates within days of release. Buy Bitwarden or 1Password instead. That's not a recommendation against ourselves, it's the honest answer.
Common questions we hear from people running password management systems applications on 365i hosting.
For most small teams, yes. Bitwarden Teams is US$4 per user per month billed annually and Enterprise is $6; 1Password Business is $8.99. At those prices you get browser and mobile clients, account recovery processes, and somebody else patching the server at three in the morning. Self-host when you have a specific reason: a procurement rule, a data residency requirement, an awkward number of seats, or a vault you already run and want to move. Cost on its own is a weak reason.
Through the Defuse PHP-Encryption library, using AES-256-CTR with HMAC-SHA256 for message integrity. The key for items in public folders is written to a file on the server, and the installer asks where to put it; the correct answer is a directory outside the web root. From version 3 onwards each user also has an RSA keypair, and item keys are shared to users through it. Personal items use a personal key, and if a user loses that, those items cannot be recovered.
Assume every credential in the vault is exposed and start rotating. The design means database access on its own does not yield plaintext passwords, because the key file is not in the database. Filesystem access alongside it is a different matter, and a web application compromise commonly gives an attacker both. This is the strongest practical argument for keeping a vault on its own hosting package, well away from the public website, or on a small managed cloud server that runs nothing else.
Our entry web hosting plan covers a team vault comfortably, because the workload is tiny and the database stays small. Configuration matters much more than resources here. Free wildcard SSL is on every plan, PHP version is selectable per package in the My365i control panel, and every package is backed up daily with 30 days of restore points. If the vault is important enough to self-host, give it its own package rather than a folder inside a public site.
No, and a host that could recover it would be a reason not to use the product. Encryption happens inside TeamPass, not in our platform, and a user's personal items are protected by a key only that user holds. A backup does not help either, because the backup contains the same ciphertext. Agree a documented break-glass process for administrator access, and test it, before you put anything important in the vault.
Get Password Management Systems apps up and running in minutes with our fast, reliable web hosting. Every plan includes one-click installation, free SSL, UK, US & Asia data centres, and dedicated expert support.
All prices exclude VAT. No contract, cancel any time.
All 1 password management systems applications available with one-click installation on our fast UK web hosting.
