I’ve been building something for the CKB ecosystem that I think is worth putting in front of the community.
Orbital is a developer environment for building and deploying CKB applications without having the development process feel like a collection of disconnected steps.
Live: Live Web App
Doc: Documentation
Orbkit: Npm Package
Source: GitHub — Orbital
The problem
Getting an idea onto a blockchain should be exciting.
But the development experience can easily become the opposite.
You start with a contract.
Then you have to think about the development environment.
Then the network.
Then funding.
Then deployment.
Then transactions.
Then figuring out what actually happened.
Then repeating all of it when you make a change.
None of these things are necessarily difficult individually.
The problem is that they don’t feel like one development experience.
That’s what I’m trying to change with Orbital.
One place for the entire development loop
The idea behind Orbital is simple:
Build → test → fund → deploy → see what happened → change → repeat.
Instead of treating these as separate tools, Orbital brings them together into one workflow.
You work on your project locally, while the Orbital interface gives you a visual representation of what’s happening around it.
The local environment and the web interface work together rather than forcing the developer to constantly move between different tools.
That means you can go from creating a project to actually interacting with it on CKB without constantly stopping to manage infrastructure.
Orbkit
A major part of this is Orbkit.
Orbkit is the local component of Orbital.
It’s what allows Orbital to remain connected to the developer’s actual workspace rather than turning everything into a remote cloud development environment.
This distinction matters to me.
I don’t want Orbital to be another platform where developers have to upload their entire development environment just to use it.
The idea is:
your project stays yours.
Orbital simply gives you a better way to interact with the development process surrounding it.
The experience I’m aiming for
Imagine someone discovering CKB for the first time.
They have an idea for a smart contract.
Instead of giving them a pile of instructions and telling them to figure out how everything connects, they should be able to enter an environment that helps them get from:
“I want to build this.”
to:
“It’s running.”
That is the experience I’m trying to create.
And this isn’t only about beginners.
For experienced developers, the value is different.
It’s about removing the repetitive parts of development that don’t actually make your contract better.
If you’ve deployed contracts repeatedly, funded development accounts repeatedly, restarted development environments repeatedly, or spent time figuring out why a deployment is still doing something, you know exactly the kind of friction I’m talking about.
Orbital is meant to make that entire loop feel much more coherent.
Development should be observable
One of the things I particularly wanted to solve was the feeling of not knowing what’s happening.
A development process shouldn’t feel like:
“I ran something. Now I’m waiting. Did it work?”
Orbital is designed around showing the state of the development process as it happens.
Builds, funding, deployment and other operations can feed back into the interface so the developer has an actual picture of what’s happening.
The goal isn’t to throw more information at developers.
It’s to give them confidence that the environment is doing what they expect.
Security shouldn’t be an afterthought
There is also a fundamental principle behind the project:
convenience shouldn’t require surrendering control.
Orbital is designed so that the developer’s local environment remains the important boundary.
The project isn’t intended to become a giant remote environment that owns your code, your workspace and your keys.
Even when the web interface is involved in deployment, the design keeps the sensitive parts of that process separated.
That makes Orbital feel less like “put your CKB project in the cloud” and more like:
“bring your CKB development environment into a better workflow.”
Why CKB?
I think CKB has an interesting opportunity here.
A blockchain ecosystem isn’t only defined by its consensus, virtual machine, or programming model.
It’s also defined by how easy it is for someone to build their first thing.
The easier it is to go from an idea to a working application, the more people can actually explore what the ecosystem is capable of.
That’s why I’m interested in developer tooling around CKB.
Not because CKB needs another abstraction for the sake of abstraction.
But because I think there is room to make the experience of building on CKB significantly better.
Where Orbital could go
I’m still developing Orbital, and I don’t think the current version is the end goal.
I’d like to eventually see it become a broader environment around CKB development.
Something where developers can:
-
Start a project quickly
-
Develop locally
-
Work with different CKB networks
-
Test without fighting their environment
-
Fund development accounts easily
-
Deploy with confidence
-
See what their applications are doing
-
Iterate quickly
-
Bring other developers into the workflow
And potentially much more.
The larger vision is not simply:
“a better deployment tool.”
It’s:
A development environment that makes CKB feel easier to build on.
I’d love feedback from the CKB community
Orbital is currently available here:
Live: Live Web App
Doc: Documentation
Orbkit: Npm Package
Source: GitHub — Orbital
I’d particularly like to hear from CKB developers:
What part of your current development workflow feels unnecessarily painful?
Because those are exactly the problems I’d like Orbital to solve next.
CKB already gives developers a lot to work with.
I’m interested in building the environment that makes it easier to actually use it.