Project status

neosource is pre-launch. Rather than hedging on every page, this is the one page that tracks what is real — so the rest of the documentation can describe things plainly and you can check here when you want the caveats.

If a page describes a behaviour, it has been verified against the running code. Where something is designed but not built, it is called out where you would look for it, not omitted.

Works today

Git. Clone, fetch and push over HTTPS and SSH. Ordinary git, ordinary remotes. This is the most exercised surface in the product.

jj. Works against the same URLs via jj git clone / jj git push, because jj speaks Git. The protocol edge handles jj’s libgit2-driven negotiation explicitly.

The web app. Code browsing, commits, pull requests, issues, teams, an Actions view for CI, and an operation log view.

CI. Workflows in .neosource/workflows/ run on hosted runners, triggered by push, pull request, and cron. Jobs declare tools with packages:. Logs stream. See How CI works here.

Importing. From a public Git URL, or an authenticated GitHub import for private repositories, with optional issue/comment/label sync.

Auth. Accounts, SSH keys, and fine-grained expiring access tokens.

Sharp edges

Things that work but will surprise you:

• Workflows live in .neosource/workflows/. A .github/workflows/ directory is ignored with no warning at all — the most common cause of “why is nothing running”.
• Workflow parse diagnostics are not shown in the UI. They are recorded and returned by the API, but the Actions page does not render them, so warnings are effectively invisible.
• No concurrency: support. Two quick pushes produce two runs and neither cancels the other.
• Job-level if: does nothing. It parses but is never evaluated. Step-level if: works.
• tags: filters are ignored. A tags-only trigger fires on every push.
• Glob matching is strict. release/* does not match release/v1/rc1.

The full inventory is in Coming from GitHub Actions.

Not built yet

• The neo CLI is not distributed. No released binary, install script or package. Use the web UI and plain git.
• Self-hosted runners. The API exists; the agent you would run is not distributed.
• Local-first CI — running your own push’s CI on your own machine with real server-side run records. Implemented and reviewed, but not deployed.
• Manual workflow dispatch via on: workflow_dispatch. Declaring it has no effect; use the API to start a run by hand.
• on: change, the jj-native change trigger. Designed, not dispatched.
• Reusable workflows, permissions:, and deployment environment:.
• Windows and macOS CI runners. Linux only.
• A jj-native wire protocol. jj works because jj speaks Git; there is no second protocol on the wire.

What this means for you

Using neosource for real work is reasonable if your workflow is Git plus CI, and you can live with the CI gaps above. It is not yet a drop-in replacement for every GitHub surface, and the areas most likely to be missing something you rely on are CI ergonomics and anything requiring a command-line client.

Documentation breadth follows implementation, not ambition. If something is not documented here, assume it is not built rather than undocumented.