> ## Documentation Index
> Fetch the complete documentation index at: https://docs.fau.fpt.icu/llms.txt
> Use this file to discover all available pages before exploring further.

# Core Commands

> Check for available updates and install them.

## validate

```bash theme={null}
fp-appimage-updater validate [app-name]
```

Parses all recipe files (or a single named one) and reports which files are valid and which contain errors. Run this after editing a recipe to catch YAML mistakes before they affect `check` or `update`.

```bash theme={null}
# Validate all recipes
fp-appimage-updater validate

# Validate a single recipe
fp-appimage-updater validate whatpulse
```

## check

```bash theme={null}
fp-appimage-updater check [app-name]
```

Contacts each app's configured update source and compares it to the locally recorded version. No files are downloaded or changed.

Output includes:

* Whether a new version is available
* The version, ETag, or Last-Modified metadata used for comparison
* Support hints such as HTTP range support for segmented downloads

### Examples

<CodeGroup>
  ```bash All apps theme={null}
  # Check all configured apps
  fp-appimage-updater check
  ```

  ```bash Single app theme={null}
  # Check a single app
  fp-appimage-updater check whatpulse
  ```

  ```bash JSON output theme={null}
  # Check all apps and format output with jq
  fp-appimage-updater --json check | jq
  ```
</CodeGroup>

## update

```bash theme={null}
fp-appimage-updater update [app-name]
```

Downloads and installs updates for all configured apps, or for a single named app. By default, the output only lists apps that were actually updated, rate-limited, or failed. Pass `--show-all` or set `show_all: true` in `config.yml` to restore the older verbose listing that includes already up-to-date apps. Each successful update reports the elapsed time so you can see how long each app took.

If a rate-limit was hit on a previous run, the affected app is skipped until its retry window expires — unless `respect_rate_limits` is disabled globally or for that app.

### Examples

<CodeGroup>
  ```bash All apps theme={null}
  # Update all apps
  fp-appimage-updater update
  ```

  ```bash Single app theme={null}
  # Update a single app
  fp-appimage-updater update hydra-launcher
  ```

  ```bash With self-update theme={null}
  # Update all apps and then update the updater itself
  fp-appimage-updater update --self-update
  ```

  ```bash JSON and jq theme={null}
  # Update an app and check if it was actually updated
  fp-appimage-updater --json update whatpulse | jq '.[0].is_updated'
  ```
</CodeGroup>

### Flags

<ParamField query="--self-update" type="boolean">
  Also update the `fp-appimage-updater` binary itself after finishing the app
  updates.
</ParamField>

<ParamField query="--debug-download-url <URL>" type="string">
  **Debug only**: Force a specific download URL for the update, bypassing the resolver. Requires `app-name`.
</ParamField>

<ParamField query="--debug-version <VER>" type="string">
  **Debug only**: Force a specific version string for the update, bypassing the resolver. Requires `app-name`.
</ParamField>

<ParamField query="--show-all" type="boolean">
  Show every app in the update results, including apps that were already up to date.
</ParamField>

<Note>
  Both `check` and `update` run multiple apps concurrently. A provider-aware
  cap limits how many requests go to the same host at once, so a large batch
  stays fast without overloading any single server.
</Note>

## doctor

```bash theme={null}
fp-appimage-updater doctor
```

Runs a local health check without contacting any remote servers. It verifies:

* The config directory exists and is readable
* The apps directory is present
* The global `config.yml` can be parsed
* The state directory is accessible
* The process lock is missing, active, or stale
* Recipe files can be parsed successfully
* Whether local update prerequisites look sane

Use `doctor` when `check` or `update` behaves unexpectedly to rule out local configuration problems.