Original verification report

Password Manager Hosting Availability Audit 2026

Original verification data for concrete third-party hosting pages across eight popular password and secrets projects.

Verified 2026-09-23 · eight most-starred live projects in Password Managers & Secrets · download CSV

In this eight-project sample, 3 of 8 projects had a concrete page at at least one tested third-party provider: PikaPods had 1 concrete app cards and Elestio had 3 project-specific managed-service pages.

Sampled projects

8

PikaPods app cards

1/8

Elestio project pages

3/8

Catalog managed flag

3/8

Project-by-project verified results

PikaPods availability requires a named app card in its public catalogue. Elestio availability requires HTTP 200 plus a project-specific “Managed … as a Service” title. A provider homepage, ignored search parameter, or 404 does not qualify. No checkout was attempted.

Continue from availability to product fit

A concrete hosting page does not make the software a fit. Compare features, operational responsibility, and official-cloud options next.

Table of Contents

What this audit measures

This audit measures whether eight leading live projects in OpenAlt’s Password Managers & Secrets category have a concrete third-party managed-hosting path visible in two public provider surfaces. It does not rank hosting quality or recommend a deployment.

The report is titled Password Manager Hosting Availability Audit 2026 and is published at /reports/password-manager-hosting-availability. The sample contains the eight most-starred live projects in OpenAlt’s production catalogue snapshot. Stars rank the sample only; they do not measure hosting quality, security, maturity, or operational suitability.

OpenAlt tested two provider signals on 2026-09-23:

  • PikaPods available means the project name appeared as a concrete app card in the public PikaPods catalogue HTML fetched on that date.
  • Elestio available means the generated project-specific /open-source/<repo> page returned HTTP 200 with a project-specific Managed ... as a Service title on that date.

PikaPods availability does not mean the search query parameter worked, and it does not mean checkout was completed. For Elestio, a 404 is unavailable, and no checkout was attempted.

OpenAlt also records a separate Catalog managed flag. This is a current project-level managed-hosting flag in OpenAlt’s catalogue. It may describe an official vendor cloud or another hosted path, so it is not expected to match the two third-party catalogues exactly.

Each report has a downloadable CSV and direct links to the tested project pages and provider catalogues in the page shell. The CSV source is /api/reports/hosting-audit.csv?report=password-managers. Provider sources are the public PikaPods apps catalogue at https://www.pikapods.com/apps and project-specific Elestio pages using https://elest.io/open-source/<repo>.

Results at a glance

The snapshot found one concrete PikaPods app card, three project-specific Elestio pages, and three projects with at least one tested provider path.

SignalResultProjects or interpretation
PikaPods concrete app cards1/8Vaultwarden
Elestio project-specific pages3/8Vaultwarden, Infisical, Authelia
At least one tested provider3/8The union of the tested provider evidence
OpenAlt Catalog managed flag3/8Infisical, Bitwarden Server, Passbolt

The cleanest interpretation is this:

In this eight-project snapshot, concrete third-party managed-hosting evidence appeared for 3 of 8 projects, while OpenAlt marked 3 of 8 as catalogue-managed; the overlap is partial, not interchangeable.

Vaultwarden is the most important contrast. It is catalog-unmanaged in OpenAlt’s current project-level flag, yet both tested providers exposed concrete app pages. That result shows why a catalogue-managed label should not be treated as a complete directory of every available hosting route.

The reverse contrast is equally important. Bitwarden Server and Passbolt are catalog-managed, but neither tested third-party provider had a concrete app page for them in this measurement. That does not deny first-party hosting, another managed provider, self-hosting, or a route that was outside these two tested surfaces.

What the statuses prove—and what they do not

The measured statuses prove that a defined public catalogue or project-specific page was present at the time of testing. They do not prove that the service is reliable, secure, supported, affordable, suitable for a particular jurisdiction, or available for successful purchase.

A concrete app card is stronger evidence than a generic provider homepage because it connects a named project to a provider’s catalogue surface. A project-specific Elestio page with HTTP 200 and a managed-service title is also stronger evidence than a broad landing page because the page identifies the project rather than merely describing the provider.

Neither signal answers the operational questions that normally determine whether a hosting choice is acceptable:

  • Does the deployment work correctly for the required features?
  • What support, backups, recovery, upgrade, and migration processes exist?
  • Where is data stored, and which residency or compliance obligations apply?
  • What price, limits, terms, account requirements, or usage conditions apply?
  • Can a user complete checkout and provision the service successfully?

This report did not attempt checkout. It did not run reliability, security, performance, backup, restore, migration, or data-residency tests. It did not inspect provider support quality. “Available” therefore means “visible through the specified public evidence rule,” not “verified as a production-ready purchase.”

Generic provider homepages should not be called one-click or managed app pages because they identify only the provider. They do not establish that the named project is listed, deployable, or supported. Unfiltered search URLs have the same weakness: a search interface or query string may return no project, a broad result, or a result whose status cannot be tied to a concrete app card. This audit uses narrower evidence rules to keep the result reproducible.

Project-by-project reading

The project-level pattern is mixed: provider evidence and OpenAlt’s managed flag identify different kinds of hosting paths.

Vaultwarden has the clearest third-party evidence. It appeared as a concrete PikaPods app card and had a project-specific Elestio page, giving it evidence from both tested providers. Its catalog-unmanaged status is not a contradiction; it simply means OpenAlt’s current project-level flag does not describe it as managed in the catalogue.

Infisical appeared on Elestio and is also marked catalog-managed by OpenAlt. This is an aligned result across one tested third-party provider and the catalogue’s broader managed-hosting classification.

Authelia appeared on Elestio even though it is not a password vault. It belongs in this broader Password Managers & Secrets category because the category includes adjacent identity, authentication, and secrets infrastructure. Its page demonstrates that category membership and hosting evidence should be read separately.

Bitwarden Server and Passbolt are both catalog-managed in OpenAlt, but neither had a concrete app page on the two tested third-party provider surfaces. The correct conclusion is limited: those two providers did not produce qualifying evidence for those projects on the test date. The result does not deny official vendor hosting or other managed-hosting routes.

SOPS, OpenBao, and gopass had neither tested provider. That means no qualifying PikaPods app card or Elestio project-specific page was found under the audit rules. It does not mean the projects cannot be hosted, that no provider supports them, or that their maintainers offer no deployment guidance.

The distinction between Vaultwarden and Bitwarden Server deserves special attention. A compatible Vaultwarden hosting path is not the same thing as official Bitwarden Server hosting. Readers comparing those projects should verify the software identity, maintenance model, feature set, account requirements, and provider terms before treating either route as an equivalent alternative.

Verification checklist and next paths

A defensible hosting verification requires checking the named project page, the evidence date, and the deployment path before making a purchase or migration decision.

  1. Confirm the exact project identity, repository, and software variant. Do not assume that similarly named projects are interchangeable.
  2. Open the direct project page supplied in the report shell, not only a provider homepage or an unfiltered search URL.
  3. Check whether the page still meets the relevant evidence rule: a concrete PikaPods app card, or an Elestio project-specific page returning HTTP 200 with a project-specific managed-service title.
  4. Verify current terms directly with the provider, including provisioning, support, backups, upgrades, migration, region, and account requirements.
  5. Test the actual deployment workflow only after the project identity and provider path are clear. A visible page is not proof that checkout or provisioning will succeed.
  6. Record the date and page URL. Availability can change after this snapshot.

For broader comparison, OpenAlt’s Password Managers & Secrets category provides the category context. Readers evaluating alternatives can continue to 1Password alternatives, inspect Vaultwarden, and review Bitwarden Server. The last two links should be compared carefully: compatible Vaultwarden hosting does not establish official Bitwarden Server hosting.

Frequently Asked Questions

Does “available” mean I can buy the service immediately?

No. It means the project met the audit’s public-page rule on 2026-09-23. PikaPods showed a concrete catalogue card, or Elestio showed a qualifying project-specific page. Checkout and provisioning were not attempted.

Does a missing provider page mean the project cannot be hosted?

No. It means neither tested provider produced qualifying evidence under this report’s rules. The project may have official vendor hosting, another managed provider, self-hosting instructions, or a page that changed after the measurement date.

Why can a project be catalog-unmanaged but still appear on a provider?

Because OpenAlt’s Catalog managed flag is a separate project-level classification. It may describe an official vendor cloud or another hosted path, while the provider tests measure concrete visibility in two external catalogues.

Is Vaultwarden hosting the same as Bitwarden Server hosting?

No. Vaultwarden is a compatible alternative project, while Bitwarden Server is the official project. A provider page for Vaultwarden does not prove that the same provider offers official Bitwarden Server hosting.