What a runner is, and why you have to provide one

Nightshift is two halves, and only one of them is ours. The part you log into holds the board, the ruleset and the decisions: what should be worked on, how much autonomy a change may have, and whether something may merge. It never has your code.

The other half is the runner. It is a process on a machine you control. It leases a card, clones the repository, runs the coding agent, pushes a branch and opens a pull request. Your source, your model key and the agent’s output are all on that machine.

That split is the product, not an implementation detail. It is what lets a team say yes to autonomous work on a private codebase: the thing holding the code is infrastructure they already trust, and the thing deciding what is allowed is a service with no copy of it.

You need two runners, not one. A coding runner writes the change and a review runner reads it adversarially. A night will not start without both, because a change nothing reviewed is not something this product will merge. The role is fixed when a runner enrols, so one machine enrolled twice is the usual arrangement rather than two machines.

What the machine needs. Nothing unusual, and nothing large.

• Outbound network access. Runners lease work by asking; nothing connects inward to them.
• A way to reach your Git host, and a model API key.
• Disk for a checkout of each repository it works on.
• To stay awake. A laptop that sleeps is a runner that is offline.

Nightshift does not host runners for you. This is the sentence worth reading twice, because it is the one people go looking for a button to avoid. Hosted runners are on the roadmap and are not something you can turn on. If you are comparing us against a product where the vendor runs everything, this is a real difference and not a temporary gap in the interface.

How you actually get one going today. Talk to us. Enrolment, the container and the variables it needs are settled and working, and the self-serve install is not published yet, so we set the first one up with you rather than pointing you at a page. Write to [email protected] and say where you want it to run. This page gains the how-to the day that command is public.

Where it can run, in rough order of effort.

A platform like Railway

One always-on container beside your other services. The least thinking about a machine, and the usual answer. Check your compute limit before adding it: a platform that stops services when a project goes over its ceiling can stop the ones you care about.

Your own hardware

A container, or a service under its own user account, on a box you already have. The right answer when the code may not leave your infrastructure.

Hosted by Nightshift

Not built. On the roadmap, and not a thing you can switch on today.

A runner that looks fine to you can read as offline to us. It reports in about once a minute, and one that has not reported for ninety seconds is counted as offline whether or not its process is alive. A sleeping laptop, a dropped network or a machine nobody restarted after a deploy all look identical from the board, and the night run will quietly dispatch nothing.