Note:
But here’s the thing—I must make my blog posts private. I’ve noticed some devs starring my repo, probably using my content for their own purposes. That didn’t sit right with me. If I made my entire blog repo private, Netlify wouldn’t be able to access it. So, I thought of a workaround: keeping only the blog folder in a private repo while linking it to my main site using Git submodules. It sounded perfect in theory. But reality had other plans.
The Day I Tried (and Failed) to Make My Blogs Private
It started as a simple thought—“What if I could keep my blogs private while still displaying them on my website?” At first, it sounded like an exciting challenge, a way to separate my personal content from the public repository while still maintaining the seamless experience of my AstroPaper blog. But little did I know, this single thought would turn into an exhausting battle with Git, Netlify, SSH keys, and my own patience.
The Idea That Sparked It All
I had been using AstroPaper to host my blogs, and all my Markdown files were inside the src/data/blog folder of my public repository. That meant anyone could just open the repo and see all my blog posts. I didn’t like that. I wanted to keep the actual .md files in a private repository while still displaying them on my public site. The idea was simple: use Git submodules to pull the private blog content into the public repo during deployment.
So I created a new private repository, TIME-MACHINE-BLOGS, and planned to add it as a submodule inside src/data/blog. If this worked, I could write my blogs in the private repo, push them, and they would still show up on my website. I was excited, and I thought it would be an easy setup. I was wrong.
The First Attempt – Adding a Git Submodule
I opened my terminal, navigated to my AstroPaper project, and ran:
git submodule add -b main git@github.com:ekrishnachaitanya2004/TIME-MACHINE-BLOGS.git src/data/blogIt added the submodule successfully. I committed and pushed the changes. But then, when I ran pnpm run dev, everything looked fine locally. “Perfect!” I thought. “Now let’s deploy.” I pushed the changes to Netlify, expecting a smooth build.
Boom. Build failed.
The First Failure – Netlify and SSH Authentication
The error message was brutal:
Host key verification failed. fatal: Could not read from remote repository. Please make sure you have the correct access rights and the repository exists.
I immediately understood the issue—Netlify’s build system couldn’t access my private repository. Since it was private, Netlify didn’t have the authentication to clone it.
After some research, I found the solution: I needed to add an SSH deploy key to my private repo. So, I generated an SSH key:
ssh-keygen -t rsa -b 4096 -C "myemail@example.com" -f netlify_deploy_keyThen, I copied the contents of netlify_deploy_key.pub and went to my private repository’s settings → Deploy Keys → Add Deploy Key. I pasted the key, enabled “Allow write access,” and saved it.
Next, I went to Netlify’s Environment Variables and added:
• Key: NETLIFY_AUTH_SSH_KEY
• Value: (pasted the private key from netlify_deploy_key)I was confident now. I triggered another build.
Failed again.
The Second Failure – The Infinite Submodule Loop
This time, I noticed something weird in my private repository. Instead of src/data/blog, it had src/data/blog/src/data/blog nested inside itself! Somehow, I had mistakenly added the public repository as a submodule inside the private repository. This was breaking everything.
I had to remove the submodule, but Git wasn’t making it easy. Commands like:
git submodule deinit -f -- src/data/blog
git rm -rf src/data/blog
git config --remove-section submodule.src/data/blogall threw errors saying that the path didn’t exist or was already removed. I was stuck in a weird state where Git thought the submodule existed, but it wasn’t actually there.
I tried deleting the .gitmodules file manually and committed the changes. Still, Netlify wasn’t happy.
The Third Failure – GitHub Push Protection
After several hours of trying different fixes, I finally managed to clean up the mess and push everything again. But GitHub had a new problem for me:
remote: Push cannot contain secrets
remote: GH013: Repository rule violations foundApparently, GitHub detected the SSH private key inside my commit history and refused to let me push. It was a security measure to prevent me from accidentally exposing sensitive information.
I had deleted the key file, but GitHub still rejected my push because the file existed in previous commits. I had to rewrite commit history to erase it permanently:
git rebase -i HEAD~5I removed the commit containing the SSH key and force-pushed:
git push --force origin LIVEThe Final Breaking Point
By now, I had spent nearly an entire day fighting with Git, Netlify, and submodules. I had tried everything, and every time I thought I fixed something, a new issue popped up. I had re-added the submodule at least five times, deleted and recreated the SSH key multiple times, and rewritten my Git history twice.
Finally, I asked myself:
“Why am I doing this? Is this even worth it?”
I took a deep breath and made the toughest decision of the day.
I removed the submodule entirely and decided to go back to the old way of just keeping my blogs inside the public repo.
git rm -rf src/data/blog
git commit -m "Removed submodule"
git push origin LIVELessons Learned
This entire experience taught me so many things:
1. Git Submodules Are a Nightmare – They seem simple but cause endless headaches when combined with private repositories and CI/CD pipelines.
2. Netlify SSH Authentication Is Tricky – Setting up deploy keys is possible but not worth the hassle for something simple like blog deployment.
3. GitHub Push Protection Is a Blessing (and a Curse) – It saved me from exposing secrets, but also made it difficult to clean up.
4. Sometimes, the Old Way Is the Best Way – After trying so hard to automate everything, I realized that my old system—just committing blogs directly—was the easiest and most reliable.At the end of the day, I wasted an entire day on something that didn’t even work. I could’ve spent this time actually writing blogs instead of trying to hide them.
To my future self, if you ever think about doing this again, DON’T. Just stick with the simple way. Some things don’t need to be complicated.
And if you ever get tempted to use Git submodules again… DON’T DO IT.
Every log and outputs are Stored— just Checkit out ,If Needed Link