3 ms·
Hey HN, my name is Erik. This is my second Show HN for Booste – looking forward to your thoughts. Booste is a command-line interface (CLI) that takes code writ
by edunteman 6y ago
Hey HN, my name is Erik. This is my second Show HN for Booste – looking forward to your thoughts.
Booste is a command-line interface (CLI) that takes code written on your local editor/IDE and executes it in EC2. It runs remotely, in a pre-configured environment, but works with your local tools thanks to a background filesync process.
I want to fix the “it works on my machine” issue by bypassing personal machines entirely. As if Docker and Heroku had a lovechild.
How I came to building Booste:
Being a mechanical engineer turned software dev, there were countless times where my laptop (glorified tablet) couldn’t handle the workload needed, so I made Booste v1: a tool to host full desktop apps on AWS and stream it over RDP (remote desktop protocol) to clients. Some may recall the Show HN of Booste v1 six months ago.
Booste v1 sucked. Unusable latency, crap unit economics, and an infrequent pain point.
Through it all, the most common customer request was for a hosted VS Code. Prospective users wanted the perks of a cloud IDE (namely no-setup environments) but wanted to use their own tools. Diving deeper, it seems that most large companies build out their own (usually buggy) version of remote “devboxes”. The need seemed consistent and clear.
After the first Show HN and a failed W20 interview, I pivoted. I gutted the graphical desktop component, zoomed in on developers, and rebuilt as a CLI: Booste v2.
Running any shell command proceeded by the world ‘booste’ will trigger the CLI. The CLI tunnels that command through SSH to EC2, executes it there, and streams the stdout back down to your command line. Filesync makes sure EC2 is ready with your code.
Where “npm start” would run an app on localhost, “booste npm start” runs the same app in the cloud, visible to your team by URL. You can edit the code locally (VS Code, Sublime, Vim) and the save is synced and hot-swapped on the live URL within a second.
How the environment sharing works:
- The creator of a “Codebox” (EC2 instance) gets a barebones Ubuntu VM, on which they can set environment variables, install interpreters and packages, or set up databases. (pre-built env templates coming soon).
- Team members join the codebox by ID and password with a single “booste join” command.
- Codebox members get repos placed next to each other on the directory tree, so code doesn’t clash.
- There is “booste clone” feature in the works, where you can clone someone’s config without actually entering and messing with their codebox.
Under the hood:
-The CLI is built in Python using the Click library
-Codebox infrastructure is automated with the AWS SDK.
---Currently, they are EC2 instances, for the sake of getting the beta live. I plan to migrate to a more flexible containerized setup in the near future. Containers make much more sense.
-I built a Dropbox-like filesync, inspired by the rsync.
---It monitors a chosen directory on your local machine and syncs it with the codebox.
---When files in that directory are added, modified, or removed, the codebox reflects this within a second. Only differentials are sent.
---All communication is encrypted with frequently cycled keys, unlike rsync.
---Bulky files (ML data, dependency packages), which would otherwise slow rsync to a crawl are ignored by a customizable .boosteignore file.
-Since files sync asynchronously (on edit), the only latency is from ssh. There’s a 0.5 - 1 second delay on booste commands.
I’ve moving from closed to open beta. Fueled by covid and the now mandatory remote development teams, I made a free tier for you.
Give it a try! Let me know what you like. Let me know what you hate.
- bwhiting2356 6y agoA few things come to mind on how this could be really useful: - not having to install things like Docker and Postgres on my own machine, save space, not having to get a computer with as much space in the first place - not having the heaving lifting on my machine means that I won't get the whirring fan and heat from my laptop - not having to deal with managing different versions of node on my machine for different projects - developer onboarding could be faster. There were a lot of little details to get up and running. Getting the npmrc token on my machine so I can install the private packages etc. etc. These could just live in the cloned cloud box that every new developer gets. - lower the barrier of entry for new developers to just start doing something fun and useful. First day of bootcamp was this install-fest where instructor had to babysit everyone to make sure they got everything configured right. It's probably good for people to learn that stuff eventually but it would help to be able to just jump right in. One downside: if the wifi is down you won't get able to get anything done at all. My go-to cloud IDE so far has been Stackblitz. I use it to do little proof of concept stuff, share the link with people. But I prefer working in my own text editor. And you can't do anything more than a simple throwaway project in stackblitz.
- edunteman 6y agoThanks for the ideas! I have yet to see what the usage will be, between having one living "shared" environment, or multiple "cloned" environments. Wifi is an unfortunate issue. Probably a mid-term feature, but one of my early beta users suggested an "offline" version of booste where we clone images downward to the laptop, for use during internet downtimes. Could be a move.
- lukevp 6y agoHmm. I like the idea of making development box setup easier with tooling but this seems less flexible than just doing a vagrant up with an Ubuntu config, or using docker desktop, and costs money. Do people have dev machines that don’t have like 10 gb free to run a VM? Maybe I’m missing something.
- 6y ago