I’m trying to establish a best practice for syncing Logseq across multiple Linux desktops and an Android phone, and I wanted to get a community consensus.
My journey has started with Syncthing in a star formation (4 clients syncing to a central server) with logseq running on all of them at the same time. The result is disastrous. This isn’t a theoretical problem; I experience significant data loss or file corruption more than half the time I make a change on one device. Blocks go missing, and today’s journal will be littered with conflict files in the bak directory. It is not usable/reliable.
This leads me to believe that any real-time file-mirroring service (Syncthing, Dropbox, etc.) is fundamentally incompatible with Logseq’s “live database” nature, where the app is constantly interacting with the files. The race conditions seem unavoidable.
After some research, the most promising solution appears to be a Git-based workflow. Do we all agree this is the best (only?) way to do it?
Best Practice?: A Hybrid Git Workflow
The setup is straightforward for anyone familiar with Git.
Backend: A private GitHub repository acts as the central source of truth.
Desktop (Linux/Mac/Windows): This part is a solved problem. Using the logseq-git plugin from the marketplace, configured to auto-pull and auto-push every few minutes, provides a completely transparent and automated sync experience. It’s a “set it and forget it” solution.
Mobile (Android/iOS): This is the manual part. Since plugins aren’t supported, the workflow is to use a dedicated Git client (like MGit on Android or Working Copy on iOS) to manually pull before opening Logseq, and then commit & push after you’re done. The syncing is not automatic/transparent, but it is 100% reliable.
This hybrid approach seems to be the only way to guarantee data integrity across a fleet of devices.
My Questions for the Community:
Do we agree this is the current best practice? For users running Logseq on many devices where data integrity is non-negotiable, is this Git workflow the accepted standard?
Has anyone successfully tamed Syncthing? Has anyone actually made a file-mirroring setup reliable for multiple clients running at the same time? I’ve seen mentions of tweaking fsWatcherDelayS, but does this truly eliminate the race conditions, or just make them less frequent? I’m looking for people who have run this for months on 2-3+ machines without a single sync conflict or data loss incident.
Looking forward to hearing your experiences and hopefully converging on a definitive recommendation for late 2025.
Hi there, I’m new in the forum, but I have been working with logseq as my journal editor for the latest 2 years.
About this question, I would like to say I’m been working with google drive sync between devices and I have been very satisfied until recent problems with my Google Drive app for MacOS it’s driving me here to find new alternatives.
For windows, macos google drive app works (used to work) perfectly. Free and very powerful.
For android, I use an app called DriveSync, that is a commercial app with a free option that covers my needs perfectly.
I think logseq should implement a google drive plugin to store the journal files so it would be more portable and powerful.
I have forgotten to say that for linux OSes you always can use rclone to set a synchronization between your google drive folder and your system, or do it directly. Otherwise you can trust in the File Manager your desktop provide you to access your Gdrive.
Here’s a write up on what I’ve set up. Not been in service for long, but seems pretty robust so far. (Only omission is that I use google cli to direct mount on Linux device)
For Logseq MD, git-like solution is better than file-mirroring service, It not only provides synchronization but also line-level versioning.
I am using a lightweight Git alternative, fossil-scm, and some autohotkey/batch script to implement repeatedly commit and manual commit function.
Fossil scm does not have mobile clients. For Android device, I setup a point-to-point syncthing pair between the phone and the fossil central server, and repeatedly run fossil client on the server to commit/pull between the syncthing folder and the fossil server.
I’ve been a daily user of Logseq + Syncthing setup for close to 3 years now and apart from the occasional hiccups related to missing blocks (which are never really missing in the sense that you can always recover from the error files), I’ve not faced any data loss. Admittedly I’m not really a heavy user on all the devices - the usage pattern skews heavily towards my Mac being the primary device → followed by Android app → followed by Linux machine.
In contrast, I found git-based workflow to be worse in my case, especially if network conditions are not stable enough, and lead to a complicated set up. My advice is to reduce the fsWatcherDelayS to 5s (from the default 10s) if you’re frequently using Logseq on multiple devices simultaneously. For a note-taking set up, I’ve found this to be more than sufficient for my use case.
I use LogSeq personally and at work (separate instances).
My personal LogSeq has been going for about 4 years as my daily driver for notes, replacing Obsidian. I’m using SyncThing (as I did for Obsidian too), across 2 phones, 3 Windows machines and 2 Linux machines. I’ve never experienced a single block go missing, except in the very odd occasion when I accidentally edit on two devices at the same time. Since then, I just open LogSeq on one device at a time. I haven’t done any tweaking to SyncThing at all. There has to be something peculiar about your setup, because I’ve been extremely happy with how easy and robust this has been. Happy to compare settings etc with you!
My work LogSeq has been going for 2 years and is saved directly into the corporate OneDrive on a Mac, which is always syncing. I use LogSeq about 3 hours total a day at work, and I’ve never had a single block go missing here either, even though I’ve heard this isn’t the recommended setup. Again, I’ve done no tweaking or anything special.
I’m seriously wondering how I’m so lucky! Again, happy to dig into any settings, my workflow, etc, to help make this work for anyone else.
Update: Forgot to mention, on that rare occasion I edited on two devices at the same time, it didn’t actually cause any data loss - SyncThing just created a “conflict” and let me resolve it.
Syncthing Setup: 2 Windows PCs (@work, @home) running Syncthing Tray, and 1 Android phone running Syncthing-fork.
They are all synced with each other in a triangular, 1-to-2 fashion. I experience rare conflicts only if I make changes to the same file on two or more devices faster than they can synchronize. Any file-based synchronization system has an inherent delay before changes made on one device are propagated to the others. If you switch to another device and make further changes to that same file within this delay window, you will get a conflict.
In my case, this delay is about 15 seconds. For instance, I typed “test” (Enter) and saw it appear on the two other devices almost simultaneously (I watched via AnyDesk) within that 15-second window.
Since I’m a single user and most changes are made on the PCs, while the Android phone is primarily for reading and checking, this setup works fine for me. It works well with Obsidian, too.
I’m using logseq sync across 2 MacBooks and 1 linux box. The only goofy thing I’ve noticed is that sometimes the daily template doesn’t update if I’ve made changes to it. Is the motivation to use something else a cost thing or privacy or..?
I’ll echo Syncthing. I have it running on my Desktop, Laptop, Mac, and Android phone. I’m able to access/update across devices, and never have had any sync issues or conflicts.
It is encouraging to hear that most of you have success with Syncthing. There may be something funky with my Syncthing setup then, since I’m seeing these issues.
I only actively work on one machine at a time, but logseq is open on most of them, most of the time. And I’ve seen that editing a journal file on one machine created 3 files in logseq/bak/journal with various degrees of differences between them.
Those that have it working, do you also have the logseq program/process open on mulitple machines at once?
But otherwise, perhaps I’ll move Syncthing debugging to another thread.
The real kicker here is the predicate requiring them to be open “all at the same time.” That is what makes this so complicated.
I have been using LogSeq for years.I synchronize across multiple laptops and Android devices.I do this using a Synology server as the main hub and source of truth.The synology software provides essentially real-time upload of changes to the server.This farms out any given change to all machines which are currently on.
It’s a little different on the Android.Before starting this session, I make sure that the files are synced adequately because running synchronization in the background on either iOS or Android has yet to be highly reliable.Once the synchronization is complete, I open the application on the Android, and everything is there.On closing LogSeq, I simply run the synchronization back to the server.
The hitch here is that I have only one instance of LogSeq running on any given device at one time.I think what you are looking to do will be available on the paid option of the DB version.
It may be the star formation you mentioned above that is causing your issues.
I run Logseq on an Android, a laptop, and a desktop. I often have it open on more than one device at a time but am only editing in one place. What I have found that causes sync issues:
I go on my laptop and start typing in a new journal page for 9/17/25. I then later go to my phone or desktop and also type something in the 9/17/25 journal page. If I did not have syncthing running on both devices prior to writing on the second device, then syncthing sees a 2025_09_27.md file on my laptop but also sees a 2025_09_27.md file on my second device, since each of them has been written to on that day to generate the journal page. Because syncthing wasn’t running on both devices before I wrote on the second device, it sees each file as ‘owned’ by the device I created it on. It then generates a conflict file because each device owns 2025_09_27.md. I expect the same would be true if created a dedicated page with the same filename on each “Daily Goals for Week-35.md”. It would generate a conflict file because each device thinks it owns a file called “Daily Goals for Week-35.md” where both are located in the same directory.
Since your devices are communicating with each other only via the central hub intermediary, I would expect they are more likely to see those kinds of conflicts pop up.
Thanks @brerlapn, but I don’t think that is what is going on.
I have logseq running on two machines. But I only edit files on one of them.
Ensure there are no logseq/bak/** files.
Edit the daily journal for today. Type gibberish continuously for 30 seconds.
At some point, the logseq file on one of the other machines creates a logseq/bak/** file.
I’ve started a debugging session with inotifywatch to see what the sequence of events is excatly. But it appears as if multiple updates come to one of the remote machines, it declares a conflict eventually.
I’m using git-based approach. I tried iCloud sync, Google Drive sync, but the most reliable solution is git. The file sync solution always makes file corrupted due to logseq write files when changes is made, and your underlying sync approach may do the sync in wrong moment, makes file corruption. To be honest, I have developer background, makes me familiar with git workflow.
I use git to manage copies on iPhone and computers, with GitHub private repository as central copy. I use standard git tools to push and pull, instead of logseq build-in / plug-ins. So, I can have absolute control.
This approach works when you strictly follow git workflow, especially familiar with conflict resolution.
Logseq MD syncs against the file system. If Logseq has read files into memory and cached them it will probably detect if the operating system or another process (like Dropbox or OneDrive) updated the file on disk “behind Logseq’s back”. It will notice a newer change on disk with a different checksum from the version in memory and indicate a conflict.
This is correct behavior and Logseq doing this is a good thing. Otherwise, an unwanted external change could silently corrupt your data.
Handling parallel changes to the same graph requires some sort of sync solution that programmatically deals with sequencing changes. Either the git-based thing, or for instance the new cloud-based “Sync”.
If you were to only run a single instance of Logseq at any one time - and made sure the other instances were killed so no data cache survived AND made sure the files were synced before starting the other instance - I assume that would work too.
I think the missing blocks problem comes from when two devices have the same BLOCK open. So, if you have two devices with today’s journal open, they’re likely both at the initial block. So if on one device, you type something, I’d say you have an equal chance that what you type there would be saved to both devices OR the empty line from the other device will erase what you typed.
To alleviate this AND be able to have multiple logseq instances open at once, I try to press ESC on my desktop apps so that no block is actually active when I’m done typing into some blocks.
On my phone, I tap to the blank space next to the hamburger menu at the top so that no block is active on my phone.
When I remember to do this, I never have the issue.
Another thing that REALLY helps is enabling the built-in Version Control on any client that supports it (non-Android). That way, if a block is deleted from one of those clients, I can go back in time and look at the page history and revert to a version that had the block I’m now missing.
Sometimes a conflict file will be created when a block goes missing or there’s some other conflict. So I have a naemon/nagios check to look for any conflict files in my graph.
This exactly matches my experience, using Syncthing across Android, two Windows, Linux, and occasionally Mac. I do have minor problems from time to time, but only one or two a year are from anything other than having my cursor actively editing the same block on multiple devices.
I’ll also note that it’s frequently possible to simply use Undo on the device that accidentally overwrote the correct block with a blank.
So overall, my experience has been 1-2 small but obvious problems a week, 50% solved with Undo, 45% solved with Syncthing conflicts, 4.9% solved with Syncthing versioning, and 0.1% or so too weird and complicated by multiple failures (especially significant network outages) to properly resolve except by reconstructing from memory.