Lost me at "verify email" though. Why get so creative, yet limit yourself to archaic "email". Why do *YOU* the provider need me to have an email or a phone?
Look, mullvad can provide vpn services without email or all that nonsense. If you want people who will use ssh to order things, these are the same people that would get your service because you're not asking for dumb things like email. It's the first thing you ask of potential users, and it's an obstacle preventing them from giving you their money!
You can issue users a recovery/access key and/or let them user their ssh public key and trust they know how to manage that on their own. If you have messages for them, display that when they login. This sort of stuff differentiates your service, ssh does too, but it's cosmetic and gimmicky. I would prefer a rest-api over ssh anyways, but ssh is cool too.
I think it's just something people do because "everyone else" is doing it. Lots of familiarity around email. "it's just not done" as they say.
People regularly lose their ssh keypair and also don’t generate a token. I think using email as a form of recovery is totally fine and regardless when you have to pay for the service you’re going to give up your email (and other personal info) via payment processor
And kudos on your service, I'll keep it mind next time I'm picking a provider.
But, my original comment is strictly about email. Even if you asked for a government-id and credit-card payment, I won't object. Just please, no email!
How would you normally recover an account? Email? So, if my email is compromised, everything gets compromised? That's not sane at all. You should normally have MFA, and if you can recover your MFA/2FA with email, it's just an over-engineered inconvenience. The way it's done right, the MFA recovery code servers as a general account recovery code as well. You save that somewhere safe and offline.
In this case, they use ssh public keys, so there is no need for all that, just add a spare public key to authorized_keys, and keep it's private key offline and safe, ideally in an HSM.
This is a service for technical people, so all that works, for general consumer service, you give them a choice. Either they choose to use a recovery key, a recovery email/phone...or recovery via payment. Let them pay $1 for recovery, proving they control the original method of payment (KYC not crypto). But if nothing else, users should be able to choose recovery code instead of email. It's more secure, because you're not relying on a 3rd party service to also be secure. I don't like them much, but recovery questions have also been used, but if you think about it, those are not that different from recovery codes, they're just more guessable.
Recovery codes aren't one string, they're usually multiple, so if users chose, they can split up their storage. For added reliability, you can require validation of recovery codes periodically, after a successful sign-in.
The nice thing about recovery codes is being able to store them securely in a password manager alongside any other entries for the service.
The downside is they're easy to leak (or lose), so the added factors in requiring access to email (also with its own 2FA) are lost in a system like this, if whatever you're managing is mission critical. I wouldn't want to make that kind of bet, personally.
I get it, that's why I advocate letting users choose. Especially with a technical audience, treating them like they can't be trusted to make mission critical choices is not good.
exe.dev ▶ doc how-exedev-works
How exe.dev works (how-exedev-works) - press q to exit
You're an engineer. We're engineers. Let's talk about what's going on under the hood.
An "exe.dev" VM runs on a bare metal machine that exe.dev rents. We happen to use Kata Containers and Cloud Hypervisor, but that's a bit of an implementation detail (and may change!).
With most providers, your VM starts with a "base image" and is given a block device. Exe.dev instead starts with a container image (by default, "exeuntu"), and hooks up an overlay filesystem to the VM. This makes creating a new VM
take about two seconds. In exchange, we lose some flexibility: you don't get to choose which filesystem you're using, nor which kernel you're using.
On the networking side, we don't give your VM its own public IP. Instead, we terminate HTTPS/TLS requests, and proxy them securely to your VM's web servers. For SSH, we handle ssh vmname.exe.xyz.I guess its an innovation at the resource management layer where you create / manage VMs. It's interesting they choose to give away individual plans. That's very generous. Though I'd feel bad using any of their resources.
> exe.dev is a subscription service that gives you virtual machines, with persistent disks, quickly and without fuss. These machines are immediately accessible over HTTPS, with sensible and secure defaults. You can share your web server as easily as you can share a Google Doc. With built-in optional authentication, so you can focus on your thing.
> Your VMs share CPU/RAM. Create as many VMs as you like with the resources you have.
Source: https://exe.dev/docs/what-is-exe
s/cloud computing should like/cloud computing should be like/
i cannot find a way in the docs to start new VMs with a bootstrap script that starts a bunch of services for me and runs a specific docker image
my use-case is that I want a full developer environment for every branch of my project, so i can vibe code on many VMs at a time
EDIT: Just realised there's an image one can pass to the new command. Still it's not clear to me whether private images would be supported and what registry this is using:
exe.dev ▶ help new
Command: new
Create a new VM
Options: --command container command: auto, none, or a custom command --env environment variable in KEY=VALUE format (can be specified multiple times) --image container image --json output in JSON format --name VM name (auto-generated if not specified) --no-email do not send email notification --prompt initial prompt to send to Shelley after VM creation (requires exeuntu image)
We are also exploring alternatives for pre-configuring your VM. (Because we make lots of VMs and feel this too, so it is very much on our mind.) One is a sub-second VM "clone" feature, so you can configure a base VM to use as an image.
Though not a fan of 100GB and egress charges. Is there a way to hardcap that?
I guess I could implement something VM side but that’s a bit convoluted