Skip to content

Update Manage applications guides to use the synced demo sample #1994

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Open
zachcasper wants to merge 2 commits into
base: edge
Choose a base branch
from
+88 −222
Open

Update Manage applications guides to use the synced demo sample #1994

Show file tree
Hide file tree
Changes from all commits
Commits
Show all changes
2 commits
Select commit Hold shift + click to select a range
0ade40c
Updated manage applications section to use sample app.bicep
zachcasper Aug 19, 2026
7f33505
Merge branch 'edge' into zachcasper-update-manage-applications
Reshrahim Aug 21, 2026
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
108 changes: 21 additions & 87 deletions docs/content/applications/connections/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -10,128 +10,62 @@ aliases:

A connection is an explicit relationship between two resources in your [Application]({{< ref "/concepts/applications" >}}). Declaring a connection from a Container to another resource adds an edge to the Application graph and injects the connected resource's properties into the Container as environment variables. Your application then reads those variables instead of hard-coding hosts, ports, or credentials.

This guide adds a Redis cache to an application and connects a Container to it. It builds on the definition from [How to model an application definition]({{< ref "/applications/definitions" >}}).
This guide adds a Redis cache to an application and connects a Container to it. It builds on the definition from [How to model application resources]({{< ref "/applications/definitions" >}}).

## Step 1: Start from an application definition

Begin with a definition that declares an Application and a Container. The following `app.bicep` defines a `frontend` Container:

```bicep
extension radius

@description('The Radius Environment ID. Injected automatically by the rad CLI.')
param environment string

resource app 'Radius.Core/applications@2025-08-01-preview' = {
name: 'my-app'
properties: {
environment: environment
}
}

resource frontend 'Radius.Compute/containers@2025-08-01-preview' = {
name: 'frontend'
properties: {
environment: environment
application: app.id
containers: {
web: {
image: 'ghcr.io/radius-project/samples/demo:latest'
ports: {
web: {
containerPort: 3000
}
}
}
}
}
}
```

See [How to model an application definition]({{< ref "/applications/definitions" >}}) to build this file from scratch.
Begin with the Radius Demo `app.bicep` from [How to model application resources]({{< ref "/applications/definitions" >}}). It declares a `demoApp` Application and a `demoContainer` Container, which the following steps connect to a Redis cache.

## Step 2: Add the resource to connect to

Add the dependency the Container needs. The following example adds a `Radius.Data/redisCaches` resource named `db` to the same Application:
<!-- markdownlint-disable-next-line MD033 -->
Add the dependency the Container needs. The demo's <a href="https://github.com/radius-project/samples/blob/{{< param version >}}/samples/demo/app-redis.bicep" target="_blank" rel="noopener">`app-redis.bicep`</a> definition adds a `Radius.Data/redisCaches` resource named `redis` to the same Application:

```bicep
resource db 'Radius.Data/redisCaches@2025-08-01-preview' = {
name: 'db'
properties: {
environment: environment
application: app.id
}
}
```
{{< rad file="/static/samples/demo/app-redis.bicep" embed=true startLine=40 endLine=47 >}}

@Reshrahim Reshrahim Aug 21, 2026

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the app.bicep changes then the line numbers may be get messed up. I think markers like //REDIS might be better to stay in sync


## Step 3: Connect the Container to the resource

Add a `connections` entry to the Container's `properties`. Each connection has a name and a `source` set to the target resource's `.id`:

```bicep
resource frontend 'Radius.Compute/containers@2025-08-01-preview' = {
name: 'frontend'
properties: {
environment: environment
application: app.id
containers: {
web: {
image: 'ghcr.io/radius-project/samples/demo:latest'
ports: {
web: {
containerPort: 3000
}
}
}
}
connections: {
redis: {
source: db.id
}
}
}
}
```
{{< rad file="/static/samples/demo/app-redis.bicep" embed=true startLine=17 endLine=38 markdownConfig=`{hl_lines=["16-20"]}` >}}

The connection name (`redis`) becomes the prefix of the environment variables Radius injects into the Container. Referencing `db.id` also orders the deployment so Radius creates the cache before the Container.
The connection name (`redis`) becomes the prefix of the environment variables Radius injects into the Container. Referencing `redis.id` also orders the deployment so Radius creates the cache before the Container.

## Step 4: Deploy the application

Deploy the updated definition with [`rad deploy`]({{< ref rad_deploy >}}):
Deploy the updated definition from its published URL with [`rad deploy`]({{< ref rad_deploy >}}):

```bash
rad deploy app.bicep
```
{{< rad-deploy path="samples/demo/app-redis.bicep" >}}

Radius provisions the Redis cache, injects its connection details into the Container, and records the connection in the Application graph.

## Step 5: Inspect the connection in the Application graph

Use [`rad application graph`]({{< ref rad_application_graph >}}) to view the resources and the connection between them:
Use [`rad application graph`]({{< ref rad_application_graph >}}) to view the resources and the connection between them. The sample includes the Environment name in its resource names; the following command uses the default Environment:

<!-- TODO: Remove the `--preview` flag when the Radius.Core Application implementation is no longer in preview. -->
```bash
rad application graph --application my-app --preview
rad application graph --application demo-default --preview
```

The output shows the `frontend` Container connected to the `db` cache, along with the infrastructure each resource created:
The output shows the `demo-default` Container connected to the `redis-default` cache, along with the infrastructure each resource created:

```text
Displaying application: my-app
Displaying application: demo-default

Name: frontend (Radius.Compute/containers)
Name: demo-default (Radius.Compute/containers)
Connections:
frontend -> db (Radius.Data/redisCaches)
demo-default -> redis-default (Radius.Data/redisCaches)
Resources:
frontend (kubernetes: apps/Deployment)
frontend (kubernetes: core/Service)
demo-default (kubernetes: apps/Deployment)
demo-default (kubernetes: core/Service)

Name: db (Radius.Data/redisCaches)
Name: redis-default (Radius.Data/redisCaches)
Connections:
frontend (Radius.Compute/containers) -> db
demo-default (Radius.Compute/containers) -> redis-default
Resources:
db (kubernetes: apps/Deployment)
db (kubernetes: core/Service)
redis-default (kubernetes: apps/Deployment)
redis-default (kubernetes: core/Service)
```

## Connection environment variables
Expand Down
118 changes: 42 additions & 76 deletions docs/content/applications/definitions/_index.md
View file
Open in desktop
Original file line number Diff line number Diff line change
@@ -1,83 +1,66 @@
---
type: docs
title: "How to model an application definition"
title: "How to model application resources"
linkTitle: "Model application resources"
description: "Learn how to model an application using Bicep and Radius Resource Types"
weight: 100
---

An application definition is a Bicep file that declares your [Application]({{< ref "/concepts/applications" >}}) and the resources it is made of. You model each resource with a [Resource Type]({{< ref "/concepts/resource-types" >}}), and Radius provisions the backing infrastructure when you deploy the file. This guide builds an `app.bicep` definition from an empty file, adds resources, and references dependencies between them.
An application definition is a Bicep file that declares your [Application]({{< ref "/concepts/applications" >}}) and the resources it is made of. You model each resource with a [Resource Type]({{< ref "/concepts/resource-types" >}}), and Radius provisions the backing infrastructure when you deploy the file. This guide walks through the Radius Demo `app.bicep` definition and explains how it models resources and dependencies.

When the definition is ready, see [How to deploy applications using Radius]({{< ref "/applications/deploy" >}}) to deploy it to an Environment.

## Step 1: Import the Radius extension

Create a Bicep file for your application and import the Radius Bicep extension. This guide uses `app.bicep`, but the file can have any name. The extension makes the Radius Resource Types available in Bicep:
Begin by importing the Radius Bicep extension. The extension makes the Radius Resource Types available in Bicep:

```bicep
extension radius
```
{{< rad file="/static/samples/demo/app.bicep" embed=true startLine=1 endLine=1 >}}

The `radius` extension is configured in the `bicepconfig.json` created by `rad initialize`. If you have custom resource types to use, see [Add custom resource types to bicepconfig.json]({{< ref "/installation/dev-workstation#configure-bicepconfigjson" >}}).

## Step 2: Declare the Environment parameter

Every Application targets a Radius [Environment]({{< ref "/concepts/environments" >}}). Declare an `environment` parameter so the Radius CLI can supply the selected Environment's resource ID when you deploy:

```bicep
@description('The Radius Environment ID. Injected automatically by the rad CLI.')
param environment string
```
{{< rad file="/static/samples/demo/app.bicep" embed=true startLine=3 endLine=4 >}}

You do not set this value yourself. `rad deploy` passes the Environment from the current [Workspace]({{< ref "/management/workspaces" >}}), or from the `--environment` flag.
You do not set this value yourself. `rad deploy` passes the Environment ID from the current [Workspace]({{< ref "/management/workspaces" >}}), or from the `--environment` flag.

## Step 3: Define the Application resource
## Step 3: Name your resources

Declare a `Radius.Core/applications` resource to group the resources that make up your application. Set its `environment` property to the parameter:
Every resource in your definition needs a `name`, and names must be unique per Resource Type within a Resource Group. You have two options:

```bicep
resource app 'Radius.Core/applications@2025-08-01-preview' = {
name: 'my-app'
properties: {
environment: environment
}
}
```
- **Static names.** Give each resource a simple, unique name per Resource Type. This works well when you deploy the application to a single Environment.
- **Environment-suffixed names.** If you deploy the same definition to multiple Environments that share a Resource Group, add the Environment name as a suffix so the names do not collide.

The demo uses the second option. It derives the Environment name from the `environment` parameter's resource ID:

{{< rad file="/static/samples/demo/app.bicep" embed=true startLine=11 endLine=11 >}}

It then interpolates `environmentName` into each resource name, such as `demo-${environmentName}`, so the same definition deploys cleanly to `dev`, `test`, and `prod`.

## Step 4: Define the Application resource

Declare a `Radius.Core/applications` resource to group the resources that make up your application. Its name applies the pattern from the previous step:

{{< rad file="/static/samples/demo/app.bicep" embed=true startLine=13 endLine=18 markdownConfig=`{hl_lines=[2]}` >}}

The Application records the resources that belong to it and the relationships between them. Radius uses it to build the Application graph and to manage the resources together.

## Step 4: Add resources with Resource Types
## Step 5: Add resources with Resource Types

Add the resources your application needs. Each resource uses a Resource Type and sets two properties that associate it with the Application:

- `environment` links the resource to the Radius Environment.
- `application` links the resource to the Application, using the Application's `.id`.

The following example adds a container that runs the application's front end:

```bicep
resource frontend 'Radius.Compute/containers@2025-08-01-preview' = {
name: 'frontend'
properties: {
environment: environment
application: app.id
containers: {
web: {
image: 'ghcr.io/radius-project/samples/demo:latest'
ports: {
web: {
containerPort: 3000
}
}
}
}
}
}
```

Referencing `app.id` creates a symbolic dependency, so Radius creates the Application before the container.

## Step 5: Choose the right Resource Type
- **`environment`** links the resource to the Radius Environment. Each resource sets this to the `environment` parameter, whose value the Radius CLI supplies at deploy time.
- **`application`** links the resource to the Application, using the Application's `.id`.

The demo adds a container that runs the application's front end:

{{< rad file="/static/samples/demo/app.bicep" embed=true startLine=20 endLine=36 markdownConfig=`{hl_lines=["4-5"]}` >}}

Referencing `demoApp.id` creates a symbolic dependency, so Radius creates the Application before the container.

## Step 6: Choose the right Resource Type

Model each part of your application with the Resource Type that best represents it. Radius ships with a set of [out-of-the-box Resource Types]({{< ref "/reference/resources" >}}) for compute, data, messaging, and more, and your platform team can publish [custom Resource Types]({{< ref "/extensibility/resource-types" >}}) for anything specific to your organization.

Expand All @@ -86,32 +69,15 @@ Model each part of your application with the Resource Type that best represents

The Environment's [Recipe Packs]({{< ref "/concepts/recipe-packs" >}}) must contain a recipe for every Resource Type your definition uses. Without a matching recipe, the deployment fails because Radius does not know how to provision that resource.

## Step 6: Parameterize the definition

Use Bicep parameters for values that change between Environments or deployments, such as an image tag or a resource size. Parameters keep a single definition reusable across `dev`, `test`, and `prod`:

```bicep
@description('Container image tag to deploy.')
param imageTag string = 'latest'

resource frontend 'Radius.Compute/containers@2025-08-01-preview' = {
name: 'frontend'
properties: {
environment: environment
application: app.id
containers: {
web: {
image: 'ghcr.io/radius-project/samples/demo:${imageTag}'
ports: {
web: {
containerPort: 3000
}
}
}
}
}
}
```
## Step 7: Parameterize the definition

Use Bicep parameters for values that change between Environments or deployments, such as a container image or a resource size. Parameters keep a single definition reusable across `dev`, `test`, and `prod`. The demo declares an `image` parameter with the published image as its default:

{{< rad file="/static/samples/demo/app.bicep" embed=true startLine=6 endLine=7 >}}

The container uses the parameter instead of hard-coding the image:

{{< rad file="/static/samples/demo/app.bicep" embed=true startLine=20 endLine=36 markdownConfig=`{hl_lines=[8]}` >}}

Supply parameter values at deploy time with `--parameters`, or store them in a `.bicepparam` file. Keep the `environment` parameter as is; the Radius CLI supplies it automatically.

Expand Down
Loading
Loading