Interest in a direct-HTTP Vault/OpenBao provider, or a fnox-native secrets-server protocol?

[robertguss]

Hey jdx,

I'm building a small self-hosted secrets server in Rust: single binary, single node, speaks the Vault KV v2 API. Because it's Vault-compatible, fnox's existing Vault provider already works against it with configuration only, so nothing here needs fnox changes. I'm asking about direction before I build toward anything upstream-facing.

Two questions:

1. Direct-HTTP Vault/OpenBao provider. The Vault provider currently shells out to the vault binary, which is BUSL-licensed. Would a PR adding a direct-HTTP provider — talks KV v2 over HTTPS, works against Vault, OpenBao, and anything API-compatible, drops the binary dependency — be welcome? I saw openbao provider #525 (openbao provider) and pulumi esc provider #568 (third-party provider precedent) and would build on whichever fits.

2. fnox-native server protocol. Longer-term: is a fnox-native protocol for a remote secrets server something you'd ever want in fnox, or do you prefer server integrations to stay behind the existing provider interface? No proposal attached — just checking whether a design discussion would be welcome before I write one.

If either answer is "not interested", that's fine. The Vault-compat path works with zero upstream buy-in. I just don't want to build toward an integration you don't want.

Cheers,
Robert

[jdx]

Thanks for asking first.

A direct-HTTP implementation for the existing vault provider would be welcome. I would prefer replacing the CLI-backed internals while preserving the current configuration, rather than introducing a separate provider. It should retain the existing authentication and TLS behavior and include compatibility tests for both Vault and OpenBao.

I may also be interested in a fnox-native server protocol, but I would need to think through the design and long-term implications quite a bit more. A design discussion would be welcome, especially if it starts with concrete use cases, desired capabilities, and what a native protocol would enable beyond the existing provider interface or Vault-compatible approach. There is no commitment that fnox would adopt it yet, but I am open to exploring it.

This comment was generated by Codex.