Product Launch
anonymous
448 points
291 comments
Posted12 days agoActive9 days ago
Exe.dev
exe.devbetasaasdevelopers
Key Features
executable documentationautomated testingintegration with development workflows
Tech Stack
docker
Key Features
Tech Stack
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 make an 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 can imagine the choice between a few coding tools and auth info for them as profile-level settings pushed to new VMs.
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.
(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
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.Firefox nightly
148.01a
I'll check for updates
Edit: still broken
148.0a1 (Build #2016134322), 757b8230f44e4152aeb7b9031ff95219471ab993 GV: 148.0a1-20251226204324 AS: 148.20251224050247 OS: Android 15
What TLS error do you get? Untrusted CA?
This site can’t provide a secure connection blog.exe.dev sent an invalid response. ERR_SSL_PROTOCOL_ERROR
For anyone else like me, you can read the article at
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.> 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?
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>.> David Crawshaw - before this, CTO and co-founder of Tailscale
> Josh Bleecher Snyder - was a Director of Engineering at Braintree, amongst other things
If the downvotes were inappropriate, other users will usually correct them. In this case the comment ended up being heavily upvoted.
Unfortunately, complaints like the one you added don't get garbage-collected when that happens, so they linger on, adding noise to the thread.
I've never heard root access described like this before and it instantly made me think this is run by script kiddies, trust = 0
— $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/200 GB RAM)? If so, this is an unbelievable bargain; other cloud providers charge hundreds of dollars per month for an equivalent VM. If it's 2 CPUs/8GB total, Hetzner offers an equivalent 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/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? :-)
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.
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.
Asking for a friend…
exedev@scarlet-canyon:~$ rsync --version
rsync version 3.2.7 protocol version 31
Copyright (C) 1996-2022 by Andrew Tridgell, Wayne Davison, and others.
p.s. thanks for making Tailscale. And I'm loving exe.dev so far!
But my perception from the homepage is you can. Am I wrong?
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.
I think it's the combination of 1) really quick to get going, 2) isolated and disposable environments and 3) persistent and on the public Internet.
Often to get element 3, persistent and public, I had 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.) that I use for other stuff and would prefer not to clutter up more with every experiment I do.
Here I can make a thing and if I'm done with it, I'm done. Some things have the 'quick to start and disposable' part 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 be 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 cloud account; could be a lot of fun. (I imagine someone will ask "have you looked at X?" here, and yes, please do that, I'm interested in all your potential values of X.)
I don't think that it's actually public? From one of their explainers, no public IP is assigned, so you'll need to ar least have to use an additional service like Cloudflare Tunnel to use it for hosting anything.
ssh exe.dev share set-public <yourvmname>It's very much a snapshot of what happens to come on a new VM today, and I put a little disclaimer in it to try to help tools get unstuck if anything there proves to be outdated or a flat-out (accidental) lie.
But if you just need a shell then yes, you can make something similar with docker.
You can do the same thing - with the added burden of actually having to set it up once ... After you set it up, it's however just as trivial to add new systems like with this linked example.
I got pretty much everything I'm self-hosting like that via keycloak (which itself let's me do social with via GitHub and Google etc pp) and a very similar nginx config like it's shown in these docs.
But the initial setup took multiple hours, even if the adding new services which support forward/proxy auth is extremely easy now.
(Jellyfin sadly doesn't as an example)
Just saying it in case you want to check it out.
I think it's fantastic they added that/provide this to their platform - it's a wonderful value-add
The forward auth/proxy auth is not a keycloak feature, it's a proxy feature
> ssh exe.dev
> The disk persists. You have sudo.
on mobile
And cannot open keyboard if that is needed.
Very strange landing page for maybe cool product.
I think knowing what the ssh command does is a pretty low bar for this platform
It's really annoying when you're interested in a product but can't find a price.
It looks like some people who work there are watching this thread, so to them I say: You have got to explain what this is, not just say "the disk persists..." and expect people to dig deeper. Most aren't that curious.
All the About page contains is:
> 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.
Don't defend this. It's not plain. It's obtuse.
A properly designed plain site will have the following text front and centre on it's hero:
"virtual machines in the cloud with persistent disks and sudo, starting from $20/month."
SSH keys are required to access exe.dev.
Same, my first thought was that it's some pentesting game where you're given a VM and your task is to somehow break it. The line "the disk persists. you have sudo" sounds like game rules.
How? It just says `ssh exe.dev`. Unless you are clairvoyant.
Just scroll down and hit the "about" link
The disk and sudo mentioned are good enough clues, then you have the about.
> The disk and sudo mentioned are good enough clues
I mean, you do you and let's agree to disagree about a good landing page UX.
Homepage -> blog -> docs -> "all docs" button:
Which has an about and pricing etc.
That is very counterintuitive to just find out what this is.
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.
It's really a joke of a 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/
131 more comments available on Hacker News
Not affiliated with Hacker News or Y Combinator. We simply enrich the public API with analytics.