Credential HUB – a self-hosted credential layer for automation tools

[luiscyphre]

Credential HUB – a self-hosted credential layer for automation tools

Hi everyone,

I’ve been working on an open-source project called Credential HUB that grew out of a problem I kept running into with automation setups:

Credentials tend to become tied to individual applications.

API keys, OAuth credentials and tokens may be stored in Node-RED, another automation platform, an AI tool, configuration files, or several of them at the same time. Once an environment grows, it becomes increasingly difficult to see which credentials exist, where they are used, and how their lifecycle is managed.

Credential HUB takes a different approach.

Instead of trying to replace the credential handling built into Node-RED or other applications, it provides a separate, self-hosted credential lifecycle and runtime access layer.

The basic idea is:

Provider → Credential HUB → authorized consumer

Credentials are managed centrally in the HUB. Consumers don't need direct administrative access to the stored credential. They can be granted access to the credential they need, while the HUB controls what is exposed at runtime.

This also means the same credential-management layer can sit alongside different tools instead of rebuilding the same credential setup separately in each application.

The project currently covers things such as:

• API tokens and OAuth-based credentials

• encrypted credential storage

• credential lifecycle/status management

• controlled consumer access

• deny-by-default credential resolution

• import/export for administration and backup

• a web UI for managing credentials and access

An important distinction is that Credential HUB is not intended to replace a general-purpose secrets manager such as Vault. Its focus is narrower: credentials used by applications, integrations and automation workflows, including their lifecycle and controlled runtime use.

For Node-RED specifically, I'm interested in whether this separation is actually useful in real-world installations.

For example, if you run several Node-RED instances, use Node-RED together with other automation/AI tools, or maintain integrations for different services, would having the credentials managed outside the individual applications solve a problem for you?

Or does Node-RED's existing credential handling already cover this well enough in practice?

The project is open source and self-hosted:

GitHub – Credential HUB

I'd particularly appreciate feedback from people running larger or long-lived Node-RED installations. I'm interested in understanding where this model helps — and where it doesn't.

Thanks and regards
Luis

[TotallyInformation]

Interesting.

I've something of a background in IT Security and have always recommended that people put authentication outside of Node-RED. Node-RED is a generic compute platform, with the best will in the world, it is unlikely to ever be as secure for authentication as a dedicated external service.

So my advice has been to run a reverse proxy with a dedicated authentication extension. This gives a number of advantages, not just a battle-tested security and privacy solution.

This looks like it could be a useful tool but, of course, I would need to study it in more detail. For commercial use, it would also be helpful to start to get real-world experiences documented and perhaps some certified security testing. But that is future stuff I'm sure. For now, it would probably be helpful to document some real-world use-cases including Node-RED. Sorry if that has already been done, I've not had time as yet to read any of the documentation.

[luiscyphre]

Thanks — and I think we're very much aligned on the architectural principle.

One of the main ideas behind Credential HUB is that automation platforms can focus on flows and orchestration, while credential management, controlled access, lifecycle and health monitoring can be handled by a dedicated external service.

Your point about real-world experience and independent security testing is also very fair. The project is still at an early stage, so I don't want to overstate its maturity. Documented deployments, threat-model reviews and eventually external security testing are definitely things I see as important steps before making stronger claims for commercial environments.

And the Node-RED use case is a good suggestion. I haven't documented a dedicated Node-RED integration scenario yet, but I think it would be useful to show concretely how a flow could discover and resolve only the credential it is allowed to use, while keeping the actual credential lifecycle outside Node-RED.

Thanks for taking the time to look at it — this kind of feedback is exactly what helps me understand which parts need better documentation.

Regards
Luis