[akshayKMR]

Regarding ssh-apps, this seems super duper niche to me even for developers. Like, I get that many devs are terminal savvy, and it's cool that it's possible to serve apps like this but is it practical (to pick for your new product /internal app)?

[qudat]

We are pretty successful over at https://pico.sh using the same techniques — and using wish

[latchkey]

As a bare metal cloud service provider, we built a little TUI app over ssh so that people could upload their public keys to us without having to use a web interface. It has worked out really well because it makes it possible to "upload" the public key without having to do anything but login.

We automatically configure ssh on the servers to auth against our own internal api for serving up the keys. This way, customers can add to authorized_keys and also use our TUI for management as well.

[bradgessler]

I'm working on a different approach that doesn't use ssh at https://terminalwire.com/.

It's meant for inherently server-based CLI's like Github, Stripe, Fly, Heroku, or any other SaaS and can be plugged directly into web frameworks. My thinking is that more companies would ship command-line interfaces if they didn't have to maintain APIs for them, deal with distributing binaries (and all the compatibility issues that come with that), or deal with all the configuration involved in hooking up SSH to their app servers.

It's in beta at the moment, and I'm currently focused on Rails apps to get the ergonomics dialed-in. My goal is to make it possible for people in any web framework to build and ship a CLI to customers in under an hour and never have to touch an API or worry about binary distribution for as long as their CLI exists.

[qudat]

At my org the biggest issue with out CLI is not the initial distribution, but supporting and maintaining multiple platforms, code signing the binaries, and making sure customers actually update the binaries.

[bradgessler]

Yeah, I put all of that under the umbrella of “distribution”—the last mile is a huge pain in the SaaS that SaaS CLIs shouldn’t have to deal with or even think about.

Terminalwire will handle the builds for all the different platforms, signing, etc. so companies can instead focus on shipping their unique features to customers.

I’m also going to ship clients that automatically update to match the version of the client that’s compatible with the server in a way that the client won’t even notice.

[darthwalsh]

At the large enterprises I've worked at, signing with our certs had to happen on our own build machines. And I don't think there was any precedent if we could sign third party binaries that had been built for us.

Having some my-company.terminalwire.com as the signing identity could work; I bet most SMB wouldn't bat an eye to ship like that.

[hamandcheese]

As a developer, I agree. Give me a great CLI, please, not a server rendered TUI.

This gives me another thought though, a "server-rendered" CLI. A tiny shim binary that just sends argv to the server, and the server sends back stdout/stderr. Haven't seen anyone try that.

[gwynforthewyn]

That sounds very similar to the command form of ssh i.e. "ssh foo.example.com ls" :)

[messh]

a "server-rendered" CLI is exactly what `keypub.sh` is, and what many ssh apps are (some are more TUI)

[hamandcheese]

Yeah, in retrospect, I'm an idiot. I wasn't considering `ssh foobar.io dothething` to be equivalent to what I was thinking in my head even though it is exactly equivalent.