# Six pages, in the order the onboarding wizard uses them.

> The same text your own agent reads on day one, inside the product, as the hive-docs knowledge collection. Written to be checked against the product rather than trusted — every claim names a call, a file or a status code.

Source: https://hiveci.io/docs
Language: en

The docs are published in English only.
1. [What Hive is](https://hiveci.io/docs/what-hive-is): Hive runs jobs — CI/CD pipelines, test suites, builds, ad-hoc work — as Kubernetes Jobs across a fleet of clusters. A **run** is a DAG of **tasks**; each task executes in a container on whichever runner the scheduler picks.
2. [Onboarding checklist](https://hiveci.io/docs/onboarding-checklist): The order below is the order the wizard uses, and it is not arbitrary: each step makes the next one possible.
3. [The GitHub App, then the project](https://hiveci.io/docs/github-app-and-projects): Hive talks to GitHub through a GitHub App installation — that is how it reads your code, posts commit statuses, and receives the webhooks that start runs. The App is public: you install it on your own account or organisation, and it issues a per-installation token scoped to the repositories you selected.
4. [Your first pipeline](https://hiveci.io/docs/first-pipeline): A pipeline lives at `.hive/main.star` in your repository. Starlark, not YAML.
5. [Credentials](https://hiveci.io/docs/credentials): Three separate things, needed at different times.
6. [Security and isolation](https://hiveci.io/docs/security-and-isolation): What the tenant boundary actually gives you, stated so you can check it rather than trust it.