Deployment hibernation is generally available
Deployment hibernation is now generally available and is no longer a Preview feature. Hibernation scales all of a development Deployment’s resources to zero, on a schedule or on demand, and preserves its configuration so that you can wake it up without recreating it.With general availability:- You can create a development Deployment with any scheduler size and with high availability turned on.
- You can turn on Development Mode for an existing Deployment yourself, from the Deployment settings in the Astro UI, the Astro API, or the Astro CLI. Astro doesn’t add a hibernation schedule when you convert an existing Deployment, so the Deployment keeps running until you add one.
Astro-managed object storage for XCom and state values
On Astro Hosted Deployments that run Astro Runtime 3.0 or later, Astro now stores XCom values larger than 64 KB in an Astro-managed object storage bucket instead of the Airflow metadata database. On Astro Runtime 3.3 and later, Astro also stores task and asset state values larger than 64 KB in the same bucket. Values of 64 KB or less stay in the metadata database. You don’t need to change your Dag code, and you can view and edit these values in the Airflow UI and with the Airflow REST API. Deployments that use Remote Execution aren’t affected.If you set your own XCom or state store backend in your Dockerfile, Astro uses its own backend instead of yours. To keep your own backend, set the backend variables as Deployment environment variables. Make the change when no Dag runs that depend on XCom or state values are in progress, because tasks in those runs can fail when the backend changes. See Use your own XCom or state store backend.If tasks already failed after a backend change, see Custom XCom backends set in your Dockerfile.Subscribe to upcoming changes for your Astro plan
Astronomer now publishes notices about planned changes to Astro, such as maintenance windows and control plane changes, on a separate Upcoming changes page for each Astro plan. Each plan also has its own RSS feed, so you receive only the notices that affect your Organization. Pages and feeds are available for the Developer, Team, Business, Enterprise, and Enterprise Business Critical plans. They don’t cover Astro Private Cloud, the Astro CLI, or Astro Runtime.Subscribe to this feed in Slack or an RSS reader to get notice of upcoming changes. You aren’t required to subscribe to hear from us. Astronomer still contacts you directly about planned changes.The first notice covers Astro web and API maintenance on November 7, 2026, at 10 AM EST. It lasts about three hours.See Subscribe to upcoming changes.Additional improvements
- You can now turn on Development Mode for an existing Deployment from the Deployment settings in the Astro UI, regardless of your plan. Turning it on sets the scheduler size to Small and turns off high availability (HA). Turn the setting back off before you save to restore your original scheduler size and HA settings. Astro doesn’t add a hibernation schedule when you convert an existing Deployment, so the Deployment stays running until you add a schedule. See Enable development mode.
- Deployment hibernation overrides now use a dedicated permission,
deployment.hibernation.update. Manually hibernating a development Deployment, waking it up, and removing an override check this permission instead ofdeployment.update. Creating, updating, deleting, pausing, and unpausing hibernation schedules still requiresdeployment.update. The Workspace Operator, Workspace Owner, Organization Owner, and Deployment Admin roles include the new permission, and existing custom Deployment roles that helddeployment.updatereceived it automatically. If you create a custom Deployment role for users who hibernate or wake Deployments, adddeployment.hibernation.updateto it. Deployment hibernation is in Preview. See Custom role permissions reference.
Deploy code to multiple Dag bundles
PreviewThis feature is in Preview.
astro deployment bundle create, then target it with astro deploy --dags --dag-bundle-name <bundle-name>. A Dag deploy that doesn’t name a bundle still goes to the default main bundle, so your existing commands and CI/CD pipelines keep working unchanged. You can also serve non-Dag bundles, such as a dbt project, alongside one or more Dag bundles.Each bundle deploy appears as its own entry in your deploy history, but rollbacks still apply to the whole Deployment, so review the bundles a rollback affects before you confirm it. Named Dag bundles require Astro CLI 1.46 or later and aren’t available on Deployments that use Remote Execution.See Deploy code to multiple Dag bundles.Approve MCP client redirect URIs for your Organization
LabsThis feature is in Labs.
Additional improvements
- The Logs page for a Deployment now includes a Custom Range time filter, so you can search an exact start and end time instead of choosing only from the preset ranges. A custom range can span a maximum of 24 hours, and your selected time range is saved in the URL so you can bookmark or share the view.
The new Astro experience is now live for all Organizations
The new Astro experience is now turned on for all Organizations and is out of Preview. It replaces the previous Astro experience, so there is no longer an opt-in or an option to switch back. The change doesn’t affect your pipelines or configuration.Astro’s navigation gives you a single view across your entire Organization instead of a single Workspace. Deployments, Dags, and Astro IDE projects all appear across Workspaces in one view, with Workspace context on every row. Filter to a specific Workspace when you need to, or work from the full picture across your Organization. Workspace, Organization, and personal settings share a single settings layout, and Otto is available across Astro.The homepage brings together Recently Failed Dags, Jump Back In, and Favorite Deployments for your whole Organization. You can favorite Dags (Airflow 3.1+) and Deployments to pin them to the top of these views and filter to only your favorites.This release also includes performance improvements for Organizations that run large numbers of Deployments across many Workspaces.The Astro IDE is generally available
The Astro IDE is now generally available and is no longer a Preview feature. The Astro IDE is a browser-based workspace for Apache Airflow where you write Dag code, validate and test changes, and deploy or push your work without setting up a local development environment.The Astro IDE includes:- Authoring with Otto: Generate and refactor Dag code with context from your Airflow version, existing repository patterns, connections, and Deployment environment. See Author dags with the Astro IDE.
- Testing: Run your Dags against an ephemeral test Deployment, or against an existing Deployment in your Workspace. See Test and run code with the Astro IDE.
- Deployment and version control: Deploy directly to Astro or push your changes to a branch in your Git provider. See Deploy code from the Astro IDE.
- Project import: Bring existing projects into the IDE from GitHub, from any Git provider, or from an Astro CLI project.
Otto investigations include ranked suggested fixes
LabsThis feature is in Labs.
- Code patch: A
git applycommand that fixes one file in your Dag code. Otto validates the patch against the code from the deploy that failed, and doesn’t show a patch that doesn’t apply. - Airflow: An operation to clear the failed task, clear the failed run, or trigger a new run, linked to the run or task in Airflow.
- Manual: Written instructions, such as a change to a connection or to Deployment configuration. When the instructions include an
astrocommand, the command is pre-filled with the IDs from the investigation.
Detailed cost breakdown for Astro AI spend
The Cost Breakdown dashboard in Organization dashboards now includes a Detailed Cost for Astro AI view that breaks down your Astro AI spend, including Otto usage, by billable item. The view separates Model Chargeback, the cost to run a model through the Astronomer LLM gateway, from the Otto Intelligence Fee, a flat fee on the tokens that pass through that gateway.For each billable item, you can see and filter by the source of the usage, such as the Astro CLI or an investigation, the model that processed the request, and the subject type and subject ID that made the request. The view doesn’t show user emails or service key names, so filter by Subject ID to find the usage of a specific user or service key.Organization dashboards require the Enterprise tier or above. All Organizations can see their total Astro AI spend on the Invoices and Usage pages. See Manage Astro billing.See Detailed Cost for Astro AI.Additional improvements
- In the new Deployment analytics view, you can now reorder and collapse panels to personalize the page.
- The new Deployment analytics view now shows the top 10 database tables by size and by row count.
Export infrastructure metrics to Datadog
You can now create a Datadog (infrastructure metrics) metrics export to send Deployment infrastructure metrics directly to Datadog, in addition to the existing Prometheus Remote Write export type. Authenticate with a Datadog API key and your Datadog site, then add custom labels and link the export to specific Deployments the same way you already do for Prometheus Remote Write exports. This export sends infrastructure metrics only. To also send Airflow application metrics to Datadog, use the separate method in Export Airflow metrics to Datadog, and you can use both together.See Export metrics from Astro.Proxy-aware IP allowlisting
If you route Astro traffic through a forward proxy or secure tunnel, such as Zscaler, you can now turn on Proxy-Aware IP Allowlisting on the IP Access List page to also accept the egress IP address of that proxy or tunnel as a valid match. Astro allows a request when either the end user’s client IP address or the egress IP address falls within an allowed range, so turning on this setting can only grant access and never blocks a user who can already sign in.See Set up IP Access List on Astro.Improved hibernation schedule management
Hibernation schedules now display as a visual weekly chart instead of a list of cards or a CRON table. The chart shows every schedule on one week-long timeline, in both UTC and your local time zone, so you can see at a glance when a Deployment will be awake or hibernating.A new Effective row shows the real, combined result of all your schedules before you save, including a warning if your schedules conflict and cause the Deployment to never wake up or never hibernate. You can also click any schedule to edit it in place with a live preview, and each schedule remembers whether it was set up with the simple day and time picker or an advanced cron expression. A new View Current Schedules Chart button on the Deployment page shows your live schedule next to the existing schedule list.See Hibernate a development Deployment.Additional improvements
- Ask Otto can now read, edit, save, deploy, and run tasks for an open Astro IDE session.
Bug fixes
- Fixed an issue where a Deployment, Workspace, or Organization-scoped API token couldn’t roll back a deploy and received a
403error. API tokens can now roll back deploys the same way a user can.
Cross-region disaster recovery for Azure dedicated clusters is generally available
Self-service cross-region disaster recovery (DR) for Azure dedicated clusters is now generally available, which means DR is now available on all three cloud providers. You can configure a primary and a secondary dedicated cluster in different Azure 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 after the primary region recovers.Azure DR includes the following capabilities:- Self-service enablement on existing clusters: You can enable DR on an existing Azure cluster from the Astro UI, the Astro API, or the Astro Terraform provider. Enabling DR only adds the secondary cluster and starts replication, so it requires no support request, no maintenance window, and no downtime. Azure is the only cloud provider where you can enable DR on an existing cluster yourself.
- No region-pairing constraint: Any supported Azure dedicated cluster region other than your primary region is a valid failover region. The Task Logs Replication SLA, which guarantees a 15-minute recovery point objective (RPO) for task logs, requires both regions to be on the same continent.
- Replication lag monitoring: The cluster’s Disaster Recovery tab reports the current database and object storage replication lag, so you can confirm that replication has caught up before you fail over.
Bug fixes
- Fixed an issue where every Airflow variable migrated from a Deployment’s metadata database into the Environment Manager was masked as a secret. A migrated variable is now masked only when its name matches one of Airflow’s sensitive-name patterns, such as a name that contains
password,secret,token, orapi_key, which matches Airflow’s own masking behavior. - Fixed an issue where you couldn’t create Redshift, Snowflake, or other connection types that have required extra fields, because the Create Connection button stayed disabled even after you filled in those fields. The button now enables when all required fields, including extra fields, have values.
Billing API added to the Astro v1 Labs API
LabsThis feature is in Labs.
Cross-region disaster recovery for GCP dedicated clusters is generally available
Self-service cross-region disaster recovery (DR) for GCP dedicated clusters is now generally available. You can configure a primary and a secondary dedicated cluster in different GCP 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.Task-level utilization metrics
Astro now shows CPU and memory utilization at the Dag, task, and task instance level in a new Resource Metrics tab in the Airflow UI, with task-to-worker mapping that ties resource use back to the Dag, task, task run, and time window. Use it to identify which tasks consume the most resources, which are likely causing out-of-memory errors, and which Dags are driving cost.This feature is available on Astro executor Hosted Runtime 3.1+ Deployments, and on Remote Execution 3.1+ Deployments using Remote Execution Agents 1.5.0+ and Helm chart 2.0.0+.See View task-level utilization metrics.Try the new Astro experience
PreviewThis feature is in Preview.
- Recently Failed Dags: An Organization-wide table of failing Dags, sorted by failure rate, with time-range filters. Each row shows the Workspace and Deployment, run history, and two actions: Investigate with Otto and Open in Airflow.
- Jump Back In: A strip of recently visited Deployments, Dags, data products, and Astro IDE projects.
- Favorite Deployments: An Organization-wide view of Deployment health with All, Healthy, and Hibernating status filters. Each card shows status, cluster and repository context, and four metrics: Dag Runs, Tasks, Worker CPU, and Worker Memory.
Test against an existing Deployment in the Astro IDE
PreviewThis feature is in Preview.
workspace.deployments.create permission.See Test against an existing Deployment.New Deployment analytics experience
PreviewThis feature is in Preview.
KubernetesPodOperator coverage, parse time, and richer per-status and per-component breakdowns. The new experience also includes improved charting controls, multi-pool visibility, and analytics charts on the Deployments list.During the preview period, you can switch between the new and previous analytics experience from the Analytics page.See View metrics for Astro Deployments.