You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Copy file name to clipboardExpand all lines: articles/container-apps/deployment-labels.md
+25-18Lines changed: 25 additions & 18 deletions
Display the source diff
Display the rich diff
Original file line number
Diff line number
Diff line change
@@ -6,37 +6,40 @@ author: craigshoemaker
6
6
ms.author: cshoe
7
7
ms.service: azure-container-apps
8
8
ms.topic: tutorial
9
-
ms.date: 10/27/2025
9
+
ms.date: 01/05/2026
10
10
zone_pivot_groups: azure-cli-or-portal
11
11
---
12
12
13
13
# Deployment labels in Azure Container Apps
14
14
15
-
Deployment labels allow you to assign meaningful names (such as dev, staging, prod) to specific container revisions. Applying these names gives you a streamlined process for handling complex deployment scenarios and environment management.
15
+
Deployment labels help you assign meaningful names, such as dev, staging, or prod, to specific container revisions. When you apply these names, you streamline handling complex deployment scenarios and environment management.
16
16
17
-
With deployment labels, you can:
17
+
By using deployment labels, you can:
18
18
19
-
- Assign clear, descriptive labels to revisions
20
-
- Have new revisions automatically assigned to labels for routing and traffic management
21
-
- Route traffic based on labels instead of changing revision names
22
-
- Promote or demote revisions by reassigning labels
23
-
- Roll back to previous revisions using label history
19
+
- Assign clear, descriptive labels to revisions.
20
+
- Automatically assign new revisions to labels for routing and traffic management.
21
+
- Route traffic based on labels instead of changing revision names.
22
+
- Promote or demote revisions by reassigning labels.
23
+
- Roll back to previous revisions by using label history.
24
+
25
+
> [!IMPORTANT]
26
+
> Before you can use deployment labels, you need to follow the steps to first [enable deployment](?pivots=azure-portal#use-deployment-labels) labels in the portal for your container app.
24
27
25
28
## Key features
26
29
27
-
Deployment labels enable you to create sophisticated deployment strategies while maintaining control over your application lifecycle with the following features:
30
+
Deployment labels enable you to create sophisticated deployment strategies while maintaining control over your application lifecycle by using the following features:
28
31
29
32
-**Label assignment**: Create and assign meaningful labels to container revisions, making it easier to manage environments like dev, staging, and prod.
30
33
31
34
-**Traffic splitting & A/B testing**: Support for traffic splitting, blind rollback, and A/B testing enables gradual rollouts and testing of new features.
32
35
33
-
-**Staging releases & auto swap**: Automatic revision activation allows you to seamlessly create new revisions and have them assigned to new or existing labels and receive traffic. Any revisions no longer referenced by a label will be shut down automatically.
36
+
-**Staging releases & auto swap**: Automatic revision activation allows you to seamlessly create new revisions and assign them to new or existing labels to receive traffic. Any revisions no longer referenced by a label are shut down automatically.
34
37
35
38
::: zone pivot="azure-portal"
36
39
37
40
## Use deployment labels
38
41
39
-
To enable deployment labels, follow these steps in the Azure portal:
42
+
By default deployment labels aren't available to your container app. To enable, deployment labels, follow these steps in the Azure portal:
40
43
41
44
1. Open your container app in the Azure portal.
42
45
@@ -48,9 +51,9 @@ To enable deployment labels, follow these steps in the Azure portal:
48
51
49
52
1. Select **Apply**.
50
53
51
-
### Create a new label
54
+
### Create a new label
52
55
53
-
New labels are based on existing labels when created in the portal. By default Container Apps creates your first label for you named *label-1*. When labels are created via CLI or Bicep, you can associate them with any existing revision or a new revision.
56
+
Create new labels in the portal based on existing labels. By default, Container Apps creates your first label named *label-1*. When you create labels through the CLI or Bicep, you can associate them with any existing revision or a new revision.
54
57
55
58
1. Open your container app in the Azure portal.
56
59
@@ -66,13 +69,13 @@ New labels are based on existing labels when created in the portal. By default C
66
69
67
70
### Label history and rollbacks
68
71
69
-
You can view the full history of a label using the following steps:
72
+
You can view the full history of a label by using the following steps:
70
73
71
74
1. Open your container app in the Azure portal.
72
75
73
76
1. From the menu, under *Application*, select **Labels**.
74
77
75
-
1. Select **Show history**associated with the label you're interested in.
78
+
1. Select **Show history**for the label you're interested in.
76
79
77
80
Use the *Show history* option for any label to:
78
81
@@ -116,6 +119,7 @@ To enable deployment labels, follow these steps in the Azure CLI:
116
119
```
117
120
118
121
1. To create a new revision with a new or existing label, use the following command:
122
+
119
123
```bash
120
124
az containerapp update \
121
125
--name $CONTAINER_APP_NAME \
@@ -125,6 +129,7 @@ To enable deployment labels, follow these steps in the Azure CLI:
125
129
```
126
130
127
131
1. To show label history, use the following command:
132
+
128
133
```bash
129
134
az containerapp label-history show \
130
135
--name $CONTAINER_APP_NAME \
@@ -133,13 +138,15 @@ To enable deployment labels, follow these steps in the Azure CLI:
133
138
```
134
139
135
140
1. To show label app traffic, use the following command:
141
+
136
142
```bash
137
143
az containerapp ingress traffic show \
138
144
--name $CONTAINER_APP_NAME \
139
145
--resource-group $RESOURCE_GROUP \
140
146
```
141
147
142
148
1. To add a label to a revision, use the following commands:
149
+
143
150
```bash
144
151
az containerapp revision label add \
145
152
--name $CONTAINER_APP_NAME \
@@ -177,11 +184,11 @@ Here's a typical workflow using deployment labels:
177
184
178
185
1.**Update a label**: Select a label (for example, "stage") to update it with new containers, scaling, or volume settings.
179
186
180
-
1.**Test the changes**: With the new revision deployed, you can route a portion of traffic to the updated label.
187
+
1.**Test the changes**: With the new revision deployed, route a portion of traffic to the updated label.
181
188
182
-
1.**Promote changes**: Once you feel confident in the production revision, you can update the production label to point to the same revision
189
+
1.**Promote changes**: When you're confident in the production revision, update the production label to point to the same revision.
183
190
184
-
1.**Monitor and rollback if needed**: If issues arise, use the label history to roll back to a previous version.
191
+
1.**Monitor and rollback if needed**: If problems arise, use the label history to roll back to a previous version.
Azure API for FHIR® provides a fully managed deployment of the Microsoft FHIR Server for Azure. The server is an implementation of the [FHIR](https://hl7.org/fhir) standard. This document provides details about the features and enhancements made to Azure API for FHIR.
21
+
22
+
## January 2026
23
+
### FHIR service
24
+
25
+
**Updates to responses for update and deletion of FHIR spec-defined search parameters**: There are a few updates to the behaviors and responses for update and deletion of FHIR spec-defined search parameters:
26
+
- Deletion of out-of-box FHIR spec-defined search parameters previously returned a "204 No Content" and the parameter was not deleted. The response is updated to correctly return "405 Method Not Allowed."
27
+
- Update of out-of-box FHIR spec-defined search parameters previously returned "201 Created", which can cause unintended behavior. The response is updated to return "405 Method Not Allowed." If you wish to update an out-of-box FHIR spec-defined search parameter, please create a new custom search parameter with a different URL.
28
+
29
+
**Enhanced response logging for deletion of non-existent search parameters**: Deletion of nonexistent search parameters previously returned a "204 No Content." The response is improved to be more informative and now returns "404 Not Found."
30
+
31
+
#### Bug fixes:
32
+
33
+
**Bug fix for profile version in capability statement**: The [capability statement](store-profiles-in-fhir.md#profiles-in-the-capability-statement) lists details of the stored profiles on the FHIR server. There was a bug where the capability statement wasn't showing the profile version that is currently loaded into the FHIR server. The issue is fixed, and the capability statement now correctly states the profile version that is loaded on the FHIR server.
title: Release notes for 2026 Azure Health Data Services monthly releases
3
+
description: 2026 - Stay updated with the latest features and improvements for the FHIR, DICOM, and MedTech services in Azure Health Data Services in 2026. Read the monthly release notes and learn how to get the most out of healthcare data.
4
+
services: healthcare-apis
5
+
author: evachen96
6
+
ms.service: azure-health-data-services
7
+
ms.subservice: workspace
8
+
ms.topic: reference
9
+
ms.date: 1/1/2026
10
+
ms.author: evach
11
+
ms.custom:
12
+
- references_regions
13
+
- build-2026
14
+
---
15
+
16
+
# Release notes 2026: Azure Health Data Services
17
+
18
+
Release notes describe features, enhancements, and bug fixes released in 2026 for the FHIR® service and DICOM® service in Azure Health Data Services.
19
+
20
+
## January 2026
21
+
### FHIR service
22
+
23
+
**Updates to responses for update and deletion of FHIR spec-defined search parameters**: There are a few updates to the behaviors and responses for update and deletion of FHIR spec-defined search parameters:
24
+
- Deletion of out-of-box FHIR spec-defined search parameters previously returned a "204 No Content" and the parameter was not deleted. The response is updated to correctly return "405 Method Not Allowed."
25
+
- Update of out-of-box FHIR spec-defined search parameters previously returned "201 Created", which can cause unintended behavior. The response is updated to return "405 Method Not Allowed." If you wish to update an out-of-box FHIR spec-defined search parameter, please create a new custom search parameter with a different URL.
26
+
27
+
**Enhanced response logging for deletion of non-existent search parameters**: Deletion of nonexistent search parameters previously returned a "204 No Content." The response is improved to be more informative and now returns "404 Not Found."
28
+
29
+
#### Bug fixes:
30
+
31
+
**Bug fix for profile version in capability statement**: The [capability statement](./fhir/store-profiles-in-fhir.md#profiles-in-the-capability-statement) lists details of the stored profiles on the FHIR server. There was a bug where the capability statement wasn't showing the profile version that is currently loaded into the FHIR server. The issue is fixed, and the capability statement now correctly states the profile version that is loaded on the FHIR server.
32
+
33
+
34
+
## Related content
35
+
36
+
[Release notes 2025](release-notes-2025.md)
37
+
38
+
[Known issues](known-issues.md)
39
+
40
+
[!INCLUDE [FHIR and DICOM trademark statement](includes/healthcare-apis-fhir-dicom-trademark.md)]
![learn-build-service-prod[bot]](https://avatars.githubusercontent.com/in/237442?v=4&size=40){kind=avatar}
0 commit comments