Option to deploy the devphone to Functions & Assets

[neri78]

I love the Dev Phone, but it would be even better if you can provide an option to deploy the app to Functions & Assets as it could be used during a workshop that people may not have installed CLI and everything.

[ayyrickay]

Hey @neri78! We have definitely considered a version that does this.

There are some security concerns here, unfortunately, that make this a long shot. We may be able to secure the dev phone endpoint by default with a developer's Twilio Credentials, because if an asset is private/protected, I think a GET request prompts credentials in the browser. In general, however, the issue here is that we don't want to open up a Dev Phone on the public internet that's easily accessible. This is particularly problematic when people inevitably forget to tear down the dev phone.

This may be worth exploring further, but I'd personally like to see the Dev Phone implemented in the Console somehow before we make it self-serve via Serverless.

Curious about your thoughts on this, given the additional context?

[jandusek]

I'd like to chime in in support of this request. Having the dev-phone available more permanently would greatly increase its usefulness. I appreciate the security concerns and getting this integrated in the Twilio Console down the line would be great. In the meantime, prompting for credentials sounds like a good compromise.

[Eclairemoy]

we could set it up like a quick deploy/code exchange template, maybe?

[ayyrickay]

Correct, Liz, there's some precedent for this in Code Exchange apps and quick deploy. We don't have any part of the app that needs a long lived server, the trickiest part would be adding the password protection + extracting the Plugin UI and deploying that to assets (which, admittedly, isn't that tricky.)

Could be cool as a flag. twilio dev-phone --deploy SOME_PASSWORD twilio dev-phone --teardown SOME_PASSWORD.

I'll put this as "needs design", though, because I still am not totally sure of how much it increases usefulness, because deployment isn't necessarily any easier than a CLI-based version, and I'm not totally sure of why a more permanent dev phone is significantly more useful than #110