What it is. DoubTech Pods is a RunPod-compatible GPU coordinator I built so my own machines do the work before I pay for cloud time. It exposes a RunPod-like API surface, but jobs run on local GPU nodes first and only overflow to serverless cloud endpoints when local capacity fills. The web console gives me an at-a-glance overview — active nodes (3/3), running and queued jobs, jobs today split local vs. cloud, my live RunPod balance and burn rate, the count of RunPod serverless endpoints (19 in the current deployment), and a system-health panel showing 100% coordinator uptime with an API health timeline and alerts.
Why I built it. Home and lab GPUs sit idle most of the day while serverless cloud time costs money by the second. Pods flips the default: local-first execution is the norm, cloud fallback is just the overflow path, and the client API never has to know which one served a given job.
What the nodes look like. Each machine runs a node agent that streams real telemetry back to the coordinator. In my fleet that's three boxes — Mysiraith (RTX 5070 Ti, 16 GB), Borethrax (RTX 3090, 24 GB), and Dahaka (RTX 5090 Laptop, 24 GB) — each card reporting live VRAM use, GPU utilization, temperature, agent version, and a rolling two-hour history (720 samples) of GPU/CPU/temp, with pause, update, restart, and remove controls per node.
The interesting engineering. The coordinator is a FastAPI service backed by PostgreSQL for state and Redis for queueing, behind nginx, with WebSocket streams for live job output and the TypeScript/Electron node agents that run on each GPU machine. A GitHub App integration scans repos for RunPod workers and deploys them locally, to cloud, or both — so bringing a new workload online is a repo scan and a click, not a manual container build.
Stack: FastAPI, React, PostgreSQL, Redis, nginx, Docker, WebSockets, TypeScript/Electron agents, GitHub App integration.
Links: pods.jaxns.net
Image Gallery
