What Is a Build Server? The Brain Behind the Pipeline
A build server is the central system that schedules pipelines, assigns jobs to agents, stores results, and presents status to the team.
Behind every pipeline is a coordinator. The build server (sometimes called the CI server) is that brain. It watches for events, decides what pipelines to run, hands jobs out to agents, collects the results and logs, and shows everyone the status. The server does not usually run the job steps itself; that is the agent's role. The server orchestrates.
What the build server does
- Listens for events and triggers.
- Schedules pipeline runs and their jobs.
- Dispatches jobs to available agents.
- Stores logs, results, and artifacts.
- Serves the dashboard, badges, and notifications.
Server vs agent
The server coordinates; the agent executes. One server manages many agents. This split lets you scale execution (add agents) independently of coordination (the server), which is how large CI systems handle thousands of jobs.
A quick example
When you push code, the build server receives the event, creates a run, and assigns its jobs to idle agents. As agents stream back logs and results, the server updates the run status you see in the UI.
Self-hosted vs managed
You can run your own build server (Jenkins is the classic example) or use a managed one (GitHub Actions, GitLab CI). Self-hosting gives control and maintenance burden; managed offloads the upkeep to a provider.
Server, agents, and speed
The server schedules fast, but throughput depends on available agents. A capable server starved of agents still queues work. Managed runners (Latchkey) provide the agent capacity so the server's schedule turns into actual parallel execution rather than a queue.
Key takeaways
- A build server schedules pipelines and coordinates agents, but does not run steps.
- The server coordinates; agents execute. One server drives many agents.
- Throughput depends on agent capacity, not just the server's scheduling.