Getting started — Rinko Hub

Seven pages, in order, take you from no account and no tooling to a repository published on Rinko Hub with its code live — and its private files protected before anything left your machine. Follow them in sequence: each one assumes the previous one is done.

What you will do

Create your account — sign up and choose your password, verify your email, and redeem your closed-beta invite code.
Install the Nexa CLI — download the nexa binary, verify it, and put it on your PATH.
Authorize your machine — run nexa login and approve this device on Rinko Hub, in a browser.
Set up a Development Root — declare the folder your projects live in.
Your first repository — create a project from the root, and stop before recording it.
Protect private files before hosting — review .nexapolicy, label files such as .env, validate, record the first version and confirm what it sealed.
Host it on Rinko Hub — publish the recorded version and verify the hosted result.

The whole path, once nexa is installed, is this — every command after nexa root runs from the root, naming the project with -p:

First publication

nexa login

cd ~/Development
nexa root

nexa init my-project

# Before the first record: review ~/Development/.nexapolicy and protect
# private files (see "Protect private files before hosting"), then
nexa my-project policy validate

nexa record -p my-project -m "Initial version"   # check its sealed: line
nexa publish -p my-project

Privacy comes before the first record, not after

A label protects a file from the version it is recorded in onwards. A version recorded before the label existed keeps that file readable, and publishing uploads every version recorded so far. Settle what is private first; a project with nothing private needs no label and loses nothing by checking.

When nexa publish prints Published to Rinko Hub., the repository exists on Rinko Hub and its code is live there. Nothing else has to run first. After that, every change is two commands:

Every change after the first

# edit files in ~/Development/my-project
nexa record -p my-project -m "Describe the change"
nexa sync -p my-project

By the end you will have used every command that makes up ordinary work with Nexa. There is nothing else to learn before you are productive. If you would rather cd into a project and run the commands there without -p, the way you would with Git, that works too — Working inside a project directory covers it.

Command	What it does	How often
`nexa login`	Authorizes this machine with Rinko Hub, in a browser.	Once per machine
`nexa root`	Makes this directory your Development Root.	Once per machine
`nexa init <project>`	Creates a project under the root to manage, by name.	Once per new project
`nexa <project> policy validate`	Checks the root's `.nexapolicy` for this project, and that every exact path it protects names a real file.	Before the first record, and after editing the policy
`nexa record -p <project> -m "…"`	Records the project's working tree as a version.	Every change
`nexa publish -p <project>`	Creates the Rinko Hub repository and publishes the recorded version.	Once per new project
`nexa sync -p <project>`	Synchronizes later recorded changes with Rinko Hub. No remote is ever named.	Every change
`nexa get owner/repo`	Brings a repository that already exists on Rinko Hub into the root.	Once per existing project

Before you start

You will need:

A supported machine. A Mac with Apple Silicon, or Linux on x86_64 or ARM64. The install page covers downloading and verifying the binary.
A Rinko Hub account with a redeemed invite code, to download the CLI during the closed beta and to publish repositories. Create your account explains every step, including where you choose your password.
A folder to keep your projects in. The examples call it ~/Development; any folder works, and existing work in it is fine.

Working without an account

Nexa is a complete version-control system on its own, and every local operation — creating repositories, recording versions, branching, merging — works offline with no account at all. If that is all you need, install the CLI, set up a Development Root, and skip nexa login and nexa publish entirely. You can publish later, or never. (During the closed beta the download itself still needs an admitted account.)

If you are coming from Git, the commands will look familiar and the model underneath them is not. Two differences matter from the first day: there is no staging area, and a branch holds a set of competing versions rather than a single pointer. Coming from Git covers both.