Self-Hosted Version Matrix

Supported versions and upstream end-of-life dates for self-hosted AGLedger. Use this page for lifecycle planning.

Current release

| Component | Version | Source | |-----------|---------|--------| | AGLedger API | v0.19.17 | Docker Hub | | Helm chart | v0.19.17 | oci://registry-1.docker.io/agledger/agledger-chart | | Install scripts | v0.19.17 | agledger-ai/install |

The API image, Helm chart, and install repo ship in lockstep — one version number covers all three.

Runtime dependencies

| Dependency | Required | Tested | Upstream EOL | |------------|----------|--------|--------------| | Node.js | >=24.0.0 (API package.json engines) | 24 LTS | Active LTS → Oct 2026; Maintenance → Apr 2028 (nodejs.org) | | PostgreSQL | 17+ | 18 (bundled image postgres:18-alpine) | 17: Nov 2029; 18: Nov 2030 (postgresql.org) | | Docker Engine | 24.0+ | Latest stable | No formal EOL; Mirantis support varies | | Docker Compose | v2 | Latest stable | — | | Kubernetes | 1.27+ (Helm chart kubeVersion) | Amazon EKS (current stable) | Each minor gets ~14 months of patch support (kubernetes.io) |

Node 24 is the only tested major. PostgreSQL 17 is the minimum — UUIDv7 primary keys and specific migration functions require 17 or later. 18 is recommended for native UUIDv7 support without the compatibility polyfill.

Kubernetes lifecycle caveat

The Helm chart accepts Kubernetes 1.27+, but K8s 1.27 reached upstream EOL in June 2024. The kubeVersion field is the floor below which helm install refuses to run — it is not a statement of active support. Run a Kubernetes version that is within its own supported window; AGLedger inherits whatever patch lifecycle your cluster has.

Tested infrastructure

AGLedger has been validated against this stack in the AGLedger testbed:

| Layer | Component | |-------|-----------| | Orchestration | Amazon EKS | | Ingress | AWS ALB (Application Load Balancer) | | TLS | AWS Certificate Manager (ACM) | | Database | Aurora PostgreSQL 17 | | Container runtime | Docker Engine 24+ |

Other platforms (GKE, AKS, self-managed Kubernetes, Cloud SQL, Azure Flexible Server) work with the software and are documented in the configuration reference, but have not been exercised in the testbed. Per-platform connection string patterns are in that guide.

Untested paths

These combinations work in theory (the Helm chart supports them) but are not validated by the AGLedger testbed. Adopt with your own verification:

• cert-manager + Let's Encrypt ingress TLS — the chart exposes ingress.tls[]; AGLedger tests ALB + ACM instead. See the TLS guide.
• Blue-green Helm upgrades — the chart supports strategy.type: RollingUpdate for multi-node clusters; AGLedger tests Recreate (single-node) and RollingUpdate but not separate blue/green clusters with traffic shifting.

Update cadence

• AGLedger — patch and minor releases ship when ready; there is no fixed cadence. Subscribe to GitHub releases on agledger-ai/install for install-script updates (version-synced to the API).
• Node.js — follow Node's own LTS schedule. Major bumps in AGLedger's engines field will be called out in release notes.
• PostgreSQL — AGLedger does not pin to a specific PG minor. Plan upgrades against PostgreSQL's own schedule. Major-version upgrades should be tested in staging against your own mandate volume.

Related

• Upgrading — apply a new AGLedger release
• TLS Configuration — database and ingress TLS
• Configuration Reference — all environment variables

Verified against install repo v0.19.17 on 2026-04-21.