DEV Community

HazTechyContent
HazTechyContent

Posted on

OpenRig - Peer to Peer donation based hardware sharing platform

#devchallenge #weekendchallenge

DEV Weekend Challenge: Generosity Edition Submission šŸ’œ

This is a submission for Weekend Challenge: Generosity Edition

What I Built

I grew up teaching myself to code in Pakistan on hardware that struggled to run
modern dev tools. GPU hours on Lambda Labs cost $0.50ā€“$3/hr. For a student
trying to fine-tune a model or run a training job, that's not accessible.

OpenRig is a peer-to-peer compute sharing platform. Donors register their idle hardware and run a lightweight agent binary. Recipients describe what they need in plain English, get matched to the best available rig via Google Gemini AI, and receive SSH access ā€” time-limited, isolated, and without ever touching the donor's actual machine.

No money changes hands. You're donating the thing that actually matters: compute.

Demo

Here is the video link

Full flow:

  1. Donor registers their rig ā†’ copies agent token ā†’ runs the agent binary
  2. Recipient browses available hardware ā†’ submits a request explaining why they need it
  3. Gemini scores the request 1ā€“10 for social/educational impact
  4. Donor sees the impact score and reason ā†’ clicks Approve
  5. Agent spins up an isolated Docker container with SSH, starts a bore tunnel, reports the public connection command back to the backend
  6. Recipient gets an SSH command and password in their dashboard ā†’ connects
  7. Donor can revoke access at any time ā†’ container and tunnel torn down automatically

Code

Here is the code:
OpenRig

How I Built It

The stack

  • Backend: Go + Fiber v3, SQLite (GORM)
  • Frontend: SvelteKit + Tailwind CSS
  • Auth: Supabase (JWT verified on the backend via JWKS)
  • AI matching: Google Gemini 3.6 Flash via Google Gen AI Golang sdk
  • Tunneling: bore (open source TCP tunnel)
  • Isolation: Docker with hardened security flags

The hardest problem: giving strangers SSH access without exposing the donor's IP

The naive approach ā€” direct SSH ā€” exposes the donor's home IP to whoever connects. That's a non-starter.

The solution is a relay architecture. The donor's agent binary runs on their machine and maintains a persistent poll loop against the backend. When a request gets approved, the agent:

  1. Spins up an Ubuntu container with SSH on a random local port
  2. Waits for SSH to actually be ready (TCP retry loop, not a fixed sleep)
  3. Starts a bore tunnel pointing at that local port
  4. Parses bore's stdout for the public port
  5. Reports ssh openrig@bore.pub -p XXXXX and the session password back to the backend

The recipient connects to bore.pub. bore forwards TCP to the donor's machine. Docker maps it into the container. The donor's real IP never appears anywhere.

Why bore and not WireGuard

WireGuard is the right production answer but would have taken the whole weekend to set up correctly. bore is one binary, one command, and the public port comes out of stdout. For a 48-hour hackathon, that's the right tradeoff. I already run wg-easy for my homelab ā€” WireGuard is the v2 plan.

Container security

Recipients land inside a resource-capped Docker container, never the host:

docker run -d \
  --cpus="2" --memory="4g" \
  --security-opt no-new-privileges \
  --cap-drop ALL \
  --cap-add NET_BIND_SERVICE \
  ubuntu:24.04
Enter fullscreen mode Exit fullscreen mode

Known limitation: bore and the container are separate processes. If the agent exits unexpectedly, bore dies but the container keeps running until the donor manually revokes. Production fix would be Kata Containers for VM-level isolation ā€” which is actually my existing side project, so v2 writes itself.

Google Gemini for matching

When a recipient submits a request, Gemini 3.6 Flash reads their reason and scores it 1ā€“10 for social or educational impact. The donor sees the score and a one-sentence explanation before deciding.

This means donors aren't just picking at random ā€” they can prioritize a student training an NLP model for an underrepresented language over someone running benchmarks.

The agent architecture

The agent is a standalone Go binary donors run in a terminal. No daemon, no system service. It polls the backend every 3 seconds:

GET /api/v1/agent/poll?token=xxx ā†’ { to_provision [...], to_revoke: [...], to_restart: [...] }
Enter fullscreen mode Exit fullscreen mode

to_restart handles agent restarts mid-session ā€” if the agent exits and relaunches, it detects running containers via docker port, restarts bore against the same local port, and reports the new public port to the backend. Recipients get a fresh SSH command on their next poll.

What I'd do differently with more time

  • Replace Docker with Firecracker for proper VM-level isolation
  • Self-host the bore server for more control
  • Add session expiry enforcement (the DB field exists, the background worker doesn't yet)
  • Proper bore process monitoring instead of letting it die silently
  • Make the agent a proper system service with socket activation

Prize Categories

Best Use of Google AI

Gemini 1.5 Flash is the matching layer between recipients and donors. Rather than a simple filter by specs, recipients describe their work in plain English and Gemini determines which available rig fits best and how impactful the use case is. Donors make informed decisions based on AI-generated impact scores rather than just first-come-first-served.

Built in ~48 hours on a fresh linux install because previous one broke.Technical debt acknowledged, demo works, shipping it.

And the GPU sharing part is not functional yet because I ran out of time and energy.

Another limitation is that the docker container is that the host can see inside the container. So having personal data is not recommended.

Top comments (0)