From another comment:

> Kontext holds secrets server-side and mints short-lived tokens per session.

That probably makes this thing DOA for most people (certainly for me and everyone I know).

Thanks. Yes, I would have to put myself in that category. Typical play here is to offer the self-hosted option. Not sure if that is in the pipeline for the creators of this. Then you are into that trust/operational overhead tradeoff conversation.

▲

mc-serious 3 hours ago | parent [-]

Fair pushback and point taken. The reason this isn’t trivial is that the CLI is the easy and lightweight part. The heavy part is the infra behind it: auth, vaulting, token refresh/exchange, revocation, provider edge cases etc.

We'll think how to best accomodate full self-hosting in the future!

▲

tjarjoura 2 hours ago | parent [-]

What do you anticipate to be the hardest part of supporting a self-hosted solution? I've worked a fair bit on converting SAAS -> self-hosted and always interested to hear others' pain points.

I imagine a lot of the organizations that would find this most valuable, and would be willing to pay a lot, would be the same ones that would require something like this.

	▲	mc-serious an hour ago \| parent [-]
		I think the hardest part is the environment/support matrix, not getting it to run in the first place. It’s usually pretty doable to make a system self-hostable on a happy path. The hard part is supporting it across lots of customer environments without being in the loop every time: custom IdPs, private networking, KMS/HSM/BYOK requirements, upgrade/migration paths, backup/restore, observability, and all the weird edge cases that only show up once other people operate it. And yes, I think your last point is right: the customers who care most about this category are often exactly the ones who will require self-hosted. What's your take? Curious what you found effective vs. what you deem hardest from your experience.