Apache Hop in production:
built, tested and kept secure
Yes. This page shows why, with evidence you can check yourself: who owns Apache Hop, who builds it, how it is tested and how vulnerabilities are handled. It also covers what to do when you need someone accountable for it in production.
Six things you can check
Apache Hop stands on its own
The first question is not who sells Apache Hop. It is whether the project itself is a safe foundation. Five things decide that.
This matters more than it sounds. Pentaho Data Integration moved to a source-available licence with version 10, and Talend retired Talend Open Studio in 2024. Many teams moving to Apache Hop come from exactly those tools. An Apache project cannot go the same way.
The project team → Migrating to Apache Hop →
Tests per release → Releases → SonarCloud analysis →
Nightly results →
Performance trend →
That gap is what Putki covers. Every supported Putki release, and the Apache Hop version it is built on, is scanned every day. Each finding is judged against what actually runs, the judgment is published with a date, and fixes ship as Putki patch releases near the end of every month, or within days when they are urgent.
Vulnerability scans → Support lifecycle → ASF security process →
Who builds Apache Hop
Apache Hop is built in the open by a community of contributors. Roughly half of the work comes from the team behind Putki, which includes two of Apache Hop's co-founders and members of its project management committee. The other half comes from other contributors, independent developers and people working for other companies.
| What the team does in Apache Hop | Where to check it |
|---|---|
| About half of all code changes in the last 12 months | Contributions, counted from Apache Hop's git history |
| More than half of the new tests | Unit and integration tests per release |
| Release management for every Apache Hop release since 2.11 | Apache Hop downloads and release notes |
| Documentation and the continuous-integration setup | github.com/apache/hop |
The other contributors matter just as much. They fix bugs, add features, review pull requests, test release candidates and answer questions on the mailing lists, and much of that never shows up in a count of code changes. The contributions page shows both halves, and says what the counts leave out.
What Putki adds, and why it isn't in Apache Hop
Putki does work that an open-source project either cannot do or should not have to: work that needs paid accounts, dedicated hardware or a contract. Everything that belongs in Apache Hop goes to Apache Hop.
| Putki does | Why it isn't part of Apache Hop | What goes to Apache Hop |
|---|---|---|
| Nightly tests against AWS, Google Cloud, Azure, Odoo and other services | They need paid vendor accounts and credentials, which an Apache project cannot hold | Integration tests that run on Apache's own build servers |
| The performance trend across releases | Reliable timings need dedicated, quiet hardware. Shared build servers give noisy numbers. | Every performance fix |
| Monthly patch releases for supported versions | Apache Hop fixes issues in its next release, and every Apache release needs a vote. Patching released versions is outside the project's scope. | The same library upgrades, so the next release has them |
| Daily vulnerability scans of supported releases, with published judgments and response targets | Scanning released versions and answering every finding against a deadline needs a company that is accountable for it | Library upgrades, and reports to the ASF for anything in Apache Hop's own code |
| Support with response times, named contacts and long support windows | A community project cannot make contractual promises | Fixes for the problems support finds |
| Connectors to commercial systems, monitoring and governance for teams | Apache Hop stays complete for anyone building pipelines. Putki adds what teams need to run it in production. | Core engine work, standard transforms and open-standard connectivity |
Your pipelines and workflows stay plain Apache Hop. Putki runs alongside them, not inside them. See what Putki includes.
Who helps when something breaks, and what if you leave
These are the two questions every production team asks about open source, and they have one answer. You depend on Apache Hop, which nobody can take away. You can pay Putki to be accountable for running it.
When something fails in production
- Community support through the mailing lists, chat and GitHub. It is helpful and best-effort, with no guaranteed response times.
- A Putki subscription adds a support desk with response times, from two business days down to two hours, depending on the plan.
- Patches for the version you run for at least 12 months, so you upgrade when you choose to.
- The engineers who write the code you are running, not a call centre.
If you stop using Putki
- Your projects keep running. Pipelines, workflows and metadata are standard Apache Hop files in your own Git repository.
- Putki connectors and plugins keep your pipelines running, with or without a subscription.
- Your history stays yours. Logs and lineage are in databases you own.
- You go back to Apache Hop's release cycle and community support.
Apache Hop, the Cyber Resilience Act and NIS2
The EU Cyber Resilience Act treats an open-source foundation that maintains software differently from a company that sells a product. For Apache Hop, the Apache Software Foundation is the open-source steward. A company that delivers Apache Hop as part of a commercial product, as know.bi does with Putki, carries the obligations of a manufacturer, including vulnerability handling and reporting.
If your organisation falls under NIS2, you have to assess the security of your suppliers. The published vulnerability judgments, the machine-readable VEX feed, the monthly patch cadence and the published support windows are the evidence that assessment asks for.
Who runs it
Putki customers run Apache Hop in production for organisations whose data has to be right, on time and auditable.
Sectors
Regions
Our customers' names stay with them. If you would like to talk to one in your sector, ask us and we will check who is willing.
Check it yourself
Every page below is public, dated and recalculated automatically. Each one explains how it counts.
Evidence
- ContributionsWho builds Apache Hop
- TestsIntegration tests against real services
- PerformancePerformance across releases
- SecurityVulnerability scans
Commitments
- LifecycleSupport lifecycle and patch policy
- PlatformsSupported environments
- SecurityHow Putki is built and hardened
- PlansPlans and response times
Apache Hop
- OverviewWhat is Apache Hop?
- SupportCommunity and paid support
- Projecthop.apache.org
- Sourcegithub.com/apache/hop
Common questions
Is Apache Hop ready for production?
Is Putki a fork of Apache Hop?
Why isn't everything Putki does part of Apache Hop?
What happens to Apache Hop if the Putki team stops contributing?
Is this page endorsed by the Apache Software Foundation?
Where to go from here
Check the evidence
See who builds Apache Hop, counted from its own public git history.
See the contributionsTry Apache Hop
Download Apache Hop and learn the basics with the free, self-paced Apache Hop Fundamentals course.
Start the courseTalk to the team
Ask the people who build Apache Hop about running it in your production environment.
Talk to usApache Hop in production:
built, tested and kept secure
Yes. This page shows why, with evidence you can check yourself: who owns Apache Hop, who builds it, how it is tested and how vulnerabilities are handled. It also covers what to do when you need someone accountable for it in production.
Six things you can check
Apache Hop stands on its own
The first question is not who sells Apache Hop. It is whether the project itself is a safe foundation. Five things decide that.
This matters more than it sounds. Pentaho Data Integration moved to a source-available licence with version 10, and Talend retired Talend Open Studio in 2024. Many teams moving to Apache Hop come from exactly those tools. An Apache project cannot go the same way.
The project team → Migrating to Apache Hop →
Tests per release → Releases → SonarCloud analysis →
Nightly results →
Performance trend →
That gap is what Putki covers. Every supported Putki release, and the Apache Hop version it is built on, is scanned every day. Each finding is judged against what actually runs, the judgment is published with a date, and fixes ship as Putki patch releases near the end of every month, or within days when they are urgent.
Vulnerability scans → Support lifecycle → ASF security process →
Who builds Apache Hop
Apache Hop is built in the open by a community of contributors. Roughly half of the work comes from the team behind Putki, which includes two of Apache Hop's co-founders and members of its project management committee. The other half comes from other contributors, independent developers and people working for other companies.
| What the team does in Apache Hop | Where to check it |
|---|---|
| About half of all code changes in the last 12 months | Contributions, counted from Apache Hop's git history |
| More than half of the new tests | Unit and integration tests per release |
| Release management for every Apache Hop release since 2.11 | Apache Hop downloads and release notes |
| Documentation and the continuous-integration setup | github.com/apache/hop |
The other contributors matter just as much. They fix bugs, add features, review pull requests, test release candidates and answer questions on the mailing lists, and much of that never shows up in a count of code changes. The contributions page shows both halves, and says what the counts leave out.
What Putki adds, and why it isn't in Apache Hop
Putki does work that an open-source project either cannot do or should not have to: work that needs paid accounts, dedicated hardware or a contract. Everything that belongs in Apache Hop goes to Apache Hop.
| Putki does | Why it isn't part of Apache Hop | What goes to Apache Hop |
|---|---|---|
| Nightly tests against AWS, Google Cloud, Azure, Odoo and other services | They need paid vendor accounts and credentials, which an Apache project cannot hold | Integration tests that run on Apache's own build servers |
| The performance trend across releases | Reliable timings need dedicated, quiet hardware. Shared build servers give noisy numbers. | Every performance fix |
| Monthly patch releases for supported versions | Apache Hop fixes issues in its next release, and every Apache release needs a vote. Patching released versions is outside the project's scope. | The same library upgrades, so the next release has them |
| Daily vulnerability scans of supported releases, with published judgments and response targets | Scanning released versions and answering every finding against a deadline needs a company that is accountable for it | Library upgrades, and reports to the ASF for anything in Apache Hop's own code |
| Support with response times, named contacts and long support windows | A community project cannot make contractual promises | Fixes for the problems support finds |
| Connectors to commercial systems, monitoring and governance for teams | Apache Hop stays complete for anyone building pipelines. Putki adds what teams need to run it in production. | Core engine work, standard transforms and open-standard connectivity |
Your pipelines and workflows stay plain Apache Hop. Putki runs alongside them, not inside them. See what Putki includes.
Who helps when something breaks, and what if you leave
These are the two questions every production team asks about open source, and they have one answer. You depend on Apache Hop, which nobody can take away. You can pay Putki to be accountable for running it.
When something fails in production
- Community support through the mailing lists, chat and GitHub. It is helpful and best-effort, with no guaranteed response times.
- A Putki subscription adds a support desk with response times, from two business days down to two hours, depending on the plan.
- Patches for the version you run for at least 12 months, so you upgrade when you choose to.
- The engineers who write the code you are running, not a call centre.
If you stop using Putki
- Your projects keep running. Pipelines, workflows and metadata are standard Apache Hop files in your own Git repository.
- Putki connectors and plugins keep your pipelines running, with or without a subscription.
- Your history stays yours. Logs and lineage are in databases you own.
- You go back to Apache Hop's release cycle and community support.
Apache Hop, the Cyber Resilience Act and NIS2
The EU Cyber Resilience Act treats an open-source foundation that maintains software differently from a company that sells a product. For Apache Hop, the Apache Software Foundation is the open-source steward. A company that delivers Apache Hop as part of a commercial product, as know.bi does with Putki, carries the obligations of a manufacturer, including vulnerability handling and reporting.
If your organisation falls under NIS2, you have to assess the security of your suppliers. The published vulnerability judgments, the machine-readable VEX feed, the monthly patch cadence and the published support windows are the evidence that assessment asks for.
Who runs it
Putki customers run Apache Hop in production for organisations whose data has to be right, on time and auditable.
Sectors
Regions
Our customers' names stay with them. If you would like to talk to one in your sector, ask us and we will check who is willing.
Check it yourself
Every page below is public, dated and recalculated automatically. Each one explains how it counts.
Evidence
- ContributionsWho builds Apache Hop
- TestsIntegration tests against real services
- PerformancePerformance across releases
- SecurityVulnerability scans
Commitments
- LifecycleSupport lifecycle and patch policy
- PlatformsSupported environments
- SecurityHow Putki is built and hardened
- PlansPlans and response times
Apache Hop
- OverviewWhat is Apache Hop?
- SupportCommunity and paid support
- Projecthop.apache.org
- Sourcegithub.com/apache/hop
Common questions
Is Apache Hop ready for production?
Is Putki a fork of Apache Hop?
Why isn't everything Putki does part of Apache Hop?
What happens to Apache Hop if the Putki team stops contributing?
Is this page endorsed by the Apache Software Foundation?
Where to go from here
Check the evidence
See who builds Apache Hop, counted from its own public git history.
See the contributionsTry Apache Hop
Download Apache Hop and learn the basics with the free, self-paced Apache Hop Fundamentals course.
Start the courseTalk to the team
Ask the people who build Apache Hop about running it in your production environment.
Talk to us