upvote
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).

reply
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.
reply
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!

reply
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.

reply
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.

reply
[dead]
reply