BHV: A Single-Command Beehive Alternative

[kunal-595]

@pradeeban , please have a look , thank you

BHV: A Simpler Beehive for GSoC 2026

Category: Show and Tell
Live Demo - https://bhv-prototype-v2.vercel.app/

Why I Built This

Beehive was ambitious and powerful, but the complexity made it hard for small clinics to adopt. I want to honor the original goals while simplifying the execution.

So I built BHV (Behavioral Health Vault) — a ground-up rewrite focused on one thing: making it actually deployable by real clinics.

---

The Project Requirements & How BHV Tackles Them

1. Single Command Deployment

The Requirement: Clinics need software they can run without a DevOps team.

How BHV Solves It:

git clone https://github.com/kunal-595/bhv-prototype-v2.git
cd bhv-prototype-v2
docker-compose up -d

That's it. Flask, MongoDB, networking — everything boots together. No manual database setup, no service orchestration, no configuration files to edit.

---

2. Simple, Human-Readable Code

The Requirement: Future maintainers should understand the codebase in hours, not weeks.

How BHV Solves It:

def create_app():
    app = Flask(__name__)
    app.config["STORAGE_TYPE"] = os.environ.get("STORAGE_TYPE", "local")
    return app

No framework magic. No abstract factories wrapping factories. A junior developer can read this and know exactly what's happening. The entire codebase is ~15 files of explicit Python.

---

3. Works Offline (Air-Gapped Clinics)

The Requirement: Rural and secure clinics often have unreliable or no internet.

How BHV Solves It:

STORAGE_TYPE=local   # Everything stays on-premise
STORAGE_TYPE=github  # Cloud sync when available

Local mode stores images in ./data/ with a self-describing manifest.json. Even if the database crashes, patient data is recoverable from the filesystem alone.

---

4. No Cloud Expertise Required

The Requirement: Clinics don't have AWS/Azure specialists on staff.

How BHV Solves It: We use GitHub private repositories as the storage backend.

Why GitHub? Because every clinic already has someone with a GitHub account. We get cloud backup and version history without teaching anyone about S3 buckets or IAM roles.

---

5. Privacy-First Architecture

The Requirement: Health data needs proper isolation and integrity checks.

How BHV Solves It:

• Each patient gets isolated storage (separate directories or repos)
• SHA-256 checksums on every uploaded file
• Bcrypt password hashing
• Portable manifest means data isn't locked in our database

---

Why This Could Replace Beehive

	Beehive	BHV
Deploy	Multiple scripts, manual DB setup	docker-compose up
Understand	Days of onboarding	Minutes
Offline	Breaks without internet	Full local mode
Cloud Storage	Requires AWS/Azure knowledge	GitHub (everyone knows it)
Codebase	50+ files, heavy abstractions	~15 files, explicit code

BHV isn't trying to be clever. It's trying to be deployable by someone with Docker installed and 20 minutes.

---

Current Progress (60 of 350 hours)

Component	Status
Flask app factory	✅
Authentication (Email + OAuth)	✅
Local storage + manifest.json	✅
GitHub private repo storage	✅
Docker Compose setup	✅
Upload/view templates	✅

Progress: ████████░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░░  60h / 350h (17%)

---

Try It

git clone https://github.com/kunal-595/bhv-prototype-v2.git
cd bhv-prototype-v2
docker-compose up -d
# Open http://localhost:5000

---

Looking for Feedback

Two specific questions:

1. GitHub Storage — Any concerns with using GitHub API for 2-5MB image files? Rate limiting experiences?

2. Offline Sync — When a user uploads offline then connects later, should we do last-write-wins or create conflict copies?

Thanks for reading. Happy to answer any questions.

— Kunal

[pradeeban]

@kunal-595 good work.
GitHub storage is alright.
Last write wins seems ok to me.

[kunal-595]

Thanks.
I will proceed with GitHub storage and last write wins for offline sync, and document the decisions.

[kunal-595]

Hi @pradeeban

Screen.Recording.2026-01-30.033234.1.1.mp4

following up on the earlier discussion i have now implmented and documented the parts we aligned on:

• Dual storage (local + GitHub) with isolation and last-write-wins sync
• Formal RBAC (ADMIN / MAINTAINER / CLINICIAN / PATIENT / DEMO)
• Failure and recovery paths (network issues, GitHub API failures, MongoDB)
• Explicit threat model (assets, trust boundries, known limitations)
• Audit logging with hash chained integrity

All of this is kept intentionally minimal and written as architecture notes.

Wanted to check if this direction and level of detail is ok from your side so far?

Before moving further, i wanted to ask would it be ok if i share my proposal draft dirctly with you for feedback?
I am a bit hesitant to post detaled technical design publicly before the selection phase, since it exposes most of the approach.

let me know what you would prefer.

[pradeeban]

of course, feel free to email me and the other mentors your draft in a single email (cc everyone there in a single email).

[kunal-595]

thanks, that works for me.
i will send a single email with the proposal draft and CC the other mentors as suggested.

[kunal-595]

Hi @pradeeban ,
I’ve prepared a draft of my GSoC proposal based on our GitHub discussion. Would you be open to review it and pointing out any improvements or gaps?
I will share the draft if that works for you.

[pradeeban]

Hi,
The deadline is March 31 - 18:00 UTC.
I recommend simply uploading it to the GSoC Portal. We have a large queue of proposals to give feedback at this point. So, we are unlikely to get back before the deadline, and we do not want you to miss the deadline.

Then, if we have comments or questions, we will reach out to you.