From 2f0e879c861ded5f137df5f4a413f8ccc30121e2 Mon Sep 17 00:00:00 2001
From: AJ Matthews <alistair.matthews@civica.co.uk>
Date: Tue, 7 Apr 2026 16:54:35 +0100
Subject: [PATCH 1/3] Ensured that 'front end' (noun) and 'front-end'
 (adjective) are used consistently as described in Microsoft style guide.

---
 .../app-host/certificate-configuration.mdx    |   2 +-
 .../content/docs/app-host/configuration.mdx   |   2 +-
 .../content/docs/app-host/container-files.mdx |  14 +-
 .../docs/app-host/executable-resources.mdx    |   4 +-
 .../app-host/migrate-from-docker-compose.mdx  |   4 +-
 .../architecture/resource-hierarchies.mdx     |   4 +-
 .../docs/architecture/resource-model.mdx      |   2 +-
 .../content/docs/dashboard/configuration.mdx  |   8 +-
 .../src/content/docs/dashboard/index.mdx      |   2 +-
 .../src/content/docs/dashboard/overview.mdx   |   4 +-
 .../dashboard/security-considerations.mdx     |   6 +-
 .../docs/dashboard/standalone-for-python.mdx  |   2 +-
 .../docs/deployment/javascript-apps.mdx       | 122 +++++++++---------
 .../src/content/docs/deployment/overview.mdx  |   2 +-
 .../src/content/docs/deployment/pipelines.mdx |  10 +-
 .../docs/fundamentals/networking-overview.mdx |   8 +-
 .../docs/fundamentals/service-discovery.mdx   |   4 +-
 ...add-aspire-existing-app-csharp-apphost.mdx |   4 +-
 ...aspire-existing-app-typescript-apphost.mdx |   6 +-
 .../src/content/docs/get-started/app-host.mdx |  24 ++--
 .../docs/get-started/aspire-sdk-templates.mdx |   8 +-
 .../get-started/deploy-first-app-csharp.mdx   |   2 +-
 .../get-started/first-app-csharp-apphost.mdx  |  16 +--
 .../first-app-typescript-apphost.mdx          |  12 +-
 .../src/content/docs/get-started/glossary.mdx |   2 +-
 .../docs/get-started/troubleshooting.mdx      |   2 +-
 .../content/docs/integrations/devtools/k6.mdx |   2 +-
 .../integrations/dotnet/project-resources.mdx |   6 +-
 .../integrations/frameworks/javascript.mdx    |  26 ++--
 .../integrations/reverse-proxies/yarp.mdx     |   2 +-
 .../content/docs/whats-new/aspire-13-1.mdx    |  10 +-
 .../src/content/docs/whats-new/aspire-13.mdx  |  14 +-
 .../src/content/docs/whats-new/aspire-9-3.mdx |   6 +-
 .../src/content/docs/whats-new/aspire-9-5.mdx |   4 +-
 src/frontend/src/content/i18n/en.json         |   2 +-
 35 files changed, 174 insertions(+), 174 deletions(-)

diff --git a/src/frontend/src/content/docs/app-host/certificate-configuration.mdx b/src/frontend/src/content/docs/app-host/certificate-configuration.mdx
index 4488c8e01..c7c2fc9fb 100644
--- a/src/frontend/src/content/docs/app-host/certificate-configuration.mdx
+++ b/src/frontend/src/content/docs/app-host/certificate-configuration.mdx
@@ -10,7 +10,7 @@ Aspire provides two complementary sets of certificate APIs:
 1. **HTTPS endpoint APIs**: Configure the certificates that resources use for their own HTTPS endpoints (server authentication)
 2. **Certificate trust APIs**: Configure which certificates resources trust when making outbound HTTPS connections (client authentication)
 
-Both sets of APIs work together to enable secure HTTPS communication during local development. For example, a Vite frontend might use `WithHttpsDeveloperCertificate` to serve HTTPS traffic, while also using `WithDeveloperCertificateTrust` to trust the dashboard's OTLP endpoint certificate.
+Both sets of APIs work together to enable secure HTTPS communication during local development. For example, a Vite front end might use `WithHttpsDeveloperCertificate` to serve HTTPS traffic, while also using `WithDeveloperCertificateTrust` to trust the dashboard's OTLP endpoint certificate.
 
 <Aside type="caution">
   Certificate customization only applies at run time. Custom certificates aren't
diff --git a/src/frontend/src/content/docs/app-host/configuration.mdx b/src/frontend/src/content/docs/app-host/configuration.mdx
index a0ebfecec..95f73d5da 100644
--- a/src/frontend/src/content/docs/app-host/configuration.mdx
+++ b/src/frontend/src/content/docs/app-host/configuration.mdx
@@ -115,7 +115,7 @@ By default, the dashboard is automatically started by the AppHost. The dashboard
 | `ASPIRE_DASHBOARD_OTLP_HTTP_ENDPOINT_URL`   | `null`                                                      | Configures the dashboard OTLP HTTP address. Used by the dashboard to receive telemetry over OTLP. If only `ASPIRE_DASHBOARD_OTLP_HTTP_ENDPOINT_URL` is configured then it is set on resources as the `OTEL_EXPORTER_OTLP_ENDPOINT` env var. The `OTEL_EXPORTER_OTLP_PROTOCOL` env var is `http/protobuf`.      |
 | `ASPIRE_DASHBOARD_CORS_ALLOWED_ORIGINS`     | `null`                                                      | Overrides the CORS allowed origins configured in the dashboard. This setting replaces the default behavior of calculating allowed origins based on resource endpoints.                                                                                                                                         |
 | `ASPIRE_DASHBOARD_UNSECURED_ALLOW_ANONYMOUS`| `false`                                                     | Configures the dashboard to not use authentication and accept anonymous access. Sets frontend, OTLP, MCP, and API auth modes to `Unsecured`.                                                                                                                                                                  |
-| `ASPIRE_DASHBOARD_FRONTEND_BROWSERTOKEN`    | Automatically generated 128-bit entropy token.              | Configures the frontend browser token. This is the value that must be entered to access the dashboard when the auth mode is BrowserToken. If no browser token is specified then a new token is generated each time the AppHost is launched.                                                                    |
+| `ASPIRE_DASHBOARD_FRONTEND_BROWSERTOKEN`    | Automatically generated 128-bit entropy token.              | Configures the front-end browser token. This is the value that must be entered to access the dashboard when the auth mode is BrowserToken. If no browser token is specified then a new token is generated each time the AppHost is launched.                                                                    |
 | `ASPIRE_DASHBOARD_TELEMETRY_OPTOUT`         | `false`                                                     | Configures the dashboard to never send [usage telemetry](/dashboard/microsoft-collected-dashboard-telemetry/).                                                                                                                                                                                                 |
 | `ASPIRE_DASHBOARD_AI_DISABLED`              | `false`                                                     | [GitHub Copilot in the dashboard](/dashboard/copilot/) is available when the AppHost is launched by a supported IDE. When set to `true` Copilot is disabled in the dashboard and no Copilot UI is visible.                                                                                                     |
 | `ASPIRE_DASHBOARD_API_ENABLED`              | `true`                                                      | Enables the dashboard [telemetry API](/dashboard/configuration/#api) (`/api/telemetry/*`) endpoints. The AppHost always sets this to `true`.                                                                                                                                                                   |
diff --git a/src/frontend/src/content/docs/app-host/container-files.mdx b/src/frontend/src/content/docs/app-host/container-files.mdx
index 62a1b0319..e6f766d40 100644
--- a/src/frontend/src/content/docs/app-host/container-files.mdx
+++ b/src/frontend/src/content/docs/app-host/container-files.mdx
@@ -340,9 +340,9 @@ For containers with `ContainerLifetime.Persistent`, changing the contents of con
 
 The `PublishWithContainerFiles` method copies files from one resource's container into another resource's container during `aspire publish`. This is the preferred approach for injecting files into containers at publish time.
 
-A key use case is embedding single-page application (SPA) or static JavaScript frontends into a reverse proxy or web server container for production deployment. During development, frontend apps like Vite or React typically run as standalone dev servers. In production, however, the compiled static assets are often served by a backend API or a dedicated web server like Nginx. `PublishWithContainerFiles` bridges this gap by copying the built frontend output into the serving container as part of the publish process — no manual file copying or multi-stage Dockerfile required.
+A key use case is embedding single-page application (SPA) or static JavaScript front ends into a reverse proxy or web server container for production deployment. During development, front-end apps like Vite or React typically run as standalone dev servers. In production, however, the compiled static assets are often served by a backend API or a dedicated web server like Nginx. `PublishWithContainerFiles` bridges this gap by copying the built front-end output into the serving container as part of the publish process — no manual file copying or multi-stage Dockerfile required.
 
-### Embed a frontend in a backend
+### Embed a front end in a backend
 
 <Tabs syncKey="apphost-lang">
 <TabItem label="C#">
@@ -376,12 +376,12 @@ await builder.build().run();
 In this example:
 
 1. The `frontend` resource builds inside its container, producing compiled JavaScript, CSS, and HTML.
-2. During publish, Aspire copies those files from the frontend container into the `api` container at `./wwwroot`.
-3. The resulting `api` container includes both the API code and the frontend static assets, ready to serve the full application.
+2. During publish, Aspire copies those files from the `frontend` container into the `api` container at `./wwwroot`.
+3. The resulting `api` container includes both the API code and the front-end static assets, ready to serve the full application.
 
-### Serve a frontend from YARP
+### Serve a front end from YARP
 
-You can also embed frontend assets into a dedicated reverse proxy container:
+You can also embed front-end assets into a dedicated reverse proxy container:
 
 <Tabs syncKey="apphost-lang">
 <TabItem label="C#">
@@ -412,7 +412,7 @@ await builder.build().run();
 </TabItem>
 </Tabs>
 
-This produces a self-contained Nginx container that serves the frontend application, with no external volume mounts or runtime file copying needed.
+This produces a self-contained Nginx container that serves the front-end application, with no external volume mounts or runtime file copying needed.
 
 `PublishWithContainerFiles` only applies in publish mode — it has no effect during `aspire run`. The destination resource must implement `IContainerFilesDestinationResource` (such as `ProjectResource`), and the source resource must implement `IResourceWithContainerFiles`.
 
diff --git a/src/frontend/src/content/docs/app-host/executable-resources.mdx b/src/frontend/src/content/docs/app-host/executable-resources.mdx
index c068d9a52..f8ed6a3fd 100644
--- a/src/frontend/src/content/docs/app-host/executable-resources.mdx
+++ b/src/frontend/src/content/docs/app-host/executable-resources.mdx
@@ -18,7 +18,7 @@ Use executable resources when you need to:
 
 Common examples include:
 
-- **Frontend development servers**: Tools like [Vercel CLI](https://vercel.com/docs/cli) or webpack dev server.
+- **Front-end development servers**: Tools like [Vercel CLI](https://vercel.com/docs/cli) or webpack dev server.
 - **Language-specific applications**: Node.js apps, Python scripts, or Go applications.
 - **Database tools**: Migration utilities or database seeders.
 - **Build tools**: Asset processors or code generators.
@@ -163,7 +163,7 @@ const app = await builder.addExecutable("app", "node", ".", ["app.js"])
 
 ## Practical example: Vercel CLI
 
-Here's a complete example using the [Vercel CLI](https://vercel.com/docs/cli) to host a frontend application with a backend API:
+Here's a complete example using the [Vercel CLI](https://vercel.com/docs/cli) to host a front-end application with a backend API:
 
 <Tabs syncKey="apphost-lang">
 <TabItem label="C#">
diff --git a/src/frontend/src/content/docs/app-host/migrate-from-docker-compose.mdx b/src/frontend/src/content/docs/app-host/migrate-from-docker-compose.mdx
index 43152e6c7..a78925ed4 100644
--- a/src/frontend/src/content/docs/app-host/migrate-from-docker-compose.mdx
+++ b/src/frontend/src/content/docs/app-host/migrate-from-docker-compose.mdx
@@ -43,7 +43,7 @@ This section demonstrates practical migration scenarios you'll likely encounter
 
 ### Multi-service web application
 
-This example shows a typical three-tier application with frontend, API, and database.
+This example shows a typical three-tier application with a front end, API, and database.
 
 **Docker Compose example:**
 
@@ -493,7 +493,7 @@ networks:
 Aspire doesn't have an equivalent for custom network isolation. Instead, Aspire automatically creates a shared container network for all container resources and uses service discovery to manage inter-service communication. All containers in an Aspire AppHost can reach each other by resource name. .NET projects and executables run on the host and access containers through injected host/port endpoints.
 
 <Aside type="note">
-If your Docker Compose setup relies on network isolation (for example, preventing a frontend service from directly accessing the database), Aspire doesn't provide a direct equivalent. Consider using application-level access controls or firewall rules in your deployment environment instead.
+If your Docker Compose setup relies on network isolation (for example, preventing a front-end service from directly accessing the database), Aspire doesn't provide a direct equivalent. Consider using application-level access controls or firewall rules in your deployment environment instead.
 </Aside>
 
 ## Migration strategy
diff --git a/src/frontend/src/content/docs/architecture/resource-hierarchies.mdx b/src/frontend/src/content/docs/architecture/resource-hierarchies.mdx
index 74c908a35..de29276f6 100644
--- a/src/frontend/src/content/docs/architecture/resource-hierarchies.mdx
+++ b/src/frontend/src/content/docs/architecture/resource-hierarchies.mdx
@@ -100,8 +100,8 @@ Endpoints are modeled as **external entities**:
 
 - They are **not edges** in the resource dependency graph.
 - They enable realistic mutual references like:
-  - A frontend app and an OIDC server mutually referencing each other's URLs (redirects, login callbacks).
-  - A backend exposing CORS settings that reference the frontend URL.
+  - A front-end app and an OIDC server mutually referencing each other's URLs (redirects, login callbacks).
+  - A backend exposing CORS settings that reference the front-end URL.
 
 <Aside type="tip">
   Endpoints are managed separately from strict dependency edges to allow
diff --git a/src/frontend/src/content/docs/architecture/resource-model.mdx b/src/frontend/src/content/docs/architecture/resource-model.mdx
index 9a37ed908..400b49ab9 100644
--- a/src/frontend/src/content/docs/architecture/resource-model.mdx
+++ b/src/frontend/src/content/docs/architecture/resource-model.mdx
@@ -116,7 +116,7 @@ The preceding example:
 
 - A PostgreSQL server (`pg`) is created and configured with a database named `appdata`.
 - A backend service (`api`) is created and connected to the database.
-- A frontend app (`web`) is created and reverse-proxies traffic to the backend.
+- A front-end app (`web`) is created and reverse-proxies traffic to the backend.
 
 Each resource participates in the application graph passively, with dependencies expressed through references.
 
diff --git a/src/frontend/src/content/docs/dashboard/configuration.mdx b/src/frontend/src/content/docs/dashboard/configuration.mdx
index 53d54b8cb..ffaa65c07 100644
--- a/src/frontend/src/content/docs/dashboard/configuration.mdx
+++ b/src/frontend/src/content/docs/dashboard/configuration.mdx
@@ -103,7 +103,7 @@ Alternatively, these same values could be configured using a JSON configuration
 
 | Option | Description |
 |--------|-------------|
-| `ASPNETCORE_URLS`<br/>Default: `http://localhost:18888` | One or more HTTP endpoints through which the dashboard frontend is served. The frontend endpoint is used to view the dashboard in a browser. When the dashboard is launched by the Aspire AppHost this address is secured with HTTPS. Securing the dashboard with HTTPS is recommended. |
+| `ASPNETCORE_URLS`<br/>Default: `http://localhost:18888` | One or more HTTP endpoints through which the dashboard front end is served. The front-end endpoint is used to view the dashboard in a browser. When the dashboard is launched by the Aspire AppHost this address is secured with HTTPS. Securing the dashboard with HTTPS is recommended. |
 | `ASPIRE_DASHBOARD_OTLP_ENDPOINT_URL`<br/>Default: `http://localhost:18889` | The [OTLP/gRPC](https://opentelemetry.io/docs/specs/otlp/#otlpgrpc) endpoint. This endpoint hosts an OTLP service and receives telemetry using gRPC. When the dashboard is launched by the Aspire AppHost this address is secured with HTTPS. Securing the dashboard with HTTPS is recommended. |
 | `ASPIRE_DASHBOARD_OTLP_HTTP_ENDPOINT_URL`<br/>Default: `http://localhost:18890` | The [OTLP/HTTP](https://opentelemetry.io/docs/specs/otlp/#otlphttp) endpoint. This endpoint hosts an OTLP service and receives telemetry using Protobuf over HTTP. When the dashboard is launched by the Aspire AppHost the OTLP/HTTP endpoint isn't configured by default. To configure an OTLP/HTTP endpoint with the AppHost, set an `ASPIRE_DASHBOARD_OTLP_HTTP_ENDPOINT_URL` env var value in _launchSettings.json_. Securing the dashboard with HTTPS is recommended. |
 | `ASPIRE_DASHBOARD_MCP_ENDPOINT_URL`<br/>Default: `http://localhost:18891` | The [Aspire MCP](/dashboard/mcp-server/) endpoint. When this value isn't specified then the MCP server is hosted with an `ASPNETCORE_URLS` endpoint. The MCP server can be disabled by configuring `Dashboard:Mcp:Disabled` to `true`. When the dashboard is launched by the Aspire AppHost this address is secured with HTTPS. Securing the dashboard with HTTPS is recommended. |
@@ -115,16 +115,16 @@ Alternatively, these same values could be configured using a JSON configuration
 
 ## Frontend
 
-The dashboard frontend endpoint authentication is configured with `Dashboard:Frontend:AuthMode`. The frontend can be secured with OpenID Connect (OIDC) or browser token authentication.
+The dashboard front-end endpoint authentication is configured with `Dashboard:Frontend:AuthMode`. The front end can be secured with OpenID Connect (OIDC) or browser token authentication.
 
-Browser token authentication works by the frontend asking for a token. The token can either be entered in the UI or provided as a query string value to the login page. For example, `https://localhost:1234/login?t=TheToken`. When the token is successfully authenticated an auth cookie is persisted to the browser, and the browser is redirected to the app.
+Browser token authentication works by the front end asking for a token. The token can either be entered in the UI or provided as a query string value to the login page. For example, `https://localhost:1234/login?t=TheToken`. When the token is successfully authenticated an auth cookie is persisted to the browser, and the browser is redirected to the app.
 
 | Option | Description |
 |--------|-------------|
 | `Dashboard:Frontend:AuthMode`<br/>Default: `BrowserToken` | Can be set to `BrowserToken`, `OpenIdConnect` or `Unsecured`. `Unsecured` should only be used during local development. It's not recommended when hosting the dashboard publicly or in other settings. |
 | `Dashboard:Frontend:BrowserToken`<br/>Default: `null` | Specifies the browser token. If the browser token isn't specified, then the dashboard generates one. Tooling that wants to automate logging in with browser token authentication can specify a token and open a browser with the token in the query string. A new token should be generated each time the dashboard is launched. |
 | `Dashboard:Frontend:MaxConsoleLogCount`<br/>Default: `10,000` | An optional limit on the number of console log messages to be retained in the viewer. When the limit is reached, the oldest messages are removed. |
-| `Dashboard:Frontend:PublicUrl`<br/>Default: `null` | Specifies the public URL used to access the dashboard frontend. The public URL is used when constructing links to the dashboard frontend. If a public URL isn't specified, the frontend endpoint is used instead. This setting is important when the dashboard is accessed through a proxy and the dashboard endpoint isn't directly reachable. |
+| `Dashboard:Frontend:PublicUrl`<br/>Default: `null` | Specifies the public URL used to access the dashboard front end. The public URL is used when constructing links to the dashboard front end. If a public URL isn't specified, the front-end endpoint is used instead. This setting is important when the dashboard is accessed through a proxy and the dashboard endpoint isn't directly reachable. |
 | `Dashboard:Frontend:OpenIdConnect:NameClaimType`<br/>Default: `name` | Specifies one or more claim types that should be used to display the authenticated user's full name. Can be a single claim type or a comma-delimited list of claim types. |
 | `Dashboard:Frontend:OpenIdConnect:UsernameClaimType`<br/>Default: `preferred_username` | Specifies one or more claim types that should be used to display the authenticated user's username. Can be a single claim type or a comma-delimited list of claim types. |
 | `Dashboard:Frontend:OpenIdConnect:RequiredClaimType`<br/>Default: `null` | Specifies the claim that must be present for authorized users. Authorization fails without this claim. This value is optional. |
diff --git a/src/frontend/src/content/docs/dashboard/index.mdx b/src/frontend/src/content/docs/dashboard/index.mdx
index 3a80211ad..3a3055b8b 100644
--- a/src/frontend/src/content/docs/dashboard/index.mdx
+++ b/src/frontend/src/content/docs/dashboard/index.mdx
@@ -211,7 +211,7 @@ Navigate to `http://localhost:18888` to open the dashboard, and point your apps'
       icon: 'random',
       title: 'Browser telemetry',
       description:
-        'Enable browser-based telemetry collection to capture frontend performance data alongside backend traces.',
+        'Enable browser-based telemetry collection to capture front-end performance data alongside backend traces.',
       href: '/dashboard/enable-browser-telemetry/',
       label: 'Enable telemetry',
       accent: 'green',
diff --git a/src/frontend/src/content/docs/dashboard/overview.mdx b/src/frontend/src/content/docs/dashboard/overview.mdx
index 7ae7275a8..548415ad3 100644
--- a/src/frontend/src/content/docs/dashboard/overview.mdx
+++ b/src/frontend/src/content/docs/dashboard/overview.mdx
@@ -64,13 +64,13 @@ For more information, see the [Standalone Aspire dashboard](/dashboard/standalon
 
 ## Configuration
 
-The dashboard is configured when it starts up. Configuration includes frontend and OTLP addresses, the resource service endpoint, authentication, telemetry limits and more.
+The dashboard is configured when it starts up. Configuration includes front-end and OTLP addresses, the resource service endpoint, authentication, telemetry limits and more.
 
 For more information, see [Aspire dashboard configuration](/dashboard/configuration/).
 
 ## Architecture
 
-The dashboard user experience is built with a variety of technologies. The frontend is built with [Grpc.AspNetCore](https://www.nuget.org/packages/Grpc.AspNetCore) NuGet package to the resource server. Consider the following diagram that illustrates the architecture of the Aspire dashboard:
+The dashboard user experience is built with a variety of technologies. The front end is built with [Grpc.AspNetCore](https://www.nuget.org/packages/Grpc.AspNetCore) NuGet package to the resource server. Consider the following diagram that illustrates the architecture of the Aspire dashboard:
 
 <ThemeImage 
   light={architectureDiagramLight}
diff --git a/src/frontend/src/content/docs/dashboard/security-considerations.mdx b/src/frontend/src/content/docs/dashboard/security-considerations.mdx
index 250078f33..03edc5d8f 100644
--- a/src/frontend/src/content/docs/dashboard/security-considerations.mdx
+++ b/src/frontend/src/content/docs/dashboard/security-considerations.mdx
@@ -18,7 +18,7 @@ The dashboard can be run in different scenarios, such as being automatically sta
 The dashboard is automatically started when an Aspire AppHost is run. The dashboard is secure by default when run from Aspire tooling:
 
 - Transport is secured with HTTPS. Using HTTPS is configured by default in _launchSettings.json_. The launch profile includes `https` addresses in `applicationUrl` and `ASPIRE_DASHBOARD_OTLP_ENDPOINT_URL` values.
-- Browser frontend authenticated with a browser token.
+- Browser front end authenticated with a browser token.
 - Incoming telemetry authenticated with an API key.
 
 HTTPS in the dashboard uses the ASP.NET Core development certificate. The certificate must be trusted for the dashboard to work correctly. The steps required to trust the development cert are different depending on the machine's operating system:
@@ -32,7 +32,7 @@ There are scenarios where you might want to allow an unsecured transport. The da
 
 The dashboard is shipped as a Docker image and can be used without the rest of Aspire. When the dashboard is launched in standalone mode, it defaults to a mix of secure and unsecured settings.
 
-- Browser frontend authenticated with a browser token.
+- Browser front end authenticated with a browser token.
 - Incoming telemetry is unsecured. Warnings are displayed in the console and dashboard UI.
 
 The telemetry endpoint accepts incoming OTLP data without authentication. When the endpoint is unsecured, the dashboard is open to receiving telemetry from untrusted apps.
@@ -95,7 +95,7 @@ Other languages have different OpenTelemetry APIs. Passing the [`OTEL_EXPORTER_O
 
 The dashboard has an optional HTTP API that exposes collected telemetry data as JSON at `/api/telemetry/*` endpoints. The telemetry API allows programmatic access to spans, logs, traces, and resource information stored in the dashboard. Because telemetry data can contain sensitive runtime information, the API is disabled by default and must be explicitly enabled.
 
-When enabled, the telemetry API is served on the same endpoint as the dashboard frontend (`ASPNETCORE_URLS`). Enable and secure the API with the following configuration:
+When enabled, the telemetry API is served on the same endpoint as the dashboard front end (`ASPNETCORE_URLS`). Enable and secure the API with the following configuration:
 
 <OsAwareTabs syncKey="terminal">
 <div slot="unix">
diff --git a/src/frontend/src/content/docs/dashboard/standalone-for-python.mdx b/src/frontend/src/content/docs/dashboard/standalone-for-python.mdx
index 4c9c8cef2..3f1889cd0 100644
--- a/src/frontend/src/content/docs/dashboard/standalone-for-python.mdx
+++ b/src/frontend/src/content/docs/dashboard/standalone-for-python.mdx
@@ -28,7 +28,7 @@ To complete this tutorial, you need the following:
 
 ## Create a sample application
 
-This tutorial uses the Aspire 13.0 Python starter template which includes a FastAPI backend and React frontend. You'll focus on the FastAPI app to demonstrate dashboard integration with standalone mode.
+This tutorial uses the Aspire 13.0 Python starter template which includes a FastAPI backend and React front end. You'll focus on the FastAPI app to demonstrate dashboard integration with standalone mode.
 
 <Steps>
 
diff --git a/src/frontend/src/content/docs/deployment/javascript-apps.mdx b/src/frontend/src/content/docs/deployment/javascript-apps.mdx
index 2a3432227..8cd30e1f4 100644
--- a/src/frontend/src/content/docs/deployment/javascript-apps.mdx
+++ b/src/frontend/src/content/docs/deployment/javascript-apps.mdx
@@ -1,18 +1,18 @@
 ---
 title: Deploy JavaScript apps
-description: Learn the main production deployment models for Vite and JavaScript frontends in Aspire.
+description: Learn the main production deployment models for Vite and JavaScript front ends in Aspire.
 ---
 
 import { Aside, Tabs, TabItem } from '@astrojs/starlight/components';
 import LearnMore from '@components/LearnMore.astro';
 
-For Vite and other JavaScript frontends, there are three common production deployment models:
+For Vite and other JavaScript front ends, there are three common production deployment models:
 
-- A backend service serves the built frontend files.
-- A reverse proxy serves the built frontend files.
-- A standalone static frontend talks directly to a separately hosted backend.
+- A backend service serves the built front-end files.
+- A reverse proxy serves the built front-end files.
+- A standalone static front end talks directly to a separately hosted backend.
 
-All three models use `AddViteApp` for local development and for producing the frontend build output during publishing. The difference is which resource becomes the production entrypoint and whether the browser talks to the backend directly.
+All three models use `AddViteApp` for local development and for producing the front-end build output during publishing. The difference is which resource becomes the production entrypoint and whether the browser talks to the backend directly.
 
 These same production models also apply to `AddJavaScriptApp`. The difference
 is that `AddViteApp` knows about Vite's development conventions, while
@@ -23,20 +23,20 @@ specific deployment target.
 
 ## Deployment rule
 
-For deployment, `AddViteApp` and `AddJavaScriptApp` should be treated as frontend build resources, not as the final production web server.
+For deployment, `AddViteApp` and `AddJavaScriptApp` should be treated as front-end build resources, not as the final production web server.
 
-To deploy a JavaScript frontend, you must choose which other resource owns the public HTTP surface in production:
+To deploy a JavaScript front end, you must choose which other resource owns the public HTTP surface in production:
 
-- Use `PublishWithContainerFiles(...)` when your backend or web server will serve the built frontend files.
-- Use `PublishWithStaticFiles(...)` when your reverse proxy, gateway, or <abbr title="Backend for Frontend">BFF</abbr> will serve the built frontend files.
+- Use `PublishWithContainerFiles(...)` when your backend or web server will serve the built front-end files.
+- Use `PublishWithStaticFiles(...)` when your reverse proxy, gateway, or <abbr title="Backend for Frontend">BFF</abbr> will serve the built front-end files.
 
-If you only add a Vite or JavaScript app and reference backend services, Aspire still needs one of these production hosting patterns to know who serves the built frontend in deployment.
+If you only add a Vite or JavaScript app and reference backend services, Aspire still needs one of these production hosting patterns to know who serves the built front end in deployment.
 
 <Aside type="tip">
   If you expected `AddViteApp(...).PublishAsDockerFile()` to behave like a
   standalone Nginx- or Apache-style static web container by default, that is not
   the primary deployment model Aspire is guiding you toward. The intended
-  default is that another resource serves the built frontend assets in
+  default is that another resource serves the built front-end assets in
   production.
 </Aside>
 
@@ -52,30 +52,30 @@ If you only add a Vite or JavaScript app and reference backend services, Aspire
 
 | Model                                  | Production entrypoint      | Aspire publish API          | Best for                                                                          |
 | -------------------------------------- | -------------------------- | --------------------------- | --------------------------------------------------------------------------------- |
-| Backend serves frontend                | API or web server          | `PublishWithContainerFiles` | Apps where one service serves both the API and the frontend                       |
-| Reverse proxy serves frontend          | Reverse proxy              | `PublishWithStaticFiles`    | Apps that want a gateway or BFF in front of APIs and static frontend assets       |
-| Static frontend calls backend directly | Static site + separate API | Custom / less integrated    | Apps that intentionally keep frontend hosting separate and can manage CORS/config |
+| Backend serves front end               | API or web server          | `PublishWithContainerFiles` | Apps where one service serves both the API and the front end                      |
+| Reverse proxy serves front end         | Reverse proxy              | `PublishWithStaticFiles`    | Apps that want a gateway or BFF in front of APIs and static front-end assets      |
+| Static front end calls backend directly | Static site + separate API | Custom / less integrated    | Apps that intentionally keep front-end hosting separate and can manage CORS/config |
 
 <Aside type="caution">
   `AddViteApp` already registers its local development endpoint. Do not call
   `.WithHttpEndpoint()` on a Vite resource.
 </Aside>
 
-## Model 1: Backend serves the built frontend
+## Model 1: Backend serves the built front end
 
-Use this model when your backend, API, or server is responsible for serving static frontend files in production from `wwwroot`, `static`, or a similar directory.
+Use this model when your backend, API, or server is responsible for serving static front-end files in production from `wwwroot`, `static`, or a similar directory.
 
-This model only works if that backend or server can actually serve the built frontend assets. In other words, the deployed application service must be both the API host and the static file host for the frontend.
+This model only works if that backend or server can actually serve the built front-end assets. In other words, the deployed application service must be both the API host and the static file host for the front end.
 
 <Aside type="note">
-  `PublishWithContainerFiles(...)` only copies the built frontend assets into
+  `PublishWithContainerFiles(...)` only copies the built front-end assets into
   the destination container. The important requirement is easy to miss in the
   helper name: the destination app must be configured to serve those files.
 </Aside>
 
 ```mermaid
 flowchart LR
-    Browser --> App["Node app<br/>serving built frontend files"]
+    Browser --> App["Node app<br/>serving built front-end files"]
     App --> Frontend["Vite build output"]
 ```
 
@@ -129,31 +129,31 @@ await builder.build().run();
 ### How it works
 
 1. `AddViteApp` runs the Vite dev server during `aspire run`.
-2. During publish, Aspire builds the frontend and extracts its production output.
+2. During publish, Aspire builds the front end and extracts its production output.
 3. `PublishWithContainerFiles` copies those files into the Node app container.
-4. The Node app becomes the deployed HTTP endpoint and serves the frontend files.
+4. The Node app becomes the deployed HTTP endpoint and serves the front-end files.
 
 ### Why Aspire supports this model
 
-This model keeps the production topology simple. The frontend build output becomes part of the same deployable unit as the backend, so one service owns the application surface, static files, and API behavior together.
+This model keeps the production topology simple. The front-end build output becomes part of the same deployable unit as the backend, so one service owns the application surface, static files, and API behavior together.
 
-It also maps well to frameworks that already know how to serve static files from `wwwroot`, `static`, or a similar folder. Instead of introducing an extra gateway or frontend-serving container, Aspire lets the backend stay responsible for the final HTTP response.
+It also maps well to frameworks that already know how to serve static files from `wwwroot`, `static`, or a similar folder. Instead of introducing an extra gateway or front-end-serving container, Aspire lets the backend stay responsible for the final HTTP response.
 
 ### When to use this model
 
 - Your backend already serves static files, or you are willing to make it do so.
-- You want one deployed service to host both the API and the frontend.
+- You want one deployed service to host both the API and the front end.
 - You want the same resource to own routing, auth, and static asset hosting.
 
 ### Implications
 
-- Your backend container gets larger because it now contains both backend code and frontend assets.
-- Frontend and backend are deployed together, which is convenient when they change together but less flexible if you want to scale or release them independently.
+- Your backend container gets larger because it now contains both backend code and front-end assets.
+- Front end and backend are deployed together, which is convenient when they change together but less flexible if you want to scale or release them independently.
 - Authentication, caching, headers, and fallback routing are handled where the backend serves the files.
 - This usually gives the simplest mental model: one deployed service, one public endpoint, one place to troubleshoot.
-- This is the default pattern Aspire is steering you toward for Vite frontends unless you intentionally introduce a gateway or BFF to own the public surface.
+- This is the default pattern Aspire is steering you toward for Vite front ends unless you intentionally introduce a gateway or BFF to own the public surface.
 
-## Model 2: Reverse proxy serves the built frontend
+## Model 2: Reverse proxy serves the built front end
 
 Use this model when a reverse proxy should be the public entrypoint for your app, either as a gateway or as a backend-for-frontend (BFF).
 
@@ -230,7 +230,7 @@ await builder.build().run();
 
 ### Dev-only gateway wiring
 
-If your gateway or BFF needs to know about the frontend dev server during local
+If your gateway or BFF needs to know about the front-end dev server during local
 development, gate that wiring to run mode only:
 
 <Tabs syncKey="apphost-lang">
@@ -275,21 +275,21 @@ if (await builder.executionContext.isRunMode()) {
 
 <Aside type="caution">
   Dev-only waits, references, and environment variables that point at the
-  frontend development server can be correct in run mode, but wrong in
+  front-end development server can be correct in run mode, but wrong in
   publish/deploy if you leave them unconditional. Publish must not depend on the
-  frontend development endpoint.
+  front-end development endpoint.
 </Aside>
 
 ### How it works
 
-1. The reverse proxy owns the public URL surface for both frontend and backend routes.
+1. The reverse proxy owns the public URL surface for both front-end and backend routes.
 2. API requests such as `/api/*` are routed to the backend service.
-3. During publish, Aspire builds the frontend and `PublishWithStaticFiles` copies the output into the proxy resource.
-4. In production, the proxy serves frontend routes itself while continuing to proxy API routes.
+3. During publish, Aspire builds the front end and `PublishWithStaticFiles` copies the output into the proxy resource.
+4. In production, the proxy serves front-end routes itself while continuing to proxy API routes.
 
 ### Why Aspire supports this model
 
-This model keeps the public entrypoint separate from the application services behind it. The reverse proxy becomes the stable edge for the app, while the frontend build and any backend services remain behind that gateway or BFF.
+This model keeps the public entrypoint separate from the application services behind it. The reverse proxy becomes the stable edge for the app, while the front-end build and any backend services remain behind that gateway or BFF.
 
 It is a good fit when you want one place to centralize routing, transforms, headers, and gateway or BFF concerns. YARP is Aspire's first-class option here, which is why the example uses it, but the architectural tradeoffs are the same for other reverse proxies.
 
@@ -302,16 +302,16 @@ It is a good fit when you want one place to centralize routing, transforms, head
 ### Implications
 
 - The reverse proxy owns the public endpoint, so backend services can stay internal behind the gateway or BFF.
-- Frontend hosting is decoupled from any individual backend service, which can make routing cleaner in multi-service apps.
-- Route rules now matter directly because the proxy decides which requests go to APIs and which requests go to the frontend.
+- Front-end hosting is decoupled from any individual backend service, which can make routing cleaner in multi-service apps.
+- Route rules now matter directly because the proxy decides which requests go to APIs and which requests go to the front end.
 - You now have a dedicated gateway/BFF in the deployment, which adds one more moving part but also gives you more control over ingress behavior.
-- This is often the better choice when the frontend needs BFF-style behavior or when a standalone Vite build would otherwise need deployment-time configuration from backend resources.
+- This is often the better choice when the front end needs BFF-style behavior or when a standalone Vite build would otherwise need deployment-time configuration from backend resources.
 
 ## A third model you may be considering
 
 Another common deployment shape is:
 
-- The frontend is deployed to its own static file host.
+- The front end is deployed to its own static file host.
 - The backend is deployed to separate compute.
 - The browser calls the backend directly.
 
@@ -427,17 +427,17 @@ await builder.build().run();
 - **Pit 2 — Switching the same value to a build arg**
 
   Example: `WithBuildArg(...)` / `withBuildArg(...)` to set the backend URL
-  during the frontend image build.
+  during the front-end image build.
 
-  Associated failure: the backend URL is usually not known when the frontend
+  Associated failure: the backend URL is usually not known when the front end
   image is being built.
 
 - **Pit 3 — Trying to wire both sides of the relationship**
 
-  Example: the frontend needs the backend URL, while the backend also needs the
-  frontend origin for CORS.
+  Example: the front end needs the backend URL, while the backend also needs the
+  front-end origin for CORS.
 
-  Associated failure: this creates a deployment-time cycle between the frontend
+  Associated failure: this creates a deployment-time cycle between the front end
   and backend. In publish/deploy, the Vite resource is a build resource, not the
   runtime web server, so it cannot be the place where the browser discovers the
   backend URL.
@@ -446,7 +446,7 @@ await builder.build().run();
   If publish throws `The given key 'Aspire.Hosting.JavaScript.ViteAppResource'
   was not present in the dictionary.`, treat that as a modeling problem, not as
   a missing dictionary entry. Move that runtime relationship to the backend,
-  reverse proxy, or other deployed resource that actually serves the frontend or
+  reverse proxy, or other deployed resource that actually serves the front end or
   owns the public HTTP surface.
 </Aside>
 
@@ -456,26 +456,26 @@ This model looks familiar if you are used to deploying:
 
 - A Vite or React app to a static site host.
 - An API to another host.
-- Frontend JavaScript that calls the API directly from the browser.
+- Front-end JavaScript that calls the API directly from the browser.
 
-It can seem like the most obvious path because it keeps the frontend as "just a
-static site" and avoids adding a backend-served frontend or reverse proxy layer.
+It can seem like the most obvious path because it keeps the front end as "just a
+static site" and avoids adding a backend-served front end or reverse proxy layer.
 
 ### Why it gets harder
 
-This model pushes more work onto the browser/frontend boundary:
+This model pushes more work onto the browser/front-end boundary:
 
 - The browser now talks to a different origin, so you often need to configure CORS.
-- The frontend needs to know the backend URL for each environment.
+- The front end needs to know the backend URL for each environment.
 - Vite apps usually consume those values at build time, which means the backend
-  URL must be known when the frontend is built or injected through a separate
+  URL must be known when the front end is built or injected through a separate
   runtime configuration pattern.
 - Local Vite proxy behavior often hides these production concerns until you try
   to deploy.
 
 ### What this means in Aspire
 
-Aspire can still orchestrate the frontend build and the backend resource, but
+Aspire can still orchestrate the front-end build and the backend resource, but
 this topology is less integrated than the two primary models above. In
 particular, Aspire does not automatically solve:
 
@@ -484,17 +484,17 @@ particular, Aspire does not automatically solve:
 - The split ownership between a standalone static site host and a separate API host.
 
 If this is the model you want, plan for explicit runtime configuration and CORS
-management. Otherwise, the backend-serves-frontend or reverse-proxy-serves-frontend
+management. Otherwise, the backend-serves-front-end or reverse-proxy-serves-front-end
 models are usually easier to reason about in Aspire.
 
 ## How to choose
 
-Choose **backend serves frontend** when the backend already owns the app surface and should also own static file hosting.
+Choose **backend serves front end** when the backend already owns the app surface and should also own static file hosting.
 
-Choose **reverse proxy serves frontend** when you want a gateway or BFF to stay in front of everything and route both frontend and backend traffic.
+Choose **reverse proxy serves front end** when you want a gateway or BFF to stay in front of everything and route both front-end and backend traffic.
 
-Choose the **standalone static frontend + direct browser-to-backend** model only
-when you intentionally want separate frontend and backend hosting and are
+Choose the **standalone static front end + direct browser-to-backend** model only
+when you intentionally want separate front-end and backend hosting and are
 willing to manage backend URL configuration and CORS explicitly.
 
 In practice, the decision is usually about **who should own the public HTTP surface in production**:
@@ -504,10 +504,10 @@ In practice, the decision is usually about **who should own the public HTTP surf
 
 ## What `AddViteApp` means in production
 
-`AddViteApp` is best thought of as a development server plus a frontend build resource:
+`AddViteApp` is best thought of as a development server plus a front-end build resource:
 
 - In run mode, it gives you the Vite dev server and HMR.
-- In publish mode, it produces frontend build artifacts.
+- In publish mode, it produces front-end build artifacts.
 - Another resource serves those artifacts in production.
 
 That distinction is easy to miss if you only read the JavaScript integration page or release notes. This article exists to make the production story explicit.
@@ -527,7 +527,7 @@ The difference is that `AddJavaScriptApp` does not assume a particular developme
 
 - Expecting `AddViteApp` to be the deployed production web server.
 - Exposing the Vite resource instead of the backend or reverse proxy resource that serves the built files.
-- Adding `AddViteApp` plus `.WithReference(...)` and assuming that is enough to deploy the frontend.
+- Adding `AddViteApp` plus `.WithReference(...)` and assuming that is enough to deploy the front end.
 - Using `.WithEnvironment(...)` on `AddViteApp` to pass the API URL to the deployed SPA.
 - Calling `.WithHttpEndpoint()` on `AddViteApp`.
 - Using `VITE_*` variables for values that must be resolved at runtime in an already-built SPA.
diff --git a/src/frontend/src/content/docs/deployment/overview.mdx b/src/frontend/src/content/docs/deployment/overview.mdx
index 2e1c2eed1..f20f2bebf 100644
--- a/src/frontend/src/content/docs/deployment/overview.mdx
+++ b/src/frontend/src/content/docs/deployment/overview.mdx
@@ -128,7 +128,7 @@ builder.AddProject<Projects.Backend>("backend")
     .WithComputeEnvironment(compose);
 ```
 
-This example shows how you could explicitly map services to different compute environments. For example, a frontend in Kubernetes and a backend in Docker Compose.
+This example shows how you could explicitly map services to different compute environments. For example, a front end in Kubernetes and a backend in Docker Compose.
 
 ## Hosting integration support matrix
 
diff --git a/src/frontend/src/content/docs/deployment/pipelines.mdx b/src/frontend/src/content/docs/deployment/pipelines.mdx
index 606da03b8..d83e6002f 100644
--- a/src/frontend/src/content/docs/deployment/pipelines.mdx
+++ b/src/frontend/src/content/docs/deployment/pipelines.mdx
@@ -86,7 +86,7 @@ Each step has:
 - **Dependencies**: Other steps that must complete before this step runs
 - **Resource context**: Access to the application's resource model and configuration
 
-Pipeline steps operate at different levels of granularity. For example, when deploying a typical web application with a frontend, API service, database, and storage, the pipeline might include:
+Pipeline steps operate at different levels of granularity. For example, when deploying a typical web application with a front end, API service, database, and storage, the pipeline might include:
 
 **Infrastructure steps** (can run in parallel):
 - `provision-cosmosdb`: Provision the CosmosDB database
@@ -96,13 +96,13 @@ Pipeline steps operate at different levels of granularity. For example, when dep
 
 **Build steps** (can run in parallel):
 - `build-apiservice`: Build container image for the API service
-- `build-webfrontend`: Build container image for the frontend
+- `build-webfrontend`: Build container image for the front end
 
 **Deployment steps** (depend on builds and infrastructure):
 - `push-apiservice`: Push API service image to registry
-- `push-webfrontend`: Push frontend image to registry
+- `push-webfrontend`: Push front-end image to registry
 - `deploy-apiservice`: Deploy API service to compute platform
-- `deploy-webfrontend`: Deploy frontend to compute platform
+- `deploy-webfrontend`: Deploy front end to compute platform
 
 This granular approach allows the pipeline to maximize parallelism—databases can be provisioned while container images are building, and as soon as both the container registry and an image are ready, the image can be pushed immediately without waiting for other unrelated operations.
 
@@ -305,7 +305,7 @@ The `aspire do` command allows you to execute individual steps and their depende
 
 **Use cases for selective step execution:**
 
-- **Incremental deployments**: After making changes to only your frontend code, run just the frontend-related steps rather than rebuilding and redeploying your entire application
+- **Incremental deployments**: After making changes to only your front-end code, run just the front-end-related steps rather than rebuilding and redeploying your entire application
 - **Troubleshooting and retry**: If a specific step fails (e.g., database provisioning times out), you can retry just that step and its dependents without repeating successful operations
 - **Development workflows**: During development, you might want to provision infrastructure once, then repeatedly deploy code changes without reprovisioning resources
 - **Selective operations**: Separate infrastructure provisioning from application deployment to align with organizational policies or approval processes
diff --git a/src/frontend/src/content/docs/fundamentals/networking-overview.mdx b/src/frontend/src/content/docs/fundamentals/networking-overview.mdx
index 7506be390..4a46198a3 100644
--- a/src/frontend/src/content/docs/fundamentals/networking-overview.mdx
+++ b/src/frontend/src/content/docs/fundamentals/networking-overview.mdx
@@ -135,7 +135,7 @@ The preceding code results in the following networking diagram:
 
 <Image
   src={proxyWithReplicas}
-  alt="Aspire frontend app networking diagram with specific host port and two replicas."
+  alt="Aspire front-end app networking diagram with specific host port and two replicas."
 />
 
 The preceding diagram depicts the following:
@@ -160,7 +160,7 @@ There are two ports defined:
 
 <Image
   src={proxyHostPortAndRandomPort}
-  alt="Aspire frontend app networking diagram with specific host port and random port."
+  alt="Aspire front-end app networking diagram with specific host port and random port."
 />
 
 The preceding diagram depicts the following:
@@ -191,7 +191,7 @@ In this scenario, both the host and service ports are random, as shown in the fo
 
 <Image
   src={proxyWithRandomPorts}
-  alt="Aspire frontend app networking diagram with random host port and proxy port."
+  alt="Aspire front-end app networking diagram with random host port and proxy port."
 />
 
 The preceding diagram depicts the following:
@@ -219,7 +219,7 @@ Consider the following diagram:
 
 <Image
   src={proxyWithDockerPortMapping}
-  alt="Aspire frontend app networking diagram with a docker host."
+  alt="Aspire front-end app networking diagram with a docker host."
 />
 
 ## Endpoint extension methods
diff --git a/src/frontend/src/content/docs/fundamentals/service-discovery.mdx b/src/frontend/src/content/docs/fundamentals/service-discovery.mdx
index fb0090905..2ae640afe 100644
--- a/src/frontend/src/content/docs/fundamentals/service-discovery.mdx
+++ b/src/frontend/src/content/docs/fundamentals/service-discovery.mdx
@@ -5,7 +5,7 @@ description: Understand essential service discovery concepts in Aspire.
 
 import { Aside } from '@astrojs/starlight/components';
 
-Service discovery is how your services find each other. Instead of hardcoding URLs like `http://localhost:5001`, your frontend can simply reference the `catalog` service by name—and Aspire handles resolving the actual address.
+Service discovery is how your services find each other. Instead of hardcoding URLs like `http://localhost:5001`, your front end can simply reference the `catalog` service by name—and Aspire handles resolving the actual address.
 
 ## How service discovery works
 
@@ -43,7 +43,7 @@ In the preceding example, the _frontend_ project references the _catalog_ projec
 2. **Enable resolution** - Allow `frontend` to use URIs like `https+http://catalog` in HttpClient
 
 <Aside type="note">
-If you don't call `WithReference()`, the frontend won't have the configuration needed to discover that service. This is intentional—services only know about their explicit dependencies.
+If you don't call `WithReference()`, the front end won't have the configuration needed to discover that service. This is intentional—services only know about their explicit dependencies.
 </Aside>
 
 ## Named endpoints
diff --git a/src/frontend/src/content/docs/get-started/add-aspire-existing-app-csharp-apphost.mdx b/src/frontend/src/content/docs/get-started/add-aspire-existing-app-csharp-apphost.mdx
index 0e1587b87..430e86ed9 100644
--- a/src/frontend/src/content/docs/get-started/add-aspire-existing-app-csharp-apphost.mdx
+++ b/src/frontend/src/content/docs/get-started/add-aspire-existing-app-csharp-apphost.mdx
@@ -502,9 +502,9 @@ builder.Build().Run();
 :::caution[JavaScript deployment note]
 This example shows how to run existing JavaScript applications with Aspire
 during development. It does not, by itself, define who serves a Vite or
-JavaScript frontend in production.
+JavaScript front end in production.
 
-If you plan to publish or deploy these frontend resources, read [Deploy
+If you plan to publish or deploy these front-end resources, read [Deploy
 JavaScript apps](/deployment/javascript-apps/) to choose the correct production
 hosting model.
 :::
diff --git a/src/frontend/src/content/docs/get-started/add-aspire-existing-app-typescript-apphost.mdx b/src/frontend/src/content/docs/get-started/add-aspire-existing-app-typescript-apphost.mdx
index 9c29469ca..684e30f5b 100644
--- a/src/frontend/src/content/docs/get-started/add-aspire-existing-app-typescript-apphost.mdx
+++ b/src/frontend/src/content/docs/get-started/add-aspire-existing-app-typescript-apphost.mdx
@@ -228,9 +228,9 @@ await builder.build().run();
 :::caution[JavaScript deployment note]
 This example shows how to run existing JavaScript applications with Aspire
 during development. It does not, by itself, define who serves a Vite or
-JavaScript frontend in production.
+JavaScript front end in production.
 
-If you plan to publish or deploy these frontend resources, read [Deploy
+If you plan to publish or deploy these front-end resources, read [Deploy
 JavaScript apps](/deployment/javascript-apps/) to choose the correct production
 hosting model.
 :::
@@ -264,7 +264,7 @@ Option 2 keeps all script configuration in `package.json`, making your scripts m
 
 <Aside type="tip">
   You can mix and match JavaScript application types. Combine Node.js APIs, Vite
-  frontends, workers, and supporting containers in the same TypeScript AppHost
+  front ends, workers, and supporting containers in the same TypeScript AppHost
   to model your full development environment in one place.
 </Aside>
 
diff --git a/src/frontend/src/content/docs/get-started/app-host.mdx b/src/frontend/src/content/docs/get-started/app-host.mdx
index efd8ba815..d5ca23859 100644
--- a/src/frontend/src/content/docs/get-started/app-host.mdx
+++ b/src/frontend/src/content/docs/get-started/app-host.mdx
@@ -464,9 +464,9 @@ Next, register the API service and wire it to the PostgreSQL resource:
 
 Now that the `api` service is defined, you can attach the front end.
 
-#### Adding a front end resource
+#### Adding a front-end resource
 
-Register the front end project, declare its dependency on the API, and let the AppHost provide the API address automatically.
+Register the front-end project, declare its dependency on the API, and let the AppHost provide the API address automatically.
 
 <Aside type="note">
 This example uses a Node.js (React) front end, but Aspire treats front ends as executable services—any language or framework works.
@@ -479,7 +479,7 @@ This example uses a Node.js (React) front end, but Aspire treats front ends as e
     <ul>
       <li><code>AddViteApp("frontend", "../frontend")</code> registers the front end as a service named <code>frontend</code>.</li>
       <li><code>WithHttpEndpoint(env: "PORT")</code> exposes the app and lets the <code>PORT</code> environment variable control the listener.</li>
-      <li><code>WithReference(api)</code> injects the API base address into the front end configuration.</li>
+      <li><code>WithReference(api)</code> injects the API base address into the front-end configuration.</li>
     </ul>
   </div>
   <div slot="typescript-content">
@@ -487,7 +487,7 @@ This example uses a Node.js (React) front end, but Aspire treats front ends as e
     <ul>
       <li><code>addViteApp("frontend", "../frontend")</code> registers the front end as a service named <code>frontend</code>.</li>
       <li><code>withHttpEndpoint({'{'} env: "PORT" {'}'})</code> exposes the app and lets the <code>PORT</code> environment variable control the listener.</li>
-      <li><code>withReference(api)</code> injects the API base address into the front end configuration.</li>
+      <li><code>withReference(api)</code> injects the API base address into the front-end configuration.</li>
     </ul>
   </div>
 </SimpleAppHostCode>
@@ -499,7 +499,7 @@ This example uses a Node.js (React) front end, but Aspire treats front ends as e
     <ul>
       <li><code>AddViteApp("frontend", "../frontend")</code> registers the front end as a service named <code>frontend</code>.</li>
       <li><code>WithHttpEndpoint(env: "PORT")</code> exposes the app and lets the <code>PORT</code> environment variable control the listener.</li>
-      <li><code>WithReference(api)</code> injects the API base address into the front end configuration.</li>
+      <li><code>WithReference(api)</code> injects the API base address into the front-end configuration.</li>
     </ul>
   </div>
   <div slot="typescript-content">
@@ -507,7 +507,7 @@ This example uses a Node.js (React) front end, but Aspire treats front ends as e
     <ul>
       <li><code>addViteApp("frontend", "../frontend")</code> registers the front end as a service named <code>frontend</code>.</li>
       <li><code>withHttpEndpoint({'{'} env: "PORT" {'}'})</code> exposes the app and lets the <code>PORT</code> environment variable control the listener.</li>
-      <li><code>withReference(api)</code> injects the API base address into the front end configuration.</li>
+      <li><code>withReference(api)</code> injects the API base address into the front-end configuration.</li>
     </ul>
   </div>
 </SimpleAppHostCode>
@@ -519,7 +519,7 @@ This example uses a Node.js (React) front end, but Aspire treats front ends as e
     <ul>
       <li><code>AddViteApp("frontend", "../frontend")</code> registers the front end as a service named <code>frontend</code>.</li>
       <li><code>WithHttpEndpoint(env: "PORT")</code> exposes the app and lets the <code>PORT</code> environment variable control the listener.</li>
-      <li><code>WithReference(api)</code> injects the API base address into the front end configuration.</li>
+      <li><code>WithReference(api)</code> injects the API base address into the front-end configuration.</li>
     </ul>
   </div>
   <div slot="typescript-content">
@@ -527,7 +527,7 @@ This example uses a Node.js (React) front end, but Aspire treats front ends as e
     <ul>
       <li><code>addViteApp("frontend", "../frontend")</code> registers the front end as a service named <code>frontend</code>.</li>
       <li><code>withHttpEndpoint({'{'} env: "PORT" {'}'})</code> exposes the app and lets the <code>PORT</code> environment variable control the listener.</li>
-      <li><code>withReference(api)</code> injects the API base address into the front end configuration.</li>
+      <li><code>WithReference(api)</code> injects the API base address into the front-end configuration.</li>
     </ul>
   </div>
 </SimpleAppHostCode>
@@ -539,7 +539,7 @@ This example uses a Node.js (React) front end, but Aspire treats front ends as e
     <ul>
       <li><code>AddViteApp("frontend", "../frontend")</code> registers the front end as a service named <code>frontend</code>.</li>
       <li><code>WithHttpEndpoint(env: "PORT")</code> exposes the app and lets the <code>PORT</code> environment variable control the listener.</li>
-      <li><code>WithReference(api)</code> injects the API base address into the front end configuration.</li>
+      <li><code>WithReference(api)</code> injects the API base address into the front-end configuration.</li>
     </ul>
   </div>
 </SimpleAppHostCode>
@@ -551,7 +551,7 @@ This example uses a Node.js (React) front end, but Aspire treats front ends as e
     <ul>
       <li><code>AddViteApp("frontend", "../frontend")</code> registers the front end as a service named <code>frontend</code>.</li>
       <li><code>WithHttpEndpoint(env: "PORT")</code> exposes the app and lets the <code>PORT</code> environment variable control the listener.</li>
-      <li><code>WithReference(api)</code> injects the API base address into the front end configuration.</li>
+      <li><code>WithReference(api)</code> injects the API base address into the front-end configuration.</li>
     </ul>
   </div>
 </SimpleAppHostCode>
@@ -561,7 +561,7 @@ In short: define the backend first (DB → API), then point the UI at the API. T
 
 #### Configuration and networking
 
-These dependencies and connections are automatically managed by Aspire. The AppHost generates configuration values like connection strings and endpoints, injecting them into services as needed. in the AppHost when you add resources, you name them (e.g., `db`, `api`, `front end`); Aspire uses these names for DNS resolution, so services can communicate using predictable addresses. Consuming services also rely on these names for configuration injection.
+These dependencies and connections are automatically managed by Aspire. The AppHost generates configuration values like connection strings and endpoints, injecting them into services as needed. in the AppHost when you add resources, you name them (e.g., `db`, `api`, `frontend`); Aspire uses these names for DNS resolution, so services can communicate using predictable addresses. Consuming services also rely on these names for configuration injection.
 
 <Pivot id="csharp">
 
@@ -671,7 +671,7 @@ The Java API receives a **ConnectionStringReference** from PostgreSQL and publis
 1. `pg` publishes a `ConnectionStringReference` (host, port, database, user, password)—a strongly typed bundle Aspire understands.
 1. `api` declares a dependency on that reference; Aspire injects the connection string into its config with a unique configuration-flow process that injects settings values, including secrets, parameters, and connection strings for both local runs and deployments.
 1. `api` then publishes an `EndpointReference` (its base URL) after its HTTP endpoint is allocated.
-1. `front end` depends on that endpoint; Aspire injects the API base URL so no hard-coded addresses are needed.
+1. `frontend` depends on that endpoint; Aspire injects the API base URL so no hard-coded addresses are needed.
 
 </Steps>
 
diff --git a/src/frontend/src/content/docs/get-started/aspire-sdk-templates.mdx b/src/frontend/src/content/docs/get-started/aspire-sdk-templates.mdx
index 706333b0d..e20dd7736 100644
--- a/src/frontend/src/content/docs/get-started/aspire-sdk-templates.mdx
+++ b/src/frontend/src/content/docs/get-started/aspire-sdk-templates.mdx
@@ -36,13 +36,13 @@ The following Aspire solution templates are available (assume the solution is na
   - **AspireSample.Test**: Either an MSTest, NUnit, or xUnit test project with project references to the AppHost and an example _WebTests.cs_ file demonstrating an integration test.
 
 - **Aspire Starter App with ASP.NET Core and React**: This template includes the AppHost and ServiceDefaults projects, plus:
-  - **AspireSample.ApiService**: An [ASP.NET Core Minimal API](https://learn.microsoft.com/aspnet/core/fundamentals/minimal-apis) project that provides data to the frontend.
-  - **AspireSample.Web**: A React-based frontend application with TypeScript configured to work with the Aspire app.
+  - **AspireSample.ApiService**: An [ASP.NET Core Minimal API](https://learn.microsoft.com/aspnet/core/fundamentals/minimal-apis) project that provides data to the front end.
+  - **AspireSample.Web**: A React-based front-end application with TypeScript configured to work with the Aspire app.
 
 - **Aspire Starter App with FastAPI and React**: This template provides a Python-based starter app with the following projects:
   - **AspireSample.AppHost**: The orchestrator project for managing the app's services.
-  - **AspireSample.ApiService**: A [FastAPI](https://fastapi.tiangolo.com/) Python backend service that provides data to the frontend.
-  - **AspireSample.Web**: A React-based frontend application with TypeScript.
+  - **AspireSample.ApiService**: A [FastAPI](https://fastapi.tiangolo.com/) Python backend service that provides data to the front end.
+  - **AspireSample.Web**: A React-based front-end application with TypeScript.
 
   For more information on getting started with Python in Aspire, see [Build your first app](/get-started/first-app-csharp-apphost/?lang=python).
 
diff --git a/src/frontend/src/content/docs/get-started/deploy-first-app-csharp.mdx b/src/frontend/src/content/docs/get-started/deploy-first-app-csharp.mdx
index 9a6764a20..c63d1f539 100644
--- a/src/frontend/src/content/docs/get-started/deploy-first-app-csharp.mdx
+++ b/src/frontend/src/content/docs/get-started/deploy-first-app-csharp.mdx
@@ -43,7 +43,7 @@ The following diagram shows the architecture of the sample app you're deploying:
 ```mermaid
 architecture-beta
     group api-docker(logos:docker-icon)[API container]
-    group f-docker(logos:docker-icon)[Front end container]
+    group f-docker(logos:docker-icon)[Front-end container]
 
     service api(logos:dotnet)[API service] in api-docker
     service http(iconoir:server-connection)[https]
diff --git a/src/frontend/src/content/docs/get-started/first-app-csharp-apphost.mdx b/src/frontend/src/content/docs/get-started/first-app-csharp-apphost.mdx
index 39b266693..93b2bcbd1 100644
--- a/src/frontend/src/content/docs/get-started/first-app-csharp-apphost.mdx
+++ b/src/frontend/src/content/docs/get-started/first-app-csharp-apphost.mdx
@@ -71,7 +71,7 @@ architecture-beta
 
 ## Create a new app
 
-To create your first Aspire application, use the [Aspire CLI](/get-started/install-cli/) to generate a new solution from a _starter_ template. These template include multiple projects, such as an API service, a web frontend, and an [Aspire AppHost](/get-started/app-host/).
+To create your first Aspire application, use the [Aspire CLI](/get-started/install-cli/) to generate a new solution from a _starter_ template. These template include multiple projects, such as an API service, a web front end, and an [Aspire AppHost](/get-started/app-host/).
 
 <Steps>
 
@@ -91,7 +91,7 @@ To create your first Aspire application, use the [Aspire CLI](/get-started/insta
     </Pivot>
     
 
-    The template provides several projects, including an API service, web frontend, and AppHost.
+    The template provides several projects, including an API service, web front end, and AppHost.
 
     <Aside type='tip' title='CLI flags' icon='list-format'>
     The following flags are used in the command:
@@ -204,9 +204,9 @@ To create your first Aspire application, use the [Aspire CLI](/get-started/insta
     _What's happening here?_
 
     - `CreateBuilder` creates the distributed application builder
-    - `AddProject` registers your API service and web frontend
+    - `AddProject` registers your API service and web front end
     - `WithReference` connects services—it injects the API's URL as an environment variable and sets up service discovery so you can use service names instead of hardcoded URLs
-    - `WaitFor` ensures the API is healthy before starting the frontend, preventing connection errors from race conditions
+    - `WaitFor` ensures the API is healthy before starting the front end, preventing connection errors from race conditions
     - `WithHttpHealthCheck` monitors service health
     
     </Pivot>
@@ -236,10 +236,10 @@ To create your first Aspire application, use the [Aspire CLI](/get-started/insta
     
     - `AddUvicornApp` adds a Uvicorn-based Python app
     - `AddUv` adds a Uv environment setup task: `uv sync`
-    - `AddViteApp` registers your React frontend
-    - `WithReference` connects the frontend to the API—it injects the API's URL and sets up service discovery
-    - `WaitFor` ensures the API is healthy before starting the frontend, preventing connection errors
-    - `PublishWithContainerFiles` bundles the frontend for production deployment
+    - `AddViteApp` registers your React front end
+    - `WithReference` connects the front end to the API—it injects the API's URL and sets up service discovery
+    - `WaitFor` ensures the API is healthy before starting the front end, preventing connection errors
+    - `PublishWithContainerFiles` bundles the front end for production deployment
 
     </Pivot>    
 
diff --git a/src/frontend/src/content/docs/get-started/first-app-typescript-apphost.mdx b/src/frontend/src/content/docs/get-started/first-app-typescript-apphost.mdx
index 9ad87e67b..9583caa4e 100644
--- a/src/frontend/src/content/docs/get-started/first-app-typescript-apphost.mdx
+++ b/src/frontend/src/content/docs/get-started/first-app-typescript-apphost.mdx
@@ -35,7 +35,7 @@ architecture-beta
 
 ## Create a new app
 
-To create your first Aspire application, use the [Aspire CLI](/get-started/install-cli/) to generate a new solution from a _starter_ template. These template include multiple projects, such as an API service, a web frontend, and an [Aspire AppHost](/get-started/app-host/).
+To create your first Aspire application, use the [Aspire CLI](/get-started/install-cli/) to generate a new solution from a _starter_ template. These template include multiple projects, such as an API service, a web front end, and an [Aspire AppHost](/get-started/app-host/).
 
 <Steps>
 
@@ -46,7 +46,7 @@ To create your first Aspire application, use the [Aspire CLI](/get-started/insta
     aspire new aspire-ts-starter -n aspire-app -o aspire-app
     ```
 
-    The template provides several projects, including an API service, web frontend, and AppHost.
+    The template provides several projects, including an API service, web front end, and AppHost.
 
     <Aside type='tip' title='CLI flags' icon='list-format'>
     The following flags are used in the command:
@@ -136,10 +136,10 @@ To create your first Aspire application, use the [Aspire CLI](/get-started/insta
 
     - `createBuilder` creates the distributed application builder
     - `addNodeApp` adds a Node.js application (the Express API)
-    - `addViteApp` registers your React frontend
-    - `withReference` connects the frontend to the API—it injects the API's URL and sets up service discovery
-    - `waitFor` ensures the API is running before starting the frontend, preventing connection errors
-    - `publishWithContainerFiles` bundles the frontend for production deployment
+    - `addViteApp` registers your React front end
+    - `withReference` connects the front end to the API—it injects the API's URL and sets up service discovery
+    - `waitFor` ensures the API is running before starting the front end, preventing connection errors
+    - `publishWithContainerFiles` bundles the front end for production deployment
 
     <LearnMore>
     This template uses a TypeScript AppHost. To learn more about how multi-language AppHosts work, see [Multi-language architecture](/architecture/multi-language-architecture/).
diff --git a/src/frontend/src/content/docs/get-started/glossary.mdx b/src/frontend/src/content/docs/get-started/glossary.mdx
index 34fd82c63..b25a85c18 100644
--- a/src/frontend/src/content/docs/get-started/glossary.mdx
+++ b/src/frontend/src/content/docs/get-started/glossary.mdx
@@ -52,7 +52,7 @@ Resources are the building blocks you compose in your AppHost.
 
 A **distributed application** is an application split into multiple independent services that communicate over a network. Instead of one monolithic application, you have:
 
-- A frontend service
+- A front-end service
 - One or more API services  
 - Databases
 - Caches
diff --git a/src/frontend/src/content/docs/get-started/troubleshooting.mdx b/src/frontend/src/content/docs/get-started/troubleshooting.mdx
index e5de9f977..4856e9976 100644
--- a/src/frontend/src/content/docs/get-started/troubleshooting.mdx
+++ b/src/frontend/src/content/docs/get-started/troubleshooting.mdx
@@ -70,7 +70,7 @@ Having issues getting started with Aspire? This page covers solutions to the mos
 
 ## "Connection refused" errors
 
-**Symptoms**: Your frontend can't connect to the API, showing connection refused errors.
+**Symptoms**: Your front end can't connect to the API, showing connection refused errors.
 
 **Solution**: Make sure you're using `WaitFor()` in your AppHost:
 
diff --git a/src/frontend/src/content/docs/integrations/devtools/k6.mdx b/src/frontend/src/content/docs/integrations/devtools/k6.mdx
index fe938c1c4..2464d7cf7 100644
--- a/src/frontend/src/content/docs/integrations/devtools/k6.mdx
+++ b/src/frontend/src/content/docs/integrations/devtools/k6.mdx
@@ -109,7 +109,7 @@ var k6 = builder.AddK6("k6", enableBrowserExtensions: true)
 // After adding all resources, run the app...
 ```
 
-The browser module brings browser automation and end-to-end web testing to k6 while supporting core k6 features. It adds browser-level APIs to interact with browsers and collect frontend performance metrics as part of your k6 tests.
+The browser module brings browser automation and end-to-end web testing to k6 while supporting core k6 features. It adds browser-level APIs to interact with browsers and collect front-end performance metrics as part of your k6 tests.
 
 For more information on how to use Grafana k6 browser, see the [Using k6 browser](https://grafana.com/docs/k6/latest/using-k6-browser/).
 
diff --git a/src/frontend/src/content/docs/integrations/dotnet/project-resources.mdx b/src/frontend/src/content/docs/integrations/dotnet/project-resources.mdx
index f7a5cf5ff..0d073baa6 100644
--- a/src/frontend/src/content/docs/integrations/dotnet/project-resources.mdx
+++ b/src/frontend/src/content/docs/integrations/dotnet/project-resources.mdx
@@ -207,7 +207,7 @@ The following diagram shows this setup:
 
 <Image
   src={proxyWithReplicas}
-  alt="Aspire frontend app networking diagram with specific host port and two replicas."
+  alt="Aspire front-end app networking diagram with specific host port and two replicas."
 />
 
 With that configuration:
@@ -226,7 +226,7 @@ builder.AddProject<Projects.Networking_Frontend>("frontend")
 
 <Image
   src={proxyHostPortAndRandomPort}
-  alt="Aspire frontend app networking diagram with specific host port and random port."
+  alt="Aspire front-end app networking diagram with specific host port and random port."
 />
 
 In this configuration:
@@ -244,7 +244,7 @@ builder.AddProject<Projects.Networking_Frontend>("frontend")
 
 <Image
   src={proxyWithRandomPorts}
-  alt="Aspire frontend app networking diagram with random host port and proxy port."
+  alt="Aspire front-end app networking diagram with random host port and proxy port."
 />
 
 In this configuration, Aspire assigns a random proxy port for the host-facing endpoint and a separate random internal port for the project.
diff --git a/src/frontend/src/content/docs/integrations/frameworks/javascript.mdx b/src/frontend/src/content/docs/integrations/frameworks/javascript.mdx
index 1c4b826b7..91827dec9 100644
--- a/src/frontend/src/content/docs/integrations/frameworks/javascript.mdx
+++ b/src/frontend/src/content/docs/integrations/frameworks/javascript.mdx
@@ -120,7 +120,7 @@ Do _not_ call `.WithHttpEndpoint()` on a Vite resource. `AddViteApp` already reg
 
 :::note
 The Vite dev server is only used for local development. During publish, Aspire
-builds the frontend assets, but another resource must serve those built files in
+builds the front-end assets, but another resource must serve those built files in
 production.
 :::
 
@@ -376,10 +376,10 @@ export async function fetchData() {
   `import.meta.env` variables are replaced at **build time** by Vite. For
   dynamic runtime values (such as a URL that changes per environment), consider
   using a server-rendered configuration endpoint instead. See [Pass runtime
-  configuration to SPA frontends](#pass-runtime-configuration-to-spa-frontends).
+  configuration to SPA front ends](#pass-runtime-configuration-to-spa-frontends).
 </Aside>
 
-## Pass runtime configuration to SPA frontends
+## Pass runtime configuration to SPA front ends
 
 Vite and other SPA build tools bake environment variables (such as `VITE_*`) into the JavaScript bundle at **build time** (for example, when building the client for production). However, Aspire sets environment variables at **runtime**. This means calling `.WithEnvironment("VITE_GOOGLE_CLIENT_ID", parameter)` on a Vite resource won't change values that were already baked into a previously built production bundle.
 
@@ -389,7 +389,7 @@ To bridge this gap, pass the parameter to your API project as a standard environ
 
 1. **Pass the parameter to the API in the AppHost**
 
-   Define the parameter in the AppHost and pass it to the API project using `WithEnvironment`. Then reference the API from the frontend so it can call the endpoint:
+   Define the parameter in the AppHost and pass it to the API project using `WithEnvironment`. Then reference the API from the front end so it can call the endpoint:
 
    ```csharp title="C# — AppHost.cs"
    var builder = DistributedApplication.CreateBuilder(args);
@@ -427,12 +427,12 @@ To bridge this gap, pass the parameter to your API project as a standard environ
 
      Use this pattern only for non-secret/public configuration values (for
      example OAuth client IDs). Do not expose secrets such as client secrets,
-     API keys, or connection strings via a frontend config endpoint.
+     API keys, or connection strings via a front-end config endpoint.
    </Aside>
 
 3. **Fetch the config value in the SPA**
 
-   In your frontend application, fetch the configuration value at startup instead of reading from `import.meta.env`:
+   In your front-end application, fetch the configuration value at startup instead of reading from `import.meta.env`:
 
    ```typescript title="TypeScript — config.ts"
    export async function getConfig() {
@@ -519,32 +519,32 @@ When you publish your application, Aspire automatically:
 1. Generates publish-time build artifacts for containerized deployment
 2. Installs dependencies using deterministic install commands based on lockfiles
 3. Runs the build script (typically "build") to create production assets
-4. Produces frontend build output that another resource can include or serve
+4. Produces front-end build output that another resource can include or serve
 
 This ensures your JavaScript applications are built consistently across
 environments and can participate in Aspire publishing workflows.
 
 :::caution[Production deployment rule]
 `AddJavaScriptApp` and `AddViteApp` are not, by themselves, the production web
-server for your frontend.
+server for your front end.
 
-During publish, Aspire uses them to build frontend assets. To deploy that
-frontend, you must choose another resource to serve those built files in
+During publish, Aspire uses them to build front-end assets. To deploy that
+front end, you must choose another resource to serve those built files in
 production.
 
 Adding `AddJavaScriptApp` or `AddViteApp` plus `.WithReference(...)` is not
-enough to make the frontend independently deployable.
+enough to make the front end independently deployable.
 :::
 
 :::note
 Local Vite proxy and route behavior does not automatically become production
-behavior. If your frontend depends on Vite development-server routing or proxy
+behavior. If your front end depends on Vite development-server routing or proxy
 configuration, configure the production-serving resource separately.
 :::
 
 <LearnMore>
   For the production deployment patterns used by `AddJavaScriptApp` and
-  `AddViteApp`, including who serves the built frontend in production, see
+  `AddViteApp`, including who serves the built front end in production, see
   [Deploy JavaScript apps](/deployment/javascript-apps/).
 </LearnMore>
 
diff --git a/src/frontend/src/content/docs/integrations/reverse-proxies/yarp.mdx b/src/frontend/src/content/docs/integrations/reverse-proxies/yarp.mdx
index a17a8c84b..7370dbd82 100644
--- a/src/frontend/src/content/docs/integrations/reverse-proxies/yarp.mdx
+++ b/src/frontend/src/content/docs/integrations/reverse-proxies/yarp.mdx
@@ -162,7 +162,7 @@ var staticServer = builder.AddYarp("static")
                           .WithStaticFiles("../static");
 ```
 
-For building frontend applications, you can use a Docker multi-stage build:
+For building front-end applications, you can use a Docker multi-stage build:
 
 ```csharp title="C# — AppHost.cs"
 var builder = DistributedApplication.CreateBuilder(args);
diff --git a/src/frontend/src/content/docs/whats-new/aspire-13-1.mdx b/src/frontend/src/content/docs/whats-new/aspire-13-1.mdx
index 32dd8e4a7..e54a88503 100644
--- a/src/frontend/src/content/docs/whats-new/aspire-13-1.mdx
+++ b/src/frontend/src/content/docs/whats-new/aspire-13-1.mdx
@@ -26,7 +26,7 @@ This release introduces:
 - **Dashboard improvements**: Dedicated Parameters tab and GenAI visualizer enhancements.
 - **Azure Managed Redis**: Renamed from `AddAzureRedisEnterprise` to `AddAzureManagedRedis` with improved validation.
 - **Container registry support**: New `ContainerRegistryResource` for general-purpose container registries.
-- **JavaScript improvements**: New frontend starter template, Vite HTTPS configuration, and pnpm fixes.
+- **JavaScript improvements**: New front-end starter template, Vite HTTPS configuration, and pnpm fixes.
 - **DevTunnels stabilization**: [📦 Aspire.Hosting.DevTunnels](https://www.nuget.org/packages/Aspire.Hosting.DevTunnels) is now a stable package.
 - **TLS termination support**: New APIs for configuring HTTPS certificates on containers and resources.
 - **Connection properties for Azure resources**: Multi-language support for Azure resource connection strings.
@@ -335,11 +335,11 @@ builder.AddDockerComposeEnvironment("compose")
 Learn more about the [Docker Compose integration](/integrations/compute/docker/).
 </LearnMore>
 
-## 🌐 JavaScript and frontend support
+## 🌐 JavaScript and front-end support
 
-### JavaScript frontend starter template
+### JavaScript front-end starter template
 
-A new `aspire-ts-cs-starter` template provides a ready-to-use JavaScript frontend setup:
+A new `aspire-ts-cs-starter` template provides a ready-to-use JavaScript front-end setup:
 
 ```bash title="Aspire CLI — Starter App ASP.NET Core/React"
 aspire new aspire-ts-cs-starter
@@ -356,7 +356,7 @@ The template uses `npm` by default. You can switch to `yarn` or `pnpm` after pro
 :::
 
 <LearnMore>
-Learn more about the [JavaScript frontend integration](/integrations/frameworks/javascript/).
+Learn more about the [JavaScript front-end integration](/integrations/frameworks/javascript/).
 </LearnMore>
 
 ### Vite HTTPS configuration
diff --git a/src/frontend/src/content/docs/whats-new/aspire-13.mdx b/src/frontend/src/content/docs/whats-new/aspire-13.mdx
index 838055a62..3b6650343 100644
--- a/src/frontend/src/content/docs/whats-new/aspire-13.mdx
+++ b/src/frontend/src/content/docs/whats-new/aspire-13.mdx
@@ -348,10 +348,10 @@ aspire new aspire-py-starter
 This template includes:
 
 - **FastAPI backend**: Python ASGI application using Uvicorn.
-- **Vite + React frontend**: Modern JavaScript frontend with TypeScript.
+- **Vite + React front end**: Modern JavaScript front end with TypeScript.
 - **OpenTelemetry integration**: Distributed tracing, logs, and metrics.
 - **Redis caching** (optional): A distributed cache across requests.
-- **Container files**: Frontend static files served by the Python backend.
+- **Container files**: Front-end static files served by the Python backend.
 
 Build a full-stack multi-language app—Python back end + JavaScript front end—fast. Explore it, customize it, ship it. [Create one now](/get-started/first-app-csharp-apphost/?lang=python) and [deploy it today](/get-started/deploy-first-app-csharp/?lang=python)!
 
@@ -663,7 +663,7 @@ Select a template:
 
 **Available starter templates:**
 
-- [**Blazor & Minimal API starter**](/get-started/first-app-csharp-apphost/?lang=csharp): Full-stack .NET application with Blazor frontend and ASP.NET Core API.
+- [**Blazor & Minimal API starter**](/get-started/first-app-csharp-apphost/?lang=csharp): Full-stack .NET application with Blazor front end and ASP.NET Core API.
 - [**React (Vite) & FastAPI starter**](/get-started/first-app-csharp-apphost/?lang=python): Multi-language application demonstrating Python and JavaScript integration.
 - **Empty AppHost**: Minimal single-file AppHost for custom applications.
 
@@ -852,7 +852,7 @@ aspire do deploy --log-level debug            # Verbose logging for troubleshoot
 
 ### Container files as build artifacts
 
-Aspire 13.0 introduces the ability to **extract files from one resource's container and copy them into another resource's container** during the build process. This enables powerful patterns like building a frontend in one container and serving it from a backend in another container.
+Aspire 13.0 introduces the ability to **extract files from one resource's container and copy them into another resource's container** during the build process. This enables powerful patterns like building a front end in one container and serving it from a backend in another container.
 
 ```csharp title="C# — Container files as build artifacts"
 var frontend = builder.AddViteApp("frontend", "./frontend");
@@ -866,11 +866,11 @@ api.PublishWithContainerFiles(frontend, "./static");
 **How it works:**
 
 1. The `frontend` resource builds inside its container, producing output files.
-2. Aspire extracts those files from the frontend container.
+2. Aspire extracts those files from the `frontend` container.
 3. The files are copied into the `api` container at `./static`.
-4. The final `api` container contains both the API code and the frontend static files.
+4. The final `api` container contains both the API code and the front-end static files.
 
-**Example: Serving frontend from backend**
+**Example: Serving front end from backend**
 
 The FastAPI app can serve the static files:
 
diff --git a/src/frontend/src/content/docs/whats-new/aspire-9-3.mdx b/src/frontend/src/content/docs/whats-new/aspire-9-3.mdx
index d17036d0a..13407b94f 100644
--- a/src/frontend/src/content/docs/whats-new/aspire-9-3.mdx
+++ b/src/frontend/src/content/docs/whats-new/aspire-9-3.mdx
@@ -245,7 +245,7 @@ For more details on requirements and how to get started, see [GitHub Copilot in
 
 ### 🧠 Remembers your filter settings
 
-The Aspire dashboard now **remembers your resource filter settings** between sessions. Previously, if you filtered the Resources view (for example, to hide support services or highlight only frontend apps), those filters were reset on page reload.
+The Aspire dashboard now **remembers your resource filter settings** between sessions. Previously, if you filtered the Resources view (for example, to hide support services or highlight only front-end apps), those filters were reset on page reload.
 
 As of 9.3, filter state is **persisted in local storage**, so your selections stick across refreshes and restarts. This small improvement makes it easier to focus on the parts of your app that matter most—especially in large graphs with many supporting services like Redis, SQL, or queues.
 
@@ -354,10 +354,10 @@ builder.AddProject<Projects.Frontend>("frontend")
        .WithComputeEnvironment(k8s);
 ```
 
-This (contrived) example shows how you could explicitly map services to different compute targets—modeling, for example, a frontend in Kubernetes and a backend in Docker Compose.
+This (contrived) example shows how you could explicitly map services to different compute targets—modeling, for example, a front end in Kubernetes and a backend in Docker Compose.
 
 <Aside type="note">
-💡 Imagine a real-world case where your frontend is deployed to a CDN or GitHub Pages, and your backend runs in Azure Container Apps. This new model makes that future possible.
+💡 Imagine a real-world case where your front end is deployed to a CDN or GitHub Pages, and your backend runs in Azure Container Apps. This new model makes that future possible.
 </Aside>
 
 ⚠️ All previous publisher registration APIs (like `AddDockerComposePublisher()`) have been removed in favor of this new model.
diff --git a/src/frontend/src/content/docs/whats-new/aspire-9-5.mdx b/src/frontend/src/content/docs/whats-new/aspire-9-5.mdx
index 8b63f6475..c2840aaf2 100644
--- a/src/frontend/src/content/docs/whats-new/aspire-9-5.mdx
+++ b/src/frontend/src/content/docs/whats-new/aspire-9-5.mdx
@@ -375,7 +375,7 @@ The Dev Tunnels integration automatically handles Azure authentication, tunnel l
 
 ### YARP static files support
 
-Aspire 9.5 adds comprehensive static file serving capabilities to the YARP integration, enabling you to serve static assets directly from YARP alongside reverse proxy functionality. This is perfect for single-page applications, frontend assets, and hybrid scenarios where you need both static content and API proxying.
+Aspire 9.5 adds comprehensive static file serving capabilities to the YARP integration, enabling you to serve static assets directly from YARP alongside reverse proxy functionality. This is perfect for single-page applications, front-end assets, and hybrid scenarios where you need both static content and API proxying.
 
 **Features:**
 
@@ -436,7 +436,7 @@ var gateway = builder.AddYarp("app-gateway")
 builder.Build().Run();
 ```
 
-This feature enables modern web application architectures where YARP acts as both a reverse proxy for backend services and a static file server for frontend assets, providing a unified entry point for your distributed application.
+This feature enables modern web application architectures where YARP acts as both a reverse proxy for backend services and a static file server for front-end assets, providing a unified entry point for your distributed application.
 
 For more information, see [Aspire YARP integration](https://aspire.dev/integrations/reverse-proxies/yarp/).
 
diff --git a/src/frontend/src/content/i18n/en.json b/src/frontend/src/content/i18n/en.json
index 90f8ede55..745b8d4c9 100644
--- a/src/frontend/src/content/i18n/en.json
+++ b/src/frontend/src/content/i18n/en.json
@@ -89,7 +89,7 @@
     "api": "API service",
     "container": "Container",
     "deploy": "Deployment options",
-    "frontendTooltip": "Toggle an example front end setup",
+    "frontendTooltip": "Toggle an example front-end setup",
     "databaseTooltip": "Toggle an example database setup",
     "apiTooltip": "Toggle an example API setup",
     "containerTooltip": "Toggle an example container setup",

From 95e9d461e2ec8317c856a129dc579f4422cd8ed7 Mon Sep 17 00:00:00 2001
From: AJ Matthews <alistair.matthews@civica.co.uk>
Date: Wed, 8 Apr 2026 10:55:06 +0100
Subject: [PATCH 2/3] Replaced with 'frontend' throughout.

---
 .../app-host/certificate-configuration.mdx    |   2 +-
 .../content/docs/app-host/configuration.mdx   |   2 +-
 .../content/docs/app-host/container-files.mdx |  12 +-
 .../docs/app-host/executable-resources.mdx    |   4 +-
 .../app-host/migrate-from-docker-compose.mdx  |   4 +-
 .../content/docs/architecture/overview.mdx    |   6 +-
 .../architecture/resource-hierarchies.mdx     |   4 +-
 .../docs/architecture/resource-model.mdx      |   2 +-
 .../docs/community/contributor-guide.mdx      |   2 +-
 .../src/content/docs/community/thanks.mdx     |   6 +-
 .../src/content/docs/community/videos.mdx     |   2 +-
 .../content/docs/dashboard/configuration.mdx  |   8 +-
 .../src/content/docs/dashboard/explore.mdx    |   4 +-
 .../src/content/docs/dashboard/index.mdx      |   2 +-
 .../src/content/docs/dashboard/overview.mdx   |   4 +-
 .../dashboard/security-considerations.mdx     |   6 +-
 .../docs/dashboard/standalone-for-python.mdx  |   2 +-
 .../docs/deployment/javascript-apps.mdx       | 122 +++++++++---------
 .../src/content/docs/deployment/overview.mdx  |   2 +-
 .../src/content/docs/deployment/pipelines.mdx |  14 +-
 .../docs/fundamentals/networking-overview.mdx |   8 +-
 .../docs/fundamentals/service-discovery.mdx   |   4 +-
 ...add-aspire-existing-app-csharp-apphost.mdx |   4 +-
 ...aspire-existing-app-typescript-apphost.mdx |   6 +-
 .../src/content/docs/get-started/app-host.mdx |  86 ++++++------
 .../docs/get-started/aspire-sdk-templates.mdx |   8 +-
 .../get-started/deploy-first-app-csharp.mdx   |  20 +--
 .../deploy-first-app-typescript.mdx           |   8 +-
 .../get-started/first-app-csharp-apphost.mdx  |  24 ++--
 .../first-app-typescript-apphost.mdx          |  16 +--
 .../src/content/docs/get-started/glossary.mdx |   4 +-
 .../docs/get-started/troubleshooting.mdx      |   2 +-
 src/frontend/src/content/docs/id/index.mdx    |   4 +-
 src/frontend/src/content/docs/index.mdx       |   4 +-
 .../content/docs/integrations/devtools/k6.mdx |   2 +-
 .../integrations/dotnet/project-resources.mdx |   6 +-
 .../integrations/frameworks/javascript.mdx    |  26 ++--
 .../docs/integrations/frameworks/orleans.mdx  |   2 +-
 .../integrations/reverse-proxies/yarp.mdx     |   2 +-
 src/frontend/src/content/docs/it/index.mdx    |   4 +-
 .../content/docs/ja/get-started/app-host.mdx  |  20 +--
 .../docs/ja/get-started/deploy-first-app.mdx  |   6 +-
 .../content/docs/ja/get-started/first-app.mdx |   8 +-
 .../src/content/docs/ja/testing/overview.mdx  |   8 +-
 .../src/content/docs/testing/overview.mdx     |   8 +-
 .../content/docs/whats-new/aspire-13-1.mdx    |  10 +-
 .../src/content/docs/whats-new/aspire-13.mdx  |  18 +--
 .../src/content/docs/whats-new/aspire-9-3.mdx |   6 +-
 .../src/content/docs/whats-new/aspire-9-5.mdx |   4 +-
 src/frontend/src/content/i18n/en.json         |   2 +-
 50 files changed, 270 insertions(+), 270 deletions(-)

diff --git a/src/frontend/src/content/docs/app-host/certificate-configuration.mdx b/src/frontend/src/content/docs/app-host/certificate-configuration.mdx
index c7c2fc9fb..4488c8e01 100644
--- a/src/frontend/src/content/docs/app-host/certificate-configuration.mdx
+++ b/src/frontend/src/content/docs/app-host/certificate-configuration.mdx
@@ -10,7 +10,7 @@ Aspire provides two complementary sets of certificate APIs:
 1. **HTTPS endpoint APIs**: Configure the certificates that resources use for their own HTTPS endpoints (server authentication)
 2. **Certificate trust APIs**: Configure which certificates resources trust when making outbound HTTPS connections (client authentication)
 
-Both sets of APIs work together to enable secure HTTPS communication during local development. For example, a Vite front end might use `WithHttpsDeveloperCertificate` to serve HTTPS traffic, while also using `WithDeveloperCertificateTrust` to trust the dashboard's OTLP endpoint certificate.
+Both sets of APIs work together to enable secure HTTPS communication during local development. For example, a Vite frontend might use `WithHttpsDeveloperCertificate` to serve HTTPS traffic, while also using `WithDeveloperCertificateTrust` to trust the dashboard's OTLP endpoint certificate.
 
 <Aside type="caution">
   Certificate customization only applies at run time. Custom certificates aren't
diff --git a/src/frontend/src/content/docs/app-host/configuration.mdx b/src/frontend/src/content/docs/app-host/configuration.mdx
index 95f73d5da..a0ebfecec 100644
--- a/src/frontend/src/content/docs/app-host/configuration.mdx
+++ b/src/frontend/src/content/docs/app-host/configuration.mdx
@@ -115,7 +115,7 @@ By default, the dashboard is automatically started by the AppHost. The dashboard
 | `ASPIRE_DASHBOARD_OTLP_HTTP_ENDPOINT_URL`   | `null`                                                      | Configures the dashboard OTLP HTTP address. Used by the dashboard to receive telemetry over OTLP. If only `ASPIRE_DASHBOARD_OTLP_HTTP_ENDPOINT_URL` is configured then it is set on resources as the `OTEL_EXPORTER_OTLP_ENDPOINT` env var. The `OTEL_EXPORTER_OTLP_PROTOCOL` env var is `http/protobuf`.      |
 | `ASPIRE_DASHBOARD_CORS_ALLOWED_ORIGINS`     | `null`                                                      | Overrides the CORS allowed origins configured in the dashboard. This setting replaces the default behavior of calculating allowed origins based on resource endpoints.                                                                                                                                         |
 | `ASPIRE_DASHBOARD_UNSECURED_ALLOW_ANONYMOUS`| `false`                                                     | Configures the dashboard to not use authentication and accept anonymous access. Sets frontend, OTLP, MCP, and API auth modes to `Unsecured`.                                                                                                                                                                  |
-| `ASPIRE_DASHBOARD_FRONTEND_BROWSERTOKEN`    | Automatically generated 128-bit entropy token.              | Configures the front-end browser token. This is the value that must be entered to access the dashboard when the auth mode is BrowserToken. If no browser token is specified then a new token is generated each time the AppHost is launched.                                                                    |
+| `ASPIRE_DASHBOARD_FRONTEND_BROWSERTOKEN`    | Automatically generated 128-bit entropy token.              | Configures the frontend browser token. This is the value that must be entered to access the dashboard when the auth mode is BrowserToken. If no browser token is specified then a new token is generated each time the AppHost is launched.                                                                    |
 | `ASPIRE_DASHBOARD_TELEMETRY_OPTOUT`         | `false`                                                     | Configures the dashboard to never send [usage telemetry](/dashboard/microsoft-collected-dashboard-telemetry/).                                                                                                                                                                                                 |
 | `ASPIRE_DASHBOARD_AI_DISABLED`              | `false`                                                     | [GitHub Copilot in the dashboard](/dashboard/copilot/) is available when the AppHost is launched by a supported IDE. When set to `true` Copilot is disabled in the dashboard and no Copilot UI is visible.                                                                                                     |
 | `ASPIRE_DASHBOARD_API_ENABLED`              | `true`                                                      | Enables the dashboard [telemetry API](/dashboard/configuration/#api) (`/api/telemetry/*`) endpoints. The AppHost always sets this to `true`.                                                                                                                                                                   |
diff --git a/src/frontend/src/content/docs/app-host/container-files.mdx b/src/frontend/src/content/docs/app-host/container-files.mdx
index e6f766d40..789795d33 100644
--- a/src/frontend/src/content/docs/app-host/container-files.mdx
+++ b/src/frontend/src/content/docs/app-host/container-files.mdx
@@ -340,9 +340,9 @@ For containers with `ContainerLifetime.Persistent`, changing the contents of con
 
 The `PublishWithContainerFiles` method copies files from one resource's container into another resource's container during `aspire publish`. This is the preferred approach for injecting files into containers at publish time.
 
-A key use case is embedding single-page application (SPA) or static JavaScript front ends into a reverse proxy or web server container for production deployment. During development, front-end apps like Vite or React typically run as standalone dev servers. In production, however, the compiled static assets are often served by a backend API or a dedicated web server like Nginx. `PublishWithContainerFiles` bridges this gap by copying the built front-end output into the serving container as part of the publish process — no manual file copying or multi-stage Dockerfile required.
+A key use case is embedding single-page application (SPA) or static JavaScript frontends into a reverse proxy or web server container for production deployment. During development, frontend apps like Vite or React typically run as standalone dev servers. In production, however, the compiled static assets are often served by a backend API or a dedicated web server like Nginx. `PublishWithContainerFiles` bridges this gap by copying the built frontend output into the serving container as part of the publish process — no manual file copying or multi-stage Dockerfile required.
 
-### Embed a front end in a backend
+### Embed a frontend in a backend
 
 <Tabs syncKey="apphost-lang">
 <TabItem label="C#">
@@ -377,11 +377,11 @@ In this example:
 
 1. The `frontend` resource builds inside its container, producing compiled JavaScript, CSS, and HTML.
 2. During publish, Aspire copies those files from the `frontend` container into the `api` container at `./wwwroot`.
-3. The resulting `api` container includes both the API code and the front-end static assets, ready to serve the full application.
+3. The resulting `api` container includes both the API code and the frontend static assets, ready to serve the full application.
 
-### Serve a front end from YARP
+### Serve a frontend from YARP
 
-You can also embed front-end assets into a dedicated reverse proxy container:
+You can also embed frontend assets into a dedicated reverse proxy container:
 
 <Tabs syncKey="apphost-lang">
 <TabItem label="C#">
@@ -412,7 +412,7 @@ await builder.build().run();
 </TabItem>
 </Tabs>
 
-This produces a self-contained Nginx container that serves the front-end application, with no external volume mounts or runtime file copying needed.
+This produces a self-contained Nginx container that serves the frontend application, with no external volume mounts or runtime file copying needed.
 
 `PublishWithContainerFiles` only applies in publish mode — it has no effect during `aspire run`. The destination resource must implement `IContainerFilesDestinationResource` (such as `ProjectResource`), and the source resource must implement `IResourceWithContainerFiles`.
 
diff --git a/src/frontend/src/content/docs/app-host/executable-resources.mdx b/src/frontend/src/content/docs/app-host/executable-resources.mdx
index f8ed6a3fd..c068d9a52 100644
--- a/src/frontend/src/content/docs/app-host/executable-resources.mdx
+++ b/src/frontend/src/content/docs/app-host/executable-resources.mdx
@@ -18,7 +18,7 @@ Use executable resources when you need to:
 
 Common examples include:
 
-- **Front-end development servers**: Tools like [Vercel CLI](https://vercel.com/docs/cli) or webpack dev server.
+- **Frontend development servers**: Tools like [Vercel CLI](https://vercel.com/docs/cli) or webpack dev server.
 - **Language-specific applications**: Node.js apps, Python scripts, or Go applications.
 - **Database tools**: Migration utilities or database seeders.
 - **Build tools**: Asset processors or code generators.
@@ -163,7 +163,7 @@ const app = await builder.addExecutable("app", "node", ".", ["app.js"])
 
 ## Practical example: Vercel CLI
 
-Here's a complete example using the [Vercel CLI](https://vercel.com/docs/cli) to host a front-end application with a backend API:
+Here's a complete example using the [Vercel CLI](https://vercel.com/docs/cli) to host a frontend application with a backend API:
 
 <Tabs syncKey="apphost-lang">
 <TabItem label="C#">
diff --git a/src/frontend/src/content/docs/app-host/migrate-from-docker-compose.mdx b/src/frontend/src/content/docs/app-host/migrate-from-docker-compose.mdx
index a78925ed4..0904b0d7a 100644
--- a/src/frontend/src/content/docs/app-host/migrate-from-docker-compose.mdx
+++ b/src/frontend/src/content/docs/app-host/migrate-from-docker-compose.mdx
@@ -43,7 +43,7 @@ This section demonstrates practical migration scenarios you'll likely encounter
 
 ### Multi-service web application
 
-This example shows a typical three-tier application with a front end, API, and database.
+This example shows a typical three-tier application with a frontend, API, and database.
 
 **Docker Compose example:**
 
@@ -493,7 +493,7 @@ networks:
 Aspire doesn't have an equivalent for custom network isolation. Instead, Aspire automatically creates a shared container network for all container resources and uses service discovery to manage inter-service communication. All containers in an Aspire AppHost can reach each other by resource name. .NET projects and executables run on the host and access containers through injected host/port endpoints.
 
 <Aside type="note">
-If your Docker Compose setup relies on network isolation (for example, preventing a front-end service from directly accessing the database), Aspire doesn't provide a direct equivalent. Consider using application-level access controls or firewall rules in your deployment environment instead.
+If your Docker Compose setup relies on network isolation (for example, preventing a frontend service from directly accessing the database), Aspire doesn't provide a direct equivalent. Consider using application-level access controls or firewall rules in your deployment environment instead.
 </Aside>
 
 ## Migration strategy
diff --git a/src/frontend/src/content/docs/architecture/overview.mdx b/src/frontend/src/content/docs/architecture/overview.mdx
index c3877acf6..45fe84e4b 100644
--- a/src/frontend/src/content/docs/architecture/overview.mdx
+++ b/src/frontend/src/content/docs/architecture/overview.mdx
@@ -43,14 +43,14 @@ Why is modality important when it comes to the AppHost's execution context? This
 - Database: PostgreSQL
 - Cache: Redis
 - AI service: Ollama or OpenAI
-- Back end: ASP.NET Core minimal API
-- Front end: React app
+- Backend: ASP.NET Core minimal API
+- Frontend: React app
 
 Depending on the mode, the AppHost might treat these resources differently. For example, in run mode, the AppHost might use a local PostgreSQL database and Redis cache—using containers, while in publish mode, it might generate deployment artifacts for Azure PostgreSQL and Redis Cache.
 
 #### Run mode
 
-The default mode is run mode, which is ideal for local development and testing. In this mode, the Aspire AppHost orchestrates your application model, including processes, containers, and cloud emulators, to facilitate fast and iterative development. Resources behave like real runtime entities with lifecycles that mirror production. With a simple <kbd>F5</kbd>, the AppHost launches everything in your app model—storage, databases, caches, messaging, jobs, APIs, front ends—all fully configured and ready to debug locally. Let's considering the app model from the previous section—where AppHost would orchestrate the following resources locally:
+The default mode is run mode, which is ideal for local development and testing. In this mode, the Aspire AppHost orchestrates your application model, including processes, containers, and cloud emulators, to facilitate fast and iterative development. Resources behave like real runtime entities with lifecycles that mirror production. With a simple <kbd>F5</kbd>, the AppHost launches everything in your app model—storage, databases, caches, messaging, jobs, APIs, frontends—all fully configured and ready to debug locally. Let's considering the app model from the previous section—where AppHost would orchestrate the following resources locally:
 
 import ThemeImage from '@components/ThemeImage.astro';
 
diff --git a/src/frontend/src/content/docs/architecture/resource-hierarchies.mdx b/src/frontend/src/content/docs/architecture/resource-hierarchies.mdx
index de29276f6..74c908a35 100644
--- a/src/frontend/src/content/docs/architecture/resource-hierarchies.mdx
+++ b/src/frontend/src/content/docs/architecture/resource-hierarchies.mdx
@@ -100,8 +100,8 @@ Endpoints are modeled as **external entities**:
 
 - They are **not edges** in the resource dependency graph.
 - They enable realistic mutual references like:
-  - A front-end app and an OIDC server mutually referencing each other's URLs (redirects, login callbacks).
-  - A backend exposing CORS settings that reference the front-end URL.
+  - A frontend app and an OIDC server mutually referencing each other's URLs (redirects, login callbacks).
+  - A backend exposing CORS settings that reference the frontend URL.
 
 <Aside type="tip">
   Endpoints are managed separately from strict dependency edges to allow
diff --git a/src/frontend/src/content/docs/architecture/resource-model.mdx b/src/frontend/src/content/docs/architecture/resource-model.mdx
index 400b49ab9..9a37ed908 100644
--- a/src/frontend/src/content/docs/architecture/resource-model.mdx
+++ b/src/frontend/src/content/docs/architecture/resource-model.mdx
@@ -116,7 +116,7 @@ The preceding example:
 
 - A PostgreSQL server (`pg`) is created and configured with a database named `appdata`.
 - A backend service (`api`) is created and connected to the database.
-- A front-end app (`web`) is created and reverse-proxies traffic to the backend.
+- A frontend app (`web`) is created and reverse-proxies traffic to the backend.
 
 Each resource participates in the application graph passively, with dependencies expressed through references.
 
diff --git a/src/frontend/src/content/docs/community/contributor-guide.mdx b/src/frontend/src/content/docs/community/contributor-guide.mdx
index 29b866d03..7d41d0aab 100644
--- a/src/frontend/src/content/docs/community/contributor-guide.mdx
+++ b/src/frontend/src/content/docs/community/contributor-guide.mdx
@@ -112,7 +112,7 @@ Before you begin, ensure you have the following installed:
     pnpm dev
     ```
 
-    This starts the Vite development server for the front end and provide hot-reload capabilities.
+    This starts the Vite development server for the frontend and provide hot-reload capabilities.
 
 1. View the site locally
 
diff --git a/src/frontend/src/content/docs/community/thanks.mdx b/src/frontend/src/content/docs/community/thanks.mdx
index a04f847b1..d663c2560 100644
--- a/src/frontend/src/content/docs/community/thanks.mdx
+++ b/src/frontend/src/content/docs/community/thanks.mdx
@@ -880,7 +880,7 @@ Aspire speaks many languages — thanks to these communities.
       <LicenseBadge title={licenseTitles.nodejs} />
     </div>
     <p>
-      The JavaScript runtime that enables Aspire to orchestrate front-end and
+      The JavaScript runtime that enables Aspire to orchestrate frontend and
       full-stack JS apps.
     </p>
     <div class="thanks-card-links">
@@ -1016,7 +1016,7 @@ Aspire speaks many languages — thanks to these communities.
     </div>
     <p>
       The typed superset of JavaScript that powers Aspire's TypeScript AppHost
-      and front-end tooling.
+      and frontend tooling.
     </p>
     <div class="thanks-card-links">
       <a href="https://www.typescriptlang.org" class="thanks-link-project">
@@ -1285,7 +1285,7 @@ The tools that power this very website.
     </div>
     <p>
       The fast, disk-space efficient package manager that builds the aspire.dev
-      front end.
+      frontend.
     </p>
     <div class="thanks-card-links">
       <a href="https://pnpm.io" class="thanks-link-project">
diff --git a/src/frontend/src/content/docs/community/videos.mdx b/src/frontend/src/content/docs/community/videos.mdx
index 3a3047bec..4a2c00e91 100644
--- a/src/frontend/src/content/docs/community/videos.mdx
+++ b/src/frontend/src/content/docs/community/videos.mdx
@@ -200,7 +200,7 @@ export const communityVideos = [
     href: 'https://youtu.be/dftmYBuZOLA?list=PL2E-vlKoo_v2dgxPizLVtdxvurOHvd8_h&t=341',
     title: 'Microservices: Aspire & Blazor SSR',
     description:
-      'Codewrinkles builds a microservices app, orchestrated with Aspire and using Blazor SSR on the front end.',
+      'Codewrinkles builds a microservices app, orchestrated with Aspire and using Blazor SSR on the frontend.',
     tags: ['Community', 'Blazor', 'SSR'],
   },
   {
diff --git a/src/frontend/src/content/docs/dashboard/configuration.mdx b/src/frontend/src/content/docs/dashboard/configuration.mdx
index ffaa65c07..53d54b8cb 100644
--- a/src/frontend/src/content/docs/dashboard/configuration.mdx
+++ b/src/frontend/src/content/docs/dashboard/configuration.mdx
@@ -103,7 +103,7 @@ Alternatively, these same values could be configured using a JSON configuration
 
 | Option | Description |
 |--------|-------------|
-| `ASPNETCORE_URLS`<br/>Default: `http://localhost:18888` | One or more HTTP endpoints through which the dashboard front end is served. The front-end endpoint is used to view the dashboard in a browser. When the dashboard is launched by the Aspire AppHost this address is secured with HTTPS. Securing the dashboard with HTTPS is recommended. |
+| `ASPNETCORE_URLS`<br/>Default: `http://localhost:18888` | One or more HTTP endpoints through which the dashboard frontend is served. The frontend endpoint is used to view the dashboard in a browser. When the dashboard is launched by the Aspire AppHost this address is secured with HTTPS. Securing the dashboard with HTTPS is recommended. |
 | `ASPIRE_DASHBOARD_OTLP_ENDPOINT_URL`<br/>Default: `http://localhost:18889` | The [OTLP/gRPC](https://opentelemetry.io/docs/specs/otlp/#otlpgrpc) endpoint. This endpoint hosts an OTLP service and receives telemetry using gRPC. When the dashboard is launched by the Aspire AppHost this address is secured with HTTPS. Securing the dashboard with HTTPS is recommended. |
 | `ASPIRE_DASHBOARD_OTLP_HTTP_ENDPOINT_URL`<br/>Default: `http://localhost:18890` | The [OTLP/HTTP](https://opentelemetry.io/docs/specs/otlp/#otlphttp) endpoint. This endpoint hosts an OTLP service and receives telemetry using Protobuf over HTTP. When the dashboard is launched by the Aspire AppHost the OTLP/HTTP endpoint isn't configured by default. To configure an OTLP/HTTP endpoint with the AppHost, set an `ASPIRE_DASHBOARD_OTLP_HTTP_ENDPOINT_URL` env var value in _launchSettings.json_. Securing the dashboard with HTTPS is recommended. |
 | `ASPIRE_DASHBOARD_MCP_ENDPOINT_URL`<br/>Default: `http://localhost:18891` | The [Aspire MCP](/dashboard/mcp-server/) endpoint. When this value isn't specified then the MCP server is hosted with an `ASPNETCORE_URLS` endpoint. The MCP server can be disabled by configuring `Dashboard:Mcp:Disabled` to `true`. When the dashboard is launched by the Aspire AppHost this address is secured with HTTPS. Securing the dashboard with HTTPS is recommended. |
@@ -115,16 +115,16 @@ Alternatively, these same values could be configured using a JSON configuration
 
 ## Frontend
 
-The dashboard front-end endpoint authentication is configured with `Dashboard:Frontend:AuthMode`. The front end can be secured with OpenID Connect (OIDC) or browser token authentication.
+The dashboard frontend endpoint authentication is configured with `Dashboard:Frontend:AuthMode`. The frontend can be secured with OpenID Connect (OIDC) or browser token authentication.
 
-Browser token authentication works by the front end asking for a token. The token can either be entered in the UI or provided as a query string value to the login page. For example, `https://localhost:1234/login?t=TheToken`. When the token is successfully authenticated an auth cookie is persisted to the browser, and the browser is redirected to the app.
+Browser token authentication works by the frontend asking for a token. The token can either be entered in the UI or provided as a query string value to the login page. For example, `https://localhost:1234/login?t=TheToken`. When the token is successfully authenticated an auth cookie is persisted to the browser, and the browser is redirected to the app.
 
 | Option | Description |
 |--------|-------------|
 | `Dashboard:Frontend:AuthMode`<br/>Default: `BrowserToken` | Can be set to `BrowserToken`, `OpenIdConnect` or `Unsecured`. `Unsecured` should only be used during local development. It's not recommended when hosting the dashboard publicly or in other settings. |
 | `Dashboard:Frontend:BrowserToken`<br/>Default: `null` | Specifies the browser token. If the browser token isn't specified, then the dashboard generates one. Tooling that wants to automate logging in with browser token authentication can specify a token and open a browser with the token in the query string. A new token should be generated each time the dashboard is launched. |
 | `Dashboard:Frontend:MaxConsoleLogCount`<br/>Default: `10,000` | An optional limit on the number of console log messages to be retained in the viewer. When the limit is reached, the oldest messages are removed. |
-| `Dashboard:Frontend:PublicUrl`<br/>Default: `null` | Specifies the public URL used to access the dashboard front end. The public URL is used when constructing links to the dashboard front end. If a public URL isn't specified, the front-end endpoint is used instead. This setting is important when the dashboard is accessed through a proxy and the dashboard endpoint isn't directly reachable. |
+| `Dashboard:Frontend:PublicUrl`<br/>Default: `null` | Specifies the public URL used to access the dashboard frontend. The public URL is used when constructing links to the dashboard frontend. If a public URL isn't specified, the frontend endpoint is used instead. This setting is important when the dashboard is accessed through a proxy and the dashboard endpoint isn't directly reachable. |
 | `Dashboard:Frontend:OpenIdConnect:NameClaimType`<br/>Default: `name` | Specifies one or more claim types that should be used to display the authenticated user's full name. Can be a single claim type or a comma-delimited list of claim types. |
 | `Dashboard:Frontend:OpenIdConnect:UsernameClaimType`<br/>Default: `preferred_username` | Specifies one or more claim types that should be used to display the authenticated user's username. Can be a single claim type or a comma-delimited list of claim types. |
 | `Dashboard:Frontend:OpenIdConnect:RequiredClaimType`<br/>Default: `null` | Specifies the claim that must be present for authorized users. Authorization fails without this claim. This value is optional. |
diff --git a/src/frontend/src/content/docs/dashboard/explore.mdx b/src/frontend/src/content/docs/dashboard/explore.mdx
index a5f664a64..494592de6 100644
--- a/src/frontend/src/content/docs/dashboard/explore.mdx
+++ b/src/frontend/src/content/docs/dashboard/explore.mdx
@@ -121,8 +121,8 @@ You can also obtain the login token from the container logs. For more informatio
 
 The **Resources** page is the default home page of the Aspire dashboard. This page lists all of the projects, containers, and executables included in your Aspire solution. For example, the starter application includes two projects:
 
-- **apiservice**: A back-end API project built using Minimal APIs.
-- **webfrontend**: The front-end UI project built using Blazor.
+- **apiservice**: A backend API project built using Minimal APIs.
+- **webfrontend**: The frontend UI project built using Blazor.
 
 The dashboard also provides essential details about each resource:
 
diff --git a/src/frontend/src/content/docs/dashboard/index.mdx b/src/frontend/src/content/docs/dashboard/index.mdx
index 3a3055b8b..3a80211ad 100644
--- a/src/frontend/src/content/docs/dashboard/index.mdx
+++ b/src/frontend/src/content/docs/dashboard/index.mdx
@@ -211,7 +211,7 @@ Navigate to `http://localhost:18888` to open the dashboard, and point your apps'
       icon: 'random',
       title: 'Browser telemetry',
       description:
-        'Enable browser-based telemetry collection to capture front-end performance data alongside backend traces.',
+        'Enable browser-based telemetry collection to capture frontend performance data alongside backend traces.',
       href: '/dashboard/enable-browser-telemetry/',
       label: 'Enable telemetry',
       accent: 'green',
diff --git a/src/frontend/src/content/docs/dashboard/overview.mdx b/src/frontend/src/content/docs/dashboard/overview.mdx
index 548415ad3..7ae7275a8 100644
--- a/src/frontend/src/content/docs/dashboard/overview.mdx
+++ b/src/frontend/src/content/docs/dashboard/overview.mdx
@@ -64,13 +64,13 @@ For more information, see the [Standalone Aspire dashboard](/dashboard/standalon
 
 ## Configuration
 
-The dashboard is configured when it starts up. Configuration includes front-end and OTLP addresses, the resource service endpoint, authentication, telemetry limits and more.
+The dashboard is configured when it starts up. Configuration includes frontend and OTLP addresses, the resource service endpoint, authentication, telemetry limits and more.
 
 For more information, see [Aspire dashboard configuration](/dashboard/configuration/).
 
 ## Architecture
 
-The dashboard user experience is built with a variety of technologies. The front end is built with [Grpc.AspNetCore](https://www.nuget.org/packages/Grpc.AspNetCore) NuGet package to the resource server. Consider the following diagram that illustrates the architecture of the Aspire dashboard:
+The dashboard user experience is built with a variety of technologies. The frontend is built with [Grpc.AspNetCore](https://www.nuget.org/packages/Grpc.AspNetCore) NuGet package to the resource server. Consider the following diagram that illustrates the architecture of the Aspire dashboard:
 
 <ThemeImage 
   light={architectureDiagramLight}
diff --git a/src/frontend/src/content/docs/dashboard/security-considerations.mdx b/src/frontend/src/content/docs/dashboard/security-considerations.mdx
index 03edc5d8f..250078f33 100644
--- a/src/frontend/src/content/docs/dashboard/security-considerations.mdx
+++ b/src/frontend/src/content/docs/dashboard/security-considerations.mdx
@@ -18,7 +18,7 @@ The dashboard can be run in different scenarios, such as being automatically sta
 The dashboard is automatically started when an Aspire AppHost is run. The dashboard is secure by default when run from Aspire tooling:
 
 - Transport is secured with HTTPS. Using HTTPS is configured by default in _launchSettings.json_. The launch profile includes `https` addresses in `applicationUrl` and `ASPIRE_DASHBOARD_OTLP_ENDPOINT_URL` values.
-- Browser front end authenticated with a browser token.
+- Browser frontend authenticated with a browser token.
 - Incoming telemetry authenticated with an API key.
 
 HTTPS in the dashboard uses the ASP.NET Core development certificate. The certificate must be trusted for the dashboard to work correctly. The steps required to trust the development cert are different depending on the machine's operating system:
@@ -32,7 +32,7 @@ There are scenarios where you might want to allow an unsecured transport. The da
 
 The dashboard is shipped as a Docker image and can be used without the rest of Aspire. When the dashboard is launched in standalone mode, it defaults to a mix of secure and unsecured settings.
 
-- Browser front end authenticated with a browser token.
+- Browser frontend authenticated with a browser token.
 - Incoming telemetry is unsecured. Warnings are displayed in the console and dashboard UI.
 
 The telemetry endpoint accepts incoming OTLP data without authentication. When the endpoint is unsecured, the dashboard is open to receiving telemetry from untrusted apps.
@@ -95,7 +95,7 @@ Other languages have different OpenTelemetry APIs. Passing the [`OTEL_EXPORTER_O
 
 The dashboard has an optional HTTP API that exposes collected telemetry data as JSON at `/api/telemetry/*` endpoints. The telemetry API allows programmatic access to spans, logs, traces, and resource information stored in the dashboard. Because telemetry data can contain sensitive runtime information, the API is disabled by default and must be explicitly enabled.
 
-When enabled, the telemetry API is served on the same endpoint as the dashboard front end (`ASPNETCORE_URLS`). Enable and secure the API with the following configuration:
+When enabled, the telemetry API is served on the same endpoint as the dashboard frontend (`ASPNETCORE_URLS`). Enable and secure the API with the following configuration:
 
 <OsAwareTabs syncKey="terminal">
 <div slot="unix">
diff --git a/src/frontend/src/content/docs/dashboard/standalone-for-python.mdx b/src/frontend/src/content/docs/dashboard/standalone-for-python.mdx
index 3f1889cd0..4c9c8cef2 100644
--- a/src/frontend/src/content/docs/dashboard/standalone-for-python.mdx
+++ b/src/frontend/src/content/docs/dashboard/standalone-for-python.mdx
@@ -28,7 +28,7 @@ To complete this tutorial, you need the following:
 
 ## Create a sample application
 
-This tutorial uses the Aspire 13.0 Python starter template which includes a FastAPI backend and React front end. You'll focus on the FastAPI app to demonstrate dashboard integration with standalone mode.
+This tutorial uses the Aspire 13.0 Python starter template which includes a FastAPI backend and React frontend. You'll focus on the FastAPI app to demonstrate dashboard integration with standalone mode.
 
 <Steps>
 
diff --git a/src/frontend/src/content/docs/deployment/javascript-apps.mdx b/src/frontend/src/content/docs/deployment/javascript-apps.mdx
index 8cd30e1f4..442d60535 100644
--- a/src/frontend/src/content/docs/deployment/javascript-apps.mdx
+++ b/src/frontend/src/content/docs/deployment/javascript-apps.mdx
@@ -1,18 +1,18 @@
 ---
 title: Deploy JavaScript apps
-description: Learn the main production deployment models for Vite and JavaScript front ends in Aspire.
+description: Learn the main production deployment models for Vite and JavaScript frontends in Aspire.
 ---
 
 import { Aside, Tabs, TabItem } from '@astrojs/starlight/components';
 import LearnMore from '@components/LearnMore.astro';
 
-For Vite and other JavaScript front ends, there are three common production deployment models:
+For Vite and other JavaScript frontends, there are three common production deployment models:
 
-- A backend service serves the built front-end files.
-- A reverse proxy serves the built front-end files.
-- A standalone static front end talks directly to a separately hosted backend.
+- A backend service serves the built frontend files.
+- A reverse proxy serves the built frontend files.
+- A standalone static frontend talks directly to a separately hosted backend.
 
-All three models use `AddViteApp` for local development and for producing the front-end build output during publishing. The difference is which resource becomes the production entrypoint and whether the browser talks to the backend directly.
+All three models use `AddViteApp` for local development and for producing the frontend build output during publishing. The difference is which resource becomes the production entrypoint and whether the browser talks to the backend directly.
 
 These same production models also apply to `AddJavaScriptApp`. The difference
 is that `AddViteApp` knows about Vite's development conventions, while
@@ -23,20 +23,20 @@ specific deployment target.
 
 ## Deployment rule
 
-For deployment, `AddViteApp` and `AddJavaScriptApp` should be treated as front-end build resources, not as the final production web server.
+For deployment, `AddViteApp` and `AddJavaScriptApp` should be treated as frontend build resources, not as the final production web server.
 
-To deploy a JavaScript front end, you must choose which other resource owns the public HTTP surface in production:
+To deploy a JavaScript frontend, you must choose which other resource owns the public HTTP surface in production:
 
-- Use `PublishWithContainerFiles(...)` when your backend or web server will serve the built front-end files.
-- Use `PublishWithStaticFiles(...)` when your reverse proxy, gateway, or <abbr title="Backend for Frontend">BFF</abbr> will serve the built front-end files.
+- Use `PublishWithContainerFiles(...)` when your backend or web server will serve the built frontend files.
+- Use `PublishWithStaticFiles(...)` when your reverse proxy, gateway, or <abbr title="Backend for Frontend">BFF</abbr> will serve the built frontend files.
 
-If you only add a Vite or JavaScript app and reference backend services, Aspire still needs one of these production hosting patterns to know who serves the built front end in deployment.
+If you only add a Vite or JavaScript app and reference backend services, Aspire still needs one of these production hosting patterns to know who serves the built frontend in deployment.
 
 <Aside type="tip">
   If you expected `AddViteApp(...).PublishAsDockerFile()` to behave like a
   standalone Nginx- or Apache-style static web container by default, that is not
   the primary deployment model Aspire is guiding you toward. The intended
-  default is that another resource serves the built front-end assets in
+  default is that another resource serves the built frontend assets in
   production.
 </Aside>
 
@@ -52,30 +52,30 @@ If you only add a Vite or JavaScript app and reference backend services, Aspire
 
 | Model                                  | Production entrypoint      | Aspire publish API          | Best for                                                                          |
 | -------------------------------------- | -------------------------- | --------------------------- | --------------------------------------------------------------------------------- |
-| Backend serves front end               | API or web server          | `PublishWithContainerFiles` | Apps where one service serves both the API and the front end                      |
-| Reverse proxy serves front end         | Reverse proxy              | `PublishWithStaticFiles`    | Apps that want a gateway or BFF in front of APIs and static front-end assets      |
-| Static front end calls backend directly | Static site + separate API | Custom / less integrated    | Apps that intentionally keep front-end hosting separate and can manage CORS/config |
+| Backend serves frontend               | API or web server          | `PublishWithContainerFiles` | Apps where one service serves both the API and the frontend                      |
+| Reverse proxy serves frontend         | Reverse proxy              | `PublishWithStaticFiles`    | Apps that want a gateway or BFF in front of APIs and static frontend assets      |
+| Static frontend calls backend directly | Static site + separate API | Custom / less integrated    | Apps that intentionally keep frontend hosting separate and can manage CORS/config |
 
 <Aside type="caution">
   `AddViteApp` already registers its local development endpoint. Do not call
   `.WithHttpEndpoint()` on a Vite resource.
 </Aside>
 
-## Model 1: Backend serves the built front end
+## Model 1: Backend serves the built frontend
 
-Use this model when your backend, API, or server is responsible for serving static front-end files in production from `wwwroot`, `static`, or a similar directory.
+Use this model when your backend, API, or server is responsible for serving static frontend files in production from `wwwroot`, `static`, or a similar directory.
 
-This model only works if that backend or server can actually serve the built front-end assets. In other words, the deployed application service must be both the API host and the static file host for the front end.
+This model only works if that backend or server can actually serve the built frontend assets. In other words, the deployed application service must be both the API host and the static file host for the frontend.
 
 <Aside type="note">
-  `PublishWithContainerFiles(...)` only copies the built front-end assets into
+  `PublishWithContainerFiles(...)` only copies the built frontend assets into
   the destination container. The important requirement is easy to miss in the
   helper name: the destination app must be configured to serve those files.
 </Aside>
 
 ```mermaid
 flowchart LR
-    Browser --> App["Node app<br/>serving built front-end files"]
+    Browser --> App["Node app<br/>serving built frontend files"]
     App --> Frontend["Vite build output"]
 ```
 
@@ -129,31 +129,31 @@ await builder.build().run();
 ### How it works
 
 1. `AddViteApp` runs the Vite dev server during `aspire run`.
-2. During publish, Aspire builds the front end and extracts its production output.
+2. During publish, Aspire builds the frontend and extracts its production output.
 3. `PublishWithContainerFiles` copies those files into the Node app container.
-4. The Node app becomes the deployed HTTP endpoint and serves the front-end files.
+4. The Node app becomes the deployed HTTP endpoint and serves the frontend files.
 
 ### Why Aspire supports this model
 
-This model keeps the production topology simple. The front-end build output becomes part of the same deployable unit as the backend, so one service owns the application surface, static files, and API behavior together.
+This model keeps the production topology simple. The frontend build output becomes part of the same deployable unit as the backend, so one service owns the application surface, static files, and API behavior together.
 
-It also maps well to frameworks that already know how to serve static files from `wwwroot`, `static`, or a similar folder. Instead of introducing an extra gateway or front-end-serving container, Aspire lets the backend stay responsible for the final HTTP response.
+It also maps well to frameworks that already know how to serve static files from `wwwroot`, `static`, or a similar folder. Instead of introducing an extra gateway or frontend-serving container, Aspire lets the backend stay responsible for the final HTTP response.
 
 ### When to use this model
 
 - Your backend already serves static files, or you are willing to make it do so.
-- You want one deployed service to host both the API and the front end.
+- You want one deployed service to host both the API and the frontend.
 - You want the same resource to own routing, auth, and static asset hosting.
 
 ### Implications
 
-- Your backend container gets larger because it now contains both backend code and front-end assets.
-- Front end and backend are deployed together, which is convenient when they change together but less flexible if you want to scale or release them independently.
+- Your backend container gets larger because it now contains both backend code and frontend assets.
+- Frontend and backend are deployed together, which is convenient when they change together but less flexible if you want to scale or release them independently.
 - Authentication, caching, headers, and fallback routing are handled where the backend serves the files.
 - This usually gives the simplest mental model: one deployed service, one public endpoint, one place to troubleshoot.
-- This is the default pattern Aspire is steering you toward for Vite front ends unless you intentionally introduce a gateway or BFF to own the public surface.
+- This is the default pattern Aspire is steering you toward for Vite frontends unless you intentionally introduce a gateway or BFF to own the public surface.
 
-## Model 2: Reverse proxy serves the built front end
+## Model 2: Reverse proxy serves the built frontend
 
 Use this model when a reverse proxy should be the public entrypoint for your app, either as a gateway or as a backend-for-frontend (BFF).
 
@@ -230,7 +230,7 @@ await builder.build().run();
 
 ### Dev-only gateway wiring
 
-If your gateway or BFF needs to know about the front-end dev server during local
+If your gateway or BFF needs to know about the frontend dev server during local
 development, gate that wiring to run mode only:
 
 <Tabs syncKey="apphost-lang">
@@ -275,21 +275,21 @@ if (await builder.executionContext.isRunMode()) {
 
 <Aside type="caution">
   Dev-only waits, references, and environment variables that point at the
-  front-end development server can be correct in run mode, but wrong in
+  frontend development server can be correct in run mode, but wrong in
   publish/deploy if you leave them unconditional. Publish must not depend on the
-  front-end development endpoint.
+  frontend development endpoint.
 </Aside>
 
 ### How it works
 
-1. The reverse proxy owns the public URL surface for both front-end and backend routes.
+1. The reverse proxy owns the public URL surface for both frontend and backend routes.
 2. API requests such as `/api/*` are routed to the backend service.
-3. During publish, Aspire builds the front end and `PublishWithStaticFiles` copies the output into the proxy resource.
-4. In production, the proxy serves front-end routes itself while continuing to proxy API routes.
+3. During publish, Aspire builds the frontend and `PublishWithStaticFiles` copies the output into the proxy resource.
+4. In production, the proxy serves frontend routes itself while continuing to proxy API routes.
 
 ### Why Aspire supports this model
 
-This model keeps the public entrypoint separate from the application services behind it. The reverse proxy becomes the stable edge for the app, while the front-end build and any backend services remain behind that gateway or BFF.
+This model keeps the public entrypoint separate from the application services behind it. The reverse proxy becomes the stable edge for the app, while the frontend build and any backend services remain behind that gateway or BFF.
 
 It is a good fit when you want one place to centralize routing, transforms, headers, and gateway or BFF concerns. YARP is Aspire's first-class option here, which is why the example uses it, but the architectural tradeoffs are the same for other reverse proxies.
 
@@ -302,16 +302,16 @@ It is a good fit when you want one place to centralize routing, transforms, head
 ### Implications
 
 - The reverse proxy owns the public endpoint, so backend services can stay internal behind the gateway or BFF.
-- Front-end hosting is decoupled from any individual backend service, which can make routing cleaner in multi-service apps.
-- Route rules now matter directly because the proxy decides which requests go to APIs and which requests go to the front end.
+- Frontend hosting is decoupled from any individual backend service, which can make routing cleaner in multi-service apps.
+- Route rules now matter directly because the proxy decides which requests go to APIs and which requests go to the frontend.
 - You now have a dedicated gateway/BFF in the deployment, which adds one more moving part but also gives you more control over ingress behavior.
-- This is often the better choice when the front end needs BFF-style behavior or when a standalone Vite build would otherwise need deployment-time configuration from backend resources.
+- This is often the better choice when the frontend needs BFF-style behavior or when a standalone Vite build would otherwise need deployment-time configuration from backend resources.
 
 ## A third model you may be considering
 
 Another common deployment shape is:
 
-- The front end is deployed to its own static file host.
+- The frontend is deployed to its own static file host.
 - The backend is deployed to separate compute.
 - The browser calls the backend directly.
 
@@ -427,17 +427,17 @@ await builder.build().run();
 - **Pit 2 — Switching the same value to a build arg**
 
   Example: `WithBuildArg(...)` / `withBuildArg(...)` to set the backend URL
-  during the front-end image build.
+  during the frontend image build.
 
-  Associated failure: the backend URL is usually not known when the front end
+  Associated failure: the backend URL is usually not known when the frontend
   image is being built.
 
 - **Pit 3 — Trying to wire both sides of the relationship**
 
-  Example: the front end needs the backend URL, while the backend also needs the
-  front-end origin for CORS.
+  Example: the frontend needs the backend URL, while the backend also needs the
+  frontend origin for CORS.
 
-  Associated failure: this creates a deployment-time cycle between the front end
+  Associated failure: this creates a deployment-time cycle between the frontend
   and backend. In publish/deploy, the Vite resource is a build resource, not the
   runtime web server, so it cannot be the place where the browser discovers the
   backend URL.
@@ -446,7 +446,7 @@ await builder.build().run();
   If publish throws `The given key 'Aspire.Hosting.JavaScript.ViteAppResource'
   was not present in the dictionary.`, treat that as a modeling problem, not as
   a missing dictionary entry. Move that runtime relationship to the backend,
-  reverse proxy, or other deployed resource that actually serves the front end or
+  reverse proxy, or other deployed resource that actually serves the frontend or
   owns the public HTTP surface.
 </Aside>
 
@@ -456,26 +456,26 @@ This model looks familiar if you are used to deploying:
 
 - A Vite or React app to a static site host.
 - An API to another host.
-- Front-end JavaScript that calls the API directly from the browser.
+- Frontend JavaScript that calls the API directly from the browser.
 
-It can seem like the most obvious path because it keeps the front end as "just a
-static site" and avoids adding a backend-served front end or reverse proxy layer.
+It can seem like the most obvious path because it keeps the frontend as "just a
+static site" and avoids adding a backend-served frontend or reverse proxy layer.
 
 ### Why it gets harder
 
-This model pushes more work onto the browser/front-end boundary:
+This model pushes more work onto the browser/frontend boundary:
 
 - The browser now talks to a different origin, so you often need to configure CORS.
-- The front end needs to know the backend URL for each environment.
+- The frontend needs to know the backend URL for each environment.
 - Vite apps usually consume those values at build time, which means the backend
-  URL must be known when the front end is built or injected through a separate
+  URL must be known when the frontend is built or injected through a separate
   runtime configuration pattern.
 - Local Vite proxy behavior often hides these production concerns until you try
   to deploy.
 
 ### What this means in Aspire
 
-Aspire can still orchestrate the front-end build and the backend resource, but
+Aspire can still orchestrate the frontend build and the backend resource, but
 this topology is less integrated than the two primary models above. In
 particular, Aspire does not automatically solve:
 
@@ -484,17 +484,17 @@ particular, Aspire does not automatically solve:
 - The split ownership between a standalone static site host and a separate API host.
 
 If this is the model you want, plan for explicit runtime configuration and CORS
-management. Otherwise, the backend-serves-front-end or reverse-proxy-serves-front-end
+management. Otherwise, the backend-serves-frontend or reverse-proxy-serves-frontend
 models are usually easier to reason about in Aspire.
 
 ## How to choose
 
-Choose **backend serves front end** when the backend already owns the app surface and should also own static file hosting.
+Choose **backend serves frontend** when the backend already owns the app surface and should also own static file hosting.
 
-Choose **reverse proxy serves front end** when you want a gateway or BFF to stay in front of everything and route both front-end and backend traffic.
+Choose **reverse proxy serves frontend** when you want a gateway or BFF to stay in front of everything and route both frontend and backend traffic.
 
-Choose the **standalone static front end + direct browser-to-backend** model only
-when you intentionally want separate front-end and backend hosting and are
+Choose the **standalone static frontend + direct browser-to-backend** model only
+when you intentionally want separate frontend and backend hosting and are
 willing to manage backend URL configuration and CORS explicitly.
 
 In practice, the decision is usually about **who should own the public HTTP surface in production**:
@@ -504,10 +504,10 @@ In practice, the decision is usually about **who should own the public HTTP surf
 
 ## What `AddViteApp` means in production
 
-`AddViteApp` is best thought of as a development server plus a front-end build resource:
+`AddViteApp` is best thought of as a development server plus a frontend build resource:
 
 - In run mode, it gives you the Vite dev server and HMR.
-- In publish mode, it produces front-end build artifacts.
+- In publish mode, it produces frontend build artifacts.
 - Another resource serves those artifacts in production.
 
 That distinction is easy to miss if you only read the JavaScript integration page or release notes. This article exists to make the production story explicit.
@@ -527,7 +527,7 @@ The difference is that `AddJavaScriptApp` does not assume a particular developme
 
 - Expecting `AddViteApp` to be the deployed production web server.
 - Exposing the Vite resource instead of the backend or reverse proxy resource that serves the built files.
-- Adding `AddViteApp` plus `.WithReference(...)` and assuming that is enough to deploy the front end.
+- Adding `AddViteApp` plus `.WithReference(...)` and assuming that is enough to deploy the frontend.
 - Using `.WithEnvironment(...)` on `AddViteApp` to pass the API URL to the deployed SPA.
 - Calling `.WithHttpEndpoint()` on `AddViteApp`.
 - Using `VITE_*` variables for values that must be resolved at runtime in an already-built SPA.
diff --git a/src/frontend/src/content/docs/deployment/overview.mdx b/src/frontend/src/content/docs/deployment/overview.mdx
index f20f2bebf..2e1c2eed1 100644
--- a/src/frontend/src/content/docs/deployment/overview.mdx
+++ b/src/frontend/src/content/docs/deployment/overview.mdx
@@ -128,7 +128,7 @@ builder.AddProject<Projects.Backend>("backend")
     .WithComputeEnvironment(compose);
 ```
 
-This example shows how you could explicitly map services to different compute environments. For example, a front end in Kubernetes and a backend in Docker Compose.
+This example shows how you could explicitly map services to different compute environments. For example, a frontend in Kubernetes and a backend in Docker Compose.
 
 ## Hosting integration support matrix
 
diff --git a/src/frontend/src/content/docs/deployment/pipelines.mdx b/src/frontend/src/content/docs/deployment/pipelines.mdx
index d83e6002f..ddcd2fd2d 100644
--- a/src/frontend/src/content/docs/deployment/pipelines.mdx
+++ b/src/frontend/src/content/docs/deployment/pipelines.mdx
@@ -82,27 +82,27 @@ A pipeline step represents a discrete unit of work in the application pipeline.
 Each step has:
 
 - **Name**: A unique identifier for the step
-- **Action**: The work to be performed during deployment  
+- **Action**: The work to be performed during deployment
 - **Dependencies**: Other steps that must complete before this step runs
 - **Resource context**: Access to the application's resource model and configuration
 
-Pipeline steps operate at different levels of granularity. For example, when deploying a typical web application with a front end, API service, database, and storage, the pipeline might include:
+Pipeline steps operate at different levels of granularity. For example, when deploying a typical web application with a frontend, API service, database, and storage, the pipeline might include:
 
 **Infrastructure steps** (can run in parallel):
 - `provision-cosmosdb`: Provision the CosmosDB database
-- `provision-storage`: Provision Azure Storage account  
+- `provision-storage`: Provision Azure Storage account
 - `provision-aca-env`: Provision Azure Container Apps environment
 - `provision-container-registry`: Set up the container image registry
 
 **Build steps** (can run in parallel):
 - `build-apiservice`: Build container image for the API service
-- `build-webfrontend`: Build container image for the front end
+- `build-webfrontend`: Build container image for the frontend
 
 **Deployment steps** (depend on builds and infrastructure):
 - `push-apiservice`: Push API service image to registry
-- `push-webfrontend`: Push front-end image to registry
+- `push-webfrontend`: Push frontend image to registry
 - `deploy-apiservice`: Deploy API service to compute platform
-- `deploy-webfrontend`: Deploy front end to compute platform
+- `deploy-webfrontend`: Deploy frontend to compute platform
 
 This granular approach allows the pipeline to maximize parallelism—databases can be provisioned while container images are building, and as soon as both the container registry and an image are ready, the image can be pushed immediately without waiting for other unrelated operations.
 
@@ -305,7 +305,7 @@ The `aspire do` command allows you to execute individual steps and their depende
 
 **Use cases for selective step execution:**
 
-- **Incremental deployments**: After making changes to only your front-end code, run just the front-end-related steps rather than rebuilding and redeploying your entire application
+- **Incremental deployments**: After making changes to only your frontend code, run just the frontend-related steps rather than rebuilding and redeploying your entire application
 - **Troubleshooting and retry**: If a specific step fails (e.g., database provisioning times out), you can retry just that step and its dependents without repeating successful operations
 - **Development workflows**: During development, you might want to provision infrastructure once, then repeatedly deploy code changes without reprovisioning resources
 - **Selective operations**: Separate infrastructure provisioning from application deployment to align with organizational policies or approval processes
diff --git a/src/frontend/src/content/docs/fundamentals/networking-overview.mdx b/src/frontend/src/content/docs/fundamentals/networking-overview.mdx
index 4a46198a3..7506be390 100644
--- a/src/frontend/src/content/docs/fundamentals/networking-overview.mdx
+++ b/src/frontend/src/content/docs/fundamentals/networking-overview.mdx
@@ -135,7 +135,7 @@ The preceding code results in the following networking diagram:
 
 <Image
   src={proxyWithReplicas}
-  alt="Aspire front-end app networking diagram with specific host port and two replicas."
+  alt="Aspire frontend app networking diagram with specific host port and two replicas."
 />
 
 The preceding diagram depicts the following:
@@ -160,7 +160,7 @@ There are two ports defined:
 
 <Image
   src={proxyHostPortAndRandomPort}
-  alt="Aspire front-end app networking diagram with specific host port and random port."
+  alt="Aspire frontend app networking diagram with specific host port and random port."
 />
 
 The preceding diagram depicts the following:
@@ -191,7 +191,7 @@ In this scenario, both the host and service ports are random, as shown in the fo
 
 <Image
   src={proxyWithRandomPorts}
-  alt="Aspire front-end app networking diagram with random host port and proxy port."
+  alt="Aspire frontend app networking diagram with random host port and proxy port."
 />
 
 The preceding diagram depicts the following:
@@ -219,7 +219,7 @@ Consider the following diagram:
 
 <Image
   src={proxyWithDockerPortMapping}
-  alt="Aspire front-end app networking diagram with a docker host."
+  alt="Aspire frontend app networking diagram with a docker host."
 />
 
 ## Endpoint extension methods
diff --git a/src/frontend/src/content/docs/fundamentals/service-discovery.mdx b/src/frontend/src/content/docs/fundamentals/service-discovery.mdx
index 2ae640afe..fb0090905 100644
--- a/src/frontend/src/content/docs/fundamentals/service-discovery.mdx
+++ b/src/frontend/src/content/docs/fundamentals/service-discovery.mdx
@@ -5,7 +5,7 @@ description: Understand essential service discovery concepts in Aspire.
 
 import { Aside } from '@astrojs/starlight/components';
 
-Service discovery is how your services find each other. Instead of hardcoding URLs like `http://localhost:5001`, your front end can simply reference the `catalog` service by name—and Aspire handles resolving the actual address.
+Service discovery is how your services find each other. Instead of hardcoding URLs like `http://localhost:5001`, your frontend can simply reference the `catalog` service by name—and Aspire handles resolving the actual address.
 
 ## How service discovery works
 
@@ -43,7 +43,7 @@ In the preceding example, the _frontend_ project references the _catalog_ projec
 2. **Enable resolution** - Allow `frontend` to use URIs like `https+http://catalog` in HttpClient
 
 <Aside type="note">
-If you don't call `WithReference()`, the front end won't have the configuration needed to discover that service. This is intentional—services only know about their explicit dependencies.
+If you don't call `WithReference()`, the frontend won't have the configuration needed to discover that service. This is intentional—services only know about their explicit dependencies.
 </Aside>
 
 ## Named endpoints
diff --git a/src/frontend/src/content/docs/get-started/add-aspire-existing-app-csharp-apphost.mdx b/src/frontend/src/content/docs/get-started/add-aspire-existing-app-csharp-apphost.mdx
index 430e86ed9..0e1587b87 100644
--- a/src/frontend/src/content/docs/get-started/add-aspire-existing-app-csharp-apphost.mdx
+++ b/src/frontend/src/content/docs/get-started/add-aspire-existing-app-csharp-apphost.mdx
@@ -502,9 +502,9 @@ builder.Build().Run();
 :::caution[JavaScript deployment note]
 This example shows how to run existing JavaScript applications with Aspire
 during development. It does not, by itself, define who serves a Vite or
-JavaScript front end in production.
+JavaScript frontend in production.
 
-If you plan to publish or deploy these front-end resources, read [Deploy
+If you plan to publish or deploy these frontend resources, read [Deploy
 JavaScript apps](/deployment/javascript-apps/) to choose the correct production
 hosting model.
 :::
diff --git a/src/frontend/src/content/docs/get-started/add-aspire-existing-app-typescript-apphost.mdx b/src/frontend/src/content/docs/get-started/add-aspire-existing-app-typescript-apphost.mdx
index 684e30f5b..9c29469ca 100644
--- a/src/frontend/src/content/docs/get-started/add-aspire-existing-app-typescript-apphost.mdx
+++ b/src/frontend/src/content/docs/get-started/add-aspire-existing-app-typescript-apphost.mdx
@@ -228,9 +228,9 @@ await builder.build().run();
 :::caution[JavaScript deployment note]
 This example shows how to run existing JavaScript applications with Aspire
 during development. It does not, by itself, define who serves a Vite or
-JavaScript front end in production.
+JavaScript frontend in production.
 
-If you plan to publish or deploy these front-end resources, read [Deploy
+If you plan to publish or deploy these frontend resources, read [Deploy
 JavaScript apps](/deployment/javascript-apps/) to choose the correct production
 hosting model.
 :::
@@ -264,7 +264,7 @@ Option 2 keeps all script configuration in `package.json`, making your scripts m
 
 <Aside type="tip">
   You can mix and match JavaScript application types. Combine Node.js APIs, Vite
-  front ends, workers, and supporting containers in the same TypeScript AppHost
+  frontends, workers, and supporting containers in the same TypeScript AppHost
   to model your full development environment in one place.
 </Aside>
 
diff --git a/src/frontend/src/content/docs/get-started/app-host.mdx b/src/frontend/src/content/docs/get-started/app-host.mdx
index d5ca23859..809e26c5f 100644
--- a/src/frontend/src/content/docs/get-started/app-host.mdx
+++ b/src/frontend/src/content/docs/get-started/app-host.mdx
@@ -31,7 +31,7 @@ Prefer writing your AppHost in TypeScript? Start with [Build your first Aspire a
 
 ## Defining your architecture
 
-Consider a simple three-tier architecture where the front end talks to an API, and the API talks to a database:
+Consider a simple three-tier architecture where the frontend talks to an API, and the API talks to a database:
 
 <Pivot id="csharp">
 
@@ -40,13 +40,13 @@ architecture-beta
 
   service db(logos:postgresql)[PostgreSQL]
   service api(logos:dotnet)[API service]
-  service frontend(logos:react)[React front end]
+  service frontend(logos:react)[React frontend]
 
   api:R --> L:db
   frontend:R --> L:api
 ```
 
-This architecture demonstrates a **.NET API** connecting to a **PostgreSQL database**, with a **React front end** consuming the API. The .NET API uses ASP.NET Core and connects to PostgreSQL using Entity Framework or a connection string. The React front end is built with Vite and communicates with the API over HTTP.
+This architecture demonstrates a **.NET API** connecting to a **PostgreSQL database**, with a **React frontend** consuming the API. The .NET API uses ASP.NET Core and connects to PostgreSQL using Entity Framework or a connection string. The React frontend is built with Vite and communicates with the API over HTTP.
 
 To build this architecture step-by-step, see the [Build your first app](/get-started/first-app-csharp-apphost/?lang=csharp) quickstart.
 
@@ -58,13 +58,13 @@ architecture-beta
 
   service db(logos:postgresql)[PostgreSQL]
   service api(logos:python)[API service]
-  service frontend(logos:react)[React front end]
+  service frontend(logos:react)[React frontend]
 
   api:R --> L:db
   frontend:R --> L:api
 ```
 
-This architecture demonstrates a **Python API** (using FastAPI/Uvicorn) connecting to a **PostgreSQL database**, with a **React front end** consuming the API. The Python API uses frameworks like FastAPI or Flask and connects to PostgreSQL using libraries like psycopg2 or SQLAlchemy. The React front end is built with Vite and communicates with the API over HTTP.
+This architecture demonstrates a **Python API** (using FastAPI/Uvicorn) connecting to a **PostgreSQL database**, with a **React frontend** consuming the API. The Python API uses frameworks like FastAPI or Flask and connects to PostgreSQL using libraries like psycopg2 or SQLAlchemy. The React frontend is built with Vite and communicates with the API over HTTP.
 
 To build this architecture step-by-step, see the [Build your first app](/get-started/first-app-csharp-apphost/?lang=python) quickstart.
 
@@ -80,13 +80,13 @@ architecture-beta
 
   service db(logos:postgresql)[PostgreSQL]
   service api(logos:nodejs-icon)[API service]
-  service frontend(logos:react)[React front end]
+  service frontend(logos:react)[React frontend]
 
   api:R --> L:db
   frontend:R --> L:api
 ```
 
-This architecture demonstrates a **Node.js API** connecting to a **PostgreSQL database**, with a **React front end** consuming the API. The Node.js API uses frameworks like Express or Fastify and connects to PostgreSQL using libraries like pg or Prisma. The React front end is built with Vite and communicates with the API over HTTP.
+This architecture demonstrates a **Node.js API** connecting to a **PostgreSQL database**, with a **React frontend** consuming the API. The Node.js API uses frameworks like Express or Fastify and connects to PostgreSQL using libraries like pg or Prisma. The React frontend is built with Vite and communicates with the API over HTTP.
 
 <Aside type="tip">
 The JavaScript/Node.js integration is provided by the [Aspire.Hosting.JavaScript](https://www.nuget.org/packages/Aspire.Hosting.JavaScript) NuGet package. Learn more in the [JavaScript integration](/integrations/frameworks/javascript/) documentation.
@@ -100,13 +100,13 @@ architecture-beta
 
   service db(logos:postgresql)[PostgreSQL]
   service api(logos:go)[API service]
-  service frontend(logos:react)[React front end]
+  service frontend(logos:react)[React frontend]
 
   api:R --> L:db
   frontend:R --> L:api
 ```
 
-This architecture demonstrates a **Go API** connecting to a **PostgreSQL database**, with a **React front end** consuming the API. The Go API uses the standard library's `net/http` package or frameworks like Gin or Echo and connects to PostgreSQL using libraries like pgx or database/sql. The React front end is built with Vite and communicates with the API over HTTP.
+This architecture demonstrates a **Go API** connecting to a **PostgreSQL database**, with a **React frontend** consuming the API. The Go API uses the standard library's `net/http` package or frameworks like Gin or Echo and connects to PostgreSQL using libraries like pgx or database/sql. The React frontend is built with Vite and communicates with the API over HTTP.
 
 <Aside type="tip">
 The Go integration is provided by the [CommunityToolkit.Aspire.Hosting.Golang](https://www.nuget.org/packages/CommunityToolkit.Aspire.Hosting.Golang) NuGet package. Learn more in the [Go integration](/integrations/frameworks/go-apps/) documentation.
@@ -120,13 +120,13 @@ architecture-beta
 
   service db(logos:postgresql)[PostgreSQL]
   service api(logos:java)[API service]
-  service frontend(logos:react)[React front end]
+  service frontend(logos:react)[React frontend]
 
   api:R --> L:db
   frontend:R --> L:api
 ```
 
-This architecture demonstrates a **Java API** (using Spring Boot) connecting to a **PostgreSQL database**, with a **React front end** consuming the API. The Java API uses Spring Boot with Spring Data JPA and connects to PostgreSQL using JDBC or Spring Data. The React front end is built with Vite and communicates with the API over HTTP.
+This architecture demonstrates a **Java API** (using Spring Boot) connecting to a **PostgreSQL database**, with a **React frontend** consuming the API. The Java API uses Spring Boot with Spring Data JPA and connects to PostgreSQL using JDBC or Spring Data. The React frontend is built with Vite and communicates with the API over HTTP.
 
 <Aside type="tip">
 The Java integration is provided by the [CommunityToolkit.Aspire.Hosting.Java](https://www.nuget.org/packages/CommunityToolkit.Aspire.Hosting.Java) NuGet package. Learn more in the [Java integration](/integrations/frameworks/java/) documentation.
@@ -177,9 +177,9 @@ You can represent that architecture in an AppHost like this:
 </SimpleAppHostCode>
 </Pivot>
 
-The AppHost models your distributed application declaratively. Each code sample above shows the same three-tier architecture—**PostgreSQL database**, **API service**, and **React front end**—but with different API implementations and, when available, different AppHost languages.
+The AppHost models your distributed application declaratively. Each code sample above shows the same three-tier architecture—**PostgreSQL database**, **API service**, and **React frontend**—but with different API implementations and, when available, different AppHost languages.
 
-In all cases, the PostgreSQL database and React front end remain identical. Aspire resource references establish dependencies between resources, and the app model ensures services start in the correct order.
+In all cases, the PostgreSQL database and React frontend remain identical. Aspire resource references establish dependencies between resources, and the app model ensures services start in the correct order.
 
 Aspire presents the same, consistent model regardless of the language or framework used: services, resources, and the connections between them.
 
@@ -462,14 +462,14 @@ Next, register the API service and wire it to the PostgreSQL resource:
 </SimpleAppHostCode>
 </Pivot>
 
-Now that the `api` service is defined, you can attach the front end.
+Now that the `api` service is defined, you can attach the frontend.
 
-#### Adding a front-end resource
+#### Adding a frontend resource
 
-Register the front-end project, declare its dependency on the API, and let the AppHost provide the API address automatically.
+Register the frontend project, declare its dependency on the API, and let the AppHost provide the API address automatically.
 
 <Aside type="note">
-This example uses a Node.js (React) front end, but Aspire treats front ends as executable services—any language or framework works.
+This example uses a Node.js (React) frontend, but Aspire treats frontends as executable services—any language or framework works.
 </Aside>
 
 <Pivot id="csharp">
@@ -477,17 +477,17 @@ This example uses a Node.js (React) front end, but Aspire treats front ends as e
   <div slot="csharp-content">
     <p><strong>Key points:</strong></p>
     <ul>
-      <li><code>AddViteApp("frontend", "../frontend")</code> registers the front end as a service named <code>frontend</code>.</li>
+      <li><code>AddViteApp("frontend", "../frontend")</code> registers the frontend as a service named <code>frontend</code>.</li>
       <li><code>WithHttpEndpoint(env: "PORT")</code> exposes the app and lets the <code>PORT</code> environment variable control the listener.</li>
-      <li><code>WithReference(api)</code> injects the API base address into the front-end configuration.</li>
+      <li><code>WithReference(api)</code> injects the API base address into the frontend configuration.</li>
     </ul>
   </div>
   <div slot="typescript-content">
     <p><strong>Key points:</strong></p>
     <ul>
-      <li><code>addViteApp("frontend", "../frontend")</code> registers the front end as a service named <code>frontend</code>.</li>
+      <li><code>addViteApp("frontend", "../frontend")</code> registers the frontend as a service named <code>frontend</code>.</li>
       <li><code>withHttpEndpoint({'{'} env: "PORT" {'}'})</code> exposes the app and lets the <code>PORT</code> environment variable control the listener.</li>
-      <li><code>withReference(api)</code> injects the API base address into the front-end configuration.</li>
+      <li><code>withReference(api)</code> injects the API base address into the frontend configuration.</li>
     </ul>
   </div>
 </SimpleAppHostCode>
@@ -497,17 +497,17 @@ This example uses a Node.js (React) front end, but Aspire treats front ends as e
   <div slot="csharp-content">
     <p><strong>Key points:</strong></p>
     <ul>
-      <li><code>AddViteApp("frontend", "../frontend")</code> registers the front end as a service named <code>frontend</code>.</li>
+      <li><code>AddViteApp("frontend", "../frontend")</code> registers the frontend as a service named <code>frontend</code>.</li>
       <li><code>WithHttpEndpoint(env: "PORT")</code> exposes the app and lets the <code>PORT</code> environment variable control the listener.</li>
-      <li><code>WithReference(api)</code> injects the API base address into the front-end configuration.</li>
+      <li><code>WithReference(api)</code> injects the API base address into the frontend configuration.</li>
     </ul>
   </div>
   <div slot="typescript-content">
     <p><strong>Key points:</strong></p>
     <ul>
-      <li><code>addViteApp("frontend", "../frontend")</code> registers the front end as a service named <code>frontend</code>.</li>
+      <li><code>addViteApp("frontend", "../frontend")</code> registers the frontend as a service named <code>frontend</code>.</li>
       <li><code>withHttpEndpoint({'{'} env: "PORT" {'}'})</code> exposes the app and lets the <code>PORT</code> environment variable control the listener.</li>
-      <li><code>withReference(api)</code> injects the API base address into the front-end configuration.</li>
+      <li><code>withReference(api)</code> injects the API base address into the frontend configuration.</li>
     </ul>
   </div>
 </SimpleAppHostCode>
@@ -517,17 +517,17 @@ This example uses a Node.js (React) front end, but Aspire treats front ends as e
   <div slot="csharp-content">
     <p><strong>Key points:</strong></p>
     <ul>
-      <li><code>AddViteApp("frontend", "../frontend")</code> registers the front end as a service named <code>frontend</code>.</li>
+      <li><code>AddViteApp("frontend", "../frontend")</code> registers the frontend as a service named <code>frontend</code>.</li>
       <li><code>WithHttpEndpoint(env: "PORT")</code> exposes the app and lets the <code>PORT</code> environment variable control the listener.</li>
-      <li><code>WithReference(api)</code> injects the API base address into the front-end configuration.</li>
+      <li><code>WithReference(api)</code> injects the API base address into the frontend configuration.</li>
     </ul>
   </div>
   <div slot="typescript-content">
     <p><strong>Key points:</strong></p>
     <ul>
-      <li><code>addViteApp("frontend", "../frontend")</code> registers the front end as a service named <code>frontend</code>.</li>
+      <li><code>addViteApp("frontend", "../frontend")</code> registers the frontend as a service named <code>frontend</code>.</li>
       <li><code>withHttpEndpoint({'{'} env: "PORT" {'}'})</code> exposes the app and lets the <code>PORT</code> environment variable control the listener.</li>
-      <li><code>WithReference(api)</code> injects the API base address into the front-end configuration.</li>
+      <li><code>WithReference(api)</code> injects the API base address into the frontend configuration.</li>
     </ul>
   </div>
 </SimpleAppHostCode>
@@ -537,9 +537,9 @@ This example uses a Node.js (React) front end, but Aspire treats front ends as e
   <div>
     <p><strong>Key points:</strong></p>
     <ul>
-      <li><code>AddViteApp("frontend", "../frontend")</code> registers the front end as a service named <code>frontend</code>.</li>
+      <li><code>AddViteApp("frontend", "../frontend")</code> registers the frontend as a service named <code>frontend</code>.</li>
       <li><code>WithHttpEndpoint(env: "PORT")</code> exposes the app and lets the <code>PORT</code> environment variable control the listener.</li>
-      <li><code>WithReference(api)</code> injects the API base address into the front-end configuration.</li>
+      <li><code>WithReference(api)</code> injects the API base address into the frontend configuration.</li>
     </ul>
   </div>
 </SimpleAppHostCode>
@@ -549,9 +549,9 @@ This example uses a Node.js (React) front end, but Aspire treats front ends as e
   <div>
     <p><strong>Key points:</strong></p>
     <ul>
-      <li><code>AddViteApp("frontend", "../frontend")</code> registers the front end as a service named <code>frontend</code>.</li>
+      <li><code>AddViteApp("frontend", "../frontend")</code> registers the frontend as a service named <code>frontend</code>.</li>
       <li><code>WithHttpEndpoint(env: "PORT")</code> exposes the app and lets the <code>PORT</code> environment variable control the listener.</li>
-      <li><code>WithReference(api)</code> injects the API base address into the front-end configuration.</li>
+      <li><code>WithReference(api)</code> injects the API base address into the frontend configuration.</li>
     </ul>
   </div>
 </SimpleAppHostCode>
@@ -572,7 +572,7 @@ architecture-beta
   service epr(iconoir:server-connection)[Endpoint Reference]
   service api(logos:dotnet)[api]
   service ctr(iconoir:server-connection)[Connection String Reference]
-  service frontend(logos:react)[front end]
+  service frontend(logos:react)[frontend]
 
   db:L <-- R:ctr
   ctr:L <-- R:api
@@ -580,7 +580,7 @@ architecture-beta
   epr:L <-- R:frontend
 ```
 
-The .NET API receives a **ConnectionStringReference** from PostgreSQL and publishes an **EndpointReference** that the React front end consumes. This creates a clear dependency chain: `PostgreSQL → .NET API → React front end`.
+The .NET API receives a **ConnectionStringReference** from PostgreSQL and publishes an **EndpointReference** that the React frontend consumes. This creates a clear dependency chain: `PostgreSQL → .NET API → React frontend`.
 
 </Pivot>
 <Pivot id="python">
@@ -592,7 +592,7 @@ architecture-beta
   service epr(iconoir:server-connection)[Endpoint Reference]
   service api(logos:python)[api]
   service ctr(iconoir:server-connection)[Connection String Reference]
-  service frontend(logos:react)[front end]
+  service frontend(logos:react)[frontend]
 
   db:L <-- R:ctr
   ctr:L <-- R:api
@@ -600,7 +600,7 @@ architecture-beta
   epr:L <-- R:frontend
 ```
 
-The Python API receives a **ConnectionStringReference** from PostgreSQL and publishes an **EndpointReference** that the React front end consumes. This creates a clear dependency chain: `PostgreSQL → Python API → React front end`.
+The Python API receives a **ConnectionStringReference** from PostgreSQL and publishes an **EndpointReference** that the React frontend consumes. This creates a clear dependency chain: `PostgreSQL → Python API → React frontend`.
 
 </Pivot>
 <Pivot id="nodejs">
@@ -612,7 +612,7 @@ architecture-beta
   service epr(iconoir:server-connection)[Endpoint Reference]
   service api(logos:nodejs-icon)[api]
   service ctr(iconoir:server-connection)[Connection String Reference]
-  service frontend(logos:react)[front end]
+  service frontend(logos:react)[frontend]
 
   db:L <-- R:ctr
   ctr:L <-- R:api
@@ -620,7 +620,7 @@ architecture-beta
   epr:L <-- R:frontend
 ```
 
-The Node.js API receives a **ConnectionStringReference** from PostgreSQL and publishes an **EndpointReference** that the React front end consumes. This creates a clear dependency chain: `PostgreSQL → Node.js API → React front end`.
+The Node.js API receives a **ConnectionStringReference** from PostgreSQL and publishes an **EndpointReference** that the React frontend consumes. This creates a clear dependency chain: `PostgreSQL → Node.js API → React frontend`.
 
 </Pivot>
 <Pivot id="go">
@@ -632,7 +632,7 @@ architecture-beta
   service epr(iconoir:server-connection)[Endpoint Reference]
   service api(logos:go)[api]
   service ctr(iconoir:server-connection)[Connection String Reference]
-  service frontend(logos:react)[front end]
+  service frontend(logos:react)[frontend]
 
   db:L <-- R:ctr
   ctr:L <-- R:api
@@ -640,7 +640,7 @@ architecture-beta
   epr:L <-- R:frontend
 ```
 
-The Go API receives a **ConnectionStringReference** from PostgreSQL and publishes an **EndpointReference** that the React front end consumes. This creates a clear dependency chain: `PostgreSQL → Go API → React front end`.
+The Go API receives a **ConnectionStringReference** from PostgreSQL and publishes an **EndpointReference** that the React frontend consumes. This creates a clear dependency chain: `PostgreSQL → Go API → React frontend`.
 
 </Pivot>
 <Pivot id="java">
@@ -652,7 +652,7 @@ architecture-beta
   service epr(iconoir:server-connection)[Endpoint Reference]
   service api(logos:java)[api]
   service ctr(iconoir:server-connection)[Connection String Reference]
-  service frontend(logos:react)[front end]
+  service frontend(logos:react)[frontend]
 
   db:L <-- R:ctr
   ctr:L <-- R:api
@@ -660,7 +660,7 @@ architecture-beta
   epr:L <-- R:frontend
 ```
 
-The Java API receives a **ConnectionStringReference** from PostgreSQL and publishes an **EndpointReference** that the React front end consumes. This creates a clear dependency chain: `PostgreSQL → Java API → React front end`.
+The Java API receives a **ConnectionStringReference** from PostgreSQL and publishes an **EndpointReference** that the React frontend consumes. This creates a clear dependency chain: `PostgreSQL → Java API → React frontend`.
 
 </Pivot>
 
diff --git a/src/frontend/src/content/docs/get-started/aspire-sdk-templates.mdx b/src/frontend/src/content/docs/get-started/aspire-sdk-templates.mdx
index e20dd7736..706333b0d 100644
--- a/src/frontend/src/content/docs/get-started/aspire-sdk-templates.mdx
+++ b/src/frontend/src/content/docs/get-started/aspire-sdk-templates.mdx
@@ -36,13 +36,13 @@ The following Aspire solution templates are available (assume the solution is na
   - **AspireSample.Test**: Either an MSTest, NUnit, or xUnit test project with project references to the AppHost and an example _WebTests.cs_ file demonstrating an integration test.
 
 - **Aspire Starter App with ASP.NET Core and React**: This template includes the AppHost and ServiceDefaults projects, plus:
-  - **AspireSample.ApiService**: An [ASP.NET Core Minimal API](https://learn.microsoft.com/aspnet/core/fundamentals/minimal-apis) project that provides data to the front end.
-  - **AspireSample.Web**: A React-based front-end application with TypeScript configured to work with the Aspire app.
+  - **AspireSample.ApiService**: An [ASP.NET Core Minimal API](https://learn.microsoft.com/aspnet/core/fundamentals/minimal-apis) project that provides data to the frontend.
+  - **AspireSample.Web**: A React-based frontend application with TypeScript configured to work with the Aspire app.
 
 - **Aspire Starter App with FastAPI and React**: This template provides a Python-based starter app with the following projects:
   - **AspireSample.AppHost**: The orchestrator project for managing the app's services.
-  - **AspireSample.ApiService**: A [FastAPI](https://fastapi.tiangolo.com/) Python backend service that provides data to the front end.
-  - **AspireSample.Web**: A React-based front-end application with TypeScript.
+  - **AspireSample.ApiService**: A [FastAPI](https://fastapi.tiangolo.com/) Python backend service that provides data to the frontend.
+  - **AspireSample.Web**: A React-based frontend application with TypeScript.
 
   For more information on getting started with Python in Aspire, see [Build your first app](/get-started/first-app-csharp-apphost/?lang=python).
 
diff --git a/src/frontend/src/content/docs/get-started/deploy-first-app-csharp.mdx b/src/frontend/src/content/docs/get-started/deploy-first-app-csharp.mdx
index c63d1f539..359d88644 100644
--- a/src/frontend/src/content/docs/get-started/deploy-first-app-csharp.mdx
+++ b/src/frontend/src/content/docs/get-started/deploy-first-app-csharp.mdx
@@ -43,11 +43,11 @@ The following diagram shows the architecture of the sample app you're deploying:
 ```mermaid
 architecture-beta
     group api-docker(logos:docker-icon)[API container]
-    group f-docker(logos:docker-icon)[Front-end container]
+    group f-docker(logos:docker-icon)[Frontend container]
 
     service api(logos:dotnet)[API service] in api-docker
     service http(iconoir:server-connection)[https]
-    service frontend(aspire:blazor)[Blazor front end] in f-docker
+    service frontend(aspire:blazor)[Blazor frontend] in f-docker
 
     frontend:L --> R:http
     http:L --> R:api
@@ -63,7 +63,7 @@ architecture-beta
 
   service api(logos:fastapi)[API service] in docker
   service http(iconoir:server-connection)[https] in docker
-  service frontend(logos:react)[React front end] in docker
+  service frontend(logos:react)[React frontend] in docker
 
   frontend:L --> R:http
   http:L --> R:api
@@ -694,7 +694,7 @@ After a deployment, the Aspire CLI writes to the provided output path (or the de
         WEBFRONTEND_PORT=8080
         ```
 
-        Finally, the `docker-compose.yaml` file defines the services for both the API and front end:
+        Finally, the `docker-compose.yaml` file defines the services for both the API and frontend:
 
         ```yaml title="./aspire-output/docker-compose.yaml"
         services:
@@ -765,7 +765,7 @@ After a deployment, the Aspire CLI writes to the provided output path (or the de
         APP_IMAGE=app:5d592d0c1d2f417b0c14c4c4a9efb4f0760be8e4
         ```
 
-        The `app.Dockerfile` is generated as a multi-stage Dockerfile to build the Python and also serve the React front end using Uvicorn:
+        The `app.Dockerfile` is generated as a multi-stage Dockerfile to build the Python and also serve the React frontend using Uvicorn:
 
         ```dockerfile title="./aspire-output/app.Dockerfile"
         ARG FRONTEND_IMAGENAME=frontend:50f0ed07a5b8f57b3213e99d96b2e8ff68a1d5d7
@@ -822,7 +822,7 @@ After a deployment, the Aspire CLI writes to the provided output path (or the de
         ENTRYPOINT ["uvicorn"]
         ```
 
-        Finally, the `docker-compose.yaml` file defines the services for both the API and front end:
+        Finally, the `docker-compose.yaml` file defines the services for both the API and frontend:
 
         ```yaml title="./aspire-output/docker-compose.yaml"
         services:
@@ -917,7 +917,7 @@ To verify that your application is running as expected after deployment, follow
             alt="Deployed ASP.NET Core/Blazor application running in Docker Compose"
         />
 
-        The front end displays the weather forecast data in the ASP.NET Core Blazor application.
+        The frontend displays the weather forecast data in the ASP.NET Core Blazor application.
 
         </Pivot>
         <Pivot id="python">
@@ -937,7 +937,7 @@ To verify that your application is running as expected after deployment, follow
             alt="Deployed Python/React application running in Docker Compose"
         />
 
-        The front end displays the weather forecast data in a stunning React template. In this example, both the API service and the React front end are running within the same Docker container.
+        The frontend displays the weather forecast data in a stunning React template. In this example, both the API service and the React frontend are running within the same Docker container.
 
         </Pivot>
 
@@ -961,7 +961,7 @@ To verify that your application is running as expected after deployment, follow
             alt="Deployed ASP.NET Core/Blazor application running in Docker Compose"
         />
 
-        The front end displays the weather forecast data in the ASP.NET Core Blazor application.
+        The frontend displays the weather forecast data in the ASP.NET Core Blazor application.
 
         </Pivot>
         <Pivot id="python">
@@ -980,7 +980,7 @@ To verify that your application is running as expected after deployment, follow
             alt="Deployed Python/React application running in Docker Compose"
         />
 
-        The front end displays the weather forecast data in a stunning React template. In this example, both the API service and the React front end are running within the same Docker container.
+        The frontend displays the weather forecast data in a stunning React template. In this example, both the API service and the React frontend are running within the same Docker container.
         </Pivot>
 
     </TabItem>
diff --git a/src/frontend/src/content/docs/get-started/deploy-first-app-typescript.mdx b/src/frontend/src/content/docs/get-started/deploy-first-app-typescript.mdx
index e9d3d9d21..701b88b82 100644
--- a/src/frontend/src/content/docs/get-started/deploy-first-app-typescript.mdx
+++ b/src/frontend/src/content/docs/get-started/deploy-first-app-typescript.mdx
@@ -39,7 +39,7 @@ architecture-beta
 
   service api(logos:nodejs-icon)[API service] in docker
   service http(iconoir:server-connection)[https] in docker
-  service frontend(logos:react)[React front end] in docker
+  service frontend(logos:react)[React frontend] in docker
 
   frontend:L --> R:http
   http:L --> R:api
@@ -438,7 +438,7 @@ After a deployment, the Aspire CLI writes to the provided output path (or the de
 
         The `aspire-output` directory contains the generated environment variables, an `app.Dockerfile`, and the Docker Compose configuration. The best part is, these files are opaque to you as a developer—you don't need to write them yourself!
 
-        The `app.Dockerfile` is generated as a multi-stage Dockerfile to build the Express API and also serve the React front end:
+        The `app.Dockerfile` is generated as a multi-stage Dockerfile to build the Express API and also serve the React frontend:
 
         ```dockerfile title="./aspire-output/app.Dockerfile"
         ARG FRONTEND_IMAGENAME=frontend:latest
@@ -537,7 +537,7 @@ To verify that your application is running as expected after deployment, follow
             alt="Deployed Express/React application running in Docker Compose"
         />
 
-        The front end displays the weather forecast data in a stunning React template. In this example, both the API service and the React front end are running within the same Docker container.
+        The frontend displays the weather forecast data in a stunning React template. In this example, both the API service and the React frontend are running within the same Docker container.
 
     </TabItem>
 
@@ -558,7 +558,7 @@ To verify that your application is running as expected after deployment, follow
             alt="Deployed Express/React application running on Azure App Containers"
         />
 
-        The front end displays the weather forecast data in a stunning React template. In this example, both the API service and the React front end are running within the same Docker container.
+        The frontend displays the weather forecast data in a stunning React template. In this example, both the API service and the React frontend are running within the same Docker container.
 
     </TabItem>
 
diff --git a/src/frontend/src/content/docs/get-started/first-app-csharp-apphost.mdx b/src/frontend/src/content/docs/get-started/first-app-csharp-apphost.mdx
index 93b2bcbd1..27efaee10 100644
--- a/src/frontend/src/content/docs/get-started/first-app-csharp-apphost.mdx
+++ b/src/frontend/src/content/docs/get-started/first-app-csharp-apphost.mdx
@@ -43,7 +43,7 @@ The following diagram shows the architecture of the sample app you're creating:
 architecture-beta
 
   service api(logos:dotnet)[API service]
-  service frontend(aspire:blazor)[Blazor front end]
+  service frontend(aspire:blazor)[Blazor frontend]
 
   frontend:L --> R:api
 ```
@@ -61,7 +61,7 @@ The following diagram shows the architecture of the sample app you're creating:
 ```mermaid
 architecture-beta
   service api(logos:fastapi)[API service]
-  service frontend(logos:react)[React front end]
+  service frontend(logos:react)[React frontend]
 
   frontend:L --> R:api
 ```
@@ -71,7 +71,7 @@ architecture-beta
 
 ## Create a new app
 
-To create your first Aspire application, use the [Aspire CLI](/get-started/install-cli/) to generate a new solution from a _starter_ template. These template include multiple projects, such as an API service, a web front end, and an [Aspire AppHost](/get-started/app-host/).
+To create your first Aspire application, use the [Aspire CLI](/get-started/install-cli/) to generate a new solution from a _starter_ template. These template include multiple projects, such as an API service, a web frontend, and an [Aspire AppHost](/get-started/app-host/).
 
 <Steps>
 
@@ -91,7 +91,7 @@ To create your first Aspire application, use the [Aspire CLI](/get-started/insta
     </Pivot>
     
 
-    The template provides several projects, including an API service, web front end, and AppHost.
+    The template provides several projects, including an API service, web frontend, and AppHost.
 
     <Aside type='tip' title='CLI flags' icon='list-format'>
     The following flags are used in the command:
@@ -133,7 +133,7 @@ To create your first Aspire application, use the [Aspire CLI](/get-started/insta
     - AspireApp.ServiceDefaults
         - Extensions.cs
         - AspireApp.ServiceDefaults.csproj
-    - AspireApp.Web  ASP.NET Core Blazor front end
+    - AspireApp.Web  ASP.NET Core Blazor frontend
         - Properties/
         - wwwroot/
         - appsettings.Development.json
@@ -152,7 +152,7 @@ To create your first Aspire application, use the [Aspire CLI](/get-started/insta
             - main.py
             - pyproject.toml
             - telemetry.py
-        - frontend/  Vite + React web front end
+        - frontend/  Vite + React web frontend
             - .dockerignore
             - public/
                 - Aspire.png
@@ -204,9 +204,9 @@ To create your first Aspire application, use the [Aspire CLI](/get-started/insta
     _What's happening here?_
 
     - `CreateBuilder` creates the distributed application builder
-    - `AddProject` registers your API service and web front end
+    - `AddProject` registers your API service and web frontend
     - `WithReference` connects services—it injects the API's URL as an environment variable and sets up service discovery so you can use service names instead of hardcoded URLs
-    - `WaitFor` ensures the API is healthy before starting the front end, preventing connection errors from race conditions
+    - `WaitFor` ensures the API is healthy before starting the frontend, preventing connection errors from race conditions
     - `WithHttpHealthCheck` monitors service health
     
     </Pivot>
@@ -236,10 +236,10 @@ To create your first Aspire application, use the [Aspire CLI](/get-started/insta
     
     - `AddUvicornApp` adds a Uvicorn-based Python app
     - `AddUv` adds a Uv environment setup task: `uv sync`
-    - `AddViteApp` registers your React front end
-    - `WithReference` connects the front end to the API—it injects the API's URL and sets up service discovery
-    - `WaitFor` ensures the API is healthy before starting the front end, preventing connection errors
-    - `PublishWithContainerFiles` bundles the front end for production deployment
+    - `AddViteApp` registers your React frontend
+    - `WithReference` connects the frontend to the API—it injects the API's URL and sets up service discovery
+    - `WaitFor` ensures the API is healthy before starting the frontend, preventing connection errors
+    - `PublishWithContainerFiles` bundles the frontend for production deployment
 
     </Pivot>    
 
diff --git a/src/frontend/src/content/docs/get-started/first-app-typescript-apphost.mdx b/src/frontend/src/content/docs/get-started/first-app-typescript-apphost.mdx
index 9583caa4e..c1a22af2e 100644
--- a/src/frontend/src/content/docs/get-started/first-app-typescript-apphost.mdx
+++ b/src/frontend/src/content/docs/get-started/first-app-typescript-apphost.mdx
@@ -27,7 +27,7 @@ The following diagram shows the architecture of the sample app you're creating:
 ```mermaid
 architecture-beta
   service api(logos:nodejs-icon)[API service]
-  service frontend(logos:react)[React front end]
+  service frontend(logos:react)[React frontend]
 
   frontend:L --> R:api
 ```
@@ -35,7 +35,7 @@ architecture-beta
 
 ## Create a new app
 
-To create your first Aspire application, use the [Aspire CLI](/get-started/install-cli/) to generate a new solution from a _starter_ template. These template include multiple projects, such as an API service, a web front end, and an [Aspire AppHost](/get-started/app-host/).
+To create your first Aspire application, use the [Aspire CLI](/get-started/install-cli/) to generate a new solution from a _starter_ template. These template include multiple projects, such as an API service, a web frontend, and an [Aspire AppHost](/get-started/app-host/).
 
 <Steps>
 
@@ -46,7 +46,7 @@ To create your first Aspire application, use the [Aspire CLI](/get-started/insta
     aspire new aspire-ts-starter -n aspire-app -o aspire-app
     ```
 
-    The template provides several projects, including an API service, web front end, and AppHost.
+    The template provides several projects, including an API service, web frontend, and AppHost.
 
     <Aside type='tip' title='CLI flags' icon='list-format'>
     The following flags are used in the command:
@@ -82,7 +82,7 @@ To create your first Aspire application, use the [Aspire CLI](/get-started/insta
                 - instrumentation.ts
             - package.json
             - tsconfig.json
-        - frontend/  Vite + React web front end
+        - frontend/  Vite + React web frontend
             - public/
                 - Aspire.png
                 - github.svg
@@ -136,10 +136,10 @@ To create your first Aspire application, use the [Aspire CLI](/get-started/insta
 
     - `createBuilder` creates the distributed application builder
     - `addNodeApp` adds a Node.js application (the Express API)
-    - `addViteApp` registers your React front end
-    - `withReference` connects the front end to the API—it injects the API's URL and sets up service discovery
-    - `waitFor` ensures the API is running before starting the front end, preventing connection errors
-    - `publishWithContainerFiles` bundles the front end for production deployment
+    - `addViteApp` registers your React frontend
+    - `withReference` connects the frontend to the API—it injects the API's URL and sets up service discovery
+    - `waitFor` ensures the API is running before starting the frontend, preventing connection errors
+    - `publishWithContainerFiles` bundles the frontend for production deployment
 
     <LearnMore>
     This template uses a TypeScript AppHost. To learn more about how multi-language AppHosts work, see [Multi-language architecture](/architecture/multi-language-architecture/).
diff --git a/src/frontend/src/content/docs/get-started/glossary.mdx b/src/frontend/src/content/docs/get-started/glossary.mdx
index b25a85c18..34b1e8c22 100644
--- a/src/frontend/src/content/docs/get-started/glossary.mdx
+++ b/src/frontend/src/content/docs/get-started/glossary.mdx
@@ -52,8 +52,8 @@ Resources are the building blocks you compose in your AppHost.
 
 A **distributed application** is an application split into multiple independent services that communicate over a network. Instead of one monolithic application, you have:
 
-- A front-end service
-- One or more API services  
+- A frontend service
+- One or more API services
 - Databases
 - Caches
 - Message queues
diff --git a/src/frontend/src/content/docs/get-started/troubleshooting.mdx b/src/frontend/src/content/docs/get-started/troubleshooting.mdx
index 4856e9976..e5de9f977 100644
--- a/src/frontend/src/content/docs/get-started/troubleshooting.mdx
+++ b/src/frontend/src/content/docs/get-started/troubleshooting.mdx
@@ -70,7 +70,7 @@ Having issues getting started with Aspire? This page covers solutions to the mos
 
 ## "Connection refused" errors
 
-**Symptoms**: Your front end can't connect to the API, showing connection refused errors.
+**Symptoms**: Your frontend can't connect to the API, showing connection refused errors.
 
 **Solution**: Make sure you're using `WaitFor()` in your AppHost:
 
diff --git a/src/frontend/src/content/docs/id/index.mdx b/src/frontend/src/content/docs/id/index.mdx
index 10f39ae00..5c7fdc2d3 100644
--- a/src/frontend/src/content/docs/id/index.mdx
+++ b/src/frontend/src/content/docs/id/index.mdx
@@ -13,7 +13,7 @@ banner:
   content: |
     <strong>🚀 Aspire 13.2 telah dirilis!</strong> — <a href="/id/whats-new/aspire-13-2/">Lihat apa yang baru di Aspire 13.2.</a>
 hero:
-  tagline: Stack Anda, disederhanakan. <p>Orkestrasi front end, API, container, dan database dengan mudah—tanpa menulis ulang, tanpa batasan. Perluas Aspire untuk mendukung proyek apa pun.</p>
+  tagline: Stack Anda, disederhanakan. <p>Orkestrasi frontend, API, container, dan database dengan mudah—tanpa menulis ulang, tanpa batasan. Perluas Aspire untuk mendukung proyek apa pun.</p>
   image:
     alt: Logo Aspire
     file: ../../../assets/aspire-hero.png
@@ -58,7 +58,7 @@ import {
     icon="puzzle"
     link="#jelajahi-integrasi"
   >
-    Orkestrasi front end, API, container, dan database tanpa penulisan ulang.
+    Orkestrasi frontend, API, container, dan database tanpa penulisan ulang.
     Perluas Aspire agar pas dengan stack Anda—deploy di mana saja.
   </SimpleCard>
   <SimpleCard
diff --git a/src/frontend/src/content/docs/index.mdx b/src/frontend/src/content/docs/index.mdx
index 580c41b62..e27fabc91 100644
--- a/src/frontend/src/content/docs/index.mdx
+++ b/src/frontend/src/content/docs/index.mdx
@@ -13,7 +13,7 @@ banner:
   content: |
     <strong>Aspire 13.2 is here!</strong> Get the latest release that brings TypeScript AppHost authoring, an agent-native CLI, and so much more. — <a href="/get-started/install-cli/">Get Aspire 13.2</a>
 hero:
-  tagline: Your stack, streamlined. <p>Orchestrate front ends, APIs, containers, and databases effortlessly—no rewrites, no limits. Extend Aspire to power any project. Free, open-source, and agent ready.</p>
+  tagline: Your stack, streamlined. <p>Orchestrate frontends, APIs, containers, and databases effortlessly—no rewrites, no limits. Extend Aspire to power any project. Free, open-source, and agent ready.</p>
   image:
     alt: Aspire logo
     file: ../../assets/aspire-hero.png
@@ -56,7 +56,7 @@ import {
     icon="puzzle"
     link="#explore-integrations"
   >
-    Orchestrate front ends, APIs, containers, and databases with zero rewrites.
+    Orchestrate frontends, APIs, containers, and databases with zero rewrites.
     Extend Aspire to fit your stack—deploy anywhere.
   </SimpleCard>
   <SimpleCard
diff --git a/src/frontend/src/content/docs/integrations/devtools/k6.mdx b/src/frontend/src/content/docs/integrations/devtools/k6.mdx
index 2464d7cf7..fe938c1c4 100644
--- a/src/frontend/src/content/docs/integrations/devtools/k6.mdx
+++ b/src/frontend/src/content/docs/integrations/devtools/k6.mdx
@@ -109,7 +109,7 @@ var k6 = builder.AddK6("k6", enableBrowserExtensions: true)
 // After adding all resources, run the app...
 ```
 
-The browser module brings browser automation and end-to-end web testing to k6 while supporting core k6 features. It adds browser-level APIs to interact with browsers and collect front-end performance metrics as part of your k6 tests.
+The browser module brings browser automation and end-to-end web testing to k6 while supporting core k6 features. It adds browser-level APIs to interact with browsers and collect frontend performance metrics as part of your k6 tests.
 
 For more information on how to use Grafana k6 browser, see the [Using k6 browser](https://grafana.com/docs/k6/latest/using-k6-browser/).
 
diff --git a/src/frontend/src/content/docs/integrations/dotnet/project-resources.mdx b/src/frontend/src/content/docs/integrations/dotnet/project-resources.mdx
index 0d073baa6..f7a5cf5ff 100644
--- a/src/frontend/src/content/docs/integrations/dotnet/project-resources.mdx
+++ b/src/frontend/src/content/docs/integrations/dotnet/project-resources.mdx
@@ -207,7 +207,7 @@ The following diagram shows this setup:
 
 <Image
   src={proxyWithReplicas}
-  alt="Aspire front-end app networking diagram with specific host port and two replicas."
+  alt="Aspire frontend app networking diagram with specific host port and two replicas."
 />
 
 With that configuration:
@@ -226,7 +226,7 @@ builder.AddProject<Projects.Networking_Frontend>("frontend")
 
 <Image
   src={proxyHostPortAndRandomPort}
-  alt="Aspire front-end app networking diagram with specific host port and random port."
+  alt="Aspire frontend app networking diagram with specific host port and random port."
 />
 
 In this configuration:
@@ -244,7 +244,7 @@ builder.AddProject<Projects.Networking_Frontend>("frontend")
 
 <Image
   src={proxyWithRandomPorts}
-  alt="Aspire front-end app networking diagram with random host port and proxy port."
+  alt="Aspire frontend app networking diagram with random host port and proxy port."
 />
 
 In this configuration, Aspire assigns a random proxy port for the host-facing endpoint and a separate random internal port for the project.
diff --git a/src/frontend/src/content/docs/integrations/frameworks/javascript.mdx b/src/frontend/src/content/docs/integrations/frameworks/javascript.mdx
index 91827dec9..1c4b826b7 100644
--- a/src/frontend/src/content/docs/integrations/frameworks/javascript.mdx
+++ b/src/frontend/src/content/docs/integrations/frameworks/javascript.mdx
@@ -120,7 +120,7 @@ Do _not_ call `.WithHttpEndpoint()` on a Vite resource. `AddViteApp` already reg
 
 :::note
 The Vite dev server is only used for local development. During publish, Aspire
-builds the front-end assets, but another resource must serve those built files in
+builds the frontend assets, but another resource must serve those built files in
 production.
 :::
 
@@ -376,10 +376,10 @@ export async function fetchData() {
   `import.meta.env` variables are replaced at **build time** by Vite. For
   dynamic runtime values (such as a URL that changes per environment), consider
   using a server-rendered configuration endpoint instead. See [Pass runtime
-  configuration to SPA front ends](#pass-runtime-configuration-to-spa-frontends).
+  configuration to SPA frontends](#pass-runtime-configuration-to-spa-frontends).
 </Aside>
 
-## Pass runtime configuration to SPA front ends
+## Pass runtime configuration to SPA frontends
 
 Vite and other SPA build tools bake environment variables (such as `VITE_*`) into the JavaScript bundle at **build time** (for example, when building the client for production). However, Aspire sets environment variables at **runtime**. This means calling `.WithEnvironment("VITE_GOOGLE_CLIENT_ID", parameter)` on a Vite resource won't change values that were already baked into a previously built production bundle.
 
@@ -389,7 +389,7 @@ To bridge this gap, pass the parameter to your API project as a standard environ
 
 1. **Pass the parameter to the API in the AppHost**
 
-   Define the parameter in the AppHost and pass it to the API project using `WithEnvironment`. Then reference the API from the front end so it can call the endpoint:
+   Define the parameter in the AppHost and pass it to the API project using `WithEnvironment`. Then reference the API from the frontend so it can call the endpoint:
 
    ```csharp title="C# — AppHost.cs"
    var builder = DistributedApplication.CreateBuilder(args);
@@ -427,12 +427,12 @@ To bridge this gap, pass the parameter to your API project as a standard environ
 
      Use this pattern only for non-secret/public configuration values (for
      example OAuth client IDs). Do not expose secrets such as client secrets,
-     API keys, or connection strings via a front-end config endpoint.
+     API keys, or connection strings via a frontend config endpoint.
    </Aside>
 
 3. **Fetch the config value in the SPA**
 
-   In your front-end application, fetch the configuration value at startup instead of reading from `import.meta.env`:
+   In your frontend application, fetch the configuration value at startup instead of reading from `import.meta.env`:
 
    ```typescript title="TypeScript — config.ts"
    export async function getConfig() {
@@ -519,32 +519,32 @@ When you publish your application, Aspire automatically:
 1. Generates publish-time build artifacts for containerized deployment
 2. Installs dependencies using deterministic install commands based on lockfiles
 3. Runs the build script (typically "build") to create production assets
-4. Produces front-end build output that another resource can include or serve
+4. Produces frontend build output that another resource can include or serve
 
 This ensures your JavaScript applications are built consistently across
 environments and can participate in Aspire publishing workflows.
 
 :::caution[Production deployment rule]
 `AddJavaScriptApp` and `AddViteApp` are not, by themselves, the production web
-server for your front end.
+server for your frontend.
 
-During publish, Aspire uses them to build front-end assets. To deploy that
-front end, you must choose another resource to serve those built files in
+During publish, Aspire uses them to build frontend assets. To deploy that
+frontend, you must choose another resource to serve those built files in
 production.
 
 Adding `AddJavaScriptApp` or `AddViteApp` plus `.WithReference(...)` is not
-enough to make the front end independently deployable.
+enough to make the frontend independently deployable.
 :::
 
 :::note
 Local Vite proxy and route behavior does not automatically become production
-behavior. If your front end depends on Vite development-server routing or proxy
+behavior. If your frontend depends on Vite development-server routing or proxy
 configuration, configure the production-serving resource separately.
 :::
 
 <LearnMore>
   For the production deployment patterns used by `AddJavaScriptApp` and
-  `AddViteApp`, including who serves the built front end in production, see
+  `AddViteApp`, including who serves the built frontend in production, see
   [Deploy JavaScript apps](/deployment/javascript-apps/).
 </LearnMore>
 
diff --git a/src/frontend/src/content/docs/integrations/frameworks/orleans.mdx b/src/frontend/src/content/docs/integrations/frameworks/orleans.mdx
index 80bbac504..cbe1b3e34 100644
--- a/src/frontend/src/content/docs/integrations/frameworks/orleans.mdx
+++ b/src/frontend/src/content/docs/integrations/frameworks/orleans.mdx
@@ -86,7 +86,7 @@ When you reference the Orleans resource from your service, those resources are a
 
 ### Add an Orleans client project
 
-Orleans clients communicate with grains hosted on Orleans servers. In an Aspire app, for example, you might have a front-end web site that calls grains in an Orleans cluster. Reference the Orleans resource from your Orleans client using `WithReference(orleans.AsClient())`:
+Orleans clients communicate with grains hosted on Orleans servers. In an Aspire app, for example, you might have a frontend web site that calls grains in an Orleans cluster. Reference the Orleans resource from your Orleans client using `WithReference(orleans.AsClient())`:
 
 ```csharp title="C# — AppHost.cs"
 var builder = DistributedApplication.CreateBuilder(args);
diff --git a/src/frontend/src/content/docs/integrations/reverse-proxies/yarp.mdx b/src/frontend/src/content/docs/integrations/reverse-proxies/yarp.mdx
index 7370dbd82..a17a8c84b 100644
--- a/src/frontend/src/content/docs/integrations/reverse-proxies/yarp.mdx
+++ b/src/frontend/src/content/docs/integrations/reverse-proxies/yarp.mdx
@@ -162,7 +162,7 @@ var staticServer = builder.AddYarp("static")
                           .WithStaticFiles("../static");
 ```
 
-For building front-end applications, you can use a Docker multi-stage build:
+For building frontend applications, you can use a Docker multi-stage build:
 
 ```csharp title="C# — AppHost.cs"
 var builder = DistributedApplication.CreateBuilder(args);
diff --git a/src/frontend/src/content/docs/it/index.mdx b/src/frontend/src/content/docs/it/index.mdx
index 7c9c17da7..384c10921 100644
--- a/src/frontend/src/content/docs/it/index.mdx
+++ b/src/frontend/src/content/docs/it/index.mdx
@@ -13,7 +13,7 @@ banner:
   content: |
     <strong>🚀 Aspire 13.2 è disponibile!</strong> — <a href="/it/whats-new/aspire-13-2/">Scopri le novità di Aspire 13.2.</a>
 hero:
-  tagline: Il tuo stack, semplificato. <p>Orchestra front end, API, container e database senza sforzo—senza riscritture, senza limiti. Estendi Aspire per potenziare qualsiasi progetto.</p>
+  tagline: Il tuo stack, semplificato. <p>Orchestra frontend, API, container e database senza sforzo—senza riscritture, senza limiti. Estendi Aspire per potenziare qualsiasi progetto.</p>
   image:
     alt: Logo Aspire
     file: ../../../assets/aspire-hero.png
@@ -57,7 +57,7 @@ import {
     icon="puzzle"
     link="#esplora-le-integrazioni"
   >
-    Orchestra front end, API, container e database senza riscritture. Estendi
+    Orchestra frontend, API, container e database senza riscritture. Estendi
     Aspire per adattarlo al tuo stack—distribuisci ovunque.
   </SimpleCard>
   <SimpleCard
diff --git a/src/frontend/src/content/docs/ja/get-started/app-host.mdx b/src/frontend/src/content/docs/ja/get-started/app-host.mdx
index a68b0613b..bc8722efa 100644
--- a/src/frontend/src/content/docs/ja/get-started/app-host.mdx
+++ b/src/frontend/src/content/docs/ja/get-started/app-host.mdx
@@ -40,7 +40,7 @@ architecture-beta
 
   service db(logos:postgresql)[PostgreSQL]
   service api(logos:dotnet)[API service]
-  service frontend(logos:react)[React front end]
+  service frontend(logos:react)[React frontend]
 
   api:R --> L:db
   frontend:R --> L:api
@@ -58,7 +58,7 @@ architecture-beta
 
   service db(logos:postgresql)[PostgreSQL]
   service api(logos:python)[API service]
-  service frontend(logos:react)[React front end]
+  service frontend(logos:react)[React frontend]
 
   api:R --> L:db
   frontend:R --> L:api
@@ -80,7 +80,7 @@ architecture-beta
 
   service db(logos:postgresql)[PostgreSQL]
   service api(logos:nodejs-icon)[API service]
-  service frontend(logos:react)[React front end]
+  service frontend(logos:react)[React frontend]
 
   api:R --> L:db
   frontend:R --> L:api
@@ -100,7 +100,7 @@ architecture-beta
 
   service db(logos:postgresql)[PostgreSQL]
   service api(logos:go)[API service]
-  service frontend(logos:react)[React front end]
+  service frontend(logos:react)[React frontend]
 
   api:R --> L:db
   frontend:R --> L:api
@@ -120,7 +120,7 @@ architecture-beta
 
   service db(logos:postgresql)[PostgreSQL]
   service api(logos:java)[API service]
-  service frontend(logos:react)[React front end]
+  service frontend(logos:react)[React frontend]
 
   api:R --> L:db
   frontend:R --> L:api
@@ -572,7 +572,7 @@ architecture-beta
   service epr(iconoir:server-connection)[Endpoint Reference]
   service api(logos:dotnet)[api]
   service ctr(iconoir:server-connection)[Connection String Reference]
-  service frontend(logos:react)[front end]
+  service frontend(logos:react)[frontend]
 
   db:L <-- R:ctr
   ctr:L <-- R:api
@@ -592,7 +592,7 @@ architecture-beta
   service epr(iconoir:server-connection)[Endpoint Reference]
   service api(logos:python)[api]
   service ctr(iconoir:server-connection)[Connection String Reference]
-  service frontend(logos:react)[front end]
+  service frontend(logos:react)[frontend]
 
   db:L <-- R:ctr
   ctr:L <-- R:api
@@ -612,7 +612,7 @@ architecture-beta
   service epr(iconoir:server-connection)[Endpoint Reference]
   service api(logos:nodejs-icon)[api]
   service ctr(iconoir:server-connection)[Connection String Reference]
-  service frontend(logos:react)[front end]
+  service frontend(logos:react)[frontend]
 
   db:L <-- R:ctr
   ctr:L <-- R:api
@@ -632,7 +632,7 @@ architecture-beta
   service epr(iconoir:server-connection)[Endpoint Reference]
   service api(logos:go)[api]
   service ctr(iconoir:server-connection)[Connection String Reference]
-  service frontend(logos:react)[front end]
+  service frontend(logos:react)[frontend]
 
   db:L <-- R:ctr
   ctr:L <-- R:api
@@ -652,7 +652,7 @@ architecture-beta
   service epr(iconoir:server-connection)[Endpoint Reference]
   service api(logos:java)[api]
   service ctr(iconoir:server-connection)[Connection String Reference]
-  service frontend(logos:react)[front end]
+  service frontend(logos:react)[frontend]
 
   db:L <-- R:ctr
   ctr:L <-- R:api
diff --git a/src/frontend/src/content/docs/ja/get-started/deploy-first-app.mdx b/src/frontend/src/content/docs/ja/get-started/deploy-first-app.mdx
index 471529bc1..d3b28bf09 100644
--- a/src/frontend/src/content/docs/ja/get-started/deploy-first-app.mdx
+++ b/src/frontend/src/content/docs/ja/get-started/deploy-first-app.mdx
@@ -45,11 +45,11 @@ import dockerIcon from '@assets/icons/docker.svg';
 ```mermaid
 architecture-beta
     group api-docker(logos:docker-icon)[API container]
-    group f-docker(logos:docker-icon)[Front end container]
+    group f-docker(logos:docker-icon)[Frontend container]
 
     service api(logos:dotnet)[API service] in api-docker
     service http(iconoir:server-connection)[https]
-    service frontend(aspire:blazor)[Blazor front end] in f-docker
+    service frontend(aspire:blazor)[Blazor frontend] in f-docker
 
     frontend:L --> R:http
     http:L --> R:api
@@ -65,7 +65,7 @@ architecture-beta
 
   service api(logos:fastapi)[API service] in docker
   service http(iconoir:server-connection)[https] in docker
-  service frontend(logos:react)[React front end] in docker
+  service frontend(logos:react)[React frontend] in docker
 
   frontend:L --> R:http
   http:L --> R:api
diff --git a/src/frontend/src/content/docs/ja/get-started/first-app.mdx b/src/frontend/src/content/docs/ja/get-started/first-app.mdx
index 8f544fba0..4ef7efaa9 100644
--- a/src/frontend/src/content/docs/ja/get-started/first-app.mdx
+++ b/src/frontend/src/content/docs/ja/get-started/first-app.mdx
@@ -42,7 +42,7 @@ import fastApiIcon from "@assets/icons/fastapi-icon.svg";
 architecture-beta
 
   service api(logos:dotnet)[API service]
-  service frontend(aspire:blazor)[Blazor front end]
+  service frontend(aspire:blazor)[Blazor frontend]
 
   frontend:L --> R:api
 ```
@@ -61,7 +61,7 @@ architecture-beta
 ```mermaid
 architecture-beta
   service api(logos:fastapi)[API service]
-  service frontend(logos:react)[React front end]
+  service frontend(logos:react)[React frontend]
 
   frontend:L --> R:api
 ```
@@ -142,7 +142,7 @@ architecture-beta
     - AspireApp.ServiceDefaults
         - Extensions.cs
         - AspireApp.ServiceDefaults.csproj
-    - AspireApp.Web  ASP.NET Core Blazor front end
+    - AspireApp.Web  ASP.NET Core Blazor frontend
         - Properties/
         - wwwroot/
         - appsettings.Development.json
@@ -161,7 +161,7 @@ architecture-beta
             - main.py
             - pyproject.toml
             - telemetry.py
-        - frontend/  Vite + React web front end
+        - frontend/  Vite + React web frontend
             - .dockerignore
             - public/
                 - Aspire.png
diff --git a/src/frontend/src/content/docs/ja/testing/overview.mdx b/src/frontend/src/content/docs/ja/testing/overview.mdx
index 0c79341f4..5dbb91bc8 100644
--- a/src/frontend/src/content/docs/ja/testing/overview.mdx
+++ b/src/frontend/src/content/docs/ja/testing/overview.mdx
@@ -23,19 +23,19 @@ Aspire のテスト機能は、分散アプリケーション全体を対象と
 <ThemeImage
   dark={testingDiagram}
   light={testingLightDiagram}
-  alt="テストプロジェクトが AppHost を起動し、AppHost が Database、API、Front end アプリケーションをオーケストレーションする様子を示した Aspire のテスト図です。テストプロジェクトは Front end アプリケーションに HTTP リクエストを送信します。"
+  alt="テストプロジェクトが AppHost を起動し、AppHost が Database、API、Frontend アプリケーションをオーケストレーションする様子を示した Aspire のテスト図です。テストプロジェクトは Frontend アプリケーションに HTTP リクエストを送信します。"
 />
 
 <Steps>
 
 1. The **テストプロジェクト** が AppHost を起動する
 1. The **AppHost** プロセスが起動する
-1. The **AppHost** が `Database`、`API`、`Front end` アプリケーションを実行する
-1. The **テストプロジェクト** が `Front end` アプリケーションに HTTP リクエストを送信する
+1. The **AppHost** が `Database`、`API`、`Frontend` アプリケーションを実行する
+1. The **テストプロジェクト** が `Frontend` アプリケーションに HTTP リクエストを送信する
 
 </Steps>
 
-テストプロジェクトは AppHost を起動し、AppHost は種類に関係なく、依存するすべてのアプリリソースをオーケストレーションします。テストプロジェクトは `Front end` アプリに HTTP リクエストを送信でき、この `Front end` アプリは `API` アプリに依存し、さらに `API` アプリは `Database` に依存しています。リクエストが成功することで、`Front end` アプリが `API` アプリと通信でき、かつ `API` アプリが `Database` から正常にデータを取得できることが確認されます。
+テストプロジェクトは AppHost を起動し、AppHost は種類に関係なく、依存するすべてのアプリリソースをオーケストレーションします。テストプロジェクトは `Frontend` アプリに HTTP リクエストを送信でき、この `Frontend` アプリは `API` アプリに依存し、さらに `API` アプリは `Database` に依存しています。リクエストが成功することで、`Frontend` アプリが `API` アプリと通信でき、かつ `API` アプリが `Database` から正常にデータを取得できることが確認されます。
 
 <Aside type="caution">
   Aspire
diff --git a/src/frontend/src/content/docs/testing/overview.mdx b/src/frontend/src/content/docs/testing/overview.mdx
index a581e0e89..ea623d4d6 100644
--- a/src/frontend/src/content/docs/testing/overview.mdx
+++ b/src/frontend/src/content/docs/testing/overview.mdx
@@ -20,18 +20,18 @@ Aspire's testing capabilities are designed specifically for closed-box integrati
 
 The following diagram shows how the Aspire testing project starts the AppHost, which then starts the application and its resources:
 
-<ThemeImage dark={testingDiagram} light={testingLightDiagram} alt="Aspire testing diagram showing how a test project starts the AppHost, which orchestrates the Database, API, and Front end applications. The test project sends an HTTP request to the Front end application." />
+<ThemeImage dark={testingDiagram} light={testingLightDiagram} alt="Aspire testing diagram showing how a test project starts the AppHost, which orchestrates the Database, API, and Frontend applications. The test project sends an HTTP request to the Frontend application." />
 
 <Steps>
 
 1. The **test project** starts the AppHost.
 1. The **AppHost** process starts.
-1. The **AppHost** runs the `Database`, `API`, and `Front end` applications.
-1. The **test project** sends an HTTP request to the `Front end` application.
+1. The **AppHost** runs the `Database`, `API`, and `Frontend` applications.
+1. The **test project** sends an HTTP request to the `Frontend` application.
 
 </Steps>
 
-The test project starts the AppHost, which then orchestrates all dependent app resources—regardless of their type. The test project can send an HTTP request to the `Front end` app, which depends on an `API` app, and the `API` app depends on a `Database`. A successful request confirms that the `Front end` app can communicate with the `API` app, and that the `API` app can successfully get data from the `Database`.
+The test project starts the AppHost, which then orchestrates all dependent app resources—regardless of their type. The test project can send an HTTP request to the `Frontend` app, which depends on an `API` app, and the `API` app depends on a `Database`. A successful request confirms that the `Frontend` app can communicate with the `API` app, and that the `API` app can successfully get data from the `Database`.
 
 <Aside type="caution">
 Aspire testing doesn't enable scenarios for mocking, substituting, or replacing services in dependency injection—as the tests run in a separate process.
diff --git a/src/frontend/src/content/docs/whats-new/aspire-13-1.mdx b/src/frontend/src/content/docs/whats-new/aspire-13-1.mdx
index e54a88503..32dd8e4a7 100644
--- a/src/frontend/src/content/docs/whats-new/aspire-13-1.mdx
+++ b/src/frontend/src/content/docs/whats-new/aspire-13-1.mdx
@@ -26,7 +26,7 @@ This release introduces:
 - **Dashboard improvements**: Dedicated Parameters tab and GenAI visualizer enhancements.
 - **Azure Managed Redis**: Renamed from `AddAzureRedisEnterprise` to `AddAzureManagedRedis` with improved validation.
 - **Container registry support**: New `ContainerRegistryResource` for general-purpose container registries.
-- **JavaScript improvements**: New front-end starter template, Vite HTTPS configuration, and pnpm fixes.
+- **JavaScript improvements**: New frontend starter template, Vite HTTPS configuration, and pnpm fixes.
 - **DevTunnels stabilization**: [📦 Aspire.Hosting.DevTunnels](https://www.nuget.org/packages/Aspire.Hosting.DevTunnels) is now a stable package.
 - **TLS termination support**: New APIs for configuring HTTPS certificates on containers and resources.
 - **Connection properties for Azure resources**: Multi-language support for Azure resource connection strings.
@@ -335,11 +335,11 @@ builder.AddDockerComposeEnvironment("compose")
 Learn more about the [Docker Compose integration](/integrations/compute/docker/).
 </LearnMore>
 
-## 🌐 JavaScript and front-end support
+## 🌐 JavaScript and frontend support
 
-### JavaScript front-end starter template
+### JavaScript frontend starter template
 
-A new `aspire-ts-cs-starter` template provides a ready-to-use JavaScript front-end setup:
+A new `aspire-ts-cs-starter` template provides a ready-to-use JavaScript frontend setup:
 
 ```bash title="Aspire CLI — Starter App ASP.NET Core/React"
 aspire new aspire-ts-cs-starter
@@ -356,7 +356,7 @@ The template uses `npm` by default. You can switch to `yarn` or `pnpm` after pro
 :::
 
 <LearnMore>
-Learn more about the [JavaScript front-end integration](/integrations/frameworks/javascript/).
+Learn more about the [JavaScript frontend integration](/integrations/frameworks/javascript/).
 </LearnMore>
 
 ### Vite HTTPS configuration
diff --git a/src/frontend/src/content/docs/whats-new/aspire-13.mdx b/src/frontend/src/content/docs/whats-new/aspire-13.mdx
index 3b6650343..ce1ae8b5b 100644
--- a/src/frontend/src/content/docs/whats-new/aspire-13.mdx
+++ b/src/frontend/src/content/docs/whats-new/aspire-13.mdx
@@ -348,14 +348,14 @@ aspire new aspire-py-starter
 This template includes:
 
 - **FastAPI backend**: Python ASGI application using Uvicorn.
-- **Vite + React front end**: Modern JavaScript front end with TypeScript.
+- **Vite + React frontend**: Modern JavaScript frontend with TypeScript.
 - **OpenTelemetry integration**: Distributed tracing, logs, and metrics.
 - **Redis caching** (optional): A distributed cache across requests.
-- **Container files**: Front-end static files served by the Python backend.
+- **Container files**: Frontend static files served by the Python backend.
 
-Build a full-stack multi-language app—Python back end + JavaScript front end—fast. Explore it, customize it, ship it. [Create one now](/get-started/first-app-csharp-apphost/?lang=python) and [deploy it today](/get-started/deploy-first-app-csharp/?lang=python)!
+Build a full-stack multi-language app—Python backend + JavaScript frontend—fast. Explore it, customize it, ship it. [Create one now](/get-started/first-app-csharp-apphost/?lang=python) and [deploy it today](/get-started/deploy-first-app-csharp/?lang=python)!
 
-The React front end communicates with the FastAPI back end via HTTP endpoints, demonstrating seamless integration between the two languages within a single Aspire application. The new template has a modern UX:
+The React frontend communicates with the FastAPI backend via HTTP endpoints, demonstrating seamless integration between the two languages within a single Aspire application. The new template has a modern UX:
 
 import pythonStarterDarkPng from '@assets/get-started/python-starter-dark.png';
 import pythonStarterLightPng from '@assets/get-started/python-starter-light.png';
@@ -663,7 +663,7 @@ Select a template:
 
 **Available starter templates:**
 
-- [**Blazor & Minimal API starter**](/get-started/first-app-csharp-apphost/?lang=csharp): Full-stack .NET application with Blazor front end and ASP.NET Core API.
+- [**Blazor & Minimal API starter**](/get-started/first-app-csharp-apphost/?lang=csharp): Full-stack .NET application with Blazor frontend and ASP.NET Core API.
 - [**React (Vite) & FastAPI starter**](/get-started/first-app-csharp-apphost/?lang=python): Multi-language application demonstrating Python and JavaScript integration.
 - **Empty AppHost**: Minimal single-file AppHost for custom applications.
 
@@ -852,7 +852,7 @@ aspire do deploy --log-level debug            # Verbose logging for troubleshoot
 
 ### Container files as build artifacts
 
-Aspire 13.0 introduces the ability to **extract files from one resource's container and copy them into another resource's container** during the build process. This enables powerful patterns like building a front end in one container and serving it from a backend in another container.
+Aspire 13.0 introduces the ability to **extract files from one resource's container and copy them into another resource's container** during the build process. This enables powerful patterns like building a frontend in one container and serving it from a backend in another container.
 
 ```csharp title="C# — Container files as build artifacts"
 var frontend = builder.AddViteApp("frontend", "./frontend");
@@ -868,13 +868,13 @@ api.PublishWithContainerFiles(frontend, "./static");
 1. The `frontend` resource builds inside its container, producing output files.
 2. Aspire extracts those files from the `frontend` container.
 3. The files are copied into the `api` container at `./static`.
-4. The final `api` container contains both the API code and the front-end static files.
+4. The final `api` container contains both the API code and the frontend static files.
 
-**Example: Serving front end from backend**
+**Example: Serving frontend from backend**
 
 The FastAPI app can serve the static files:
 
-```python title="Python — Serving front end from back end"
+```python title="Python — Serving frontend from backend"
 from fastapi import FastAPI
 from fastapi.staticfiles import StaticFiles
 
diff --git a/src/frontend/src/content/docs/whats-new/aspire-9-3.mdx b/src/frontend/src/content/docs/whats-new/aspire-9-3.mdx
index 13407b94f..d17036d0a 100644
--- a/src/frontend/src/content/docs/whats-new/aspire-9-3.mdx
+++ b/src/frontend/src/content/docs/whats-new/aspire-9-3.mdx
@@ -245,7 +245,7 @@ For more details on requirements and how to get started, see [GitHub Copilot in
 
 ### 🧠 Remembers your filter settings
 
-The Aspire dashboard now **remembers your resource filter settings** between sessions. Previously, if you filtered the Resources view (for example, to hide support services or highlight only front-end apps), those filters were reset on page reload.
+The Aspire dashboard now **remembers your resource filter settings** between sessions. Previously, if you filtered the Resources view (for example, to hide support services or highlight only frontend apps), those filters were reset on page reload.
 
 As of 9.3, filter state is **persisted in local storage**, so your selections stick across refreshes and restarts. This small improvement makes it easier to focus on the parts of your app that matter most—especially in large graphs with many supporting services like Redis, SQL, or queues.
 
@@ -354,10 +354,10 @@ builder.AddProject<Projects.Frontend>("frontend")
        .WithComputeEnvironment(k8s);
 ```
 
-This (contrived) example shows how you could explicitly map services to different compute targets—modeling, for example, a front end in Kubernetes and a backend in Docker Compose.
+This (contrived) example shows how you could explicitly map services to different compute targets—modeling, for example, a frontend in Kubernetes and a backend in Docker Compose.
 
 <Aside type="note">
-💡 Imagine a real-world case where your front end is deployed to a CDN or GitHub Pages, and your backend runs in Azure Container Apps. This new model makes that future possible.
+💡 Imagine a real-world case where your frontend is deployed to a CDN or GitHub Pages, and your backend runs in Azure Container Apps. This new model makes that future possible.
 </Aside>
 
 ⚠️ All previous publisher registration APIs (like `AddDockerComposePublisher()`) have been removed in favor of this new model.
diff --git a/src/frontend/src/content/docs/whats-new/aspire-9-5.mdx b/src/frontend/src/content/docs/whats-new/aspire-9-5.mdx
index c2840aaf2..8b63f6475 100644
--- a/src/frontend/src/content/docs/whats-new/aspire-9-5.mdx
+++ b/src/frontend/src/content/docs/whats-new/aspire-9-5.mdx
@@ -375,7 +375,7 @@ The Dev Tunnels integration automatically handles Azure authentication, tunnel l
 
 ### YARP static files support
 
-Aspire 9.5 adds comprehensive static file serving capabilities to the YARP integration, enabling you to serve static assets directly from YARP alongside reverse proxy functionality. This is perfect for single-page applications, front-end assets, and hybrid scenarios where you need both static content and API proxying.
+Aspire 9.5 adds comprehensive static file serving capabilities to the YARP integration, enabling you to serve static assets directly from YARP alongside reverse proxy functionality. This is perfect for single-page applications, frontend assets, and hybrid scenarios where you need both static content and API proxying.
 
 **Features:**
 
@@ -436,7 +436,7 @@ var gateway = builder.AddYarp("app-gateway")
 builder.Build().Run();
 ```
 
-This feature enables modern web application architectures where YARP acts as both a reverse proxy for backend services and a static file server for front-end assets, providing a unified entry point for your distributed application.
+This feature enables modern web application architectures where YARP acts as both a reverse proxy for backend services and a static file server for frontend assets, providing a unified entry point for your distributed application.
 
 For more information, see [Aspire YARP integration](https://aspire.dev/integrations/reverse-proxies/yarp/).
 
diff --git a/src/frontend/src/content/i18n/en.json b/src/frontend/src/content/i18n/en.json
index 745b8d4c9..e5a51f670 100644
--- a/src/frontend/src/content/i18n/en.json
+++ b/src/frontend/src/content/i18n/en.json
@@ -89,7 +89,7 @@
     "api": "API service",
     "container": "Container",
     "deploy": "Deployment options",
-    "frontendTooltip": "Toggle an example front-end setup",
+    "frontendTooltip": "Toggle an example frontend setup",
     "databaseTooltip": "Toggle an example database setup",
     "apiTooltip": "Toggle an example API setup",
     "containerTooltip": "Toggle an example container setup",

From 71f22abefae5d380fc54669e1f787cb96ebfda50 Mon Sep 17 00:00:00 2001
From: AJ Matthews <alistair.matthews@civica.co.uk>
Date: Wed, 8 Apr 2026 12:24:56 +0100
Subject: [PATCH 3/3] Implemented feedback from @copilot.

---
 src/frontend/src/content/docs/dashboard/overview.mdx   | 2 +-
 src/frontend/src/content/docs/get-started/app-host.mdx | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/src/frontend/src/content/docs/dashboard/overview.mdx b/src/frontend/src/content/docs/dashboard/overview.mdx
index 7ae7275a8..dce258055 100644
--- a/src/frontend/src/content/docs/dashboard/overview.mdx
+++ b/src/frontend/src/content/docs/dashboard/overview.mdx
@@ -70,7 +70,7 @@ For more information, see [Aspire dashboard configuration](/dashboard/configurat
 
 ## Architecture
 
-The dashboard user experience is built with a variety of technologies. The frontend is built with [Grpc.AspNetCore](https://www.nuget.org/packages/Grpc.AspNetCore) NuGet package to the resource server. Consider the following diagram that illustrates the architecture of the Aspire dashboard:
+The dashboard user experience is built with a variety of technologies. The frontend communicates with the resource server over gRPC using the [Grpc.AspNetCore](https://www.nuget.org/packages/Grpc.AspNetCore) NuGet package. Consider the following diagram that illustrates the architecture of the Aspire dashboard:
 
 <ThemeImage 
   light={architectureDiagramLight}
diff --git a/src/frontend/src/content/docs/get-started/app-host.mdx b/src/frontend/src/content/docs/get-started/app-host.mdx
index 809e26c5f..eb74b8086 100644
--- a/src/frontend/src/content/docs/get-started/app-host.mdx
+++ b/src/frontend/src/content/docs/get-started/app-host.mdx
@@ -527,7 +527,7 @@ This example uses a Node.js (React) frontend, but Aspire treats frontends as exe
     <ul>
       <li><code>addViteApp("frontend", "../frontend")</code> registers the frontend as a service named <code>frontend</code>.</li>
       <li><code>withHttpEndpoint({'{'} env: "PORT" {'}'})</code> exposes the app and lets the <code>PORT</code> environment variable control the listener.</li>
-      <li><code>WithReference(api)</code> injects the API base address into the frontend configuration.</li>
+      <li><code>withReference(api)</code> injects the API base address into the frontend configuration.</li>
     </ul>
   </div>
 </SimpleAppHostCode>
@@ -561,7 +561,7 @@ In short: define the backend first (DB → API), then point the UI at the API. T
 
 #### Configuration and networking
 
-These dependencies and connections are automatically managed by Aspire. The AppHost generates configuration values like connection strings and endpoints, injecting them into services as needed. in the AppHost when you add resources, you name them (e.g., `db`, `api`, `frontend`); Aspire uses these names for DNS resolution, so services can communicate using predictable addresses. Consuming services also rely on these names for configuration injection.
+These dependencies and connections are automatically managed by Aspire. The AppHost generates configuration values like connection strings and endpoints, injecting them into services as needed. In the AppHost when you add resources, you name them (e.g., `db`, `api`, `frontend`); Aspire uses these names for DNS resolution, so services can communicate using predictable addresses. Consuming services also rely on these names for configuration injection.
 
 <Pivot id="csharp">