If you can selfhost I'd recommend looking at Vaultwarden. They support sharing credentials in groups and emergency access conditions, which have proved useful to me and my family in the past. The apps/integrations (Android, iOS, Browsers, Desktop, CLI) are provided by Bitwarden and they are available cross platform.
33 points
Cancel These 5 Subscriptions — Free GitHub Repos Replace DocuSign, Typeform & 1Password
Five monthly bills you can cancel this week. Each one has a free, open-source GitHub twin you can self-host — how it works, what it replaces, and where it breaks.
Chapters:
0:00 The five
0:16 #5 MailCheap
1:09 #4 Formbricks
1:58 #3 Documenso
2:48 #2 Clean Your TV
3:38 #1 Vaultwarden
4:25 The ranking
Repos:
Vaultwarden - dani-garcia/vaultwarden
Clean Your TV - Gathin23/cleanyourtv
Documenso - documenso/documenso
Formbricks - formbricks/formbricks
MailCheap - marclou/mailcheap
New free, open-source tools every few days - subscribe.
#github #opensource #selfhosted
3 likes · 75 views
Vaultwarden exposure review begins at the admin route
Vaultwarden exposure review begins at the admin route
Vaultwarden is a self-hosted password manager server with a separate administration page. The admin page can change server configuration, inspect users, and manage the deployment. Its exposure deserves separate treatment from the normal vault login. A reachable web service can be intended, while an unexpectedly reachable admin route creates a much narrower and more valuable attack path.
A ZoomEye query for app="Vaultwarden" returned four matches on 28 October 2026, using sub_type=all and a page size of one. A title="Vaultwarden" query returned 88,580. The title result is broad enough that it should not be described as four or eighty-eight thousand exposed admin pages. The app fingerprint is the better candidate list, and each candidate still needs owner confirmation.
Treat the admin token as an asset
Vaultwarden's environment template points operators to the ADMIN_TOKEN guidance and warns that a bypass option exists. The first question is whether the admin page is enabled at all. If it is, determine how the token is generated, where it is stored, which person or automation can read it, and how it is rotated. A token placed in a shell history, a world-readable compose file, or a shared secret store with broad group access is a high-value credential.
Network policy should restrict the admin route separately from the user-facing vault endpoints. If a reverse proxy protects the application, add an independent authentication rule for the admin path and verify that a request cannot reach the backend route around the proxy. Preserve logs for login attempts and configuration changes. Do not assume that a password manager's transport encryption protects an exposed management interface from credential stuffing or operator error.
Verify data custody
A Vaultwarden deployment stores more than account names. Its database, configuration, attachments, and backups may contain sensitive material. Inventory where those artifacts live and who can read them. A backup that copies the entire data directory to a broadly accessible bucket can reduce the benefit of strong client-side encryption for other data. Follow the project's supported backup and restore process and test restoration without copying production data into a shared test environment.
Review the public exposure with the Vaultwarden measurement, then compare matches with DNS and certificate records. A match can be a legitimate service, a test deployment, or a stale host. The action is to confirm the admin route policy, not to label the service vulnerable from a fingerprint.
Use a controlled test: request the admin route without a token, with an expired or wrong token, and with the approved token from an authorized network. Confirm each result. Then change the token and verify that old sessions and automated jobs fail. The response is complete when the owner knows which route is exposed, who can administer it, and how the credential and configuration are removed.
References
- Vaultwarden environment template
- Vaultwarden enabling the admin page
- ZoomEye measurement for Vaultwarden
I Built an Open-Source Alternative to Browser Sync — Your Data, Your Server
I wanted to sync my bookmarks, browsing history, and open tabs across devices without depending on Google or another third-party sync service.
So I built HelixSync — an open-source, self-hosted solution that puts you in control of your browser data.
What is HelixSync?
HelixSync lets you sync your browsing experience across your devices using a server that you host yourself.
It works with Helium and Chromium-based browsers, including Chrome, Brave, Edge, and Vivaldi.
Here's what you can sync:
- 🔖 Bookmarks — Keep your bookmarks, folders, and changes in sync.
- 🕘 Browsing history — Access synced history across connected browsers.
- 📑 Open tabs and windows — Pick up where you left off on another device.
- 🎨 Tab groups — Sync group names, colors, and collapsed states.
Whether you're switching between computers or just want the same browsing setup everywhere, HelixSync helps keep everything in sync.
Your data stays yours
I wanted a solution where I could control where my browsing data is stored instead of handing it over to a third-party service.
With HelixSync, you run the server yourself, and your data is stored in your own PostgreSQL database.
HelixSync uses end-to-end encryption. Your synced browsing data is encrypted so the server stores ciphertext rather than readable bookmarks and history.
No Google account. No Microsoft account. No third-party sync service required.
You can also manage your connected devices through a web dashboard and revoke access whenever you want.
What about passwords?
HelixSync intentionally does not sync passwords. It focuses on browser data such as bookmarks, history, tabs, and tab groups.
For password management, I recommend Vaultwarden, a lightweight server compatible with Bitwarden clients that you can host yourself.
I prefer keeping these responsibilities separate: HelixSync handles browser synchronization, while Vaultwarden handles passwords.
Together, they can help you build a self-hosted setup without relying on a third-party cloud service for either purpose.
Easy to get started
You don't need a complicated infrastructure to run HelixSync.
With Docker Compose, you can get the server, database, and web dashboard running on your own machine or server.
The basic setup is straightforward:
1. Deploy HelixSync on your server.
2. Create your account and save your recovery code.
3. Install the browser extension.
4. Connect your browsers to your server.
5. Choose which data you want to sync.
Once everything is connected, synchronization happens in the background.
You can also run it behind your own domain with HTTPS and manage your connected devices through the dashboard.
Built for people who value privacy and self-hosting
HelixSync is open source and released under the MIT license.
The goal is simple: give people a way to sync their browser data without having to depend on someone else's infrastructure.
If you already run a home server, a VPS, or a collection of self-hosted applications, HelixSync might fit right into your setup.
Try HelixSync
🚀 GitHub: GhaziAlibi/helixsync
🌐 Chrome Web Store: chromewebstore.google.com
I'd love to hear your feedback, ideas, and suggestions. Contributions and bug reports are welcome!
A question for the community: Do you prefer using browser-provided sync services, or would you rather host your own? What features would you want from a self-hosted browser sync solution?
1 reaction
This reminds me of the days of Log4j
vaultwarden#7887
1 like
Pre-registered result - your scanner misses half of self-hosted apps' own security advisories
---
title: Pre-registered result - your scanner misses half of self-hosted apps' own security advisories
published: true
tags: security, opensource, selfhosted, devops
---
Three days ago I posted that 31.6% of security advisories for self-hosted AI tools never reach the database your scanner reads. A pre-registered follow-up then showed that AI wasn't the cause: AI projects were no worse than matched non-AI projects (p = 0.30). The pattern that did show up was self-hosted applications vs libraries. That was exploratory, so I wrote down a confirmatory test before collecting any data, froze the code, and ran it on fresh repositories.
It came back this morning. The split holds.
The test
- Frame: 40 self-hosted applications, the top of the awesome-selfhosted catalogue by stars. 40 libraries, the most-depended-on on npm, PyPI and Go. No repository reused from earlier samples. Selection never looked at advisories.
- Measure: a published repository advisory, at least 14 days old, is scanner-blind when no OSV record names any package. OSV is searched under its own GHSA ID and under every CVE alias. Dependabot, npm audit and pip-audit can only match an advisory that names a package.
- Test: two-sided permutation test at the repository level, 10,000 permutations, seed fixed in advance. H1 was supported only if p < 0.05 with applications higher.
The result (snapshot 2026-10-18)
| Group | Eligible advisories | Scanner-blind | 95% CI |
|---|---:|---:|---|
| Self-hosted applications (27 repos with advisories) | 909 | 53.0% | 49.8–56.3% |
| Libraries (5 repos with advisories) | 11 | 0% | 0–25.9% |
Applications minus libraries is +53.0 points, p = 0.0057. That is still p = 0.02 after dropping the heaviest repo in each group. All 80 repositories were readable, and the OSV canary resolved.
Spot-check it yourself. Vaultwarden's GHSA-h6cc-rc6q-23j4 is 404 on api.osv.dev. Its CVE record exists, but it lists only a Git commit range and no package, so no package scanner can match it to your container.
What didn't come out cleanly
- Within each publication period alone, the difference points the same way but isn't significant. The library side has only 5 repos before May 2026 and 1 after.
- Only 5 of the 40 top libraries publish repository advisories at all, so the library rate is imprecise.
- Part of the application number is review lag. 81.5% of 14–29-day-old app advisories are blind, against 36.8% of those 90+ days old. More than a third of old ones are still invisible.
- Exploratory, not pre-registered: apps whose advisories name a registry package (gogs, Payload, copyparty) are mostly visible. Apps shipped only as images are almost entirely blind: Immich, Stirling-PDF, paperless-ngx, Rocket.Chat and LibreChat are at 100%.
What to do
If you self-host something, don't expect your dependency scanner to warn you about that application's own advisories. Watch its Security tab, or run blindspot.py --package repo:OWNER/REPO. If you maintain an app, naming a package in your advisories is what lets them reach scanners.
Full write-up, data (CC BY 4.0) and code (Apache-2.0), including the pre-registration and both amendments: github.com/munimtechnologies/advisory-import-cens…
The research, code and this post were made with AI agents working for me. Every number is checked against the run's own output files, but no independent human has reviewed it yet. Corrections are welcome.
— MV2 of Munim, Inc.
Fix the Vaultwarden "HTTPS Required" Secure Context Error
---
title: "Fix the Vaultwarden \"HTTPS Required\" Secure Context Error"
published: true
description: "Fix Vaultwarden's \"You are not using a secure context\" and \"Could not locate Subtle crypto\" errors with a tested Caddy HTTPS reverse proxy."
tags: selfhosted, docker, security, https
canonical_url: deploylark.com
---
If you start Vaultwarden with a plain docker run -p 8000:80 and open it from another machine, you don't get a login page. You get this:
!Vaultwarden web vault opened over plain HTTP from another machine, showing only the message: You are not using a secure context which is required for the Subtle Crypto API to work. You need to enable HTTPS!
You are not using a secure context which is required for the Subtle Crypto API to work. You need to enable HTTPS!
This isn't a bug, and no Vaultwarden setting turns it off. Lots of people hit it, because Vaultwarden is a very common first self-hosted app. On October 14, 2026, the Vaultwarden repository had about 69,000 GitHub stars, and the vaultwarden/server image had been pulled more than 344 million times from Docker Hub. Below I reproduce the error, explain why it happens, and fix it with a reverse proxy.
TL;DR:
- The web vault needs the browser's crypto.subtle API, which only exists in a secure context. Plain HTTP from a LAN IP isn't one.
- No Vaultwarden setting turns this off. Put a reverse proxy with a certificate in front. Caddy with reverse_proxy 127.0.0.1:8000 fixed it in my test.
- Bind Vaultwarden to 127.0.0.1:8000 and set DOMAIN to the HTTPS URL people will type.
- http://localhost loads the page, but current Bitwarden clients require HTTPS, so don't rely on it.
- Once your own account exists, set SIGNUPS_ALLOWED to "false".
Reproduce the error
Start Vaultwarden over plain HTTP
This is the "broken" compose file I started with:
services:
vaultwarden:
image: vaultwarden/server:1.37.4
container_name: vaultwarden
restart: unless-stopped
volumes:
- ./vw-data:/data
ports:
- "8000:80"
$ docker compose up -d
$ docker logs vaultwarden
| Version 1.37.4 |
[start][INFO] Rocket has launched from http://0.0.0.0:80
I opened it from another machine at http://<your server's LAN IP>:8000/, for example http://192.168.1.50:8000/. In my lab the address happened to be 172.30.0.2. In the browser:
window.isSecureContext = false
typeof crypto.subtle = "undefined"
Error: Could not instantiate WebCryptoFunctionService. Could not locate Subtle crypto.
What about localhost?
Opening http://localhost:8000/ does count as a secure context, and the login page rendered:
!Vaultwarden web vault login page rendered over http://localhost:8000
But the console logged this right away:
Unable to fetch ServerConfig from http://localhost:8000/api ... Insecure URL not allowed. All URLs must use HTTPS.
That matches what a Vaultwarden contributor wrote in PR #7137: since Bitwarden clients v2025.11.0, the clients require HTTPS everywhere. So treat localhost over HTTP as a quick peek at most, not a working setup. I didn't try to log in or sync that way.
Why Vaultwarden requires HTTPS
Web Crypto only works in a secure context
Bitwarden encrypts your vault in the browser using the Web Crypto API (crypto.subtle). Browsers only expose that API in a "secure context", which means a page served over HTTPS or from localhost. The Vaultwarden wiki says HTTPS is "pretty much required nowadays" for this reason.
Over plain HTTP from a LAN IP, crypto.subtle is simply missing. People have reported this error for years. In 2018 it looked like Cannot read property 'importKey' of null (#153). A more recent report is "Web Vault stuck on loading with Subtle crypto errors" (#5485).
Fix it with a reverse proxy
Run Caddy in front of Vaultwarden
The wiki recommends a reverse proxy and suggests Caddy if you don't already have a preference. Vaultwarden's built-in Rocket TLS (ROCKET_TLS=...) exists, but the wiki advises against it.
Here is what I ran. Vaultwarden now listens only on 127.0.0.1, and DOMAIN is set to the HTTPS URL users will actually type:
services:
vaultwarden:
image: vaultwarden/server:1.37.4
container_name: vaultwarden
restart: unless-stopped
environment:
DOMAIN: "https://vault.example.test"
volumes:
- ./vw-data:/data
ports:
- "127.0.0.1:8000:80"
Caddyfile:
vault.example.test {
tls internal
reverse_proxy 127.0.0.1:8000
}
docker compose up -d
docker run -d --name caddy --restart unless-stopped --network host \
-v "$PWD/Caddyfile":/etc/caddy/Caddyfile:ro \
-v caddy_data:/data caddy:2-alpine
This command depends on a few things:
- --restart unless-stopped makes Caddy come back after a reboot, like Vaultwarden does. My original test run didn't have it, so add it.
- --network host means Caddy binds ports 80 and 443 directly on the host, so nothing else may be using them (sudo ss -tlnp | grep -E ':(80|443) ').
- vault.example.test has to resolve to the server. On a test box, add a line like 127.0.0.1 vault.example.test to /etc/hosts. On other client machines, use the server's LAN IP instead. On a real server, create a DNS A or AAAA record for your domain.
The wiki's Using Docker Compose page shows a tidier layout for a real server. It runs Caddy as a second service in the same compose file, proxies to vaultwarden:80 over the compose network, and drops the ports: section from Vaultwarden. I tested the docker run version above, not that one.
tls internal makes Caddy issue a certificate from its own local CA, because my test box has no public domain. On a real server with a real domain, delete the tls internal line. According to Caddy's docs, it then gets a Let's Encrypt certificate automatically, as long as ports 80 and 443 are reachable and DNS points at the server. That path needs a public domain, so I couldn't run it here. The Umami analytics guide shows the same Caddy setup for a real domain.
Here is the difference in one picture:
!Diagram comparing two paths. A browser at https://vault.example.com reaches Caddy on port 443 with a certificate, which is a secure context, and Caddy forwards to 127.0.0.1:8000, where Vaultwarden listens on port 80 in its container. A browser on the LAN at http://server-ip:8000 uses plain HTTP, which is not a secure context, so crypto.subtle is missing. The fixed compose file binds 8000 to 127.0.0.1, which closes that path.
Check that it works
With the proxy in place, https://vault.example.test was a secure context (isSecureContext = true). Vaultwarden reported the right domain in /api/config:
$ curl -sk https://vault.example.test/api/config # needs the /etc/hosts entry above
... "vault": "https://vault.example.test" ...
The login page loaded with no crypto errors.
To check the crypto was really working, I created an account. That's the step that needs crypto.subtle, because the client derives keys from your master password before sending anything. The server log showed registration succeeding (timestamps trimmed):
[response][INFO] (register_verification_email) POST /identity/accounts/register/send-verification-email => 200 OK
[response][INFO] (register_finish) POST /identity/accounts/register/finish => 200 OK
!Vaultwarden web vault open after creating a new account over HTTPS
My browser was set to ignore the untrusted local CA. With tls internal in real use, you'd need to install Caddy's root certificate on every device, which is exactly the hassle the wiki warns about with self-signed certificates.
Lock down your new HTTPS vault
Turn off open registration
With the fixed compose file above, SIGNUPS_ALLOWED is still at its default, which is true. The whole point of this guide is to put the vault on an HTTPS domain, so anyone who can reach the URL can create an account on your server. Once you've created your own account (and any for family or team members), disable sign-ups:
environment:
DOMAIN: "https://vault.example.test"
SIGNUPS_ALLOWED: "false"
Then apply it with docker compose up -d. To add people later, the .env.template lists SIGNUPS_DOMAINS_WHITELIST for allowing only your email domain, or you can invite them from an organization. If you enable the /admin page to manage users, set a strong ADMIN_TOKEN first, as the wiki's Enabling admin page article explains. I didn't re-test with SIGNUPS_ALLOWED set to false or with the admin page.
Keep the HTTP port private
Don't publish Vaultwarden's plain-HTTP port to the network. In the compose file that's host port 8000 ("127.0.0.1:8000:80"). Keep the 127.0.0.1: prefix so the only way in is through the HTTPS proxy, not http://<server-ip>:8000. Then add an Uptime Kuma monitor for the HTTPS URL, so you hear about a broken certificate before your phone does.
Still seeing the error?
Check the URL and DOMAIN
1. Make sure you're really on https://. Bookmarks and old browser tabs often still point at http://ip:8000.
2. Set DOMAIN to the exact HTTPS URL, including any subpath. If you change hostnames later, update DOMAIN too (discussion #7715).
Mobile apps and self-signed certificates
Mobile apps are pickier than browsers. The wiki says the mobile app needs a properly configured certificate chain, including OCSP stapling if you run your own CA. A long-running Android thread (#687) and discussion #7544 both ended up being certificate problems. The browser worked and the app didn't. I didn't test mobile apps.
If you can't use a public domain, follow the wiki's private CA guide instead of a one-off self-signed cert, and install the CA on every client.
FAQ
Running without a public server
Can I use Vaultwarden without HTTPS?
Not in practice. Over plain HTTP from another machine, the web vault won't load at all, as shown above. Over http://localhost the page renders, but current Bitwarden clients refuse non-HTTPS server URLs.
Do I need a domain to run Vaultwarden on my home network?
No, but a domain makes it much easier. The wiki has a guide for a private instance with Let's Encrypt certificates that uses the DNS challenge, so the server never has to be reachable from the internet. It covers a free Duck DNS subdomain or a domain on Cloudflare. Without any domain, you're left with a private CA installed on every device, and the wiki says that method is meant for testing and development only.
Can I use Nginx Proxy Manager instead of Caddy?
You should be able to. Any reverse proxy that serves a valid certificate and passes WebSockets gives the browser its secure context. I tested Caddy only. In Nginx Proxy Manager, a proxy host to port 80 with a Let's Encrypt certificate and Websockets Support turned on should do the job. The Nginx Proxy Manager guide walks through that setup. Per the WebSocket notifications wiki page, WebSockets have run on Vaultwarden's main port since v1.29.0, and v1.31.0 removed the old port 3012. You don't need a separate rule for it.
Clients and accounts
Why can't the Bitwarden mobile app connect to my server?
Usually because of the certificate. The browser may accept a chain that the app rejects. Check that your proxy serves the full chain, and see the [mobile apps section](#mobile-apps-and-self-signed-certificates) above.
Why can people still sign up after I set SIGNUPS_ALLOWED to false?
People ask this often (for example in discussion #4058), and Vaultwarden's own docs explain two causes. First, if you ever saved settings on the admin page, Vaultwarden wrote a config.json, and per the wiki, values in that file take precedence over environment variables. Change the setting on the admin page instead. Second, the .env.template says SIGNUPS_DOMAINS_WHITELIST lets listed domains register even when SIGNUPS_ALLOWED is false.
---
Originally published on DeployLark: Fix the Vaultwarden "HTTPS Required" Secure Context Error
@Lonely__MH 要免费 那就在 docker 里部署个 Vaultwarden 就行 功能和 1password 差不多，客户端也齐全 dani-garcia/vaultwarden
1 like · 11 views
@Bitwarden @Redisinc @elastic @Minio @ProtonPrivacy @KeePassXC @syncthing Deep‑dive blog that sparked the exit wave: blog.ppb1701.com | Vaultwarden repo: dani-garcia/vaultwarden
1 like · 6 views
Vaultwarden is a self-hosted Bitwarden-compatible server in Rust. 68k stars, still shipping commits, and your vault stays on your box.
dani-garcia/vaultwarden
1 like · 201 views
Mentions
If you can selfhost I'd recommend looking at Vaultwarden. They support sharing credentials in groups and emergency access conditions, which have proved useful to me and my family in the past. The apps/integrations (Android, iOS, Browsers, Desktop, CLI) are provided by Bitwarden and they are available cross platform.
Cancel These 5 Subscriptions — Free GitHub Repos Replace DocuSign, Typeform & 1Password Five monthly bills you can cancel this week. Each one has a free, open-source GitHub twin you can self-host — how it works, what it replaces, and where it breaks. Chapters: 0:00 The five 0:16 #5 MailCheap 1:09 #4 Formbricks 1:58 #3 Documenso 2:48 #2 Clean Your TV 3:38 #1 Vaultwarden 4:25 The ranking Repos: Vaultwarden - dani-garcia/vaultwarden Clean Your TV - Gathin23/cleanyourtv Documenso - documenso/documenso Formbricks - formbricks/formbricks MailCheap - marclou/mailcheap New free, open-source tools every few days - subscribe. #github #opensource #selfhosted
Vaultwarden exposure review begins at the admin route Vaultwarden exposure review begins at the admin route Vaultwarden is a self-hosted password manager server with a separate administration page. The admin page can change server configuration, inspect users, and manage the deployment. Its exposure deserves separate treatment from the normal vault login. A reachable web service can be intended, while an unexpectedly reachable admin route creates a much narrower and more valuable attack path. A ZoomEye query for app="Vaultwarden" returned four matches on 28 October 2026, using sub_type=all and a page size of one. A title="Vaultwarden" query returned 88,580. The title result is broad enough that it should not be described as four or eighty-eight thousand exposed admin pages. The app fingerprint is the better candidate list, and each candidate still needs owner confirmation. Treat the admin token as an asset Vaultwarden's environment template points operators to the ADMIN_TOKEN guidance and warns that a bypass option exists. The first question is whether the admin page is enabled at all. If it is, determine how the token is generated, where it is stored, which person or automation can read it, and how it is rotated. A token placed in a shell history, a world-readable compose file, or a shared secret store with broad group access is a high-value credential. Network policy should restrict the admin route separately from the user-facing vault endpoints. If a reverse proxy protects the application, add an independent authentication rule for the admin path and verify that a request cannot reach the backend route around the proxy. Preserve logs for login attempts and configuration changes. Do not assume that a password manager's transport encryption protects an exposed management interface from credential stuffing or operator error. Verify data custody A Vaultwarden deployment stores more than account names. Its database, configuration, attachments, and backups may contain sensitive material. Inventory where those artifacts live and who can read them. A backup that copies the entire data directory to a broadly accessible bucket can reduce the benefit of strong client-side encryption for other data. Follow the project's supported backup and restore process and test restoration without copying production data into a shared test environment. Review the public exposure with the Vaultwarden measurement, then compare matches with DNS and certificate records. A match can be a legitimate service, a test deployment, or a stale host. The action is to confirm the admin route policy, not to label the service vulnerable from a fingerprint. Use a controlled test: request the admin route without a token, with an expired or wrong token, and with the approved token from an authorized network. Confirm each result. Then change the token and verify that old sessions and automated jobs fail. The response is complete when the owner knows which route is exposed, who can administer it, and how the credential and configuration are removed. References - Vaultwarden environment template - Vaultwarden enabling the admin page - ZoomEye measurement for Vaultwarden
I Built an Open-Source Alternative to Browser Sync — Your Data, Your Server I wanted to sync my bookmarks, browsing history, and open tabs across devices without depending on Google or another third-party sync service. So I built HelixSync — an open-source, self-hosted solution that puts you in control of your browser data. What is HelixSync? HelixSync lets you sync your browsing experience across your devices using a server that you host yourself. It works with Helium and Chromium-based browsers, including Chrome, Brave, Edge, and Vivaldi. Here's what you can sync: - 🔖 Bookmarks — Keep your bookmarks, folders, and changes in sync. - 🕘 Browsing history — Access synced history across connected browsers. - 📑 Open tabs and windows — Pick up where you left off on another device. - 🎨 Tab groups — Sync group names, colors, and collapsed states. Whether you're switching between computers or just want the same browsing setup everywhere, HelixSync helps keep everything in sync. Your data stays yours I wanted a solution where I could control where my browsing data is stored instead of handing it over to a third-party service. With HelixSync, you run the server yourself, and your data is stored in your own PostgreSQL database. HelixSync uses end-to-end encryption. Your synced browsing data is encrypted so the server stores ciphertext rather than readable bookmarks and history. No Google account. No Microsoft account. No third-party sync service required. You can also manage your connected devices through a web dashboard and revoke access whenever you want. What about passwords? HelixSync intentionally does not sync passwords. It focuses on browser data such as bookmarks, history, tabs, and tab groups. For password management, I recommend Vaultwarden, a lightweight server compatible with Bitwarden clients that you can host yourself. I prefer keeping these responsibilities separate: HelixSync handles browser synchronization, while Vaultwarden handles passwords. Together, they can help you build a self-hosted setup without relying on a third-party cloud service for either purpose. Easy to get started You don't need a complicated infrastructure to run HelixSync. With Docker Compose, you can get the server, database, and web dashboard running on your own machine or server. The basic setup is straightforward: 1. Deploy HelixSync on your server. 2. Create your account and save your recovery code. 3. Install the browser extension. 4. Connect your browsers to your server. 5. Choose which data you want to sync. Once everything is connected, synchronization happens in the background. You can also run it behind your own domain with HTTPS and manage your connected devices through the dashboard. Built for people who value privacy and self-hosting HelixSync is open source and released under the MIT license. The goal is simple: give people a way to sync their browser data without having to depend on someone else's infrastructure. If you already run a home server, a VPS, or a collection of self-hosted applications, HelixSync might fit right into your setup. Try HelixSync 🚀 GitHub: GhaziAlibi/helixsync 🌐 Chrome Web Store: chromewebstore.google.com I'd love to hear your feedback, ideas, and suggestions. Contributions and bug reports are welcome! A question for the community: Do you prefer using browser-provided sync services, or would you rather host your own? What features would you want from a self-hosted browser sync solution?
This reminds me of the days of Log4j vaultwarden#7887
Pre-registered result - your scanner misses half of self-hosted apps' own security advisories --- title: Pre-registered result - your scanner misses half of self-hosted apps' own security advisories published: true tags: security, opensource, selfhosted, devops --- Three days ago I posted that 31.6% of security advisories for self-hosted AI tools never reach the database your scanner reads. A pre-registered follow-up then showed that AI wasn't the cause: AI projects were no worse than matched non-AI projects (p = 0.30). The pattern that did show up was self-hosted applications vs libraries. That was exploratory, so I wrote down a confirmatory test before collecting any data, froze the code, and ran it on fresh repositories. It came back this morning. The split holds. The test - Frame: 40 self-hosted applications, the top of the awesome-selfhosted catalogue by stars. 40 libraries, the most-depended-on on npm, PyPI and Go. No repository reused from earlier samples. Selection never looked at advisories. - Measure: a published repository advisory, at least 14 days old, is scanner-blind when no OSV record names any package. OSV is searched under its own GHSA ID and under every CVE alias. Dependabot, npm audit and pip-audit can only match an advisory that names a package. - Test: two-sided permutation test at the repository level, 10,000 permutations, seed fixed in advance. H1 was supported only if p < 0.05 with applications higher. The result (snapshot 2026-10-18) | Group | Eligible advisories | Scanner-blind | 95% CI | |---|---:|---:|---| | Self-hosted applications (27 repos with advisories) | 909 | 53.0% | 49.8–56.3% | | Libraries (5 repos with advisories) | 11 | 0% | 0–25.9% | Applications minus libraries is +53.0 points, p = 0.0057. That is still p = 0.02 after dropping the heaviest repo in each group. All 80 repositories were readable, and the OSV canary resolved. Spot-check it yourself. Vaultwarden's GHSA-h6cc-rc6q-23j4 is 404 on api.osv.dev. Its CVE record exists, but it lists only a Git commit range and no package, so no package scanner can match it to your container. What didn't come out cleanly - Within each publication period alone, the difference points the same way but isn't significant. The library side has only 5 repos before May 2026 and 1 after. - Only 5 of the 40 top libraries publish repository advisories at all, so the library rate is imprecise. - Part of the application number is review lag. 81.5% of 14–29-day-old app advisories are blind, against 36.8% of those 90+ days old. More than a third of old ones are still invisible. - Exploratory, not pre-registered: apps whose advisories name a registry package (gogs, Payload, copyparty) are mostly visible. Apps shipped only as images are almost entirely blind: Immich, Stirling-PDF, paperless-ngx, Rocket.Chat and LibreChat are at 100%. What to do If you self-host something, don't expect your dependency scanner to warn you about that application's own advisories. Watch its Security tab, or run blindspot.py --package repo:OWNER/REPO. If you maintain an app, naming a package in your advisories is what lets them reach scanners. Full write-up, data (CC BY 4.0) and code (Apache-2.0), including the pre-registration and both amendments: github.com/munimtechnologies/advisory-import-cens… The research, code and this post were made with AI agents working for me. Every number is checked against the run's own output files, but no independent human has reviewed it yet. Corrections are welcome. — MV2 of Munim, Inc.
Fix the Vaultwarden "HTTPS Required" Secure Context Error --- title: "Fix the Vaultwarden \"HTTPS Required\" Secure Context Error" published: true description: "Fix Vaultwarden's \"You are not using a secure context\" and \"Could not locate Subtle crypto\" errors with a tested Caddy HTTPS reverse proxy." tags: selfhosted, docker, security, https canonical_url: deploylark.com --- If you start Vaultwarden with a plain docker run -p 8000:80 and open it from another machine, you don't get a login page. You get this: !Vaultwarden web vault opened over plain HTTP from another machine, showing only the message: You are not using a secure context which is required for the Subtle Crypto API to work. You need to enable HTTPS! You are not using a secure context which is required for the Subtle Crypto API to work. You need to enable HTTPS! This isn't a bug, and no Vaultwarden setting turns it off. Lots of people hit it, because Vaultwarden is a very common first self-hosted app. On October 14, 2026, the Vaultwarden repository had about 69,000 GitHub stars, and the vaultwarden/server image had been pulled more than 344 million times from Docker Hub. Below I reproduce the error, explain why it happens, and fix it with a reverse proxy. TL;DR: - The web vault needs the browser's crypto.subtle API, which only exists in a secure context. Plain HTTP from a LAN IP isn't one. - No Vaultwarden setting turns this off. Put a reverse proxy with a certificate in front. Caddy with reverse_proxy 127.0.0.1:8000 fixed it in my test. - Bind Vaultwarden to 127.0.0.1:8000 and set DOMAIN to the HTTPS URL people will type. - http://localhost loads the page, but current Bitwarden clients require HTTPS, so don't rely on it. - Once your own account exists, set SIGNUPS_ALLOWED to "false". Reproduce the error Start Vaultwarden over plain HTTP This is the "broken" compose file I started with: services: vaultwarden: image: vaultwarden/server:1.37.4 container_name: vaultwarden restart: unless-stopped volumes: - ./vw-data:/data ports: - "8000:80" $ docker compose up -d $ docker logs vaultwarden | Version 1.37.4 | [start][INFO] Rocket has launched from http://0.0.0.0:80 I opened it from another machine at http://<your server's LAN IP>:8000/, for example http://192.168.1.50:8000/. In my lab the address happened to be 172.30.0.2. In the browser: window.isSecureContext = false typeof crypto.subtle = "undefined" Error: Could not instantiate WebCryptoFunctionService. Could not locate Subtle crypto. What about localhost? Opening http://localhost:8000/ does count as a secure context, and the login page rendered: !Vaultwarden web vault login page rendered over http://localhost:8000 But the console logged this right away: Unable to fetch ServerConfig from http://localhost:8000/api ... Insecure URL not allowed. All URLs must use HTTPS. That matches what a Vaultwarden contributor wrote in PR #7137: since Bitwarden clients v2025.11.0, the clients require HTTPS everywhere. So treat localhost over HTTP as a quick peek at most, not a working setup. I didn't try to log in or sync that way. Why Vaultwarden requires HTTPS Web Crypto only works in a secure context Bitwarden encrypts your vault in the browser using the Web Crypto API (crypto.subtle). Browsers only expose that API in a "secure context", which means a page served over HTTPS or from localhost. The Vaultwarden wiki says HTTPS is "pretty much required nowadays" for this reason. Over plain HTTP from a LAN IP, crypto.subtle is simply missing. People have reported this error for years. In 2018 it looked like Cannot read property 'importKey' of null (#153). A more recent report is "Web Vault stuck on loading with Subtle crypto errors" (#5485). Fix it with a reverse proxy Run Caddy in front of Vaultwarden The wiki recommends a reverse proxy and suggests Caddy if you don't already have a preference. Vaultwarden's built-in Rocket TLS (ROCKET_TLS=...) exists, but the wiki advises against it. Here is what I ran. Vaultwarden now listens only on 127.0.0.1, and DOMAIN is set to the HTTPS URL users will actually type: services: vaultwarden: image: vaultwarden/server:1.37.4 container_name: vaultwarden restart: unless-stopped environment: DOMAIN: "https://vault.example.test" volumes: - ./vw-data:/data ports: - "127.0.0.1:8000:80" Caddyfile: vault.example.test { tls internal reverse_proxy 127.0.0.1:8000 } docker compose up -d docker run -d --name caddy --restart unless-stopped --network host \ -v "$PWD/Caddyfile":/etc/caddy/Caddyfile:ro \ -v caddy_data:/data caddy:2-alpine This command depends on a few things: - --restart unless-stopped makes Caddy come back after a reboot, like Vaultwarden does. My original test run didn't have it, so add it. - --network host means Caddy binds ports 80 and 443 directly on the host, so nothing else may be using them (sudo ss -tlnp | grep -E ':(80|443) '). - vault.example.test has to resolve to the server. On a test box, add a line like 127.0.0.1 vault.example.test to /etc/hosts. On other client machines, use the server's LAN IP instead. On a real server, create a DNS A or AAAA record for your domain. The wiki's Using Docker Compose page shows a tidier layout for a real server. It runs Caddy as a second service in the same compose file, proxies to vaultwarden:80 over the compose network, and drops the ports: section from Vaultwarden. I tested the docker run version above, not that one. tls internal makes Caddy issue a certificate from its own local CA, because my test box has no public domain. On a real server with a real domain, delete the tls internal line. According to Caddy's docs, it then gets a Let's Encrypt certificate automatically, as long as ports 80 and 443 are reachable and DNS points at the server. That path needs a public domain, so I couldn't run it here. The Umami analytics guide shows the same Caddy setup for a real domain. Here is the difference in one picture: !Diagram comparing two paths. A browser at https://vault.example.com reaches Caddy on port 443 with a certificate, which is a secure context, and Caddy forwards to 127.0.0.1:8000, where Vaultwarden listens on port 80 in its container. A browser on the LAN at http://server-ip:8000 uses plain HTTP, which is not a secure context, so crypto.subtle is missing. The fixed compose file binds 8000 to 127.0.0.1, which closes that path. Check that it works With the proxy in place, https://vault.example.test was a secure context (isSecureContext = true). Vaultwarden reported the right domain in /api/config: $ curl -sk https://vault.example.test/api/config # needs the /etc/hosts entry above ... "vault": "https://vault.example.test" ... The login page loaded with no crypto errors. To check the crypto was really working, I created an account. That's the step that needs crypto.subtle, because the client derives keys from your master password before sending anything. The server log showed registration succeeding (timestamps trimmed): [response][INFO] (register_verification_email) POST /identity/accounts/register/send-verification-email => 200 OK [response][INFO] (register_finish) POST /identity/accounts/register/finish => 200 OK !Vaultwarden web vault open after creating a new account over HTTPS My browser was set to ignore the untrusted local CA. With tls internal in real use, you'd need to install Caddy's root certificate on every device, which is exactly the hassle the wiki warns about with self-signed certificates. Lock down your new HTTPS vault Turn off open registration With the fixed compose file above, SIGNUPS_ALLOWED is still at its default, which is true. The whole point of this guide is to put the vault on an HTTPS domain, so anyone who can reach the URL can create an account on your server. Once you've created your own account (and any for family or team members), disable sign-ups: environment: DOMAIN: "https://vault.example.test" SIGNUPS_ALLOWED: "false" Then apply it with docker compose up -d. To add people later, the .env.template lists SIGNUPS_DOMAINS_WHITELIST for allowing only your email domain, or you can invite them from an organization. If you enable the /admin page to manage users, set a strong ADMIN_TOKEN first, as the wiki's Enabling admin page article explains. I didn't re-test with SIGNUPS_ALLOWED set to false or with the admin page. Keep the HTTP port private Don't publish Vaultwarden's plain-HTTP port to the network. In the compose file that's host port 8000 ("127.0.0.1:8000:80"). Keep the 127.0.0.1: prefix so the only way in is through the HTTPS proxy, not http://<server-ip>:8000. Then add an Uptime Kuma monitor for the HTTPS URL, so you hear about a broken certificate before your phone does. Still seeing the error? Check the URL and DOMAIN 1. Make sure you're really on https://. Bookmarks and old browser tabs often still point at http://ip:8000. 2. Set DOMAIN to the exact HTTPS URL, including any subpath. If you change hostnames later, update DOMAIN too (discussion #7715). Mobile apps and self-signed certificates Mobile apps are pickier than browsers. The wiki says the mobile app needs a properly configured certificate chain, including OCSP stapling if you run your own CA. A long-running Android thread (#687) and discussion #7544 both ended up being certificate problems. The browser worked and the app didn't. I didn't test mobile apps. If you can't use a public domain, follow the wiki's private CA guide instead of a one-off self-signed cert, and install the CA on every client. FAQ Running without a public server Can I use Vaultwarden without HTTPS? Not in practice. Over plain HTTP from another machine, the web vault won't load at all, as shown above. Over http://localhost the page renders, but current Bitwarden clients refuse non-HTTPS server URLs. Do I need a domain to run Vaultwarden on my home network? No, but a domain makes it much easier. The wiki has a guide for a private instance with Let's Encrypt certificates that uses the DNS challenge, so the server never has to be reachable from the internet. It covers a free Duck DNS subdomain or a domain on Cloudflare. Without any domain, you're left with a private CA installed on every device, and the wiki says that method is meant for testing and development only. Can I use Nginx Proxy Manager instead of Caddy? You should be able to. Any reverse proxy that serves a valid certificate and passes WebSockets gives the browser its secure context. I tested Caddy only. In Nginx Proxy Manager, a proxy host to port 80 with a Let's Encrypt certificate and Websockets Support turned on should do the job. The Nginx Proxy Manager guide walks through that setup. Per the WebSocket notifications wiki page, WebSockets have run on Vaultwarden's main port since v1.29.0, and v1.31.0 removed the old port 3012. You don't need a separate rule for it. Clients and accounts Why can't the Bitwarden mobile app connect to my server? Usually because of the certificate. The browser may accept a chain that the app rejects. Check that your proxy serves the full chain, and see the [mobile apps section](#mobile-apps-and-self-signed-certificates) above. Why can people still sign up after I set SIGNUPS_ALLOWED to false? People ask this often (for example in discussion #4058), and Vaultwarden's own docs explain two causes. First, if you ever saved settings on the admin page, Vaultwarden wrote a config.json, and per the wiki, values in that file take precedence over environment variables. Change the setting on the admin page instead. Second, the .env.template says SIGNUPS_DOMAINS_WHITELIST lets listed domains register even when SIGNUPS_ALLOWED is false. --- Originally published on DeployLark: Fix the Vaultwarden "HTTPS Required" Secure Context Error
@Lonely__MH 要免费 那就在 docker 里部署个 Vaultwarden 就行 功能和 1password 差不多，客户端也齐全 dani-garcia/vaultwarden
@Bitwarden @Redisinc @elastic @Minio @ProtonPrivacy @KeePassXC @syncthing Deep‑dive blog that sparked the exit wave: blog.ppb1701.com | Vaultwarden repo: dani-garcia/vaultwarden
Vaultwarden is a self-hosted Bitwarden-compatible server in Rust. 68k stars, still shipping commits, and your vault stays on your box. dani-garcia/vaultwarden