> ## Documentation Index
> Fetch the complete documentation index at: https://astronomer.io/docs/llms.txt
> Use this file to discover all available pages before exploring further.
# 2026 Astro release notes: January to June
> Astro release notes from January to June 2026, covering features, bug fixes, and version updates for Astro, the Astro CLI, Astro Runtime, and the Remote Execution Agent.
[Subscribe to Astro release notes](/docs/astro/release-notes-subscribe) to receive updates via RSS, email, or Slack.
Astro release notes from January to June 2026. See the [current release notes](/docs/astro/release-notes) for the latest updates.
### Enable Sub-Second Pipelines
**Labs**
This feature is in [Labs](/docs/astro/feature-previews).
You can now enable [Sub-Second Pipelines](/docs/astro/sub-second-pipelines) on Airflow 3.2+ Deployments that use the [Astro executor](/docs/astro/astro-executor). Sub-Second Pipelines pair the Astro executor with a dedicated event-driven Event Scheduler that picks up and dispatches API-triggered Dag runs in under a second and sustains approximately 1,000 Dag runs per minute, where the Celery executor queues and falls behind. Use them for high-throughput triggered workloads, on-demand inference, programmatic workflow invocation, and API-driven reverse ETL.
Enable the **Sub-Second Pipelines** toggle on the Deployment, create a worker queue with the **Sub-Second** toggle on, and route your Dag's tasks to that queue. Sub-Second Pipelines support API-triggered Dag runs only; runs triggered by cron schedules, timetables, asset and data-aware scheduling, or message queues continue to use the standard scheduler. You can confirm a run took the sub-second path from the Dag's `sub_second` tag, the **Sub-Second Metrics** tab in the Airflow UI, the Event Scheduler logs, or the SLA Metrics API.
See [Enable Sub-Second Pipelines](/docs/astro/sub-second-pipelines).
### Review code with Otto
**Labs**
This feature is in [Labs](/docs/astro/feature-previews).
You can now use [Otto](/docs/astro/otto/otto-overview) to review your Airflow code automatically when you open a pull request or merge request. The Otto review action posts a sticky summary comment, adds inline comments where it finds issues, and offers commit suggestions where a concrete fix is available. Each review returns a structured verdict of `approve`, `comment`, or `request_changes`, with line-anchored findings rated `high`, `medium`, or `low` severity.
Otto reviews changes against Astronomer compatibility knowledge, Airflow community standards, and your team's conventions captured in Otto Memory, so it catches issues that generic code review misses. The action supports GitHub through a Marketplace action and GitLab through a CI/CD template and Docker image. You can also run a review on demand from the [Astro CLI](/docs/cli/v1.43/astro-otto) with `astro otto --persona reviewer`.
See [Review code with Otto](/docs/astro/otto/otto-code-review).
### Additional improvements
* When you add the first IP address range to your organization's IP access list, the Astro API now rejects the request with a `400 Bad Request` error if your current IP address falls outside the submitted ranges, which prevents you from accidentally locking yourself out. The same protection applies when you add multiple ranges at once, and users with IP access list bypass permission can still add the first range even when their IP falls outside it. See [Set up IP Access List](/docs/astro/ip-access-list).
### Bug fixes
* Fixed the SMTP connection form in the Astro UI so its fields map to the correct Airflow SMTP provider parameter keys. The SSL and TLS fields are now labeled **Disable SSL** and **Disable TLS** and map to `disable_ssl` and `disable_tls`, where setting a field to `true` disables that protocol and `false` allows it. The sender email field now maps to `from_email` instead of `mail_from`.
### Investigate Dag failures with Otto
**Labs**
This feature is in [Labs](/docs/astro/feature-previews).
You can now use [Otto](/docs/astro/otto/otto-overview) to investigate Dag failures on Astro from the Astro UI, Astro alerts, or the Astro API. Each investigation produces a structured diagnosis with a root cause type, severity, suggested fix, and a checklist of Dag- and task-level checks, drawing on Airflow, Astro, and Astro Observe context. You can also ask Otto to investigate a Dag failure interactively in the [Astro CLI](/docs/cli/v1.43/astro-otto).
To investigate critical Dag failures automatically, pair a Dag failure alert's **Dag Trigger** notification channel with a Dag that calls the [investigation API](https://www.astronomer.io/docs/astro/api/v-1-labs/observability/start-a-dag-failure-diagnosis-run), then route the diagnosis to Slack, a pull request, or an incident management system. You can also tailor investigations with Otto investigation guidance set at the Workspace or Deployment level.
See [Investigate with Otto](/docs/astro/otto/otto-investigate).
### Dag-level access control is generally available
Dag-level access control is now generally available. You can assign roles scoped to individual Dags within a Deployment to enforce least-privilege security and enable multiple teams to collaborate in a single Deployment without exposing Dags across team boundaries.
Dag roles can be bound to Dags by **Dag tag** or **Dag ID** and assigned to users, Teams, and API tokens. Astro provides two default Dag roles, **Dag Viewer** and **Dag Author**, and you can create custom Dag roles with granular permissions.
This feature requires Astro Runtime 3.1-12+ and an Enterprise plan. See [Dag-level access control](/docs/astro/dag-level-access-control).
### Additional improvements
* The **Basic** section of Deployment details in the Astro UI now includes a **Deployment Namespace** row with copyable text, so you can retrieve a Deployment's namespace without using the Astro CLI or API.
### API server horizontal autoscaling
**Preview**
This feature is in [Preview](/docs/astro/feature-previews).
You can now enable horizontal autoscaling for the Airflow API server on Airflow 3 Deployments. Autoscaling scales between a fixed minimum of two replicas and a configurable maximum from `2` to `10`. Autoscaling works on all Airflow 3 Deployments, and supports the Astro, Celery, and Kubernetes executors.
See [Configure API server autoscaling](/docs/astro/api-server-autoscaling).
### Project-scoped connections and variables in the Astro IDE
**Preview**
This feature is in [Preview](/docs/astro/feature-previews).
You can now link Workspace-level connections, Airflow variables, and environment variables to specific [Astro IDE](/docs/astro/ide-overview) projects. Project-linked objects only affect that project's ephemeral test Deployments, without affecting Deployments that aren't started from the Astro IDE. You can also set value overrides per project, or auto-link a Workspace object to every Astro IDE project in a Workspace.
See [Make connections, Airflow variables, and environment variables available](/docs/astro/ide-test-run#make-connections-airflow-variables-and-environment-variables-available).
### Migrate Airflow connections and variables to the Environment Manager
**Preview**
This feature is in [Preview](/docs/astro/feature-previews).
You can now bulk migrate connections and Airflow variables from a Deployment's Airflow metadata database into the [Astro Environment Manager](/docs/astro/manage-connections-variables#astro-environment-manager). Astro creates a Workspace environment object linked to the source Deployment, then removes the source object from the metadata database, so you can manage and reuse the object centrally without losing access on the source Deployment.
See [Migrate Airflow connections and variables from a Deployment](/docs/astro/migrate-metadata-db-to-environment-manager#migrate-airflow-connections-and-variables-from-a-deployment).
### Promote a Deployment environment object to the Workspace
**Preview**
This feature is in [Preview](/docs/astro/feature-previews).
You can now promote a single Deployment-scoped connection, Airflow variable, environment variable, or metrics export to the Workspace level in the [Astro Environment Manager](/docs/astro/manage-connections-variables#astro-environment-manager). Astro keeps the source Deployment linked, so it continues to use the same values, and you can reuse the object on other Deployments or Astro IDE projects.
See [Promote a Deployment environment object to the Workspace](/docs/astro/migrate-metadata-db-to-environment-manager#promote-a-deployment-environment-object-to-the-workspace).
### Additional improvements
* When you select one or more Deployments on the Astro UI **DAGs** page, the tag filter dropdown now shows only tags from those Deployments.
* The workspace filter on the Astro Observe homepage now displays your current Workspace by default, matching the Workspace context the page is already using to query data.
* The maximum threshold for the **DAG Duration** Astro Alert is now 7 days (604,800 seconds), up from 1 day.
* You can now designate security contact email addresses for your organization, in addition to Organization Owners, to receive security notifications. See [Configure security contacts](/docs/astro/organization-settings#configure-security-contacts).
### Bug fixes
* Fixed an issue where users with the **Organization Observe Admin** or **Organization Observe Member** role received a 403 error when accessing the Airflow `/dags` page on Astro Runtime 3.2-3 or later. These roles now include read access to Dag runs, Human-in-the-Loop details, and task instances.
* Fixed an issue on slow or large Workspaces where the Astro Observe **Recently Failed DAGs** table could show stale paginated results with mismatched page contents and totals. The table now resets to the first page in that scenario. Failed run counts also now use Dag run end time when available, so they better match the selected time range.
### Additional improvements
* Organization, Workspace, and Deployment API token tables and details pages in the Astro UI now show a **Last Rotated** column and row, with the UTC timestamp of the most recent rotation. Tokens that have never been rotated display `Never`.
### Additional improvements
* Disaster recovery configuration and actions have moved from the cluster **Details** page to a dedicated **Disaster Recovery** tab on eligible cluster detail pages. Use this tab to view DR status, initiate failover or failback, and enable or disable DR. See [Disaster recovery](/docs/astro/disaster-recovery).
* The lineage sidebar now includes an **Alerts** tab when you select an Airflow Dag or task asset. From this tab, you can view existing alerts for the asset, create Dag or task failure alerts pre-scoped to the selected context, and edit or delete alerts based on your existing permissions.
* The Astro UI color mode toggle now persists your dark or light mode preference across page refreshes.
### Bug fixes
* Fixed an issue where AWS disaster recovery cluster creation through the Astro API incorrectly used the primary cluster's `SecondaryVpcCidr` for the disaster recovery cluster secondary VPC CIDR. The API now correctly applies the `DRSecondaryVpcCidr` request value.
### Introducing Otto, Astronomer's data engineering agent
**Labs**
This feature is in [Labs](/docs/astro/feature-previews).
[Otto](/docs/astro/otto/otto-overview) is Astronomer's data engineering agent, purpose built for Airflow and designed to get smarter every session. Use Otto to build pipelines, debug failures, investigate production incidents, and manage Airflow upgrades, grounded in Astronomer's compatibility knowledge base and your team's accumulated memory.
Key capabilities include:
* **Exploration**: Query your data warehouse, trace lineage, and profile tables without leaving the agent session.
* **Dag authoring**: Describe what you need in natural language. Otto writes the Dag, configures connections, triggers a run, and iterates until it works. When something breaks during development, Otto pulls task logs, reads Dag source, inspects variables and connections, and traces through the failure to propose a fix.
* **Investigation**: When a production Dag fails, ask Otto to pull the logs, analyze the failure, and propose a fix. Otto reads production task logs, run history, connections, and Dag source, then works through the diagnosis interactively with you.
* **Airflow upgrades**: Otto analyzes your Dag fleet against Astronomer's compatibility knowledge base, identifies what breaks, proposes specific code changes, and produces a prioritized plan. See [Upgrade Airflow with Otto](/docs/astro/otto/otto-upgrades).
Access Otto from your terminal with [`astro otto`](/docs/cli/v1.43/astro-otto), or in Astro through the [Astro IDE](/docs/astro/ide-overview).
See [Get started with Otto](/docs/astro/otto/get-started-otto).
### Enforce dedicated clusters for new Deployments
Organization Owners can now restrict new Deployments to dedicated clusters only. When you enable **Enforce Dedicated Clusters**, Astro rejects requests to create new Deployments on standard clusters, both in the Astro UI and through the Astro API. Existing Deployments on standard clusters continue to run without changes.
See [Enforce dedicated clusters for new Deployments](/docs/astro/organization-settings#enforce-dedicated-clusters-for-new-deployments).
### Cross-region disaster recovery is generally available
Self-service cross-region disaster recovery (DR) for AWS dedicated clusters is now generally available. You can configure a primary and a secondary dedicated cluster in different AWS regions, and fail over with minimal downtime and data loss. After failover, Astro automatically enables synchronization in the reverse direction, so you can fail back once the primary region recovers.
See [Disaster recovery](/docs/astro/disaster-recovery).
### AWS VPC peering is generally available
Self-service VPC peering configuration for Astro dedicated clusters on AWS is now generally available. You can create VPC peering connections between an external AWS VPC and an Astro dedicated cluster directly from the Astro UI, without contacting Astronomer support.
See [AWS Networking: VPC Peering](/docs/astro/connect-aws-vpc-peering).
### Additional improvements
* You can now create Azure dedicated clusters in the `southafricanorth` region. See [Astro Hosted resource reference](/docs/astro/resource-reference-hosted).
* The Dag access management page now shows an error when assigning or editing a Dag role for a user, team, or API token fails, replacing the previous silent-failure behavior. See [Dag-level access control](/docs/astro/dag-level-access-control).
* The Astro UI has an updated visual style to align with the Astronomer brand.
### Bug fixes
* Fixed an issue where configuring custom workload identity for Remote Execution Deployments on AWS and GCP could fail when workload identity options did not provide derived project or account data. The identity configuration flow now uses the cluster cloud provider account directly.
### Blueprint in the Astro IDE
**Preview**
This feature is in [Preview](/docs/astro/feature-previews).
Blueprint is now available in the [Astro IDE](/docs/astro/ide-overview). Blueprint is a template-based Dag authoring system that lets platform teams define reusable workflow templates in Python, while analysts, analytics engineers, and data scientists assemble those templates into production Dags through a visual builder and form-driven configuration — without writing Airflow code.
Key capabilities include:
* **No-code Dag authoring**: Drag blueprints onto a visual canvas, configure them through forms, and connect them to define dependencies.
* **Platform-defined templates**: Platform teams write blueprints using the open-source [airflow-blueprint](https://github.com/astronomer/blueprint) library, encoding best practices, operational defaults, and guardrails.
* **Dag YAML generation**: Blueprint produces plain YAML configuration files that live in your Git repository alongside your other project files.
* **Built-in testing**: Start an ephemeral test Deployment directly from the IDE to validate individual tasks or full Dags before committing.
* **Blueprint versioning**: Pin Dags to specific blueprint versions so existing workflows continue to work when a blueprint is updated.
See [Blueprint](/docs/astro/ide-blueprint).
### Additional improvements
* Clicking a failed Dag row on the Observe home page now navigates directly to the corresponding Asset Catalog details page. See [Observe](/docs/astro/astro-observe).
* You can now copy an alert ID directly from the actions menu in the Alerts list. See [Alerts](/docs/astro/alerts).
* The Dag API tokens table in Dag access management now supports search, making it faster to locate specific tokens. See [Dag-level access control](/docs/astro/dag-level-access-control).
* The Ask Astro web application has been removed from Astro.
### Additional improvements
* The universal metrics exporter now scrapes metrics from triggerer, webserver, and apiserver components in addition to base, worker, scheduler, and Dag processor containers. These metrics are available automatically without additional configuration. See [Export metrics](/docs/astro/export-metrics).
* Observe event timelines now include a **Run ID** column and display indented task and dataset events under their parent Dag events, making it easier to scan and correlate related timeline activity.
* Clicking a Dag start, success, or failure event in the Observe timeline now opens the corresponding Airflow run page directly in a new tab.
### Bug fixes
* Fixed an issue where updating environment variables, changing the default Pod size, or editing executor settings on non-development Deployments returned the error `Hibernation spec is not allowed for non-development deployments`. This was caused by an empty `hibernationSpec` object stored in the Deployment's scaling configuration data.
### API token access management pages
You can now click an API token's row in the Astro UI to open a dedicated access management page for Workspace and Deployment API tokens. From these pages, you can view token details and manage applicable roles, including Deployment roles and Dag roles, without navigating away from the token context.
See [Workspace API tokens](/docs/astro/workspace-api-tokens) and [Deployment API tokens](/docs/astro/deployment-api-tokens).
### Self-service user profile updates
You can now update your user profile directly from the Astro UI. Users managed by an Identity Provider (IdP) can update profile preferences but cannot edit name fields, which are managed by the IdP.
### Self-service disable Disaster Recovery
You can now disable Disaster Recovery (DR) for eligible clusters directly from the cluster actions menu in the Astro UI.
See [Set up disaster recovery](/docs/astro/disaster-recovery-setup#disable-dr).
### Custom GCP workload identity at Deployment creation
You can now specify a custom workload identity for eligible GCP Deployments at creation time, instead of configuring it after Deployment creation.
See [Authorize deployments to cloud resources](/docs/astro/authorize-deployments-to-your-cloud#dedicated-clusters-only-share-or-reuse-a-managed-identity-using-a-wildcard).
### Additional improvements
* Cluster details in the Astro UI now display the **GCP Project Number** for GCP clusters. You can copy this value directly from the cluster details page.
### Bug fixes
* Fixed a 500 error that occurred when Git deployments to Astro used a trailing slash in the Astro project path.
* Fixed an issue where dbt bundle deletion failed when the object version ID was missing from cloud storage metadata.
* Fixed an issue where Airflow variable values and value overrides in the Astro UI required a non-empty value. You can now create or update Airflow variables with empty values.
* Fixed missing Airflow 3 metric exports for scheduler heartbeat, triggerer heartbeat, task heartbeat kill, and asset metrics. These metrics are now available in telemetry output.
* Fixed an issue where clicking **Open Airflow** in the Astro UI also navigated the current page to Deployment details. The button now only opens Airflow in a new tab.
* Fixed an issue where the alert edit page in the Astro UI showed stale values after saving changes. The page now reflects updates immediately without a manual refresh.
### Async sessions and session history in the Astro IDE
**Preview**
The Astro IDE is in [Preview](/docs/astro/feature-previews).
Sessions in the [Astro IDE](/docs/astro/ide-overview) are no longer tied to an open browser tab. You can submit a prompt, close the browser, and return later to see the completed response. The AI agent continues processing in the background.
Key changes include:
* **Async processing**: After submitting a prompt, you can navigate away and return later to see the completed response.
* **Session history**: The **Sessions** tab shows a chronological list of your past sessions. Click any session to resume it with full context.
* **Session persistence**: Conversation data is stored in cloud object storage and can be fully restored at any time.
* **Private sessions**: Sessions are private to the user who created them, while projects remain shared across the Workspace.
### Underlying Data tab and updated cost categories in Organization Dashboards
Organization Dashboards now include an **Underlying Data** tab with raw data tables in a standardized financial format for Deployment activity, Workspace activity, and daily cost breakdowns. You can filter, download, email, and schedule exports directly from these tables. The **Cost Breakdown** dashboard also now includes additional cost categories and a new **Detailed Costs** view with granular breakdowns by Deployment, Compute Types, Worker Queues, or Clusters.
See [Export and schedule Organization Dashboard data](/docs/astro/org-dash-exports) and [Organization Dashboard](/docs/astro/organization-dashboard).
### Smaller VPC subnet support for AWS clusters
You can now create dedicated clusters on AWS with a VPC subnet range as small as /22, down from the previous minimum of /21. This gives you more flexibility to configure cluster networking with smaller address spaces when a full /21 block isn't available.
See [Create a dedicated Astro cluster](/docs/astro/create-dedicated-cluster#setup).
### GCP europe-west3 (Frankfurt) region support for standard clusters
You can now create standard deployments in the GCP `europe-west3` (Frankfurt, Germany) region.
### Cross-region disaster recovery for AWS dedicated clusters now in Preview
**Preview**
This feature is in [Preview](/docs/astro/feature-previews).
You can now configure cross-region disaster recovery (DR) for AWS dedicated clusters. DR lets you pair a primary and secondary cluster in different AWS regions so you can fail over with minimal downtime and data loss if a full region outage occurs.
Key capabilities include:
* Self-service failover and failback from the Astro UI.
* Automatic replication of Deployments, Dag run history, task instance metadata, environment variables, connections, Airflow variables, and task logs to the secondary cluster.
* Recovery time objective (RTO) of less than one hour and recovery point objective (RPO) of less than 15 minutes with the optional Task Logs Replication SLA.
* All hostnames, including Airflow UI, Airflow API, and Remote Execution API URLs, are automatically updated to point to the active cluster after failover.
Cross-region DR requires the Enterprise Business Critical tier. You can enable DR when creating a new dedicated cluster or submit a support request to enable it on an existing cluster. See [Disaster recovery](/docs/astro/disaster-recovery).
### Improved authentication resilience
Astro now runs authentication services directly in each data plane, removing the dependency on a single-region control plane component for authenticating requests. This reduces the affected area of control plane incidents, so your Deployments remain accessible even when parts of the control plane are unavailable.
Deployment URLs now route directly through the data plane. Old URLs continue to work and automatically redirect for 6-12 months. If you have strict network allowlists or custom networking configurations, Astronomer will contact you with guidance on any required updates.
### Direct access Deployment API tokens
You can now create direct access Deployment API tokens that authenticate requests directly at the Deployment level without depending on the control plane. During a control plane outage, Dags and automations that use direct access tokens continue to access the Airflow API without interruption.
Direct access tokens are available to Organization Owners through the Astro UI when creating a Deployment API token. The role assigned to a direct access token cannot be changed after creation. See [Deployment API tokens](/docs/astro/deployment-api-tokens#direct-access-token-api-tokens).
### Additional improvements
* Updated Astro infrastructure to improve reliability and performance.
### Dag-level access control now in Labs
**Labs**
This feature is in [Labs](/docs/astro/feature-previews). Reach out to your account team to enable this feature.
You can now assign roles scoped to individual Dags within a Deployment. Dag-level access control lets you enforce least-privilege security and enable multiple teams to collaborate in a single Deployment without exposing Dags across team boundaries.
Dag roles can be bound to Dags by **DAG Tag** or **DAG ID** and assigned to users, Teams, and Organization API tokens. Astro provides two default Dag roles, **Dag Viewer** and **Dag Author**, and you can create custom Dag roles with granular permissions.
This feature requires Astro Runtime 3.1-12+ and an Enterprise plan. See [Dag-level access control](/docs/astro/dag-level-access-control).
### Additional improvements
* Added support for AWS PrivateLink and Azure Private Link to enable private connectivity between Astro clusters and customer-managed Remote Execution Agents.
### Additional improvements
* Updated Astro infrastructure to improve reliability and performance.
### Bug fixes
* Fixed an issue where the event timeline in the lineage graph did not correctly filter events based on the **before** time selection.
### New GCP regions available for dedicated clusters
You can now create dedicated clusters in the following GCP regions:
* `northamerica-northeast2`
* `southamerica-west1`
* `australia-southeast2`
### Additional improvements
* Added an optional **Description** field to all environment manager objects, including Connections, Environment Variables, Airflow Variables, and Metrics Exports.
* In the [Astro IDE](/docs/astro/ide-overview), you can now include whole directories in chat context instead of selecting files individually, improving bulk operations and multi-file questions.
### Bug fixes
* Fixed an issue where the **Extra** field in the Astro connection manager used a text input instead of a JSON editor, causing errors like `TypeError: 'str' object does not support item assignment` when setting JSON session parameters on connections.
* Fixed incorrect dag duration metrics caused by duplicate events.
* Fixed **Run History** date range filtering to include long-running runs that started within the selected range but spanned beyond the end date.
### Astro API v1 now generally available
The Astro API v1 is now generally available. The v1 API provides a production-ready API with coverage under standard Astronomer support SLAs. The previous v1beta1 API is deprecated and will reach end of support in January 2027. See the [v1beta1 deprecation notice](https://www.astronomer.io/docs/astro/api/v-1-beta-1/v1beta1-deprecation-notice) and [migration guide](/docs/astro/api/v-1-beta-1/migrate-v1-api) for details.
### Pre-emptive migrations to shorten Airflow 2 to Airflow 3 upgrades
Shortened the duration of future in-place Airflow 2 to Airflow 3 upgrades by executing a database migration and preparation across all Airflow 2 Deployments. This applies only to Astro Runtime 12 and 13, as those are the minimum versions required to upgrade to Airflow 3 and Astro Runtime 3. All Runtime versions below 12 are deprecated. Once you upgrade from a deprecated version to Runtime 12 or 13, the pre-emptive migration will be executed. In some cases, this optimization has reduced in-place Airflow 2 to Airflow 3 upgrade times from hours to minutes.
### Bug fixes
* Fixed an issue where Deployments remained stuck in the `Deploying` state if a worker queue name contained Airflow component keywords such as "scheduler."
### Astro Observe data quality now in Preview
**Preview**
This feature is in [Preview](/docs/astro/feature-previews).
Astro Observe data quality for Snowflake and Databricks is now available in Preview. Data quality helps you monitor tables and columns for data quality issues including row volume changes, schema changes, and null columns, alerting on issues and displaying upstream and downstream table-level lineage to help keep your data accurate and complete.
See [data quality](/docs/astro/observe-data-quality) for setup and more information.
### Additional improvements
* Astro Observe [SLAs](/docs/astro/observe-slas) now support flexible cron-based schedules to capture complex business logic and allow more control over SLA sensitivity.
### Additional improvements
* Organization Owners can now manage API token assignments and roles from the API Token Details page. You can now add an API token to a Workspace or Deployment, update an API token’s role within a Workspace or Deployment, and remove an API token from a Workspace or Deployment directly from **Organization Settings -> Access Management -> API Tokens**.
### Additional improvements
* You can now view the details and roles assigned to an API token by clicking on any token in the **Organization Settings -> Access Management -> API Tokens** table, which opens the new API Token Details page.