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.
5 Likes
Ah, perfect. Let’s see if anything comes of this.
I am waiting this to happen.
1 Like
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.
4 Likes
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.
9 Likes
I’m hoping for something like this too
1 Like
Also looking forward to logseq having access to the server or docker storage
1 Like
Hey folks, I don’t understand the challenge. What are you waiting for? Logseq has API for developers - if you want, host it anywhere and make a tunnel to have a persistent address. If you don’t know what it means - Logseq just markdown file, add any git repository and/or install git plugin. you can edit markdown files anywhere - on Draft on iOS or in GitHub or gitea.
1 Like
I would also like to have access to this - or alternatively, a way to self-host the backend to the Sync feature (seems less likely since its build on Amplify, so it would be a lot to re-implement).
I don’t have strict requirements like others, I just prefer to self-host all my data. I would want to access my notes from multiple devices without hacky solutions like mobile file syncing or messing with git from mobile. Since mobile doesn’t support plugins, a plugin based solution wouldn’t work.
2 Likes
I am also interested. I often want to take notes on work computer that do not allow installation of software or browser filesystem access
Relevant discussion: Logseq in docker - ability to open directory on server · logseq/logseq · Discussion #7841 · GitHub
1 Like
I would love to use this feature - that’s the only thing that’s blocking me from switching from Trilium notes to Logseq.
I was thinking about using webfuse (GitHub - falk-werner/webfuse: websocket filesystem based on libfuse) to write another fs backend and have it work with webfuse server running next to logseq container on server (or directly on the logseq container). But I don’t have much experience with js and fuse, so it could be quite difficult
1 Like
I’d love this feature too! I have selfhosted server in homenetwork and logseq installed on my laptop and mobile with git sync which is good enough for me. However if logseq web client can support graph on server, I’m going to use it to publish my blog and promote to all I can reach from Internet and ground. (Sure a file privilege control on serverend should be in place beforehand 