Why neosource

There are a lot of places to host code. This page is about the handful of things neosource does differently, and where each of them stops.

For what is actually built versus designed, see Project status — this page describes intent and architecture, that one describes reality.

Planning and code are one product

Most forges treat project management as an afterthought: issues with labels, and a board bolted on. Teams that want real planning end up running a second tool alongside, and then spend their time keeping the two in sync — the issue tracker knows about the work, the forge knows about the code, and neither knows about the other.

neosource treats planning as a first-class surface with the same weight as the repository. Teams, cycles, triage, and projects are built in, and planning runs on two tracks: a ticket is a team’s own work, numbered ENG-7 and owned by no repository — because real work frequently spans several or none — while an issue is intake against one repository, numbered api#42. A ticket can track the issues it subsumes.

The payoff is that the link between a change and the work it belongs to is a fact the system knows, not a convention you maintain by pasting URLs between two products.

Planning covers the model in detail.

Where it stops: this is planning for engineering teams. It is not a general-purpose work tracker, and it is not trying to be a replacement for company-wide project management.

Your infrastructure is in the EU, and stays there

neosource runs on European bare metal. Not a European region of an American cloud — European hardware, operated by us.

Concretely, as of today:

• Compute and storage run on Hetzner, in Germany. The object store, the databases, and the message bus are all software we operate ourselves on that hardware.
• One subprocessor: Scaleway (French, region fr-par) sends transactional email — password resets, notifications, verification.
• No US subprocessors.
• No analytics, no tracking, no CDN, and no third-party fonts. The web app loads nothing from a third party. You do not have to take that on trust — open the page source, or your browser’s network tab, and check.

When you connect a GitHub account or import a repository, that talks to GitHub by definition. That is you exercising data portability, on your instruction, and it happens only when you ask for it.

Where it stops: we are a hosted platform. Self-hosting is not a supported configuration — see Self-hosting for the reasoning. “Your data is in the EU” is a promise about where we run, not a promise that you can run it yourself.

CI that already speaks GitHub Actions

Workflow YAML is deliberately close to GitHub Actions: the same triggers, the same job graph, needs:, matrix builds, artifacts, and the expression syntax you already know. Bringing a pipeline over is mostly a copy.

The one significant divergence is the job environment. Instead of picking a container image per job, a job declares the tools it needs:

jobs:
  test:
    packages: [go, postgresql]
    steps:
      - run: go test ./...

Tools come from a package overlay rather than a base image, so a job gets a sharp, cached environment without anyone maintaining a Dockerfile whose only purpose is “Go plus one database client”. Dependencies are content-addressed, so the same declaration resolves to the same thing on every run and across unrelated repositories.

This is compatibility and an efficiency change, which is deliberate — pipelines are the single most expensive thing to migrate between forges, and the common alternative is to invent a new pipeline language and make you rewrite everything.

See Coming from GitHub Actions for exactly what works, what works with caveats, and what does not.

Features are not held back to sell a tier

Our pricing principle: if it does not cost us at runtime, it does not cost you.

Single sign-on, SAML, fine-grained permissions, protected branches, required reviews, audit visibility — these are configuration flags. Serving them costs us essentially nothing per customer, so gating them behind an enterprise contract is a pricing decision rather than an engineering one. We do not make that decision.

What we do meter is what genuinely consumes resources: storage, CI compute, and bandwidth. Those have a real per-unit cost, they scale with use, and pretending otherwise would just mean charging everyone for the heaviest user.

The line is drawn on cost, not on company size. A two-person team gets the same security controls as a two-thousand-person one.

An engine built for concurrent writers

Git’s model assumes one machine holds a lock while it updates a ref. Every hosted forge has to work around this, and it is why scaling a forge has historically meant building a large distributed system to paper over a single-node assumption.

neosource is built on a novel distributed engine of our own: immutable content-addressed objects, an append-only operation log, and operation heads advanced by compare-and-swap. Multiple servers can accept writes to the same repository concurrently, and convergence is a property of the design rather than of a lock.

Several consequences fall out of that rather than being features bolted on: changes keep a stable identity across rebases, so review comments follow the change instead of being orphaned by a force-push; stacked pull requests are ordinary rather than a workaround; and the operation log means the repository’s history of operations is inspectable, not just its history of commits.

This also matters more than it used to. When several agents are writing to a repository at once, the write path stops being a background detail.

The storage engine covers how this works, and Code review covers what it buys you day to day.

What we are not claiming

Being straight about the boundaries, since every other section is an argument for something:

• We are not the fastest forge, because we have not measured that against anyone else. The web app is a single-page application built to stay responsive, and we care about it a great deal — but “faster than X” is a claim that requires numbers we have not published.
• We are not decentralised or federated. We are a platform, operated by us, in one jurisdiction. That is a deliberate trade: it is what makes the operating and privacy commitments on this page possible to actually make.
• We are not finished. See Project status.