So I tried this the other day after Filippo Valsorda, another Go person, posted about it. My reaction was 'whoa, this really makes it easier to start a quick project', and it took a minute to figure out why I felt that way when, I mean, I have a laptop and could spin up clloud stuff so it seems like should've I had what I needed already.
I think it's the combination of 1) really quick to get going, 2) isolated and disposable environments and 3) can be persistent and out there on the Internet.
Often to get element 3, persistent and public, I'd have to jump through hoops in a cloud console and/or touch my 'main' resources (install things or do other sysadmin work on a laptop or server, etc.), resources I use for other stuff and would prefer not to clutter up with every experiment I do.
Here I can make a thing and if I'm done with it, I'm done. Some things have 'quick to start, isolated, and disposable' down but are necessarily ephemeral and/or don't support publishing and this avoids that local minimum too.
This is good stuff. I hope they get a sustainable paid thing going. I'd use it.
Also, though I realize in a sense I'm wishing competition on a biz I just said I'd support: some parts of the design here could work elsewhere as well. You could have an open-source "click here to start a thing! and click here to archive it." layer you can run on top of your VM or machine or whatever flavor of cloud account; could be a lot of fun. (I imagine someone will want to ask "have you looked at X?" here, and yes, please reply, I'm interested in all sorts of potential values of X.)
Thanks, I couldn't figure out what the hell was wrong. The front page is just... not helpful. Given the amount of pushbash how everyone feels about this, it should be removed from HN frontpage!
Thanks. I feel like I expect home pages to contain at least a modicum of information. And three seconds spent thinking about accessibility would have told them that light gray links on a white background are a terrible idea...
Apologies for the vagueness of the home page, we were not expecting to be here today. There is a little more info in our first blog post https://blog.exe.dev/meet-exe.dev and docs, but far needs to be written.
(We have also built some interesting tech behind this that we are excited to write up, I have a doc two pages long of blog posts we want to write.)
The page you are trying to view cannot be shown because the authenticity of the received data could not be verified.
Please contact the website owners to inform them of this problem.
I just tried this out in Firefox on macOS and there are no issues, so this might have something to do with our LetsEncrypt wildcard cert and the CA roots installed on Android. Could you tell me what version of Android you are using?
I signed up and started a VM. Didn’t really expect the default chat interface at boot. I’m currently on my iPad and would probably have bookmarked it for later, but now I’m playing with it. Cool idea :)
Edit: it comes out of the box with screenshot capabilities. The defaults on this are very well considered. Im impressed within the first 15 min.
Edit2: this is very neat. I will be recommending it to my non-coder friends who don’t really have the local setup to use Claude but would like to try a Claude-like tool.
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.)
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? :-)
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.
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.
Oh I’m going to need more info than this. It’s a service that provides persistent disk and VM’s but doesn’t tell you what those shared resource limits are, what the pricing is, or anything other than to ssh in…
Hello, an exe.dev person here. There are some very early docs, exe.dev/docs (which are also accessible over ssh once you ssh in). There is a lot more to come, very early days, please bear with us. I was not expecting to see it here today.
I have played with it and it's so easy get started with that now I want a quick-project idea as an excuse to use it!
I'm sure you've thought of this, but lots of people get 'free' (or really: zero incremental cost to them) use of some coding chat tool through a subscription or free allowance like what Google is offering.
If you wanted to let those access your custom tools (browser!) and docs about the environment, a low-fuss way might be to drop a skills/ dir of info and executables that call your tools into new installs' homedirs, and/or a default AGENTS.md with the basic info and links to more.
And this seems like more fuss, but if you wanted to be able to expose to the Web whatever coding tool people 'bring', similar to how you expose your built-in chat, there's apparently an "agent control protocol" used as a sort of cross-vendor SDK by projects like https://willmcgugan.github.io/toad-released/ that try to put a nice interface on top of everything. Not saying this'd be easy at all, but you could imagine the choice between a few coding tools and auth info for them as profile-level settings pushed to new VMs. Or maybe no special settings, and bringing your own tools is just a special case of bringing your own image or setup script.
But, as y'all note, it's a VM. You can install whatever, and use it through the terminal (or VSCode remoting or something else). "It's a computer" is a pretty good open standard to build on.
Thanks! We are thinking a lot about how to prepopulate VMs. The first thing we are going to start with is a fast ‘clone’ command, so you can preconfigure a base VM then make as many as you like. Lots of other ideas floating around too.
Re sketch: the code is not the same but the agent is deeply inspired by it. Eg the screenshot support, which just seems obvious to us. Philip has done the heavy lifting here, he hangs out in the discord if you want to chat about it.
Might be a good place for yunohost/coolify style services, especially if you have multiple separate entities - though probably tricky to do inbound mail because of IP allocation?
Hello, I am behind this company. My co-founder Josh Bleecher Snyder has also been hanging around the internet for a while. There are several of us hacking away. It is very early days, we have a lot of work to do to earn your trust but it is my intention to do so.
Hello, an exe.dev person here. They are VMs, on a crosvm-derived VMM. So I consider them "actually VMs", though we do not currently support custom kernels. You can do VM things in there, like create TUN devices, etc.
Thank you! Yes, KVM. And public IPs are very useful and we want to do them. We will have to charge and/or limit them, unlike VMs, unfortunately, because IPv4 is scarce. (I am busy trying to buy some right now.) You can follow along here: https://github.com/boldsoftware/exe.dev/issues/6
Not super important to me (and you state explicitly it may change) but your docs are a little out of date here, I think. crosvm versus Cloud Hypervisor / Kata Containers, is, I think, different?
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.
Simpler and easier seems to be the answer. How much does it cost to spread 8gbs RAM across some VMs? Most providers require additional of how many VMs over how many hours, what the specs kf each are specifically, etc. Then once you have it you're setting up an SSH key or shared password depending on use and they make the authentication simpler as well. Maybe wouldn't be great for a huge business but it's you just wanted the ability to play with an isolated server, it might be worth it.
I have not used E2B (though I really like their web site), though it looks like there are quite a few differences. Our disks are persistent (without manual snapshotting), we have a TLS proxy by default with built-in auth and link sharing.
It also looks like they have many features we do not have (yet).
I believe the target use is also quite different. You can use exe.dev VMs for running your agent. But you can also use it for hosting your site. E.g. blog.exe.dev is an exe.dev VM.
The description of authentication mechanism is confusing me. it’s over ssh, but how is this integrated?
> Private by default, share with discord-style links exe.dev takes care of TLS and auth for you. By default only you can reach your HTTP services, and you have easy mechanims to share them with friends and colleagues.
You ssh in with any key, and it asks you for an email to verify. You're then at a exe.dev console.
There are a couple different link patterns:
exe.dev ▶ doc sharing
Sharing (sharing) - press q to exit
You can share your VM's HTTP port (see the http proxy documentation /proxy) with your friends. There are three mechanisms:
1. Make the HTTP proxy public with share set-public <vm>. To point the proxy
at a different port inside the VM, run share port <vm> <port> first.
Marking it public lets anyone access the server without logging in.
2. Add specific e-mail addresses using share add <vm> <email>. This will
send the recipient an e-mail. They can then log into exe.dev with that e-mail,
and access https://vmname.exe.xyz/.
3. Create a share link with share add-link <vm>. The generated
link will allow anyone access to the page, after they register and login.
Revoking the link (which can be done with the remove-link command)
does not revoke their access, but you can remove users who are already
part of the share using share remove <vm> <email>.
Thanks! love the idea, looking forward to playing with this. I understand now from comments that this was brought to this site sooner than intended, sorry if I asked in a rude way.
I really enjoyed using this service. I signed up on my phone two nights ago, (using termux + ssh) and then used the builtin web agent to setup a small webapp. I was up and running with an HTTPS server in minutes, since all the HTTPS certs are automatically taken care of.
I'm not using it yet, but the way that it handles sharing looks incredibly sweet: an excellent way to take "home-cooked software and bare-foot developers" "perfect software: an audience of one" from one to a few / many people. Just sharing links that people can easily sign into, without having to build a whole auth system seems ridiculously easy here, and that is super cool. You don't have to think about it, you can just build your app: this fills a huge gap that makes making connected online software so much easier. https://outofdesk.netlify.app/blog/perfect-softwarehttps://news.ycombinator.com/item?id=46334206https://exe.dev/docs/sharing
I used the included Shelley agent, which has a perfectly adequate simple web ui, to do all development. It was able to debug a bunch of pretty gnarly problems, using screenshots & scrolling down to get check it's work.
My output is a super simple site, very close to vibe coded, in ~90 minutes, but I quite enjoyed setting up a little guestbook project here: https://nan-falcon.exe.xyz/
https://exe.dev/docs/how-exedev-works
https://exe.dev/docs/pricing
I think it's the combination of 1) really quick to get going, 2) isolated and disposable environments and 3) can be persistent and out there on the Internet.
Often to get element 3, persistent and public, I'd have to jump through hoops in a cloud console and/or touch my 'main' resources (install things or do other sysadmin work on a laptop or server, etc.), resources I use for other stuff and would prefer not to clutter up with every experiment I do.
Here I can make a thing and if I'm done with it, I'm done. Some things have 'quick to start, isolated, and disposable' down but are necessarily ephemeral and/or don't support publishing and this avoids that local minimum too.
This is good stuff. I hope they get a sustainable paid thing going. I'd use it.
Also, though I realize in a sense I'm wishing competition on a biz I just said I'd support: some parts of the design here could work elsewhere as well. You could have an open-source "click here to start a thing! and click here to archive it." layer you can run on top of your VM or machine or whatever flavor of cloud account; could be a lot of fun. (I imagine someone will want to ask "have you looked at X?" here, and yes, please reply, I'm interested in all sorts of potential values of X.)
(We have also built some interesting tech behind this that we are excited to write up, I have a doc two pages long of blog posts we want to write.)
https://blog.exe.dev/meet-exe.dev
Secure Connection Failed
Edit: it comes out of the box with screenshot capabilities. The defaults on this are very well considered. Im impressed within the first 15 min. Edit2: this is very neat. I will be recommending it to my non-coder friends who don’t really have the local setup to use Claude but would like to try a Claude-like tool.
— $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.)
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.)
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
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.
I'm sure you've thought of this, but lots of people get 'free' (or really: zero incremental cost to them) use of some coding chat tool through a subscription or free allowance like what Google is offering.
If you wanted to let those access your custom tools (browser!) and docs about the environment, a low-fuss way might be to drop a skills/ dir of info and executables that call your tools into new installs' homedirs, and/or a default AGENTS.md with the basic info and links to more.
And this seems like more fuss, but if you wanted to be able to expose to the Web whatever coding tool people 'bring', similar to how you expose your built-in chat, there's apparently an "agent control protocol" used as a sort of cross-vendor SDK by projects like https://willmcgugan.github.io/toad-released/ that try to put a nice interface on top of everything. Not saying this'd be easy at all, but you could imagine the choice between a few coding tools and auth info for them as profile-level settings pushed to new VMs. Or maybe no special settings, and bringing your own tools is just a special case of bringing your own image or setup script.
But, as y'all note, it's a VM. You can install whatever, and use it through the terminal (or VSCode remoting or something else). "It's a computer" is a pretty good open standard to build on.
Is the chat descended from Sketch?
Re sketch: the code is not the same but the agent is deeply inspired by it. Eg the screenshot support, which just seems obvious to us. Philip has done the heavy lifting here, he hangs out in the discord if you want to chat about it.
I love the idea of just ssh in and do your thing. I’ll bookmark and come back when there’s some more info. Things are going to move fast…
> David Crawshaw - before this, CTO and co-founder of Tailscale
> Josh Bleecher Snyder - was a Director of Engineering at Braintree, amongst other things
I have not used E2B (though I really like their web site), though it looks like there are quite a few differences. Our disks are persistent (without manual snapshotting), we have a TLS proxy by default with built-in auth and link sharing.
It also looks like they have many features we do not have (yet).
I believe the target use is also quite different. You can use exe.dev VMs for running your agent. But you can also use it for hosting your site. E.g. blog.exe.dev is an exe.dev VM.
> Private by default, share with discord-style links exe.dev takes care of TLS and auth for you. By default only you can reach your HTTP services, and you have easy mechanims to share them with friends and colleagues.
Is anyone with access to a link able to get in?
Edit: Answered below, thank you.
There are a couple different link patterns:
I'm not using it yet, but the way that it handles sharing looks incredibly sweet: an excellent way to take "home-cooked software and bare-foot developers" "perfect software: an audience of one" from one to a few / many people. Just sharing links that people can easily sign into, without having to build a whole auth system seems ridiculously easy here, and that is super cool. You don't have to think about it, you can just build your app: this fills a huge gap that makes making connected online software so much easier. https://outofdesk.netlify.app/blog/perfect-software https://news.ycombinator.com/item?id=46334206 https://exe.dev/docs/sharing
I used the included Shelley agent, which has a perfectly adequate simple web ui, to do all development. It was able to debug a bunch of pretty gnarly problems, using screenshots & scrolling down to get check it's work.
My output is a super simple site, very close to vibe coded, in ~90 minutes, but I quite enjoyed setting up a little guestbook project here: https://nan-falcon.exe.xyz/
I've never heard root access described like this before and it instantly made me think this is run by script kiddies, trust = 0