Roadmap
Last edited: 4 September 2026
The coordinated release of ngit v3, ngit-grasp v3, ngit-ci 0.1.0, and the next GitWorkshop version makes self-hosted private repository infrastructure and self-hosted CI practical parts of the same Nostr Git stack. Those are big steps forward, but they are only the start. Self-hosting proves that a team can control its repositories, compute, and trust policy. It should remain a first-class option, not become a requirement for using private development infrastructure.
Direction, not shipped behaviour
The coordinated launch ships the foundations described in the Today column below. The other ideas on this page are design direction, without a promised protocol, release, or delivery date.
The larger direction is to decompose what a forge once bundled into replaceable roles. A project should be able to keep its identity and policy while choosing repository storage, CI coordination, compute, and runner software independently. Each role could be self-hosted, provided as a service, or combined with others without becoming the authority over the project.
| Area | Today | Direction |
|---|---|---|
| Private repositories | Run a private ngit-grasp service | Choose a private GRASP provider, self-host, or combine both |
| Repository permissions | Enforce access in the repository service | Connect access to compatible Nostr group protocols |
| CI compute | One operator runs the coordinator and its attached compute | One coordinator routes different jobs to several machines and, later, independent providers |
| Workflow runners | GitHub Actions-compatible workflows run through act | Multiple runner styles, including a Nix-native option across supported platforms and architectures |
Private repositories without an infrastructure requirement
We want private GRASP service providers to offer repository hosting for people who do not want to operate a server. A repository's Nostr identity and signed state should not become the property of that provider. Teams should be able to choose a provider, move between providers, add redundancy, or continue to self-host according to their own requirements.
Access should also compose with existing Nostr group protocols. The goal is to avoid creating an isolated membership system for every private Git service, while still letting a provider enforce repository access without learning or controlling more than it needs to.
This requires careful work on private event delivery, Git authorization, membership changes, recovery, and metadata privacy. The current private GRASP profile is the operational starting point, not the final hosted-service model.
From one coordinator to a compute commons
Inside ngit-ci, the design already separates two responsibilities:
- the coordinator observes repository activity, applies policy, selects workflows, handles trust and secrets, and signs CI attestations; and
- the runner or sandbox supplies the environment in which a selected job executes.
Operationally, those parts are one self-hosted system today. Someone runs ngit-ci, points it at the repositories they want it to serve, and supplies its compute through embedded act or an attached adapter. Even when the coordinator and a microVM adapter are separate processes, they remain one operator's deployment.
Routing different jobs from one coordinator to several machines is a concrete next step, not a wholesale redesign. The runner boundary and capability model lay much of the foundation, but that routing has not been implemented. The first version could keep every machine within one operator's trust boundary.
Beyond that, a trusted coordinator could assign jobs to independent compute providers. Its choices could account for the provider's identity and history, the risk of the code being run, secret exposure, isolation, available platforms and architectures, capacity, and cost.
Nostr can make that a market instead of a fixed integration. Providers can advertise capabilities and availability; coordinators can select among them; and users can choose which coordinators and attestations they trust. Market participation alone would not make a result trustworthy. Signed provenance and each participant's explicit trust policy remain essential.
Two existing projects provide useful prior art:
- Loom explores a general Nostr compute market with worker discovery, job status, results, and payment; and
- Hive CI explores CI workflows executed through Loom workers.
ngit-ci already uses the shape of Loom's execution-adapter contract for its local sandbox boundary, and its event work has been informed by Hive. It does not yet implement a remote Loom marketplace or a stable, independent CI protocol. The CI interoperability page tracks that boundary.
More than one way to run a workflow
act is a practical bridge for projects that already know GitHub Actions-compatible workflows. It should not define what Nostr CI can become. The CI events, coordinator policy, and runner boundary are intended to support different workflow languages and execution software.
We are also working towards an efficient, Nix-native CI option. The aim is to use Nix's reproducible build model and caching directly, with execution across supported platforms and architectures, instead of translating every job through a GitHub-style act runner. It would be another runner choice, not a replacement imposed on every project.
Other implementations should be able to make different choices while participating in the same wider CI model. Runner diversity is part of the design, not a compatibility problem to hide.
Work still to do
Turning this direction into dependable infrastructure requires more than connecting a coordinator to remote machines. The open design work includes:
- a reviewed, implementation-independent CI protocol profile;
- private GRASP discovery and authorization that composes with Nostr groups;
- capability, availability, price, and payment discovery for compute;
- provider selection, reputation, and risk policy without a global trust authority;
- safe secret delivery and strong isolation for untrusted jobs;
- integrity and discovery for logs, artifacts, workflows, and results; and
- bounded retries, cancellation, accounting, and recovery across providers.
The principles are more settled than the mechanisms: users should be able to self-host or use a service; coordinators should make trust decisions explicit; policy and execution should remain separable; and no provider should own a project's identity.