How long your release is supported,
and how fixes reach you
Which Putki releases are supported and until when, what each one receives, when patches ship and how quickly we respond.
Putki is built on Apache Hop. Why that is a safe foundation, and what Putki adds to it, is on Apache Hop in production
Supported releases
Putki ships a new release line roughly every quarter, each built on an Apache Hop release. A line is supported for 12 months from the day it is released, and its end date never moves earlier once published.
| Release line | Built on Apache Hop | Released | Latest patch | Supported until | Status |
|---|---|---|---|---|---|
| 2026.12 (LTS) | 2.20.0 | Planned for December 2026 | — | 18 months after release | Planned |
| 2026.09 | 2.19.0 | 2026-09-17 | 2026.09.02 | 2027-09-17 | Supported |
| 2026.06 | 2.18.1 | 2026-07-06 | 2026.06.02 | 2027-07-06 | Supported |
| 2026.03 | 2.17.1 | 2026-03-16 | 2026.03.07 | 2027-03-16 | Supported |
| 2025.08 | 2.14.0 | 2025-09-03 | 2025.08.03 | 2026-09-03 | End of life |
| 2025.05 | 2.14.0 | 2025-07-03 | 2025.05.03 | 2026-07-03 | End of life |
Updated 2026-10-31, from the same data as the vulnerability scans page.
Fixes during support
| Kind of fix | Supported release | LTS, after 12 months | End of life |
|---|---|---|---|
| Vulnerabilities that affect a supported configuration | Yes | Critical and actively exploited only | No |
| Regressions that lose data or break a default setup | Yes | Yes | No |
| Other regressions and narrow defects | Yes, in the monthly patch | No | No |
| New features and connectors | No: those come in the next release line | No | No |
| Published vulnerability judgments | Yes | Yes | No |
A finding that does not affect a supported configuration is not left unanswered. We publish why it does not apply on the vulnerability scans page and in the VEX feed, so your scanner's report comes with our answer attached.
When patches ship
One patch release a month
Near the end of every month, one patch release per supported line, with everything found since the previous one. You plan one change window a month.
A notice when there is nothing to ship
"No patches this month" is published like a release. Silence would leave you unsure whether anyone looked.
Urgent fixes within days
When a vulnerability can be reached in a shipped product under a supported configuration, and it is actively exploited or trivially exploitable, the fix ships as soon as it is ready.
Exploitability decides urgency, not the severity score alone. A CVSS score describes how bad exploitation would be, not whether it can happen in your installation. We use it to order the queue. What makes a fix urgent is whether the vulnerable code can actually be reached, and whether the issue is listed in CISA's catalogue of known exploited vulnerabilities.
How fixes reach you
| You run | You receive |
|---|---|
| Putki containers | Rebuilt images for the patch release. Pull the new tag and redeploy. |
| A Putki client installation | A small patch archive, putki-patch- |
| Plain Apache Hop, 2.19 or later | Apache Hop fixes issues in its next release and does not patch versions it has released. Each Putki patch release also carries an archive, apache-hop-patch- |
Every patch release is announced on the public release feed, and customers read its notes on their own release page. The machine-readable VEX feed carries the same information for your scanner.
How quickly we respond
| What | Basic | Professional | Enterprise |
|---|---|---|---|
| Security report from anyone | Acknowledged within one business day, assessment confirmed within five, at security@putki.io | ||
| Support request | 2 business days | 2 business hours | Agreed per contract, from 2 hours for P1 |
| Support hours | Business hours CET | 8:00 to 20:00 CEST | Agreed per contract |
| Named contacts | 1 | 3 | 5 |
Plans and prices are on the pricing page.
When your release reaches end of life
Every end date is published when a line is released, so the upgrade can be planned a year ahead. Before you upgrade, the vulnerability scans page shows which open findings the newer line resolves, the integration tests show how it behaves against real services, and the performance trend shows whether its Apache Hop version is faster or slower than yours.
Your pipelines and workflows are plain Apache Hop files, so an upgrade does not convert or rewrite them. Customers on Professional and Enterprise plans can use their coaching calls to plan the move.
Running a release that is close to end of life?
Tell us what you run, and we'll help you plan the upgrade or tell you honestly whether it can wait.