WebholeVault: Building Private Photo & Video Storage From Scratch
I've spent a lot of time building websites, running servers, experimenting with AI, and figuring out how much of my digital life I can put back under my own control.
Eventually that led me to another question:
What would my own private photo and video storage service look like if I built it from scratch?
That question became WebholeVault
WebholeVault is a privacy-first photo and video storage platform I'm developing as part of the Clifford's Webhole ecosystem.
There are no public profiles.
There is no public photo feed.
There is no follower count.
There is no algorithm trying to figure out what you should look at next.
The basic idea is much simpler:
Your photos. Your videos. Your account. Private storage.
๐ Why Build Another Photo Storage Service?
There are already plenty of places on the internet where you can upload photos and videos.
But many modern platforms are built around some combination of sharing, discovery, galleries, communities, professional portfolios, collaboration, or social networking.
That's not what I wanted to build.
I wanted something closer to a personal digital vault.
When you upload something to WebholeVault, it isn't supposed to become part of a public community.
It goes into your account.
Other customers can't browse it.
There is no public user search.
There are no public galleries.
There are no followers.
WebholeVault is being designed around the idea that private should actually mean private.
That doesn't mean other photo platforms don't offer privacy. They do.
The difference is what each platform is fundamentally designed to do.
๐ธ SmugMug vs WebholeVault
SmugMug is a powerful photography platform with unlimited full-resolution storage, galleries, websites, sharing tools, password protection, and detailed privacy controls.
Users can make photos and galleries public, unlisted, password protected, or private. SmugMug is especially well suited to photographers who want to organize, display, share, and even sell their work.
WebholeVault takes a different approach.
WebholeVault isn't trying to give every user a photography website or public gallery.
There is no public-facing customer site.
There is no portfolio.
There is no public gallery system.
There is no photo selling system.
WebholeVault starts from the opposite direction:
Everything belongs inside your private vault.
Instead of building a public photography platform and providing controls for making portions of it private, WebholeVault is being built as private storage from the beginning.
๐ Flickr vs WebholeVault
Flickr has been part of the online photography world for decades.
It combines photo and video hosting with albums, profiles, followers, groups, comments, public discovery, and community features.
Flickr also provides privacy controls. Individual photos and videos can be restricted, and private content can be shared with selected people.
But Flickr is still fundamentally a photography community.
People can publish photographs publicly, follow photographers, participate in groups, interact with other users, and discover photography from around the world.
WebholeVault isn't a photography community.
There are no followers.
There are no comments.
There are no public profiles.
There are no public groups.
There is no public photo stream.
There is no discovery algorithm.
There isn't even a mechanism for another WebholeVault customer to search for your account.
Two people could use WebholeVault for years and never know the other person has an account.
That's intentional.
Flickr helps photographers share and discover photography.
WebholeVault is designed to store your personal media privately.
Those are two very different goals.
๐ชฃ Photobucket vs WebholeVault
Photobucket has evolved considerably from the image-hosting service many people remember from the early web.
Modern Photobucket accounts are private by default, and the platform provides personal storage along with albums, sharing links, and collaborative Groups where invited people can share photos and videos.
That's a much stronger privacy model than simply assuming everything uploaded to an image host is public.
But sharing and collaboration remain important parts of the Photobucket experience.
WebholeVault deliberately strips the concept back even further.
The primary relationship isn't:
User โ Gallery โ Audience
or:
User โ Group โ Members
It's simply:
User โ Vault โ Media
Your WebholeVault account exists to hold your photos and your videos.
The platform doesn't need to build a social graph around them.
๐ A Different Philosophy
SmugMug, Flickr, and Photobucket are mature platforms with capabilities WebholeVault doesn't have โ and in some cases doesn't intend to have.
That's okay.
I'm not trying to clone them.
I'm building something based on a different question.
Instead of asking:
"How can people upload photos and then decide who they want to share them with?"
WebholeVault starts by asking:
"What if the photos and videos simply weren't public in the first place?"
That distinction influences the entire architecture.
No public profiles.
No public search.
No public galleries.
No follower system.
No popularity metrics.
No social feed.
No pressure to publish anything.
Just a private place for your media.
That's the niche I'm exploring with WebholeVault.
Your photos. Your videos. Your vault.
๐๏ธ Building It From the Ground Up
WebholeVault isn't an off-the-shelf photo gallery with a different logo slapped on top.
I'm building the application and infrastructure myself.
The current stack includes:
- Python
- FastAPI
- PostgreSQL
- Docker
- Private Cloud object storage
- Nginx Proxy Manager
- Authenticated media delivery
- Server-generated thumbnails
- Automated backups
- Linux infrastructure
The application runs on my own VPS infrastructure while media objects are stored privately in the cloud.
That gives me control over the application while allowing the storage layer to grow independently.
๐ธ Photos and Videos
WebholeVault originally started with photos.
It didn't stay that way for long.
The platform now supports both photos and videos.
Uploaded media can be displayed inside the user's private library, while the application keeps track of information such as:
- File name
- File size
- Media type
- Image dimensions
- Video duration
- Storage usage
Video playback is authenticated rather than exposing the underlying storage objects publicly.
Users can also seek forward and backward during playback just like they would expect from a normal video service.
โฌ๏ธ Uploading Media
One area I've spent quite a bit of time on is the upload process.
Uploading a large video isn't the same as uploading a small JPEG.
WebholeVault therefore uses a multi-stage upload process.
The interface tracks:
- Browser โ Server upload
- Server-side processing and storage
The progress indicator doesn't simply jump to 100% when the browser finishes sending the file.
It waits until WebholeVault has actually finished processing the upload.
That sounds like a small detail.
It isn't when you're dealing with large media files.
๐๏ธ Trash, Restore, and Permanent Delete
Accidentally deleting a photo shouldn't immediately destroy it.
WebholeVault includes a Trash system.
Media can be:
- Moved to Trash
- Restored
- Permanently deleted
This gives users a chance to recover something before it disappears for good.
The underlying storage system also uses lifecycle management as another layer of storage housekeeping.
๐ Organizing the Vault
As the project has grown, I've also been building the foundation for organizing larger media collections.
WebholeVault understands that a real photo library eventually becomes more than a handful of files.
The architecture is being designed so that navigating and managing a growing collection remains practical instead of turning into one giant pile of thumbnails.
๐ Private Storage Means Private Storage
One of the most important design decisions was keeping the actual media storage private.
WebholeVault doesn't simply upload a file somewhere and expose a permanent public URL.
The cloud storage used by the platform is private.
Access to media is handled through the application.
That means WebholeVault can verify that the person requesting a photo or video is actually authorized to access it.
This is a fundamental part of the design rather than something being added later.
๐ก๏ธ Security From the Beginning
Security isn't something I wanted to bolt onto WebholeVault after everything else was finished.
Some of the protections already built into the platform include:
- Authentication-protected media
- Private object storage
- CSRF protection
- File-type validation
- Account ownership checks
- Controlled administrative access
- Audit logging
- Automated backups
I've also been testing the application specifically for authorization mistakes โ especially situations where one user might attempt to access another user's media.
With private storage, that boundary is critical.
๐งฐ VaultOps
Running a storage service also requires administrative tools.
That's where VaultOps comes in.
VaultOps is the administrative side of WebholeVault.
It includes tools for account management, storage information, media metadata, and controlled privileged review.
Administrative access to customer media isn't designed as a casual "browse everybody's photos" feature.
Privileged media review uses a case-based system requiring a reason and justification before access.
Review actions are audited.
Cases must be explicitly opened and closed.
The goal is accountability.
If privileged access is ever necessary for legitimate operational, abuse, security, or legal reasons, there should be a record of why it happened and what was accessed.
๐พ Backups Matter
If you're building something designed to hold people's photos, backups aren't optional.
WebholeVault is integrated into my automated server backup infrastructure.
Nightly backups include the application and PostgreSQL database, with copies sent off-server to separate cloud backup storage.
Local backups are also retained for short-term recovery.
I don't consider a system finished simply because it's running.
I want to know how I'm going to recover it when something eventually goes wrong.
๐ฑ Going Beyond the Browser
WebholeVault is also beginning to move beyond being only a web application.
I've started developing an Android application for the platform.
The goal is to make uploading photos and videos from a phone or tablet much more natural while still using the same WebholeVault account and backend infrastructure.
That's an area I'm actively experimenting with now.
๐งช Why I'm Not Rushing Into Paid Accounts
I originally designed several possible storage plans for WebholeVault.
But before turning this into a paid service, I made a decision:
First, I want real users beating on it.
My initial goal is roughly 20โ30 early users uploading real photos and videos.
That will tell me far more than synthetic testing ever could.
I want to see:
- How the VPS behaves under multiple users
- How upload traffic affects performance
- How video playback behaves
- How storage consumption grows
- How much bandwidth is actually used
- What Cloud storage costs look like in the real world
- What breaks when people use the application in ways I didn't anticipate
That's why the initial phase of WebholeVault is focused on free early-access testing rather than paid subscriptions.
Once I have real-world data, I'll have a much better foundation for deciding what comes next.
๐ง This Is Still a Work in Progress
WebholeVault isn't a finished product.
And that's part of why I'm documenting it here.
There will be bugs.
There will be features that change.
There will probably be things I build one way and completely redesign later.
That's software development.
But the core platform is already far beyond the original experiment.
What started as:
"Can I build my own private photo storage?"
has turned into authentication, object storage, databases, video streaming, upload processing, account management, administrative controls, audit systems, backups, and now Android development.
And I'm still building.
๐ Part of Clifford's Webhole
WebholeVault represents a lot of what Clifford's Webhole is about.
Build it. Host it. Understand it. Improve it.
I could have installed an existing photo platform and called it a day.
But where's the fun in that?
Building WebholeVault has forced me deeper into Python, FastAPI, PostgreSQL, object storage, authentication, media processing, Docker networking, security, Android development, and infrastructure design.
That's exactly the kind of project I created Clifford's Webhole for.
A place to experiment.
A place to build.
And occasionally a place to wonder why something that worked perfectly yesterday suddenly throws a 500 error today.
Then figure it out.
๐ What's Next for WebholeVault?
The immediate goal is real-world testing.
I want to get WebholeVault into the hands of a small group of early users and see what happens when the system starts handling real accounts, real photos, real videos, and real-world usage.
From there I'll continue working on:
- Android integration
- Media organization
- Upload improvements
- Performance
- Storage monitoring
- Security
- User experience
- Administrative tooling
- Infrastructure scaling
I'll be documenting that journey here on Clifford's Webhole.
WebholeVault isn't just something I'm launching.
It's something I'm building in public.
Welcome to the Vault.
Built from scratch inside Clifford's Webhole.