Choosing a note system: My Experience with Syncthing, BookStack, and Git
tl;dr: Git-backed Markdown files have become my favorite way to store my personal notes, surpassing BookStack in simplicity and reliability, and offering more QoL features than Syncthing file shares.
A close friend and I have an inside joke centering around someone asking her the vague question, "Where do you keep your files?"
Well… Certainly everyone has a unique answer to that question. I’ve been storing personal notes on my computer for years and years.
The manner in which I’ve stored those notes has gone through several phases:
- TXT files stored locally on my computer (1990’s - 2015)
- TXT files shared between computers via Syncthing (2015 - 2021)
- Self-hosted BookStack on a FAMP-stack VPS (2021 - 2025 Q3)
- Git-backed Markdown files with a local Forgejo and external Codeberg remotes (2025 Q3 - Present)
The recent move to Git-backed Markdown has felt like such a significant improvement over my prior systems that I felt like writing about it.
I had read posts that some folks were fond of this setup, but at first I was doubtful because I felt like I’d be stuck forever running tons of commit commands and dealing with merge conflicts. In actuality, that hasn’t been as big of an issue as I thought it would be. I’ve got some tips and tricks to speed up working with Git listed at the bottom of this post.
Some notes about my particular use case
Here’s some background information to give you context about how I’m using and interacting with these tools:
- I’m the only user: Many knowledgebase platforms provide support for multiple users, and that adds layers of complexity. Since complexity leads to risk, that introduced anxiety. I’m looking for stability, simplicity, and a sense of being “at ease” when interacting with the overall system.
- 99% of my use happens at home: Since I work from home, only rarely do I need to access the information remotely. Do I really need to host complex infrastructure and have my data living offsite when the vast majority of my usage is done within my home LAN?
Thoughts on note-taking products
I flirted with Microsoft OneNote, Evernote, Ulysses, and several others.
All of these have nice interfaces, and some have cool and interesting features. However, I was never comfortable with any of them, because they all suffer from one or more of the following dealbreakers:
- Paid software
- Vendor lock-in
- Telemetry
- Part of bulky office suites
- Data stored in an opaque format
- Data synced to third-party sources I had zero control over
- AI-littered interfaces
- Private data used to train LLM models
Comparing TXT files in Syncthing, BookStack, and Git-backed Markdown files for storing personal notes
Ok, so let’s get down to it! I’m going to rate these three ways of storing and sharing content on a 0-5 scale:
- 5 being the highest marks for a particular measurement
- 1 being the lowest
- 0 means “this feature is not applicable or not available on the platform”
Here’s how I feel the platforms stack up:
| Feature | Syncthing TXT | BookStack | Git-backed Markdown |
|---|---|---|---|
| Available on multiple devices | |||
| Ease of hosting and operating | |||
| Knowledgebase features | |||
| Usable on your work computer | |||
| Mobile-friendly web interface | |||
| Revision control | |||
| Data safety at rest | |||
| Content accessible if platform unavailable | |||
| Total ratings score | 20/40 (50%) | 28/40 (70%) | 38/40 (95%) |
Ratings, explained
Let’s go over each of the ratings in the table above.
Available on multiple devices
All three solutions are available on multiple devices. So, it’s a tie here.
Ease of hosting and operating
Syncthing is free. You can simply run the software on two or more personal computers to get your shares working, and it’s not too complex to set up. You don’t need to involve a dedicated “server” unless you want an always-on replica, or you want a remote device that’s available independently from your physical home location. Every so often I ran into bizarre conflicts with out-of-sync files, or remotes that would appear to be stuck syncing at “99% complete” forever, but otherwise Syncthing is reliable and works well. There’s some security risk as you are indeed hosting a service with externally-open ports.
BookStack has hosted options, but they’re costly for a personal knowledgebase for a solo user. If you choose to go self-hosted, BookStack requires a stunningly-complex setup to run:
- You’ll need to build, manage, and operate a VPS instance.
- Then, you’ll need to understand how to operate and maintain: SSH, ZeroTier†, Apache, PHP, MySQL, BookStack, Composer, Laravel, all the various and changing BookStack dependences, Let’s Encrypt, Cron. († Optional, but I recommend using it.)
- If you choose to store your backups on AWS S3, you’ll need an AWS account and need to configure and operate AWS CLI.
Once BookStack is up and running, it’s easy to operate. But then, updates come along. From a long-term maintenance perspective, there are some further drawbacks:
- Updating the platform is a challenge, as the ever-changing
composerdependencies can get frustrating to work with over time. On more than one occasion, a requiredcomposerpackage wasn’t available on FreeBSD, or had issues running, causing platform updates to fail. - You are responsible to ensuring the platform is backed up, ideally to an off-site, third party source (like AWS S3). I was reasonably sure the backups were working, but I wasn’t ever able to feel fully at-ease knowing so much of my valuable personal information was teetering on a single point of failure.
Git-backed Markdown hosting is trivial and free on many platforms out there, like Codeberg, GitHub, etc. There’s nothing to maintain and no services to run. Just keep the git package up-to-date on your machine and interact with the files with your favorite text editor. If you want, you can self-host a Git instance on something like Forgejo. This setup is more secure than Syncthing, as there are no services listening on open ports.
Knowledgebase features
Syncthing text files have zero ability for cross-linking, showing images, etc. You could certainly use Markdown files here, editing them in an IDE much like I’ll talk about in a moment for Git-backed Markdown files… So in some ways this is a decent option. However, you won’t have the online read-only interface provided by a Git host, which adds a decent amount of utility.
BookStack wins here, hands-down. There are many useful features for organizing, formatting, and embedding rich content. I had some really slick HTML and CSS formatting on some pages.
Git-backed Markdown files don’t have many features per se, but if you’re viewing them in an IDE like VSCodium or VSCode, the Markdown will start to become more useful. Header levels, code blocks, and callout blocks help your content become more readable. And once published to a Git hosting platform, you’ll be able to browse the content in a read-only mode and see rich formatting, hyperlinks, and image support. I had to give up the ability to make some really custom HTML and CSS tweaks, but that was an OK tradeoff considering the other wins.
Usable on your work computer
Syncthing runs as a service on your local machine, and it needs to open port connections to peers. Most workplaces probably won’t want you installing a service like Syncthing on a work computer.
BookStack is accessible over the web, so it’s “just another website” to access.
Git-backed Markdown is probably A-OK to use on a work machine. If you’re geeky enough to want a personal knowledgebase with this setup, you probably have Git running on your work computer, too.
Mobile-friendly web interface
Syncthing is not suitable for personal knowledgebase content on a mobile device. It’s technically possible, and I do run the Syncthing client on my personal devices for media syncing (photos, mostly). But, editing text files on a mobile device is a tedious affair. Only true sadists need apply for this lifestyle.
BookStack has a fantastic web interface, and you can even edit on mobile devices.
Git-backed Markdown, if synced up to a publicly-accessible service like Codeberg, GitHub, etc., gives you a “good-enough” web interface that can show your content. You can even make changes to the content on mobile, which again is “good-enough” for basic changes on the go. I think BookStack’s editor wins over online Git edits here, so I rated it a bit higher.
Revision control
Syncthing can store copies of changed files, but you have to set up a revision scheme. In most cases, after a certain amount of time or number of revisions, older content is purged.
BookStack has very good revision control for pages. You can see a page’s history and revert to older versions right within the web interface.
Git-backed Markdown files wins in terms of revision control, with powerful features like blame and the UI’s of online repos. All changes from the beginning of the repo’s creation are stored on every machine that works with the repo.
Data safety at rest
Syncthing introduces a few subtle sources of risk for the data at rest:
- When viewing a file, stray keystrokes could accidentally modify a file you’re simply reading. An accidental save would then change the file. Without a Git-style blame system, you might not notice until it was too late. This could be as simple as an errant key stroke or an accidental deletion of an entire section of content.
- It’s possible for infection on a remote to silently spread to and corrupt local files on all replicas.
BookStack is a website that is typically operated in a publicly-accessible state (unless you lock it down with any number of methods). If the server is compromised, your data is at risk. If the server’s backups aren’t configured properly, your content is lost. You must be forever vigilant operating this setup, and that adds a slight mental tax to your life. I never felt that my data here was truly safe.
Git-backed Markdown is utterly immune to almost all disasters. Absolutely nothing can happen to plain-text files sitting on your machine. And in even the most spectacular failure scenarios, any machine with a repo clone becomes a point-in-time recovery backup of the entire state and history of the content.
Content accessible if platform unavailable
Syncthing and Git-backed Markdown content is available at all times, regardless of the platform’s operational status, so this is never a problem.
BookStack content is not accessible if the platform goes offline, leaving you in a serious bind. Most people will run a single instance of BookStack without a mirror, so there’s a painful single point of failure. Several times while updating BookStack or the various service dependencies, a wonky composer update or a random problem causing Apache or SSL certs to go haywire would make all of my notes inaccessible. At a time when I needed my notes the most, I couldn’t get to them. I had a pre-update ritual of opening up every page I thought I might need in separate browser tabs so that I could have my notes ready in case BookStack went offline. This felt like some sort of silly voodoo practice and I’m glad to no longer need to do that.
Summary thoughts
I was excited for the features that BookStack provided, but as I moved content into the platform I was left with a vague feeling of unease. Moving content into BookStack never left me feeling totally secure. I figured the platform itself was trustworthy, but what if the platform was discontinued? What if the server got hacked? What if my backups weren’t working and I was humming along with ever onlyone copy of my most precious data in existence?
I noticed as I began to move content out of BookStack and into Git that I started feeling a sense of security and safety. It felt safe because I knew nothing could ever happen to my files. I didn’t have to worry about backups to S3 failing or any number of other “silent killers” that could be of hidden risk. I know my content is cold and at rest, static and immutable unless manually invoked to change by my hand. And… knowing those changes are fully tracked over the content’s entire lifetime gives me a sense of quiet and ease that I truly value.
Appendix: Miscellaneous thoughts on the platforms
BookStack
- If you’re working in the HTML editor, accidental presses of ESC or clicks outside the editor’s popup window will close the editor modal and cause you to lose any changes you’ve made. This happened to me more than once and was quite frustrating.
- I have a lot of tabular content, and BookStack writes really pedantic HTML tables with width percentages on every cell in the table. It was ugly and obtuse to work with.
Git-backed Markdown
- Rendered Markdown output is possible directly from within VSCodium or VSCode with the Mark Sharp extension from Jonathan Yeung. I can usually visually parse Markdown in edit mode just fine, but sometimes “you just want pretty.”
- Obviously, you aren’t relegated to just storing Markdown files in a Git repo or a Syncthing share. You can add all sorts of content easily, including folders of source code for projects. I’ve also been storing the pure Markdown output of LLM conversations. Now everything is searchable and stored safely.
Tip: Save time making commits
Since this is a repo only used by me, I can get away with some shortcuts:
- I don’t use PRs, I just work directly on
main. - I don’t bother with descriptive commit messages unless there’s a major change.
I wrote a little helper alias gcp that allows me to quickly commit staged files with a boilerplate message.
alias gcp="git commit -m \"Updates\" && git push origin main"
So yeah, my commit history looks like this…
d38be3a (HEAD -> main, origin/main, origin/HEAD, codeberg/main, codeberg/HEAD) Updates
ce5e530 Updates
b0f1bc3 CLEANUP OF MIGRATED CONTENT
9c0013d Updates
50c4354 Updates
9717e83 Updates
baffaa0 Updates
2c64ee6 MAJOR REORGANIZATION
bfcfb1f Updates
c15075a Updates
22d6444 Updates
883f25c Updates
eb4b504 Updates
679fe8c Updates
ff28c48 Updates
6a7cc24 Updates
8bb9b71 Add old training files
51b09a0 Updates
c6e9d53 Add archived notes
faf8868 Updates
…but it’s ok because tools like blame and the remotes’ web interfaces help me investigate any file histories or changes I’m interested in.
Tip: Host a local Forgejo instance
This is totally optional, but hosting a Forgejo instance locally is relatively easily (I operate a homelab with a local VM server). Day-to-day changes are pushed almost instantly, which keeps me in mental flow while working. At the end of each day, I push all changes out to a third-party, external remote, for disaster recovery and to ensure I can access my latest notes while outside of my home.