Sphere v0.2.0: Introducing a Public Hub for Shareable, Sandboxed Commands

Nakadra — Mon, 23 Jun 2025 18:20:09 +0000

Hey Dev Community! We're Clein, Kelly, and Ronald, the team behind Sphere.

A few weeks ago, we introduced Sphere v0.1 – a Rust-based CLI tool for running commands in isolated, portable sandboxes, born out of our experiences developing on mobile with Termux in Kenya. [https://dev.to/spheredevs/we-built-a-docker-alternative-in-rust-on-our-phones-in-kenya-heres-why-21c0].

Today, we're incredibly excited to launch Sphere v0.2.0, which takes a giant leap forward by introducing the SphereHub MVP!

What is the SphereHub?

Imagine a world where any script, tool, or simple utility you write can be easily shared with others, and where you can just as easily pull in tools built by the community, all with guarantees of isolation and integrity. That's the vision behind SphereHub.

With v0.2.0, Sphere is no longer just a local tool. It's the beginning of an ecosystem.

How It Works:

1. Publishing Your Sphere (Sharing is Caring!)

Got a cool .sphere file that automates a task or provides a useful utility? You can now prepare it for the public SphereHub with our new command:


bash
sphere publish ./my-utility.sphere
This command doesn't directly upload (for security and moderation in this MVP stage). Instead, it:
Validates your .sphere file (ensuring it has an id).
Prompts you for metadata like author and description.
Calculates a SHA256 hash of your file's content.
Then, it gives you clear, step-by-step instructions on how to create a Pull Request to our central, GitHub-based registry: https://github.com/Nakadra/sphere-hub-registry.
Once your PR is merged, your Sphere is "live"!
2. Consuming Public Spheres (Effortless Dependencies!)
This is where the magic happens. Let's say someone published a Sphere with the ID com.community.super-formatter/v1.0.0. You can now use it in your own my-project.sphere like this:
# my-project.sphere
id = "com.me.my-project/v1"
entrypoint = "echo 'Formatting code...'; formatter my-code.txt; echo 'Done!'"

[dependencies]
formatter = "com.community.super-formatter/v1.0.0"
When you run sphere run my-project.sphere:
Sphere checks your local cache.
If com.community.super-formatter/v1.0.0 isn't there, it automatically fetches the master index from the SphereHub.
It downloads the super-formatter .sphere file.
Crucially, it verifies the downloaded file's SHA256 hash against the one listed in the Hub's index. This ensures you're running exactly what was published, with no tampering.
It caches the dependency locally and then runs your project!
Why This Matters
Simplicity: No complex package management configurations. Just list your dependency ID.
Security: Hash verification provides a strong guarantee of integrity.
Portability: Because every Sphere runs in its own sandbox, dependencies "just work."
Community: We're laying the groundwork for a rich ecosystem of reusable computational building blocks.
Try It Out!
Sphere v0.2.0 is available now on GitHub:
https://github.com/Nakadra/sphere-runtime/releases/tag/v0.2.0
The SphereHub registry is young and needs your contributions to grow:
https://github.com/Nakadra/sphere-hub-registry
We're still very early in this journey, and your feedback is more valuable than ever. What do you think of the SphereHub concept? What tools would you like to see published?
Join our Discord Server to chat with us![https://discord.gg/ZnUCaUGr]
Thanks for reading!
Clein, Kelly and Ronald

We Built a Docker Alternative in Rust on Our Phones in Kenya. Here's Why.

Nakadra — Tue, 17 Jun 2025 14:14:29 +0000

This post introduces Sphere, a new open-source computational runtime written in Rust. It's our answer to the complexity of modern software deployment.

GitHub Repository: https://github.com/Nakadra/sphere-runtime

Hi everyone, we're Clein, Kelly, and Ronald. For the past few months, we've been working obsessively on a problem that has bothered us for our entire careers: software is too complex, and environments are too fragile.
The endless cycle of "it works on my machine" but fails on the server, the dependency hell, the heavy machinery of tools like Docker just to run a simple script... it all felt like we were building skyscrapers with stone tools.
We dreamed of a simpler way. A way to define a piece of work and have it run identically everywhere—from a massive cloud server to the termux terminal on the Android phone where we wrote the first lines of code for this project.
Today, we're excited to share the first version of our solution: Sphere.
What is Sphere?
Sphere is a new kind of computational runtime. Instead of bundling your code with an entire operating system (like Docker), Sphere runs your code inside a fresh, pristine, minimal sandbox that is created and destroyed for every single run.
You define a process in a simple .sphere file.
my-script.sphere
Generated toml

A simple Sphere file

entrypoint = "echo 'Hello, from inside a perfectly isolated Sphere!'"
Use code with caution.
Toml
And run it with the sphere command:
Generated bash
sphere my-script.sphere
Use code with caution.
Bash
This seems simple, but the magic is what happens behind the scenes:
A Sandbox is Born: A new, empty temporary directory is created.
Execution is Contained: The entrypoint command is forced to run inside this empty directory.
The Universe is Erased: As soon as the command finishes, the sandbox and everything in it vanishes, leaving your system completely clean.
This guarantees perfect reproducibility and isolation.
The Real Power: Composable Dependencies
Where Sphere truly shines is in its ability to compose software. One Sphere can declare another as a dependency, and the runtime will automatically link them.
Imagine a main-app.sphere that needs a tool called greeter:
main-app.sphere
Generated toml
entrypoint = "echo 'Main app starting...'; greeter; echo 'Main app finished.'"

[dependencies]

greeter = "com.util.greeter/v1"

Use code with caution.

Toml

The sphere runtime will find the com.util.greeter/v1 Sphere in your local cache, make its entrypoint available as the greeter command, and inject it into the sandbox. The result is a system where you can build complex applications by snapping together small, simple, and verifiable tools.

A Live Experiment: See the Isolation for Yourself

Let's prove the core value proposition. Create a file called site-builder.sphere:

Generated toml

entrypoint = """

echo "

Welcome!

" > index.html

echo "Site created. Listing files in my directory:"

ls

"""

Use code with caution.

Toml

Now, run it:

Generated bash

sphere site-builder.sphere

Use code with caution.

Bash

The output will show the index.html file being created inside the sandbox:

Command STDOUT

Generated code

Site created. Listing files in my directory:

index.html

Use code with caution.

Inside its sandbox, it successfully created index.html. But now, check your own project directory. You will find that no index.html file was created there. The builder did its job and then vanished without a trace. This is the "leave no trace" principle that makes Sphere so clean and predictable.

This is Just the Beginning (The Roadmap)

Sphere v0.1 is an MVP; a working prototype of a big idea. Our roadmap is ambitious:

True Security Sandboxing: Using Linux namespaces and chroot to create a truly inescapable jail for processes.

The SphereHub: A public, global registry to make sharing and discovering Spheres as easy as cargo install.

The SphereGrid: A decentralized cloud to run Spheres as a next-generation serverless platform.

We Need Your Help

We believe this is a better way to build and run software, and we want to build it in the open. Sphere is open source (MIT licensed). We are at the very beginning of a long and exciting journey.

Please, check out the repository, try the tool, break it, and tell us what you think. Open an issue, suggest a feature, or just say hello. We would be honored to have you join us.

Thank you for your time.

Clein Pius, Kelly Gregory, & Ronald Oloo

Link to GitHub Repository Again: https://github.com/Nakadra/sphere-runtime

DEV Community: Nakadra

Sphere v0.2.0: Introducing a Public Hub for Shareable, Sandboxed Commands

What is the SphereHub?

How It Works:

We Built a Docker Alternative in Rust on Our Phones in Kenya. Here's Why.

A simple Sphere file

Welcome!