> For the complete documentation index, see [llms.txt](https://kerno.gitbook.io/docs/llms.txt). Markdown versions of documentation pages are available by appending `.md` to page URLs; this page is available as [Markdown](https://kerno.gitbook.io/docs/guides/start-the-environment.md).

# Start the environment

Kerno tests your application by calling it over HTTP. Before it can do that, you need to start your app and tell Kerno where it is.

### Prerequisites

Before you begin, make sure you have:

* Kerno installed and the agent running, with your coding agent connected over MCP. See the [Quickstart](/docs/getting-started/quickstart.md).
* Docker running on your machine.

### Step 1 — Start your application

Bring up your app however you normally do:

```bash
docker compose up
```

or

```bash
npm run dev
```

Confirm it responds before continuing, and note the URL it listens on.

### Step 2 — Tell Kerno where it is

Ask your agent:

> "Set up the Kerno environment. My app runs at <http://localhost:3000>."

Your agent saves the configuration, and Kerno probes the URL from inside its sandbox to confirm it is reachable. An unreachable address is caught here rather than surfacing later as a confusing test failure.

If your application runs somewhere other than your machine, such as a shared dev environment, say so and give the URL you use to reach it.

### Step 3 — Give Kerno datastore access (optional but recommended)

Without this, Kerno tests your app purely through its HTTP API. With it, Kerno can also set up and verify state directly in your database, which covers cases your API cannot express.

Ask your agent:

> "Also configure Postgres at postgresql://user:pass\@localhost:5432/mydb."

{% hint style="info" %}
Use a host address Kerno's sandbox can actually reach. When the sandbox and your database sit in different Docker networks, `host.docker.internal` is usually correct rather than `localhost`.
{% endhint %}

Kerno also needs to derive your database schema from your source code, which it does automatically for most projects. If it cannot, it will pause and ask you for a path to your schema rather than guessing. See [Environment Setup](/docs/core-concepts/environment-setup.md) for the formats it recognises.

### Step 4 — Wait for ready

Ask your agent to check the environment status. You are waiting for `ready_for_endpoint_test` to report true.

{% hint style="warning" %}
"My containers are running" and "Kerno is ready to test" are different things. Check the readiness signal rather than assuming.
{% endhint %}

### What gets written to your repository

Kerno writes a small amount of state under `.kerno/` at your repository root:

```
.kerno/
├── config.yaml              # your local settings, including credentials — gitignored
├── default.config.yaml      # shared defaults — safe to commit
├── .gitignore               # written by Kerno
├── hooks/                   # git hooks Kerno installs
├── mcp-jobs/                # per-job logs — gitignored
└── scenarios/               # generated tests, once you create some
```

`config.yaml` is gitignored because it holds credentials. `default.config.yaml` carries team-wide defaults and is meant to be committed, as is everything under `scenarios/` once you have generated tests.

In a monorepo, `scenarios/` lives under each app's own directory, while configuration and hooks stay at the workspace root.

### Updating the configuration

If your app moves to a different port, or your database credentials change, ask your agent to save the new details. There is nothing to rebuild.

### What's next

Continue to [Capture a baseline](/docs/guides/capture-a-baseline.md) to generate your first tests.