Host it on Rinko Hub

Your project has a recorded version and its private files were protected before it was recorded. This page puts it on Rinko Hub and checks the result. Every command still runs from ~/Development, naming the project.

Before you publish

• nexa my-project policy validate succeeds — see Protect private files before hosting.
• The first record's sealed: count matched the files you meant to protect, or the project has nothing private and you have confirmed that.
• You are signed in: nexa login.

Publish it

$ nexa publish -p my-project

Privacy before hosting my-project:
  policy:  4 rule(s) over 1 label(s)
  sealed:  3 file(s) in the version being published

Published to Rinko Hub.

nexa publish does the whole job of first publication. It creates the repository on Rinko Hub — named after the project unless you pass a name, as in nexa publish -p my-project other-name — waits for Rinko Hub to prepare it, which can take up to about two minutes, and then performs the initial synchronization of your recorded versions. When it prints Published to Rinko Hub., the repository and its code are live. You do not need to run nexa sync first.

What it publishes is the recorded state. Edits made since the last nexa record are not recorded on your behalf; if there are any, the command still succeeds and prints Warning: unrecorded working-tree changes were not included. Record them and run nexa sync -p my-project to send them. If nothing is recorded at all, it refuses rather than publishing an empty repository.

New repositories are private unless you pass --public, and --org <ORG> creates the repository under an organization rather than your personal account. Visibility decides who can open the repository; it does not change what is sealed — a sealed file stays unreadable to anyone without its key, in a public repository too.

The privacy summary

Before it creates anything, a first publication states what it is about to upload, from your real local state: the rules in force for this project, and how many files are sealed in the version being published. It is a report, not a gate — a project with no secrets is published without ceremony:

Privacy before hosting docs-site:
  policy:  no label rules for this project -- every file is published
           readable by whoever can read the repository. If nothing here
           is secret, that is fine.
  sealed:  0 file(s) in the version being published

It warns about two things that mean the protection is not what you think:

• An exact path in the policy that matches no file — it protects nothing, usually because of a typo.
• A protected file that an earlier version, recorded before its rule, holds readable:

Privacy before hosting my-project:
  policy:  1 rule(s) over 1 label(s)
  sealed:  1 file(s) in the version being published
  warning: `.env` (secrets) is readable in 1 version(s) being published, recorded
           before the rule. Labels are not retroactive: treat what it held as
           exposed, and rotate any credential in it.

A second nexa publish -p my-project never creates a second repository: it recognises the one that exists and synchronizes it, so an interrupted run is safe to repeat. The summary is printed once, by the publication that creates the repository.

Verify the hosted result

Open Rinko Hub in a browser. The repository is listed under your account, and browsing it shows the files you recorded. Check the protected ones in particular:

• Signed in as yourself, a protected file is marked with a lock. The lock is how you see that a rule took effect; a file you meant to protect that shows no lock was recorded readable.
• Anyone who does not hold the label — a visitor to a public repository, or a collaborator who was never granted it — is not given the file's name or content. If you can, check from such an account or a private window.
• The repository's Labels page lists secrets; it is the label from this project's repository.

If a file you meant to protect is readable to someone without the key, it was recorded before its rule: rotate what it held, fix the rule, and record again.

Later changes

Everything after first publication is a two-command loop, still run from the root:

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

$ nexa sync -p my-project

Synchronized with Rinko Hub.

nexa sync exchanges work with Rinko Hub in both directions: it sends what Rinko Hub lacks, receives what you lack, and reconciles the branch. No remote, no URL, no branch name — the project already knows which repository it is and where it is hosted. Every record still applies the policy, so a new private file is protected as soon as a rule names it — add the rule before the record that first includes the file.

Rinko Hub keeps more than one copy of your repository, and nexa sync synchronizes with all of them. If one copy is temporarily unavailable, the command still succeeds and adds a line on standard error — Repository redundancy is temporarily degraded; Rinko Hub will retry. — which is information, not an instruction.

What you have now

• nexa login — authorized this machine, once.
• nexa root — made a folder your Development Root, once.
• nexa init my-project — created a project to manage, once per project.
• nexa my-project label create secrets, a project block in .nexapolicy, and nexa my-project policy validate — protected its private files, once per project and whenever a new kind of private file appears.
• nexa record -p my-project -m "…" — records the project as a version.
• nexa publish -p my-project — created the hosted repository and published it, once per project.
• nexa sync -p my-project — synchronizes every later recorded change.

Next step

Core concepts explains the model underneath these commands — why a branch holds competing candidates rather than a single pointer, and what that makes possible.