diff --git a/src/frontend/src/content/docs/reference/cli/commands/aspire-run.mdx b/src/frontend/src/content/docs/reference/cli/commands/aspire-run.mdx index e2f6bd455..e58d9a048 100644 --- a/src/frontend/src/content/docs/reference/cli/commands/aspire-run.mdx +++ b/src/frontend/src/content/docs/reference/cli/commands/aspire-run.mdx @@ -52,6 +52,19 @@ If graceful shutdown is taking too long and you need to exit immediately, press On Windows, TypeScript/JavaScript AppHosts started with `tsx` or `npm` run in an isolated console session so that the Ctrl+C signal is delivered correctly to the Node.js process rather than to an unrelated foreground window. ::: +## 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: + +```bash title="Aspire CLI" +export ASPIRE_CLI_START_TIMEOUT=300 +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` 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 By default, `aspire run` starts the distributed application once. It doesn't watch the AppHost or resource source files. After you change AppHost code, stop the running AppHost with , and then run `aspire run` again. For individual resource changes, keep the AppHost running and restart or rebuild the resource from the Aspire CLI or dashboard when needed. diff --git a/src/frontend/src/content/docs/reference/cli/commands/aspire-start.mdx b/src/frontend/src/content/docs/reference/cli/commands/aspire-start.mdx index 1693f1127..cebe7a17d 100644 --- a/src/frontend/src/content/docs/reference/cli/commands/aspire-start.mdx +++ b/src/frontend/src/content/docs/reference/cli/commands/aspire-start.mdx @@ -60,6 +60,17 @@ The parent log also captures the replayed child output under `DetachedAppHost/.. Pressing while `aspire start` is waiting for the AppHost to start will terminate the startup process. +### 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: + +```bash title="Aspire CLI" +export ASPIRE_CLI_START_TIMEOUT=300 +aspire start +``` + +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`. + ## 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. diff --git a/src/frontend/src/content/docs/reference/cli/commands/aspire-wait.mdx b/src/frontend/src/content/docs/reference/cli/commands/aspire-wait.mdx index 8b7c73649..a6c41be30 100644 --- a/src/frontend/src/content/docs/reference/cli/commands/aspire-wait.mdx +++ b/src/frontend/src/content/docs/reference/cli/commands/aspire-wait.mdx @@ -20,6 +20,8 @@ aspire wait [options] The `aspire wait` command blocks until a named resource within a running AppHost reaches a target status. This is useful for CI/CD pipelines and automation workflows where you need to wait for resources to be ready after starting an AppHost with `aspire run --detach`. +The `--timeout` option here controls how long to wait for a *resource* to reach its target status. It's separate from the `ASPIRE_CLI_START_TIMEOUT` environment variable, which controls how long `aspire run` and `aspire start` wait for the *AppHost itself* to finish starting up. See [aspire run](/reference/cli/commands/aspire-run/#configuring-the-startup-timeout) for details. + The command connects to a running AppHost via the backchannel and streams resource state changes in real-time. It validates that the specified resource exists before entering the wait loop, so typos in resource names are caught immediately rather than causing a silent timeout. When executed without the `--apphost` option, the command: