I've spent years chasing race conditions in production systems, revenue systems handling real money, Kafka worker queues, and now reviewing LLM-generated backend code for a living. The pattern is always the same: code works fine until something fails mid-execution, then two processes think they own the same job.
AetherGrid is my answer to that. Job execution ownership runs on time-bound leases that renew continuously for the job's whole runtime, not a boolean flag that lies to you the moment a worker crashes or a heartbeat drops. Real subprocess execution with enforced timeouts, reconciliation that reclaims abandoned work, 280 tests behind it, including one that genuinely kills a process that ignores SIGTERM.
Live now on Product Hunt, launching August 21st. Would love feedback from anyone who's dealt with execution ownership or lease-based systems in their own infra, and happy to answer anything about the architecture.
Repo: https://github.com/wycliffRotich...
What happens to your AI workload when the worker executing it suddenly disappears?
Does another worker take over? Who owns that job? Can two workers accidentally execute the same work? And how do you know what happened?
These are the kinds of problems that led me to build AetherGrid.
Hey Product Hunt! I'm Wycliffe Rotich, Founder and CEO of AetherGrid.
I've spent a significant amount of time building an open-source control plane for distributed AI workloads, with one central idea: a job should have one owner at a time, even when infrastructure fails.
AetherGrid coordinates workloads across the compute you already own. It brings together:
Multidimensional scheduling: Places workloads based on available compute resources.
Worker coordination: Manages distributed workers and their execution lifecycle.
Lease-based ownership: Uses time-bound leases to establish who owns a job.
Tenant-scoped access: Supports API key issuance for named tenants.
Execution reliability: Handles worker and process failures with predictable ownership and recovery behavior.
But here's something I want to make clear.
I didn't build AetherGrid to give the world another dashboard or wrap an existing orchestration tool in a new interface. I wanted to build the actual control plane: the scheduling, coordination and ownership mechanisms that determine how distributed workloads get executed.
The project is built in the open. You can inspect the implementation, read the Architecture Decision Records, run the tests, challenge the design and see how the pieces fit together.
Now I'd like to invite you to do something beyond simply looking at the launch.
Star the repository if you believe this is worth building.
Fork AetherGrid if you want to experiment, extend it or explore how it could fit into your infrastructure.
Run it and tell me what works, what doesn't, and where you think it needs to improve.
Challenge the engineering decisions. I'm particularly interested in feedback from people working with distributed systems, GPU infrastructure, AI workloads, platform engineering and cloud computing.
If you're operating compute infrastructure and have a workload orchestration problem, I'd also be interested in discussing a real technical evaluation.
This project has been built through a lot of engineering, testing and deliberate design decisions. Now I want more engineers to get their hands on it.
Explore AetherGrid:
GitHub: https://github.com/wycliffRotich-dev/aethergrid
Website: https://www.aethergrid.co.ke
I'm Wycliffe, building AetherGrid from Kenya, and I'm excited to see what this community does with it.
Let's build something useful.