Release publication
Releases require builds, fresh vulnerability scans, SBOMs, signatures, clean Kubernetes installs, and signed upgrade, backup and restore checks.
ASTRONOMER RESOURCES / STATUS
Astronomer is in alpha. This page separates what ships, what you have to turn on, and what has not been proven yet, so you can plan an evaluation around facts rather than promises.
Alpha · Reviewed against the current Astronomer source · Requirements vary by release01 / STATUS BOARD
Available means implemented in the alpha product with automated tests. It does not mean every topology and failure mode has been accepted on production-like infrastructure.
In the product today
Shipped; you turn it on
No claim made until evidence exists
02 / KNOWN LIMITS
These are current limits of the product. Some are deliberate boundaries; none comes with a promised date.
| Area | Limit |
|---|---|
| Provisioning | Astronomer does not create clusters, machines or node pools. This is by design. |
| Branch tracking | Targets release immutable versions; following a branch is intentionally excluded. |
| Management-plane outage | Released intent keeps reconciling; new intent, approvals and the central view wait for the management plane. |
| Log query | Loki, OpenSearch, Elasticsearch and Splunk are queryable; Datadog and CloudWatch are deep links; S3 and syslog are shipping-only. |
| API-server allowlist | Monitoring and enforcement are unavailable for self-managed providers; the console says so. |
| Bulk actions | Bulk delete is available; bulk scale and restart, and node changes, act on one object at a time. |
| Directory discovery | Pre-login principal discovery works with LDAP connectors only. |
| Audit transactions | Not every domain change writes its audit row in the same database transaction yet. |
| Image scanning | Vulnerability scanning only, not runtime protection; not shown for the management cluster. |
| Custom resources | Complex or non-structural CRDs may be easier to edit in YAML. |
| Upstream vulnerabilities | Some upstream image findings are carried with explicit, expiring, digest-specific waivers, disclosed with the release. |
03 / HOW IT IS TESTED
Static gates cover Go builds and tests, frontend type checks, lint, unit tests and bundle budgets, Helm render tests and the API contract. Stateful lanes add PostgreSQL and worker integration, restart and outage recovery, tunnel HA, database failover and browser qualification.
A green static gate is not a measured scale result, and a local single-node pass is not proof of multi-host HA, production restore or accessibility. Those need separate, retained evidence, and the product makes no claim until it exists.
Releases require builds, fresh vulnerability scans, SBOMs, signatures, clean Kubernetes installs, and signed upgrade, backup and restore checks.
Kubernetes v1.33, v1.34 and v1.35; PostgreSQL 16 and 17; Chrome and Edge 130+, Firefox 128+, Safari 18+.
Use non-production clusters, keep the encryption key with your database backups, and rehearse a restore before relying on it.
FAQ
We do not recommend it during alpha. Start with non-production clusters and the workflows that matter most to you. We will tell you plainly what has and has not been proven for your scenario. #
They can. Releases record intentional API changes in a compatibility review, and clients should be checked before upgrading. #
There is no date. The items under Not yet proven are what we need evidence for, and early access testing on real clusters is how that evidence gets built. #
NEXT STEP
We will help you pick the clusters, workflows and tests that answer your questions.