I built MySolido — a personal data vault that runs entirely on your own PC. No cloud provider, no third-party server — just a local Solid Pod under your control.
Why I built it
There are wallets (EUDI), identity systems (Jouw.id, Athumi) and infrastructure being built across Europe. But there’s no consumer product where people actually store their stuff. MySolido fills that gap: the vault where your documents, medical records, photos, passwords and contracts live — locally, on your own machine.
What’s under the hood
Community Solid Server v7.1.9 running locally
Flask/Python frontend — browse, upload, search, organize
Windows installer (.exe) and macOS (.dmg) available
What’s new since v1.0
Bridge service — a read-only mirror of your local pod on a Dutch VPS (bridge.mysolido.com). Access your vault from your phone, share files over the internet. Local stays master, Bridge is read-only.
Share links — token-based URLs with optional password and expiry. Recipients don’t need Solid or a WebID.
ODRL policies — per-container usage policies (W3C Recommendation). Machine-readable rules for what recipients can do with your data.
Consent module — record, view and withdraw consent, conforming to W3C Data Privacy Vocabulary v2.3 and ISO/IEC TS 27560:2023.
Watermarking — PDF and image watermarks on shared files (“Shared with [recipient] on [date]”), applied on-the-fly via the Bridge.
Profile module — structured personal attributes stored as JSON-LD with DPV vocabulary. Foundation for the “Reverse Google” intention economy concept.
AI assistant — local RAG pipeline (Ollama + ChromaDB) that searches your documents. Hybrid mode available: local indexing + cloud API for answers. Your files never leave your PC during indexing.
Audit logging — full log of who accessed what and when.
ZIP export — backup your entire vault.
The bigger picture: Reverse Google
The long-term vision is what I call the Omgekeerde Google (Reverse Google): users store rich personal data locally, voluntarily signal purchase intentions anonymously, companies bid on those intentions, and users receive compensation. Inverting the surveillance advertising model. The profile module and consent system are the first building blocks.
Local is always master. The Bridge syncs via scp, secured with bcrypt password auth and Let’s Encrypt HTTPS.
Questions for the community
WebID resolution: My pod runs on localhost:3000 locally and is mirrored to a public URL. What’s the recommended way to handle WebID when the same pod exists at both addresses?
Sharing with non-Solid users: I’ve built token-based share links alongside WAC. Is anyone else bridging the gap between Solid access control and sharing with the non-Solid world?
ODRL enforcement: I’m using ODRL policies as a juridical layer (not technical enforcement). Combined with watermarking for traceability. Curious how others approach policy-driven data sharing in practice.
To answer your questions, I can only help you with the first one, local/cloud interop. I still haven’t decided how I’ll do that, but I think it can be done with any standard bridging software. I have used ngrok in the past to connect to a POD running locally from a different network, as long as you configure the base url properly it should work. I’ve also seen things like Tailscale that some people use to expose local services on the internet. Though I’m not sure how easy that is to configure with CSS.
Although I will say, ideally Solid Apps should be able to work against localhost! The point of Solid is that apps connect directly from the browser to your solid server, so it shouldn’t be necessary for a 3rd party server to access a POD outside of your computer… But I’m sure you’ll find apps that don’t work like that. You can try with one of my apps, Umai, to see if it works for you.
I have tried running your project locally, and it seems to work fine but I’m not sure which credentials to introduce in the login screen . Maybe this is obvious somewhere in the interface, but I don’t understand the language. Also, if I weren’t already familiar with Solid I would know how to log in to an app. I did use the POD’s url, `127.0.0.1:3000`, but I think most people’s intuition is to use the same url they use to browse the POD. In this case, `localhost:5000`, but that didn’t seem to work.
Thanks Noel! Great to see someone working on a similar approach.
Login: The first time you run MySolido, it auto-creates a pod and credentials. The login screen asks for the CSS password that was generated during setup — it’s shown in the terminal output on first run. I realize that’s not obvious, especially with the Dutch interface. I’ll add an English language option and make the first-run experience clearer. Good feedback.
URL confusion: You’re right — localhost:5000 is the Flask UI, but the pod URL for CSS is 127.0.0.1:3000. I should make this clearer in the interface. The localhost vs 127.0.0.1 distinction also matters on Windows due to IPv6 resolution issues.
Local ↔ cloud interop: I chose a different approach than ngrok/Tailscale — a read-only Bridge service on a Dutch VPS (bridge.mysolido.com). The local pod stays master, the Bridge mirrors it. Share links work over the internet without exposing localhost. But I agree that ideally Solid apps should work against localhost directly.
I’ll check out Umai against my local pod — thanks for the suggestion. And I’ll update this post with the latest features (Bridge, ODRL policies, consent requests, AI assistant) that have been added since March.
@NoelDeMartin Thanks for the feedback, very helpful!
Two things we’ve fixed since your test:
Language — MySolido is now fully bilingual (Dutch/English). Switch via Settings → Language. So the interface should be readable now.
Login confusion — There’s no login required when running locally. The correct URL is http://localhost:5000 (Flask UI). Port 3000 is the CSS server running in the background — you don’t interact with it directly. We’ve added a clearer hint on the welcome screen and in the README.
The Bridge login screen only appears when accessing your vault remotely via bridge.mysolido.com.
I’ll definitely try Umai — curious to see how it connects to a local pod.
I have managed to switch the UI to English, but I’m still not sure how to log in to Solid Apps :/. Looking at the CSS data, I have seen that my user email is `user@mysolido.local`, but I haven’t been able to guess the password given that it’s generated on registration and I haven’t been able to find it. Changing the “bridge password” doesn’t seem to work, so I guess they are different passwords?
I have looked at the README, and that would allow most users to know how to log in (at least the ones that are somewhat familiar with Solid), using `http://127.0.0.1:3000/mysolido/profile/card#me\` as the log in url. But I think it’s still a bit confusing when it comes to user/password.
You mentioned that you don’t have to interact with the CSS instance, but then how can I log in? You said that the log in screen appears with `bridge.mysolido.com`? Being this a local Solid POD, I think it would be great if there is a way to log in without relying on a live domain. Ideally, I should even be able to use the POD and connect to apps whilst being offline. What are your thoughts about that?
Hey Noel, thanks for giving MySolido a real go — your questions are spot on.
The credentials confusion is a genuine UX bug. Three different credentials exist (CSS account, internal client credentials, Bridge password) and only the last one is visible in the UI. The CSS account is auto-generated at setup and never shown, which is why you can’t log in from external Solid apps. I’ll fix both the Profile page (to expose these) and the README (to explain the login flow). That should be a quick win.
On offline use and not relying on a live domain: I agree. MySolido itself runs fully offline — the Bridge is optional, only needed for external exposure. The real issue is Solid’s WebID resolution: http://127.0.0.1:3000/... can’t be resolved by external apps. mDNS, tunnel services, or an optional Bridge are workarounds, but you’re probably right that a protocol-level solution is cleaner. Curious to hear your thoughts given your CRDT work — I suspect local-first Solid PODs is a space where your research and MySolido’s positioning overlap.
Well, that’s the thing, it depends on the app. As I mentioned, all my apps should work anyways against local urls (because they are PWAs, they run entirely on the browser). It would be nice to be able to use at least those apps without any bridging or tunnels.
Well, I have been working on local-first Solid Apps, not PODs. And my CRDT approach doesn’t use any special functionality in the POD, it should work with any server that adheres to the Solid protocol.
But as I mentioned I am working on a similar project as well. I’ll make sure to make it work with applications that don’t have a server-side component, but otherwise I don’t see many solutions besides doing a bridge like you’re doing.
Maybe the only thing I would mention is that it would be nice if that is configurable, and not hard-coded to the bridge running in your domain. Of course, it makes perfect sense to have it as a default option for people who don’t want to manage their own bridges.
. Maybe this is obvious somewhere in the interface, but I don’t understand the language. Also, if I weren’t already familiar with Solid I would know how to log in to an app. I did use the POD’s url, `127.0.0.1:3000`, but I think most people’s intuition is to use the same url they use to browse the POD. In this case, `localhost:5000`, but that didn’t seem to work.