> For the complete documentation index, see [llms.txt](https://protocol-labs.gitbook.io/testground/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://protocol-labs.gitbook.io/testground/table-of-contents/concepts-and-architecture/daemon-and-client.md).

# Daemon and client

The Testground runtime revolves around a traditional daemon/client architecture, communicating over HTTP.

This architecture is flexible enough to run the daemon within a shared cluster, with many users, developers, and integrations (e.g. GitHub Actions) hitting the same daemon to schedule build and run jobs.

> At the moment, we do not run Testground in shared-cluster deployments; most developers spin up personal Kubernetes clusters, and run both the daemon and the client on their own development machines, pointing the local daemon to the remote k8s API.
>
> However, as of Testground v0.5, **we do support running the daemon within a Kubernetes cluster as a pod.** This capability is vital to pave the way for shared-cluster deployments, which will enable much more efficient resource utilization and CI workflows.

## Testground Daemon

The Testground daemon is responsible for:

1. Scheduling and executing tasks (plan builds and test runs).
2. Collecting the outputs from test runs into an archive.
3. Performing builder and runner healthchecks.
4. Setting up the dependencies for builders and runners to operate.

You start the Testground daemon by running:

```
$ testground daemon
```

Exit with `Control-C`.

## Testground Client

The Testground client offers a CLI-based user experience, allowing you to:

1. Manage and describe the test plan and SDK sources the client knows about.
2. Interact with the daemon by executing builds and runs, collecting outputs, requesting runner termination, and triggering healthchecks.

```
$ testground help
```

## Asynchronous Tasks

The Testground daemon executes tasks, i.e., plan builds and test runs, asynchronously. By default, when you execute a build or run command, you'll be returned a task ID. This ID can be used to check the status of the task:

```
$ testground status -t <id>
```

Or see the task logs - you can use `-f` to follow the logs live:

```
$ testground logs -t <id> [-f]
```

To visualize all the running tasks:

```
$ testground tasks
```


---

# Agent Instructions
This documentation is published with GitBook. GitBook is the documentation platform designed so that both humans and AI agents can read, navigate, and reason over technical content effectively. Learn more at gitbook.com.

## Querying This Documentation
If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter, and the optional `goal` query parameter:

```
GET https://protocol-labs.gitbook.io/testground/table-of-contents/concepts-and-architecture/daemon-and-client.md?ask=<question>&goal=<endgoal>
```

`ask` is the immediate question: it should be specific, self-contained, and written in natural language.
`goal` is optional and describes the broader end goal you are ultimately trying to accomplish on behalf of the user. GitBook uses it to tailor the answer towards what is most useful for that goal.

The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.