crawshaw

Interestingly, it's the .xyz on our VM domain that causes problems. It's apparently far more of a problematic gTLD than I realized. E.g. it appears Southwest Airlines blocks the entire thing, as do some enterprise networks are working with.

(We have a fix for this coming in a few weeks.)

(exe.dev co-founder here) The platform is designed make it easy for you to share if you like, but we are not typically in the business of pointing directly at products users make. Maybe we should change that! It would be fun to have a "best of exe.dev" on our site.

I’m just going to keep building. :)

If you have a good local VM flow that’s great. I couldn’t make it work for me. I ended up needing it to run when my laptop was shut, both as an agent and the servers I am building.

It’s a real tension, working with a remote dev env has never been my first choice. But agents seem to tip the balance enough in favor of remote that I have switched.

I think it’s worth trying. There’s a lot of value in having the agent in the box. You can give it root so it can do something like tcpdump unsupervised. And if you happen to build a new server, you can keep it serving indefinitely. That’s the whole motivation behind exe.dev.

For those looking to run agents: the short lifecycle of the typical “sandbox” seems surprisingly limiting to me. I have no actual workflow where I want one of these products. Sometimes a VM can live for 30 minutes, but it also might need to live for a month, and I don’t know beforehand.

This is why I have been avoiding the word sandbox for exe.dev. I don’t think developers agents need something “sandbox” shaped.

This is the nature of large institutions: they have to distrust their own people. You cannot be relied on to act well, you must be checked first.

There is a good reason for this! In a large group of people, there are bad people.

This is also why I am done working at large companies. I learned a lot, met some great people, but am uninterested in a low trust environment. I like relying on my colleagues. When they do something unexpected, I am surprised and study it to learn, not lambast.

My eight year old found a Terry Pratchett book of mine on the shelf the other day. He is a little too young to read them today but I realized I get to enjoy Pratchett all over again through him.

Nah. There are billions of people on the internet, and it varies from a dusty library to Atlantic City (though for some reason we let kids into the casino?). It is not one thing any more, but there are plenty of fun corners.

I could type ~four lines and an alert box response from a visual form.

For years I have lamented the amount of paperwork necessary in most of modern programming to get things done. I don't know how important that is now that I have a machine fill out the paperwork. It would still be better if there was less fuss.

exe.dev | full time member of technical staff | sf bay area only

competitive salary, meaningful early equity, 2 days a week in the downtown sf office

come build a cloud. we are doing everything from custom hardware to custom ssh servers to our own global load balancer. very senior small high-trust team looking for someone we can rely on to get done whatever is most important in the stack for the business. some days that means patch the vmm. other days it means figure out passkey quirks.

more about what we are building here: https://crawshaw.io/blog/building-a-cloud email me at david@exe.dev.

One VC (well, two) understood it. Despite what you hear, there is a lot of variation. Speak to a lot of people.

Hello, author here.

Our exe.dev web UI still runs on AWS. We also have a few users left on our VM hosts there, as when we launched in December we were considering building on AWS. Now almost all customer VMs are on other bare metal providers or machines we are racking ourselves. We built our own GLB with the help of another vendor's anycast network. You can see that if you try any of the exe.xyz names generated for user VMs.

We would move exe.dev too, but we have a few customers who are compliance sensitive going through it, so we need to get the compliance story right with our own hardware before we can. It is a little annoying being tied to AWS just for that, but very little of our traffic goes through them, so in practice it works.

Author here.

I need to fix our transfer pricing. (In fact I'm going to go look at it now.) I set that number when we launched in December, and we were still considering building on top of AWS, so we put a conservative limit based on what wouldn't break the bank on AWS. Now that we are doing our own thing, we can be far more reasonable.

Author here.

Almost every VC rejected us when we went to get seed funding for Tailscale, we knew none of them. Friends of friends of acquaintances got us meetings. Fundraising is very possible for you if you are committed to building a business. Most important thing is don't think of fundraising as the goal, it is just a tool for building a business. (And some businesses don't need VC funding to work. Some do.)

The biggest challenge is personal: do you want to build a business or do you want to work with cool tech? Sometimes those goals are aligned, but usually they are not. Threading the needle and doing both is difficult, and you always have to prioritize the business because you have to make payroll.

Author here. Most of our infra is custom, the VMM is based on cloud-hypervisor (a project spiritually similar to Firecracker). We have a lot of work to do, including on the VMM, but right now there is more value for users if we spend our time on the VM management layer and GLB.

Hi, co-founder here. If you would like more detail, and often HN does, I wrote up some more about what we are doing here: https://crawshaw.io/blog/building-a-cloud

This is an S-1 for Firefly Aerospace Inc.

Based on this and recent product releases, Anthropic seems keen on building a closed ecosystem around their excellent model. That is their business choice, I suspect it will work well. But I cannot say I am particularly excited to have my entire development stack owned by one company.

You can get this effect today by installing Tailscale on your exe.dev VM. :)

The reason we put so much effort into exposing these publicly is for sharing with a heterogeneous team without imposing a client agent requirement. The web interface should be easy to make public, easy to share with friends with a Google Docs-style link, and ssh should be easy to share with teammates.

That said, nothing wrong with installing tunneling software on the VM, I do it!

Amazingly even most p2p works with NAT, see (and I am biased here) Tailscale.

I certainly wish we simply had more addresses. But v4 works.

(exe.dev co-founder here)

We are not running out of IPv4 space because NAT works. The price of IPv4 addresses has been dropping for the last year.

I know this because I just bought another /22 for exe.dev for the exact thing described in this blog post: to get our business customers another 1012 VMs.

(exe.dev co-founder here)

IPv6 does not work on the only ISP in my neighborhood that provides gigabit links. I will not build a product I cannot use.

Even when IPv6 is rolled out, it is only tested for consumer links by Happy Eyeballs. Links between DCs are entirely IPv4 even when dual stacked. We just discovered 20 of our machines in an LAX DC have broken IPv6 (because we tried to use Tailscale to move data to them, which defaults to happy eyeballs). Apparently the upstream switch configuration has been broken for months for hundreds of machines and we are the first to notice.

I am a big believer in: first make it work. On the internet today, you first make it work with IPv4. Then you have the luxury of playing with IPv6.

That is very true. We use copy on write for exe.dev base images right now, and are accumulating a lot of storage because of version drift.

We believe the fix here is to mount the base image as a read-only block device, then mount a read-write block device overlay. We have not rolled it out yet because there are some edge cases we are working through, and we convinced ourselves we could rework images after the fact onto a base image.

Right now our big win from copy-on-write is cloning VMs. You can `ssh exe.dev cp curvm newvm` in about a second to split your computer into a new one. It enables a lot of great workflows.

Nice to see this work! I experimented with this for exe.dev before we launched. The VM itself worked really well, but there was a lot of setup to get the networking functioning. And in the end, our target are use cases that don't mind a ~1-second startup time, which meant doing a clean systemd start each time was easier.

That said, I have seen several use cases where people want a VM for something minimal, like a python interpreter, and this is absolutely the sort of approach they should be using. Lot of promise here, excited to see how far you can push it!

Send me an email!

exe.dev | Full time | SF Bay Area | multiple roles

Support Engineer - If you want to use Claude or Codex (or Shelley!) to trawl through our code base, augmented with (carefully scoped) API keys to make our customers lives better, we are hiring.

Designer - If you want to use Claude or Codex (or Shelley!) to make our product functional and beautiful, we are hiring. You do not ship mocks or assets to other teams. There is no other team. You ship by pushing to production. Don't worry, we've got your back.

Software Engineer - If you see a pattern here, we are hiring. Expect to design, build, and run entire subsystems. What matters is attention to product detail and overall architecture, we have agents for writing code.

With significant industry experience, pay will be over $200,000 with meaningful equity.

We are a small team and going to stay one. The focus is building a high-trust environment. Success for us is if you say "I'm going to fix the load balancer" we all sigh with relief, because you are on it and we can rely on you to take on and solve large projects.

The concern is not losing access to some new IDE for operating outside the terms of service. The concern is when you lose access to the IDE, you also lose access to your 20 year old Gmail account.

A general problem for Google products is that everything is mixed together.

But you also want smart phones, electric cars, and a navy. There needs to be a path towards doing things other than foisting them on people who are out of sight.

Lot of things could be added to this list. Good luck getting permission to start a hospital, or permission to mine/refine anything with a slightly messy process (e.g. rare earth metals). You can't build a new port. The California Coastal Commission won't let you open a new hotel anywhere on the water. You can't even keep a bar open late in San Francisco.