---
title: "Build & Deploy"
id: "344"
type: "page"
slug: "build-deploy"
published_at: "2026-05-19T11:30:45+00:00"
modified_at: "2026-09-21T01:36:28+00:00"
url: "https://xedant.com/agents/agent/docs/build-deploy"
markdown_url: "https://xedant.com/agents/agent/docs/build-deploy.md"
excerpt: "In Xedant Agent, a “build” is an automatic check that keeps the AI’s work under…"
---

# Build & Deploy

[https://xedant.com/agents/agent/docs/build-deploy.md](https://xedant.com/agents/agent/docs/build-deploy.md)

## What are builds?

In Xedant Agent, a “build” is an automatic check that keeps the AI’s work under control. Despite the name, a build does not need to “build” anything or produce finished files — it is enough to run a command and report errors and warnings in a form the [build parser](/agents/agent/docs/build-deploy#build-parser)
 can recognize.

Think of builds as quality checkpoints. Each one is a separate automatic check that runs when the files it watches change. A compiler finding syntax errors is a build. A linter flagging unused variables (a linter is a “code style checker”) is a build. Tests failing on an assertion are a build. A security scanner finding vulnerabilities is a build too. They all work the same way: a command that produces structured error output.

Builds are configured in the `.xedant/build.yml` file at the project root: for each one you define the command, which files to watch, and the parsing rules in `.xedant/build.parser`. When the agent changes the project, Xedant Agent notices the changes and starts the matching builds by itself — nothing to press.

The real power is [AutoFix](/agents/agent/docs/autofix)
. When it is enabled, build errors and warnings are automatically sent to the agent as chat messages. The model sees the exact output, understands what went wrong, and fixes it — the edits start the builds again, and that is how a feedback loop is born. The more builds you configure, the more automatic checks the model passes and the better the result.

## Build configuration

Builds are defined in the `.xedant/build.yml` file: each is a named task with a command, file patterns to watch, and additional settings. You don’t have to create the file by hand — use the **Fix with AI** button (in the project settings opened from the build panel header) and let the agent do the setup.

```
build:
  task-name:
    path: "src/"              # Working directory for the command
    command: "npm run check"  # Shell command to execute
    delay: 3                 # Seconds to wait before starting (default: 3)
    timeout: 60              # Max execution time in seconds (default: 60)
    watch: "*.ts *.js"      # File patterns or build names (space- or comma-separated), or `chat` to watch the current chat completion
    commandOutput: ""         # Path to an additional output file (optional)
    ignore: []                # Regex patterns to filter out of errors/warnings
    replacements:             # Find/replace in output paths
      - find: "/tmp/build"
        replace: "/project"
    stopStrings: []           # Strings that immediately abort the build
    startSound: ""            # Sound when the build starts (built-in or custom)
    endSound: ""              # Fallback sound when the build finishes (used when no result-specific sound is set)
    successSound: ""          # Sound on a successful build (overrides endSound)
    warningSound: ""          # Sound when the build finishes with warnings (overrides endSound)
    errorSound: ""            # Sound on a failed build (overrides endSound)
    soundVolume: 1.0          # Volume 0-1 for build sounds
```

What each setting means:

- **path** — the working folder where the command runs. Defaults to the project root
- **command** — the command to run; any command available in your environment works
- **delay** — the pause (in seconds) after a file changes before the run: when several files change at once, the build is not started repeatedly but waits for the changes to settle. Default is 3 seconds
- **timeout** — the maximum execution time in seconds; if the command does not fit, it is aborted. Default is 60 seconds
- **watch** — which files to watch: name patterns (for example, `*.ts *.js`) or names of other builds (for example, `server-build,client-copy`). When watching another build, this build starts only after that one completes successfully
- **commandOutput** — path to an additional output file to parse: some tools write their results to a file instead of the console (for example, JetBrains inspectcode produces XML) — point this at it and the parser will extract errors from there
- **ignore** — search patterns filtered out of errors and warnings: handy for silencing known false positives and noise from specific tools
- **replacements** — find/replace pairs for paths in the output: needed when the build runs in temporary folders (containers, isolated directories), so error locations point at your real files
- **stopStrings** — strings whose appearance immediately aborts the build (for example, `"The operation was canceled"`)
- **startSound** — sound when the build starts (a built-in name like `"complete"` or your own file from `.xedant/sounds/`)
- **endSound** — fallback sound when the build finishes, when no result-specific sounds are set
- **successSound** — sound on a successful build (takes precedence over `endSound`)
- **warningSound** — sound when the build finishes with warnings (takes precedence over `endSound`)
- **errorSound** — sound on a failed build (takes precedence over `endSound`)
- **soundVolume** — volume of build sounds (0-1, default 1.0)

Builds can be chained: instead of watching files, a build can wait for another build to finish:

```
build:
  compile:
    command: "dotnet build"
    watch: "*.cs"

  test:
    command: "dotnet test --no-build"
    watch: compile    # Runs only after a successful compile
```

The system watches the project’s files and starts builds by itself: a file matching a `watch` pattern changed — the `delay` countdown begins; if more files change during it, the timer resets. After the countdown, the command runs. If files change while the build itself is running, the running build is canceled and starts fresh with the changes included.

Build results are stored in `.xedant/build/` — three files per task: `{task-name}.output.txt` (the full command output), `{task-name}.errors.txt` (recognized errors), and `{task-name}.warnings.txt` (recognized warnings).

Editing `build.yml` by hand is not required. The `.xedant/README.md` file describes the full format — just ask the agent to add or change builds, and it will set everything up correctly.

## Parser files

Xedant Agent uses three parser files to pull errors and warnings out of text output. All three share the same format and describe themselves with built-in comments — you usually don’t need to edit them by hand. If you add your own check with an unfamiliar output format, or your app produces errors the parser does not recognize, ask the agent to update the parser.

The easiest way to fix patterns is straight from the output: select text in any build, deploy, or script output window — a floating **Fix parser** button appears. Press it, and the agent receives the selected text together with a ready prompt to update the right parser file — no typing needed.

### Parser format

Every parser file consists of `[ERROR]` and `[WARNING]` blocks. Inside a block are text-search patterns (regular expressions) that the parser tries to match against the command output in order:

- **Comment lines** starting with `#` are ignored — parser files use them to explain what is responsible for what
- **Single-line patterns** — an expression that must match one output line completely. The parser then tries the next pattern on the next line
- **Multi-line patterns** — wrapped in `{{...}}` and capture any number of consecutive lines: this is how context after an error header, stack traces, and other multi-line output is captured

Here is an example of patterns catching a TypeScript error together with its context:

```
# TypeScript errors
[ERROR]
.*\.ts.*              # Matches a line containing a .ts file path
Error.*               # Matches a line starting with "Error"
{{^\s+}}              # Matches zero or more lines starting with whitespace (context)
[/ERROR]
```

The parser walks the output lines and, at each position, tries the patterns of the `[ERROR]` blocks in order. When all patterns of a block have matched in sequence, those lines are extracted as one error and the parser moves on. `[WARNING]` blocks work exactly the same way. Patterns placed earlier in the file take priority: as soon as a match is found, the other blocks are not tried.

The parser automatically rereads its rules when the file changes — edits take effect immediately, without a restart.

### build.parser

The `.xedant/build.parser` file extracts errors and warnings from build command output. It already contains patterns for common tools — C# (MsBuild, CSC), TypeScript, Svelte, Vite, Python (ruff), and ReSharper — and you can add patterns for any tools your project uses.

```
# C# errors - MsBuild format with file path and (line,col)->(line,col) CSxxxx:
[ERROR]
\[MsBuild\].*\(\d+,\d+\)-\>\(\d+,\d+\)\s+CS\d+\:.*
[/ERROR]

# Python ruff errors (F/E codes) - with file location and context
[ERROR]
[A-Z]\d+\s+(\[\*\]\s+)?.*
\s*--\>.*
{{^\s+.*|\d+\s+\|.*}}
[/ERROR]

# C# warnings
[WARNING]
\(\d+,\d+\): warning
[/WARNING]
```

### deploy.parser

The `.xedant/deploy.parser` file extracts errors and warnings from your running application — what happens after the build, at the “live” stage. It recognizes common runtime errors: unhandled exceptions, stack traces, database connection failures, HTTP error codes, and application crashes across platforms:

```
# Unhandled exceptions (full stack trace)
[ERROR]
Unhandled exception\.
{{\S.*}}
[/ERROR]

# ASP.NET error log level (Serilog/ILogger)
[ERROR]
^err\:.*
{{^\s+\S.*}}
[/ERROR]

# HTTP 500 internal server errors
[ERROR]
.*status code 500
[/ERROR]

# Connection refused errors
[ERROR]
Connection refused
[/ERROR]

# SQL database exceptions
[ERROR]
SqlException\:.*
{{^\s+\S.*}}
[/ERROR]

# Warning log level
[WARNING]
^warn\:.*
{{^\s+\S.*}}
[/WARNING]
```

### output.parser

The `.xedant/output.parser` file is the general-purpose parser for plain script output: shell errors, Python tracebacks, Node.js exceptions, npm failures, and other frequent error formats. It is used when the output does not belong to builds or deploys:

```
# Shell command not found
[ERROR]
.*command not found
[/ERROR]

# Python tracebacks
[ERROR]
^Traceback \(most recent call last\)\:
{{.*}}
[/ERROR]

# npm ERR!
[ERROR]
^npm ERR\!.*
[/ERROR]

# Python warnings
[WARNING]
.*Warning\:.*
{{^\s+.*}}
[/WARNING]
```

## Configuration validation

Xedant Agent automatically validates all `.xedant/` configuration files when you save them. The validation runs as a build, and the results show on the build panel: errors in red, warnings in yellow.

Every save runs one check per configuration file:

- `build.yml` — YAML syntax, requires `command` or `prompt`, warns about unknown properties
- `deploy.yml` — YAML syntax, warns about unknown properties
- `project.yml` — YAML syntax, requires `name`, warns about unknown properties
- `hooks.yml` — YAML syntax, warns about unknown event types and properties
- `mcp.yml` — YAML syntax, warns about unknown top-level keys and server properties
- `skills.yml` — YAML syntax, warns about unknown properties and a missing `enabled`
- `models.yml` — YAML syntax, warns about unknown properties (expects `variables`)
- `providers.yml` — YAML syntax, warns about unknown provider and environment properties
- `*.parser` — block pairing (`[ERROR]`/`[/ERROR]`), regular expression validity, patterns outside blocks

Error and warning messages link to the right section of `.xedant/README.md`, so you can find the correct format:

```
Error: build.yml - 'lint': Missing required field 'command' or 'prompt' (see .xedant/README.md#buildyml)
Warning: deploy.yml - 'staging': Unknown property 'restart' (see .xedant/README.md#deployyml)
Warning: skills.yml - 'my-skill': Missing 'enabled' property (see .xedant/README.md#skillsyml)
```

Nothing to configure: edit the configuration files and the check runs itself on save. Fix the errors — and the next check comes back clean.

## Deploy configuration

Deployment is the launch of your application: on your own computer for testing, or on a remote server for real users. It is configured in the `.xedant/deploy.yml` file. Xedant Agent supports two methods: **debug** — for local development, and **docker** — for deploying to remote servers.

### Debug deploy (local)

The debug method runs the application right on your machine — the most common option during development:

```
deploy:
  my-app:
    method: "debug"            # Required: must be "debug"
    os: "linux"                # "linux" or "windows" (default: "linux")
    path: "./server"           # Path to the application files
    command: "dotnet run"      # Command to start the application
    delay: 3                   # Delay before starting (default: 3)
    timeout: 60                # Max execution time (default: 60)
    watch: "build-app"         # Build names (space- or comma-separated), or `chat`
    shallowCopy: true          # Copy only changed files (default: true)
    url: "https://app.example.com/"  # Optional URL for the link button
    startSound: ""            # Sound when the deploy starts (built-in or custom)
    endSound: ""              # Sound when the deploy finishes (built-in or custom)
    soundVolume: 1.0          # Volume 0-1 for deploy sounds
    environment:                # Environment variables for the process
      - APP_KEY=your-key
      - APP_DB=/path/to/database
```

Key settings:

- **watch** — a list of build names (space- or comma-separated), or `chat` to start after a chat completes. The deploy starts or restarts automatically when all the listed builds have finished successfully
- **shallowCopy** — when enabled, copies only the changed files on every restart: noticeably faster than a full copy
- **url** — the optional address of your application: a clickable button appears in the interface and opens the app in a new tab
- **environment** — environment variables passed to the started process
- **startSound** — sound when the deploy starts (a built-in name like `"complete"` or your own file from `.xedant/sounds/`)
- **endSound** — sound when the deploy finishes
- **soundVolume** — volume of deploy sounds (0-1, default 1.0)

### Docker deploy (remote)

The docker method ships your application to a remote server as a container. Suited for staging (pre-release testing) and production (the live version for users):

```
deploy:
  my-docker:
    method: "docker"             # Required: must be "docker"
    os: "linux"
    host: "server.com"          # Remote host
    username: "deploy"           # SSH username
    sshKeyPath: "~/.ssh/key"    # SSH key path
    sshPort: 22                  # SSH port (default: 22)
    imageName: "app:latest"      # Docker image name
    containerName: "myapp"       # Container name
    dockerfilePath: "./Dockerfile"
    buildContext: "."             # Build context (default: ".")
    buildArgs:                    # Docker build arguments
      - NODE_ENV=production
    environmentVariables:         # Container environment variables
      - PORT=3000
      - DATABASE_URL=postgresql://...
    portMappings:                 # Host:Container port mappings
      "8080": "3000"
    volumeMappings:               # Host:Container volume mappings
      "/var/log/app": "/app/logs"
    networks:                     # Docker networks
      - myapp-network
    pullLatestImage: true         # Pull the base image before building (default: true)
    removeExistingContainer: true # Remove the old container before deploying (default: true)
    healthCheckPath: "/"          # Health check endpoint (default: "/")
    healthCheckInterval: 30       # Health check interval in seconds (default: 30)
    healthCheckRetries: 3         # Health check retries (default: 3)
    localSourcePath: "."          # Local path to deploy from
    remoteWorkDir: "/tmp/deploy"  # Remote working directory
    excludePaths:                 # Paths to exclude from rsync
      - ".git"
      - "node_modules"
      - ".xedant"
```

Deploy output is saved in `.xedant/deploy/`: `{deploy-name}.log` — for the runtime output, plus client-side debug logs at `{domain}.log` (automatically truncated to 100 MB).

Creating and editing `deploy.yml` by hand is not required. The `.xedant/README.md` file fully describes both methods — just ask the agent to set up deployment, and it will sort out the details.

## Managing builds and deploys

The **status panel** at the bottom of the screen is responsible for live build and deploy control. It updates itself over live connections — no page reload needed.

### Managing builds

The **Builds** panel shows all configured builds as an accordion list: each with its name, a status icon, and the count of errors/warnings.

- **Rebuild** — hover over a finished build: a rebuild button appears for a manual run (disabled while it executes)
- **View output** — click the build’s name: the full output opens with three tabs — **Log** (the raw output, the last 2000 lines), **Errors** (recognized errors, red), **Warnings** (yellow)
- **Jump to errors** — click the error or warning counter, and the output dialog opens straight on the right tab
- **Copy** — copies the current tab’s content to the clipboard
- **Send** — sends the errors or warnings to the agent as a message in a `build.log` code block. For warnings, a request is added: “fix warnings, don’t ignore them”. The content is limited to the first 20 KB

The build panel header has a settings button that opens the project settings, where every configuration file has a **Fix with AI** button: it inserts a ready prompt into the chat input that asks the agent to configure automatic builds, using `.xedant/README.md` as the reference.

In build output dialogs and in the error/warning sections of the build panel, selecting text opens a floating **Fix parser** button: pressing it sends the selected text to the agent with a request to update `build.parser` — no need to type the prompt manually.

Builds that pass without problems collapse by themselves. Builds with errors or warnings stay expanded — so you notice them right away.

### Managing deploys

The **Deploys** panel shows every configured deploy with its name, state, and action buttons:

- **Start** — launches the application; the runtime output streams in real time
- **Stop** — gracefully stops the running application
- **Restart** — stops and immediately starts again (also fires automatically when the watched builds finish)
- **Open URL** — when the address is set in `deploy.yml`, the button opens your application in a new browser tab
- **View output** — a dialog with the Log, Errors, and Warnings tabs, same as for builds. Deploy output is parsed live by the `deploy.parser` parser: runtime errors — unhandled exceptions, database connection failures, HTTP 500 errors — are detected and highlighted. Selecting text opens the **Fix parser** button for updating `deploy.parser`

The status panel can be resized or fully collapsed to free up screen space. On mobile devices, the build and deploy panels stack vertically below the main content.

## Creative builds

“Build” is just a name. Any check that produces structured errors can hide behind it. Here are a few examples beyond traditional compilation:

### Linters and formatters

A linter is a standalone check of code style and typical mistakes (unused variables, formatting inconsistencies):

```
build:
  eslint:
    path: "client/"
    command: "npx eslint src/ --format stylish"
    watch: "*.ts *.svelte"

  ruff:
    path: "src/"
    command: "ruff check ."
    watch: "*.py"
```

### Type checking

Checks that data in the code is used correctly (no mixed-up types, everything consistent):

```
build:
  typecheck:
    path: "client/"
    command: "npx tsc --noEmit"
    watch: "*.ts"
```

### Running tests

Automatically runs your written tests and reports failures:

```
build:
  tests:
    path: "server/"
    command: "dotnet test --no-build"
    watch: compile
```

### Security scanners

Check the project’s dependencies for known vulnerabilities:

```
build:
  audit:
    path: "./"
    command: "npm audit"
    watch: "package.json"
```

### Custom project checks

You can write your own checking scripts for your project’s rules: naming conventions, required file structures, API contract compliance — any invariants the project must uphold. As long as the script prints errors in a format the parser understands, it works as a build. If the output format is not recognized, ask the agent to add the right patterns to `build.parser`.

Every build you add is one more automatic feedback channel for the agent through AutoFix. A project with compiler, linter, type-checking, and test builds gives the model four independent quality checks — each catches its own categories of problems the others might miss.

## Automatic rebuilds and AutoFix

When the agent changes project files, Xedant Agent notices and starts the matching builds by itself. No commands, no buttons — the whole verification cycle runs on its own.

The automatic workflow looks like this:

1. **The agent changes files** — the model edits the project’s code
2. **Builds start** — Xedant Agent notices the changes and runs the matching builds after the configured delay
3. **Output is parsed** — the build parser extracts errors and warnings from each build’s output
4. **AutoFix reviews the results** — when builds produced errors, AutoFix wraps them in a markdown code block and sends them to the agent as a chat message. For warnings, it adds “fix warnings, don’t ignore them”
5. **The agent fixes the problems** — the model sees the error output, understands what happened, and makes corrections
6. **Builds restart** — the fixes change the files again, and the cycle starts over
7. **Success** — when all builds pass without errors, the cycle ends and the application is redeployed

This cycle runs entirely without you. AutoFix turns on only when there is no active agent session, checks for repeated errors in the last 10 messages (to avoid looping), and respects the concurrency limit. You can watch the process on the build panel and in the chat history — or simply come back later and see the result.

[Learn more about AutoFix configuration and limits](/agents/agent/docs/autofix)

**[← Files](/agents/agent/docs/files)**

**[Git →](/agents/agent/docs/git)**