Escaping the 15GB Trap: My Slightly Stubborn Journey from Google Photos to Open Source
Today felt like a small personal victory.
After many months of irritation, experiments, false starts, and a few moments where I thought I might cook my Raspberry Pi alive… I finally got an open-source photo management system running at home. And more importantly, it works.
This whole thing started because of the now famous 15GB limit on Google accounts. Years ago that sounded huge. Practically infinite. Now? It feels like a tiny lunchbox trying to store a lifetime of photos.
And the real culprit is not even the photos anymore.
<h3>The Problem: Modern Phones Don’t Just Take Photos</h3>
I belong to the older generation of digital photography. Back then a photo was just… a photo. Small file. A few hundred kilobytes maybe. Life was simple.
Now every time you press the shutter on a Samsung phone, it quietly records a LIVE photo. Which basically means a short video clip plus multiple frames.
Nice feature. Cute effect.
But multiply that by thousands of pictures over years and suddenly your Google storage graph looks like a rocket launch.
Cloud companies love this of course.
Without a proper photo management system, what you end up with over time is not a collection. It’s an ocean of photos and videos.
And when Google keeps sending those polite little reminders that your storage is almost full… well… the irritation begins.
<h3>Things I Tried (Before Finally Doing Something Serious)</h3>
Like most people, my first solutions were the obvious ones.
<ul>
<li>Free up space by deleting large files. Quick win, but temporary.</li>
<li>Delete unwanted pictures. This sounds good in theory but in reality it takes forever.</li>
<li>Remove all videos and only keep pictures. Actually a pretty effective policy.</li>
<li>Create another Google account. Yes… I did that.</li>
<li>Then another backup account. Now the problem becomes remembering chronology.</li>
<li>Eventually I started thinking: why not something local?</li>
</ul>
<h3>Enter the Raspberry Pi</h3>
I already had a small Raspberry Pi running at home and an old 500GB SSD where I had dumped a lot of my photo backups.
Those photos themselves were survivors. I had already lost a big nostalgic archive earlier when an HDD died and even professional recovery couldn’t bring it back. That still hurts.
So this time I did things slightly better.
I bought another 1TB SSD and wrote a small bash script using <code>rsync</code> to mirror the 500GB drive once every week.
Old school? Yes.
Reliable? Also yes.
So now I had storage and backup.
But browsing photos using Samba shares and Windows Explorer was honestly painful. It works… but generating thumbnails for thousands of images makes everything slow and clunky.
I needed a proper photo management interface.
<h3>A Small Breakthrough: Cloudflare Tunnel</h3>
Yesterday something interesting happened.
I managed to expose my Raspberry Pi through a Cloudflare Tunnel so I could access it from anywhere. That deserves its own post someday.
But once that worked, a new idea popped into my head.
If I could reach my Pi from anywhere… then why not run my own Google Photos at home?
That started the search.
<h3>The Two Options That Showed Up</h3>
Two names kept appearing.
<ul>
<li>Lychee</li>
<li>PhotoPrism</li>
</ul>
Lychee looked lighter. PhotoPrism looked powerful but heavy.
And almost every article on the internet warned:
“PhotoPrism needs at least 4GB RAM for decent performance.”
My Raspberry Pi 3 definitely does not have that.
But curiosity won.
<h3>Trying Lychee</h3>
Installing Lychee through Docker was actually pretty easy. I had a day off so it was just me and the terminal the whole day.
Everything looked good… until I ran into something strange.
The hostname in the docker-compose configuration needed to exactly match what the browser would call.
That meant I couldn’t just run something like:
localhost:8080
and then access it via my domain through Cloudflare.
It simply is not supported, and I wonder if its Apache htaccess or some other limitation.
Since remote access through my domain was one of my main goals, Lychee unfortunately had to go.
<h3>Considering Another Option: My VPS</h3>
For a brief moment I thought maybe I should just run everything on my VPS server.
But that machine is a very minimal VM. It would require its own backup strategy.
And honestly storing all my personal photos there didn’t feel any safer than just continuing with Google Photos.
So that idea died quickly.
<h3>Time to Try the Beast: PhotoPrism</h3>
Everyone said it was heavy.
So naturally… I tried it anyway.
The installation through Docker was surprisingly straightforward. Containers started, MariaDB spun up, everything looked promising.
At first the page wouldn’t load.
Then after about two or three minutes the login screen appeared.
Okay.
The warnings about it being heavy were definitely real.
<h3>The Raspberry Pi Almost Melted</h3>
Initially the interface was empty because I forgot to mount my photo directory into the container. After fixing that, indexing started.
And then things went crazy.
PhotoPrism began loading TensorFlow models for AI face detection and image classification.
On my Raspberry Pi.
This was not a good idea.
The CPU shot to the sky. The Pi sounded like it was fighting for its life. SSH became laggy. I was honestly worried it might corrupt the SSDs or damage the filesystem.
And the worst part?
It processed maybe ten photos before choking.
Out of hundreds of thousands.
Clearly not going to work.
<h3>Attempt Two</h3>
I recreated the containers and this time tried indexing only a smaller folder without videos.
Same story.
Slow.
Very slow.
Basically going nowhere except learning a lot of Docker commands.
So I gave up for the day and slept it off.
<h3>The Real Solution</h3>
Next morning I came back to the system. I anways had to try the tunnel from an external network and it worked like a charm. There was this itch still for making the PhotoPrism work. So…
This time before indexing I went into the advanced settings and started disabling things.
Face recognition — off
Image classification — off
That helped a bit but it was still painfully slow.
So I checked the logs.
PhotoPrism was creating about ten thumbnails per image, and each picture was taking roughly 4–5 seconds to process.
That meant days of indexing.
Possibly weeks.
My Pi would probably melt before finishing.
But the good news was something important: the software gave full control over features.
That is something I really appreciate about good open source.
<h3>The Final Attempt (This One Worked)</h3>
I removed the containers again and edited the docker-compose configuration directly.
This time I disabled everything heavy through environment variables.
No TensorFlow, face recognition/ classification
No RAW /EXIF processing or FFMPEG
No JSON generations for backup etc
Basically I stripped it down to what I really needed:
A web interface to browse photos and videos.
That’s it.
I also ran the interface in read-only mode just to protect my files while testing.
And suddenly…
It worked.
Indexing became reasonable. The Pi stayed alive. The system was responsive.
<h3>What I Have Now</h3>
Right now the setup looks like this:
Raspberry Pi at home
500GB SSD with my photo library
1TB SSD weekly rsync backup
PhotoPrism running in Docker
Read-only photo browsing interface
I can access everything through the Pi’s local IP.
Next step is exposing it through my Cloudflare tunnel on my subdomain so I can reach it from anywhere just like Google Photos.
<h3>Future Ideas</h3>
Later I might upgrade hardware and re-enable some features like:
Image classification
Face recognition
Location mapping
All of that can be enabled simply by changing the Docker configuration and recreating the container.
That flexibility is honestly amazing.
I might also experiment with Nextcloud, though PhotoPrism feels more specialized for media.
Another idea is to attach the backup drive to a second Raspberry Pi so even if one machine fails the other can still serve the photos.
<h3>Why This Feels Good</h3>
For the first time in years I am not worried about that 15GB storage warning.
My photos are local.
Backed up.
Accessible from anywhere.
And running on hardware I already owned.
Also… this whole process reminded me why tinkering with systems is fun. There was frustration, trial and error, almost burning a Raspberry Pi, learning Docker commands I didn’t know yesterday… and finally seeing it all work.
Phew.
I didn’t plan to write this much but maybe I’m just excited.
So tell me honestly.
Am I just an old guy and stubbornly avoiding cloud subscriptions, and this is nothing new… or is this actually a sensible setup?

Austin Cross

A personal account of migrating from Google Photos to a self-hosted photo management system due to the 15GB storage limit. The author sets up PhotoPrism on a Raspberry Pi 3 using Docker, encountering severe performance issues caused by TensorFlow-based AI features. The solution was disabling face recognition, image classification, RAW/EXIF processing, and FFMPEG through environment variables, reducing PhotoPrism to a lightweight read-only photo browser. The setup uses a 500GB SSD for the photo library, a 1TB SSD with weekly rsync backups, and a Cloudflare Tunnel for remote access. Future plans include re-enabling features on upgraded hardware and experimenting with Nextcloud.