Local (on-server) storage for self-hosted Logseq

As the Github backend has been deprecated, I’d love it if we had the option to use local storage (self-hosted only). This would get rid of the need to sync between different devices for people running Logseq on their own server. It would also allow us to use Browsers that don’t support the File System Access API (Firefox, IE, Opera, WebView).

It is already possible to build Logseq to run as a web service, it is in the default documentation: here

To use it on the internet you would have to secure it (yourself) with a proxy-server in front of it.

All of this is not terribly complicated but is not trivial either.

Yes, I know. There is also an official docker container, which I have running behind a reverse-proxy.

But these versions do not allow us to use the local storage of the server running the application. For the Logseq instance deployed on their own servers that makes sense, of course. But for a self-hosted instance it would not just be convenient, but be logical.


Ah, perfect. Let’s see if anything comes of this.

I am waiting this to happen.

To continue this thread from GitHub, crawfordlong said:

… the current model is not optimal. …

To summarize: self-hosted, browser-based logseq ftw.

It took a while, but I finally twigged this is just not how Logseq works. However IMHO this should be the primary way it works.

Please correct me if I’m wrong, but my understanding is that logseq is a browser app that uses File System API to access data locally. This means each copy of the app is stuck in a silo on one machine with kludgy, slow and unreliable syncing if you want to use it anywhere else.

This is probably ok for the (rare?) person who only wants it in one place, but we all have multiple devices nowadays. I need to be able to have a thought and reach for the nearest device to jot it down. This is what, say, Roam does for me.

Hosting Logseq this way nukes all the sync issues in one fell swoop!

Storing the files on the server means that self-hosted Logseq can be a direct competitor to Roam (and a lot of the others), but with all the upsides of open-source, active development and local control.

As a Logseq fan willing to self host I’d switch from Roam in a heartbeat if I could host it this way. Without it Logseq is just too much hassle for me to make it seamless.

1 Like

Other than the self-hosted part, when I was first introduced to logseq, it was entirely browser-based. I would go to logseq.com from any device when- and wherever a thought occurred to me, jot it down, go to another device, expand on the thought, and everything was backed up silently to github behind the scenes in glorious, plain markdown.

Now I have to use a roll-your-own sync, and always have specific devices with me and switch to them to take notes. (Things have gotten marginally easier with a two-tier sync system: Syncthing for personal laptops, github for work and any mobile devices, but … that’s not a great solution.)

I don’t want to suggest I don’t appreciate the time, effort, and consideration that has gone into the logseq we have today, but it is unquestionably less convenient for my needs (and, again, I’m not assuming my needs are the dominant ones). The app-focused development has further complicated things, because I simply cannot (as in, am not permitted to by various rules and mechanisms) install apps on most of my devices that I use in a context when I’m adding to and using notes. For the same reason, I can’t use a proprietary backend sync, something that is arguably not useful anyway because of the app restrictions. What I can do is self-host in a secure environment. I would happily accept a “lite” version of the frontend without some of the current features, as 99.9% of the value to me is in non-hierarchical notes and two-way links.

To be clear, I would happily pay an “enthusiast” or “small office enterprise” license for the self-hosted, browser-focused product. Logseq deserves support and success. I just can’t use it to its full potential with its current direction.