Skip to content
Open
Show file tree
Hide file tree
Changes from all commits
Commits
File filter

Filter by extension

Filter by extension

Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
Original file line number Diff line number Diff line change
Expand Up @@ -54,7 +54,7 @@ On Windows, TypeScript/JavaScript AppHosts started with `tsx` or `npm` run in an

## Configuring the startup timeout

`aspire run` waits for the AppHost to reach a stable running state before it considers startup complete. If the AppHost build or startup takes longer than the default 120-second window—for example on a slow machine or in a CI environment—set the `ASPIRE_CLI_START_TIMEOUT` environment variable to a higher number of seconds:
`aspire run` waits for the AppHost to reach a stable running state before it considers startup complete. If the AppHost startup takes longer than the default 120-second window—for example on a slow machine or in a CI environment—set the `ASPIRE_CLI_START_TIMEOUT` environment variable to a higher number of seconds:

```bash title="Aspire CLI"
export ASPIRE_CLI_START_TIMEOUT=300
Expand All @@ -63,6 +63,8 @@ aspire run

If `ASPIRE_CLI_START_TIMEOUT` is set to a value that isn't a positive whole number of seconds, `aspire run` displays an error and exits without starting the AppHost. This behavior also applies to `aspire run --detach` and to `aspire start`.

`ASPIRE_CLI_START_TIMEOUT` only bounds the time the AppHost takes to reach a stable running state after it starts executing. Restoring and building the AppHost project—including a required safety build performed for an explicit `--no-build`—doesn't count against this budget, so a long restore or build on a cold or large solution won't cause a misleading startup timeout. Once the build completes, the AppHost receives the full configured startup budget.

`ASPIRE_CLI_START_TIMEOUT` controls how long `aspire run` and `aspire start` wait for the AppHost to start. It's separate from `aspire wait --timeout`, which controls how long `aspire wait` waits for an individual *resource* inside an already-running AppHost to reach a target status.

## Hot Reload and watch behavior
Expand Down
Original file line number Diff line number Diff line change
Expand Up @@ -62,15 +62,17 @@ Pressing <Kbd windows="Ctrl+C" mac="⌃+C" linux="Ctrl+C" /> while `aspire start

### Configuring the startup timeout

`aspire start` waits up to 120 seconds by default for the AppHost to reach a stable running state. If the AppHost build or startup takes longer than that—for example on a slow machine or in a CI environment—set the `ASPIRE_CLI_START_TIMEOUT` environment variable to a higher number of seconds:
`aspire start` waits up to 120 seconds by default for the AppHost to reach a stable running state. If the AppHost startup takes longer than that—for example on a slow machine or in a CI environment—set the `ASPIRE_CLI_START_TIMEOUT` environment variable to a higher number of seconds:

```bash title="Aspire CLI"
export ASPIRE_CLI_START_TIMEOUT=300
aspire start
```powershell title="Aspire CLI"
$env:ASPIRE_CLI_START_TIMEOUT = "15"
aspire start --no-build
```

If `ASPIRE_CLI_START_TIMEOUT` is set to a value that isn't a positive whole number of seconds, `aspire start` displays an error and exits without starting the AppHost. This behavior also applies to `aspire run`, including `aspire run --detach`.

`ASPIRE_CLI_START_TIMEOUT` only bounds the time the AppHost takes to reach a stable running state after it starts executing. The detached launcher doesn't consume this budget while its child process restores and builds, and a required safety build performed for an explicit `--no-build` runs before the budget begins. A required safety build can take longer than the configured timeout; once it completes, the AppHost receives the full startup budget.

## Hot Reload and watch behavior

By default, `aspire start` starts the AppHost as a detached background process. It doesn't watch the AppHost or resource source files. After you change AppHost code, restart the detached AppHost by running `aspire start` again. For individual resource changes, keep the AppHost running and restart or rebuild the resource from the Aspire CLI or dashboard when needed.
Expand Down
Loading