The topic of My NAS became a private Git server, and now I can’t imagine managing my home… is currently the subject of lively debate — readers and analysts are keeping a close eye on developments.
This is taking place in a dynamic environment: companies’ decisions and competitors’ reactions can quickly change the picture.
Every NAS I’ve bought over the years has been laser focused on storage and backups. Like most people who get into home servers, I started with the simple and straightforward goal of keeping my files organized in one place, and ensuring that nothing important got lost if a drive failed. But over the years, I’ve taken to using my Synology NAS for more than just storage.
My Synology NAS sits at the center of my self-hosted stack. It’s power-efficient and handles everything from Docker containers to my media library, even Immich. Complete with easy remote access via a reverse proxy, it’s become the place where all the important moving elements of my home network live. But that’s also created a problem I didn’t anticipate earlier on.
Turns out, the more infrastructure I move onto the NAS, the more small but important changes I keep making to the system without any reliable way to track them. A Docker Compose file might start a certain way, but all too often I’ll be making changes to environment variables late at night to tweak it to my needs. And a few hours, days, weeks, or even months later, if something would break, I’d be left scrambling to figure out what I’d changed or tweaked. To solve this problem, I turned my NAS into a private Git server. As a hobbyist, I don’t really need enterprise DevOps for a home lab. However, since my NAS already stores my most important files and runs my life, it should also be responsible for handling the version controls for the stack that powers it.
Diving into setting up my NAS server, I had a few choices on hand. The first choice was simple. Synology already offers its own Git Server package, so naturally, I was tempted to use that. I tried it out and while it worked just fine, giving me Git hosting on my NAS with SSH access. And if all you want is basic push, pull, and clone functionality, it does the trick. The problem is that Synology’s built-in Git server is a bit too limiting and does little more than Git over SSH. There’s no interface for browsing repositories or issue tracking, or pull requests. Issue tracking, in particular, is something I find very handy for leaving myself little notes about my own stack. And that last part matters more than it might sound like for a home server.
A lot of what I use Git for as a hobbyist is not just version control, but operational storage. If I change a Docker stack, test a new mount path, or even if I update permissions for a container, I want a record of what I changed and why. Issue tracking, in particular, is useful for leaving myself notes about unfinished work or problems that I need to revisit earlier. Within the context of my home server, my Git use is less about collaboration with other people and more about revisiting what I’ve been up to.
The other issue is access control. Synology’s Git server requires users to have SSH access to the NAS. I don’t like that. I don’t want to hand out broad access to my NAS just so that someone can push to my private repository. Even if it is just me using it most of the time, I would rather keep Git access separate from direct system access. So, I installed Gitea instead.
While practically every software developer uses a flavor of GitHub for storing software projects, that’s not really what is my main use case. Most of my repositories aren’t software projects. Instead, I use them as operational files to keep track of changes to my system. My Docker Compose stacks are critical, and they go to a dedicated repo. If I update a container path or change an environment variable, it goes to Gitea. Similarly, setup notes for Immich, my backup workflows, media mounts, and even shell scripts that I’m using are within Git.
Without version control, your self-hosted infrastructure can quickly become a game of guessing what changes you made. Often I’ll tweak things to fix problems and forget to document them. And if I ever need to rebuild this setup, you can be sure I wouldn’t remember precisely what I tweaked. In fact, I ran into this specific issue when a broken update killed my Raspberry Pi-based wireless scan server project. Committing your changes and documentation to Git solves that problem.
Anytime I test out a new stack in Portainer and something breaks, I don’t need to dig through old notes. I can open the repository and see the exact changes.
On the face of it, installing Gitea solved a very simple problem for me — that of documentation. And yes, there are simpler methods of documentation. for example, you can spin up Dokuwiki and store notes there. However, Dokuwiki doesn’t offer the array of tracking features that a Git server can.
My GitHub profile is what I use for public projects, experiments, and collaboration. Meanwhile, the private Git server running on my NAS handles the boring but equally important stuff — tracking infrastructure files, configs, documentation, and more. It’s the best of both worlds.
Gitea is a self-hosted Git service that lets you host and manage private repositories, version control and project documentation.
Why it matters
News like this often changes audience expectations and competitors’ plans.
When one player makes a move, others usually react — it is worth reading the event in context.
What to look out for next
The full picture will become clear in time, but the headline already shows the dynamics of the industry.
Further statements and user reactions will add to the story.