Hacker News Reader

Hacker News

Comment by MontyCarloHall | Hacker News Reader

Full thread

MontyCarloHall

The individual plan says:

— $20/month

— 25 VMs

— 2 CPUs

— 8GB RAM

— 25GB disk

— 100GB bandwidth

Is this 2 CPUs/8GB RAM per VM (in other words, 50 CPUs/200GB RAM)? If so, this is an unbelievable bargain (too good to be true?); other cloud providers charge hundreds of dollars per month for an equivalent VM.

If, OTOH, it's 2 CPUs/8GB total, Hetzner offers an equivalent VM for about $5/month (with much more disk and bandwidth), and I'm not sure what the exe.dev value proposition is. (I'm also not sure why one would want to split 25 VMs across so few shared CPUs/such little memory.)

View on HN

No I apologize for the confusion (exe.dev person here). What is different about this service is you get dedicated resources that you share between your VMs. The initial allocation is conservative, we want to give people more (or drop the price).

The goal is to reduce the marginal cost of creating a VM to zero. Instead of installing a container manager or using Unix users, just make another VM.

(I will get a better version of this table online tonight.)

>Instead of installing a container manager or using Unix users, just make another VM.

What is the advantage of this? Unless you need something exotic like different kernel configurations per instance, what's the problem with using containers on the same instance?

BTW, a Hetzner dedicated server with 2 CPUs/8GB RAM that would let me run my own hypervisor is about $14 USD/month. For anyone who's a big enough power user to care about the distinction of running distributed workflows on VMs versus containers, I'm not sure that an extra $5/month is worth your "hypervisor as a service." But then again, HN commenters infamously poopooed Dropbox [0], so what do I know? :-)

[0] https://news.ycombinator.com/item?id=9224

Containers aren’t enough for me. I like to do things like create TUN devices, run docker compose, etc. I believe the VM is a fundamentally better abstraction.

Consider this: sometimes when you are using a VPS, you start a new project and say to yourself, "I should put this on a new VPS." Not all the time, but it does happen. And when it does, we are faced with the problem that starting a new project immediately costs us $X/month. I would like a new project to initially cost nothing.

> create TUN devices

Is that possible and useful with exe.dev? The docs say:

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.

> run docker compose

You can run multiple compose stacks in a single VPS.

> you start a new project and say to yourself, "I should put this on a new VPS."

I never did that.

Tun devices are possible and useful on exe.dev today, because it means, for example, you can install the full copy of Tailscale.

But to your point: if a single VPS meets all your needs and you do not feel constrained by the marginal cost of another VPS then the exe pricing model is not going to bring you much value. Perhaps the automatic TLS termination and auth proxy with link sharing is useful. But if not, then it sounds like you are well served by existing products.

Is exe.dev just a better version of sketch.dev or do they both have a different use case?

> dedicated Are plan CPUs pinned/reserved (dedicated) or time-shared with other customers under load, and what contention should I expect?

You guys really need to work on simplifying your communication on your website. I was also very confused about how the 8GB - whether it is per VM, shared etc.

I thought it was pretty clear from their documentation. And it solves an issue I have. They’ve found a customer in me.

What's the issue?

Is rsync installed in the stock vm environment by default?

Asking for a friend…

[exe.dev co-founder here]

  exedev@scarlet-canyon:~$ rsync --version
  rsync  version 3.2.7  protocol version 31                                         
  Copyright (C) 1996-2022 by Andrew Tridgell, Wayne Davison, and others.

Our base image is most of an Ubuntu server. We trim out, for example, systemd features that are designed for working with system hardware, and then add a lot of standard software, as our block device cloning is a lot faster and more efficient than apt. So you will find vim, git, go, curl, sqlite3, etc all installed. If you think something obvious is missing please let us know!

Would love it if Tailscale came pre-installed! Or even better: some simple way to make it so every VM I start up is automatically/easily part of my Tailnet.

p.s. thanks for making Tailscale. And I'm loving exe.dev so far!

[exe.dev cofounder here] That's a good idea! I will add it to a list I have for exeuntu. Automatic login would be really nice, let me see if I can figure out how to do that. Thanks for trying exe.dev!

emacs!

The docs remark “VMs share the resources allocated to the user” so I interpret as resources allocated to your account, VMs provisioned within those limits.

That's decent value considering the price of a vps is close for much more work.

The only difference is the bandwidth: vps in europe givr you 10 tiles that, unmeterred.

Very cool for training: I can make people log into those vm and deploy nginx just for learning.

The value proposition appears to be CLI cred.

It's not actually a VM - it's a container, and they are fundamentally different. This feels like false advertising.

I guess the question is: can I run systemd services ob their VMs? If not, then yeah that’s false advertising.

But my perception from the homepage is you can. Am I wrong?

Reply on news.ycombinator.com