Show HN: We are three devs from Kenya and built a Docker alternative in Rust

RonaldOloo 5 days ago | parent | next [-]

Hey everyone, one of the co-founders here(Ronald Oloo). Just wanted to add a bit more technical context for those interested. We chose Rust for this project for its performance and, more importantly, its safety guarantees. The long-term vision for Sphere's security relies on being able to build a truly minimal, secure sandbox, and Rust's memory safety is a huge part of that foundation. The dependency system right now is simple (it just uses a local JSON index), but it's designed to be the prototype for a future federated SphereHub. The goal is to avoid the centralized pitfalls of other package managers. We know it's a long road ahead to get to true chroot/namespace-level sandboxing, but we're excited about the architecture. Happy to dive into any technical questions about the implementation!

▲

tuananh 4 days ago | parent [-]

> it's a long road ahead to get to true chroot/namespace-level sandboxing

but everyone is moving to microvm because namespace/cgroup is not enough.

- GCP did with cloudrun v2

- aws did with firecracker

- Microsoft use VM for wsl2

- Apple with microvm for their Apple Container

	▲	Clein 4 days ago \| parent [-]
		Hi @tuananh, Thank you so much for this incredibly insightful comment and for sharing these examples (GCP Cloud Run v2, AWS Firecracker, WSL2, Apple Container). This is exactly the kind of expert feedback we were hoping to get by sharing Sphere at this early stage. You are absolutely right. While our initial thoughts for Phase 2 were around chroot/namespaces, the industry trend towards MicroVMs for superior isolation is undeniable, and your point about them being a step beyond what namespaces/cgroups can offer is very well taken. Firecracker, in particular, is a technology we have immense respect for. Our "true sandboxing" goal on the roadmap is precisely about achieving that level of robust, kernel-level isolation. Your comment gives us a strong signal to prioritize research and prototyping with MicroVM technology as we design that phase. The ultimate aim for Sphere is to provide the strongest practical isolation with the least possible overhead, and if MicroVMs are the best way to achieve that, then that's the direction we'll head. This MVP (v0.1) is focused on proving the core concepts of the declarative format, dependency management, and basic environmental isolation. Your feedback is invaluable in helping us shape the next, more critical security layers. Would you mind if we referenced your comment (and these examples) in our GitHub issue for "Feature: Implement true chroot/namespace sandboxing" as we explore the best path forward? We'd love to credit you for the pointer. Thanks again for taking the time to share your knowledge! - Clein, Kelly, & Ronald (The Sphere Team)

▲

Kellygreg 5 days ago | parent | prev | next [-]

Co-founder here(kelly Gregory). So excited to finally share this. For me, the 'aha' moment for Sphere was realizing how much of our time as developers is spent fighting our tools instead of solving problems. We're constantly wrestling with environments, dependencies, and CI/CD pipelines. The core idea of Sphere is to make computation a 'solved problem'. You should be able to define a task and have it run predictably, securely, and portably without thinking about the underlying machine. We started with a simple command runner, but the vision is a global, decentralized compute grid. This MVP is just the first step on that journey. We're really keen to hear from other devs about what their biggest pain points are in this area!

▲

Clein 5 days ago | parent | prev [-]

Hi HN, we're the creators, Clein, Kelly, and Ronald. We're incredibly excited (and nervous!) to share this with you all. We started this project on our phones using termux, driven by the frustration of how complex modern software deployment has become. Our goal is to build a tool that's simple, secure by default, and truly portable. This is version 0.1, a very early MVP, but it demonstrates the core concept. The project is fully open source, and we're here to answer any and all questions. We would be grateful for any feedback, harsh or kind! We're ready to learn.