(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
Edit: also same on OnePlus Nord N30
147.0b7 (Build #2016133535), 455e50920c4926534376b719df4cf1ed714bc61d GV: 147.0-20251222164020 AS: 147.0 OS: Android 14
What TLS error do you get? Untrusted CA?
I am not sure. I even tried Google Chrome
This site can’t provide a secure connection blog.exe.dev sent an invalid response. ERR_SSL_PROTOCOL_ERROR
https://i.imgur.com/HOwb7g3.jpeg
also tried mozilla firefox on desktop
Secure Connection Failed
An error occurred during a connection to blog.exe.dev. SSL received a record that exceeded the maximum permissible length.
Error code: SSL_ERROR_RX_RECORD_TOO_LONG
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.
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>.Edit: Answered below, thank you.
> 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.
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? :-)
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.
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!
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.
But my perception from the homepage is you can. Am I wrong?
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 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) can be persistent and out there on the Internet.
Often to get element 3, persistent and public, I had to jump through hoops in a cloud console and/or mess with 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 attempt.
Here I can make a thing and if I'm done, I'm done, nothing else impacted, or if it's useful it can stick around and become shared or public. Some other environments also have 'quick to start, isolated, and disposable' down, but are ephemeral only, limited, or don't have great publishing or sharing, and this avoids that trough too. And VMs go well with building general-purpose software you could fling onto any machine, not tied to a proprietary thing.
This is good stuff. I hope they get a sustainable paid thing going. I'd sign up.
Also, though I realize in a sense it'd be competition to a business I just said I like: some parts of the design could work elsewhere too. You could have an open-source "click here to start a thing! and click here to archive it." layer above a VM, machine, or whatever sort of cloud account; could be a lot of fun. (I imagine someone will think "have you looked at X?" here, and yes, chime in, interested in all sorts of 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, which just need some identity provider. If you look for the mentioned term via Google or AI/llm you will find multiple options, some of which are as easy to setup as a simple docker run cmd with an open port
I.e. https://docs.goauthentik.io/add-secure-apps/providers/proxy/...
Zero information available on mobile.
I thought it is some kind of portfolio site that does not work on mobile.
> ssh exe.dev
> The disk persists. You have sudo.
on mobile
And cannot open keyboard if that is needed. It is like big CTA but does not do anything.
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.
Granted, navigation on mobile could be better – the “All docs” breadcrumb is the only way to find the pricing and rest of the docs. On desktop it is clearer.
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."
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.
SSH keys are required to access exe.dev.
Homepage -> blog -> docs -> "all docs" button:
Which has an about and pricing etc.
That is very counterintuitive to just find out what this is.
How? It just says `ssh exe.dev`. Unless you are clairvoyant.
scroll down and hit the "about" link. I do agree though the landing page could be more resourceful.
I'm not going to SSH to a random server.
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.
That’s probably the oddest thing to read on a tech VC forum.
The lading page was garbage. It’s forgivable because designing goods landing pages is hard. But inventing wacky ideas about why a bad landing page might have some hidden genius, isnt constructive feedback
Opening a random website likely exposes you to more risk.
it's fiine i think
... which it is.
> ssh exe.dev
> The disk persists. You have sudo.
I've seen enough of these kinds of services in my lifetime that I also immediately knew what it was, for example sdf.org, which is one of the OG services, and various "tilde" services like tilde.town.
All this was totally lost on me from looking at the website. “I already have tilde and sdf, I don’t need this.”
If I hadn’t looked into the comments I would still think that.
It didn't read as a company with products at all to me from the front page. Just a cryptic " The disk persists. You have sudo." with links to "Login" and "About * Blog * Discord" --- no pricing link, which made me think it was a weird hobby / art.
We do not want to end up in the state AWS is in, where any production work requires navigating the differences between how AWS manage v4 and v6. And that means rolling out v6 is going to be a lot of work for us. It will get done.
I added a public tracking bug here: https://github.com/boldsoftware/exe.dev/issues/16
Trying my way around it now. Not sure what is going on:
me: apt install apache
the shell: exe.dev repl: command not found: "apt"
me: bash
the shell: exe.dev repl: command not found: "bash"
Thanks for trying it!
Oh, I think I found a real shell now! You have to click "VMs" then on the VM and then "Terminal".
Yay, this is great!
The two constraints are that, one, when small underlying resources are expensive (we hope to fix that soon by not being small!), and two, we do not want to make the resource allocation so small that the VM feels unpleasant to use. So there is a floor on how small we make them.
That said, I very very much want to drop prices. We started with conservative numbers.
So, exactly what you said, but for the benefit of the user, and for the profit of the company, by offering an excellent product.
(I am a happy customer of their previous product, Sketch.dev.)
The threat is having a private key stolen, in which case, having multiple keys can mitigate the amount of damage a threat actor can do. However, to steal your private key would involve a successful attack against your client, not against any server you might have given the public key to.
Based on what the commenter below found about sshpiper I believe that you use the ssh identity + the ip from the slot to resolve the vm target. sshpiper knows how to route the ssh identity + slot ip to the correct VM. I suspect you have a custom sshpiper plugin to do that routing.
You use the slot record indirection so you can change the ip of a slot without having to update everyone’s A records across the customer base. It also makes it easy to shuffle around vm-slot mappings within a customer. I haven’t tested, but I’m guessing this dns server is internal (coredns?), and the ips too.
I did something similar (ip + identity routing) for a project a few weeks ago. Yours is a lot more elegant with the dns indirection.
I’m no ssh expert, but in theory you should be able to ssh -J exe.dev myvm.exe.xyz for a one-liner? Or maybe you don't even need it, if that DNS server within the ssh exe.dev is the same as the public DNS. Pardon for not testing it yet!
> $ nslookup abc.exe.xyz
> abc.exe.xyz canonical name = s001.exe.xyz.
> $ telnet s001.exe.xyz 22
> Trying 100.20.12.135...
> Connected to s001.exe.xyz.
> Escape character is '^]'.
> SSH-2.0-SSHPiper
Each VM you create (up to 25 of them) gets a different CNAME record of the form s0NN.exe.xyz where NN ranges from 01 to 25. Each of these names, from s001.exe.xyz to s025.exe.xyz, resolves to a different IP address.
Therefore the individual VM can be distinguished this way, and the account they are associated with can be identified using the SSH public key that is used to authenticate.
> ssh exe.dev
Please complete registration by running: ssh exe.dev Connection to exe.dev closed.
Anyone get a similar issue?
Enjoy my creation https://love-storm.exe.xyz:8001
I mean it and I wish the best of luck for the project
That being said, I tried to look at it for asap golang project deployments and I am the creator of https://spocklet-pomodo.hf.space/ a single main.go + single dep multiplayer pomodoro (please note that it was one shotted out of curiosity and also frustration as https://cuckoo.team would sometimes glitch for me)
That being said, I face the issue where I can't have a go.mod or run go mod tidy because I face this error
exedev@crimson-cobra:~$ go mod tidy go: finding module for package github.com/gorilla/websocket go: pomodo imports
github.com/gorilla/websocket: module github.com/gorilla/websocket: Get "https://proxy.golang.org/github.com/gorilla/websocket/@v/lis...": dial tcp: lookup proxy.golang.org on 1.1.1.1:53: read udp 10.42.0.45:33739->1.1.1.1:53: i/o timeout
Hope that the project fixes this and wishing best of luck to the project. I am a little busy right now with studies but your idea truly inspired me and perhaps I want to create a similar thing or collaborate on it with you too so I will join discord hopefully sooner than later.
I am looking further into it and seeing if I can fix that error as I would love to host some exe.dev's services and wishing the best of luck for the project and hope that it becomes sustainable enough.
Out of curiosity, if I may ask, what is the tech stack behind this which generates the vm's. Is it libvirt or firecracker perhaps?
For my own use cases, I recently rediscovered incus and even ran it on cachyos on my desktop to try it out and there were some hiccups partially because I was running it on non standard debian/ubuntu but I am overall very pleasant with incus but still, I am interested in what tech stack you used so please discuss!!
Also what cloud provider are you using. Pro tip but if you are looking for something cheap, either go with ovh or upcloud.
I really really love hetzner a lot too. (Hey hetzner_OL if you are reading this, love hetzner, have a nice day and hope your christmas was good:)
But still hetzner is a little admittedly more strict than ovh but maybe hetzner can respond to it as I know that their policy can ban accounts if someone abuses and considering that you provide compute (to even free) chances of abuse can rise but overall hetzner's the cheapest so I hope hetzner team might make an special exception/response to your post/my comment.
I am imagining a github private action which ssh's into this and then updates and runs a simple shell script which can be a reinstall state every time someone updates something in git to get git-ops style workflow. If someone implements it for exe.dev, just credit me :) (if you so wish) ` An amazing product overall. 7/10 due to that one hiccup which saddened me a bit (but which I have faith can be fixed) but its a 9-10/10 potential and that means a lot and a 7/10 at launch is pretty good
Please just tell me every decision/question I had in depth since I love details about projects like these ^^
Another minor suggestion I can have is having asciinema gif too to showcase what it does for some people. To me I only understood to run the command ssh exe.dev which then helped me learn but the only way I understood what exe.dev does beforehand was reading the comments on HN
An asciinema can go a long way in this journey, perhaps, let me know your thoughts.
And have a nice day! One thing I am wondering tho is if you are gonna open source the project, one project which feels similar to your project which is open source is this https://github.com/ekzhang/ssh-hypervisor that runs on top of firecracker
UPDATE: this is fixed now.
``` ssh exe.dev Please complete registration by running: ssh exe.dev Connection to exe.dev closed. ```
like you give 2 cpu. 8gb memory for 20vms. Which I believe you wont be able to use 20 of them at the same time if they share 2 cpu only
SSH is really the only protocol you can do shenanigans like that over, it's a shame not to use them.
[1] (seems overloaded right now) https://words.filippo.io/whoami-updated/
ssh crabmusket.github.exe.dev
Small nit: I think you should make it more clear in the docs (if not in the landing page) that one can just use any key with the ssh command the very first time and it automatically gets registered. Also on the web UI one should have the ability to add the ssh keys. I logged into the web UI first, and was a bit confused.
I think the pricing is alright for the resource and remote development features, though might be a bit much if someone doesn't need higher level of resources for deploying something that's mostly already developed.
Anyway, this reminds me of a product called Okteto that had similar UX. They were focused on leveraging k8s for declarative deployment. But for some reason they suspended their managed cloud/SaaS offering for individual/non-enterprise clients, I wonder if it was because they couldn't make the pricing work. Hope that doesn't happen here.
also it's a bad ui meme
The downsides:
- usage-based pricing would be nice, $20/month is pretty steep to start, but also no room to scale up?
- 100GB/month is only 300k views for a small-ish page or API, 10k req/day is a tiny amount of traffic. Can't make anything public with that. Even the smallest servers at Hetzner have unlimited bandwidth
some feedback:
No matter what i do, i can't ssh into VM that i created Local terminal; always timeout built in terminal; SSH handshake failed: ssh: handshake failed: EOF
shelley agent seems to be install, but it always shows isn't running.
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
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.
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.
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.
Sort of a container which "feels like" a VM? Reminds me of Virtuozzo / OpenVZ VM approach which was popular ~20 years ago when RAM was expensive...
- Email delay to Gmail inboxes for verifying an SSH key used via SSH via email is longer than the timeout of the "Waiting for verification email..." stage in the SSH key registration. Wait longer or provide a non-email way to authorize a new key. You could imagine a few ways to do this: Allow users to add/delete SSH keys from the website or exe.dev shell; create a bearer token/random string that I can generate from the exe.dev shell or website to associate a new SSH key; SSH key signatures (existing key signs new key); SSH CAs (like @cert-authority); etc.
- SSH U2F/FIDO2 authentication support has become mainstream, and offers you a way to have homogeneous auth across web and SSH interfaces. Maybe consider unifying authN this way?
- exe.dev ssh interface does not allow me to list SSH keys, only to delete them. Consider moving all authN/authZ functionality into an "auth" subcommand/submenu (like you have for "share") and support SSH pubkey CRUD in there.
- You make some strong assumptions about email addresses that aren't true -- what happens on email address changes, lost email access, etc. This will become more important when you start billing (and possibly costly).
- How do I manage persistent disks? Any way to attach them to a different VM after I'm done with them on the original one? Is there always a single PD per VM or can these be managed separately? What about data or database volumes? Can PDs be attached to one or multiple VMs at a time?
On a side note, a lot of people in this thread are doing a sort of "I don't get it, your website sucks" but it's like, come on dude! Just read the site! It takes less time to read the pricing, docs, and FAQ than it does to post about how you don't get it.
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.
s/cloud computing should like/cloud computing should be like/
I'm very much into the product itself, but that would get extremely tiresome if I was trying to use it consistently. I assume I have to be using it wrong in some way for there to be that much friction...
If you are interested in our work and agents, I would suggest trying Shelley, the little agent we have in exe.dev. There has been some discussion about what to do with sketch on its discord channel, but we won't be putting energy into it going forward.
(A blog post with far more details is in the works.)
I'd love an easy way to connect to and run an existing GitHub/GitLab repo in a VM and spin it up, and iterate on that and be able to open PRs etc from there.
Also, stop charging for SSO/OAuth2 integration. Seriously. There's a huge list of services that stupidly charge for SSO/OAuth integration at https://sso.tax, and this list needs to get smaller, not grow. SSO doesn't cost anything to implement. Especially if I'm the one hosting it on my own infrastructure.
I can't tell if this is sarcasm or not. I'm going to assume that it is, in fact, sarcasm. Because this is definitely untrue in reality.
I run a bunch of services for friends and family, things like Immich, wallabag, mealie etc. Less than 10 users, but do you expect me to crate and maintain separate accounts for each one for every service?
The SSO tax is stupid. If your whole business model is based on putting SSO behind a paywall, it’s a sign of a broken business model.
But it was a choice that does not come for free. I dread a page of buttons for third-party services, and the control I give them over my life. I hate that I never know if I should log in with GitHub, or Google, and for a dozen services I have multiple accounts because I got lost in the miasma of oauth2.
Still, it was better than passwords!
But since the last product I built, the world has changed. We have passkeys now. Which are superior in every way for individuals using a third-party service. You get better UX. You get better privacy. It is a fundamentally better technology.
I did not list SSO under teams because I want to "tax" people. I did it because SSO only makes sense for businesses, where an administrator controls accounts, and can delete yours when necessary. There, oauth2 is the best technology we have. But for individuals, it is a dead technology. I am reluctant to make everyone's exe.dev experience worse for legacy tech.
Passwords are much better than the OAuth2 coolaid, and passwords will still be better as long as older devices can't support passkeys due to arbitrary restrictions.
Passkeys work great for me and I greatly prefer them. Exe.dev I think is the first service I've seen that's so passkey centric and it makes a lot of sense.
> 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
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.
Did have an issue with auto-generated server name being taken (and similar names being taken). So there could be even less friction on that aspect. But I like the idea of not talking/listing features or showing diagrams, just give me access.
I mean I do need to know pricing, usage limits, uptime etc. But just let me easily find that after giving access.
1. the home page should have a link to all docs
2. about page docs link should be a link to all docs, not a link to itself
reactordev•1mo ago
crawshaw•1mo ago
reactordev•1mo ago
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…
twotwotwo•1mo ago
I'm sure you've thought of this, but: lots of people have some amount of 'free' (or really: zero incremental cost to users) access to some coding chat tool through a subscription or free allowance like Google's.
If you wanted to let those programs 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 quite a good open standard to build on.
Is the chat descended from Sketch?
crawshaw•1mo ago
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.
reactordev•1mo ago
Man, this brings me back. Kudos to you guys! Just find a better solution than Ceph or minio.
jeffrallen•1mo ago
Also, telling Shelley to get inspiration from the VM name can be fun.