2
6 Comments

Dev Environment as a Service - Would you use it?

Hey Indie Hackers!

First-time poster here. I'm a self-taught dev into endurance running, motorcycles, and wine.

When I first started learning, and even now, I really struggled to figure out environment setup and all the non-coding parts of coding. There doesn't seem to be a good solution for this, making the "it works on my machine" statement a meme at this point. Docker solves it in part, but I found it to be super opaque, and not good for the initial writing of code.

I built Booste to solve the machine config issue. It's a command line tool for developers that syncs code to a remote VM (EC2 hosted and managed by Booste) and runs it there rather than locally. One person sets up the VM environment, and team members can jump in and run their code in that environment without setup.

In practice: instead of typing a command like python hello(dot)py to run a python script locally, you'd type booste python hello(dot)py and that flags to the CLI that you want to execute it in the remote env. It processes there and streams back to the terminal, seeming as if it's running on your own machine.

TBH, I've had the service up for a month, launched on Hacker News, and am not feeling the pull I'd expect. Lots of vaguely positive feedback, but the traction and churn doesn't reflect that. I'm at an inflection point where I need to decide: do I need to work harder to get it in front of people, or do I need to change the product?

Would love feedback:

  • Based on this post, do you understand what Booste is?
  • Would you pay for this?
  • What strategies have you used to separate the vaguely-positive feedback from the true signal?

Cheers

on May 30, 2020
  1. 1
    1. Yes
    2. No
    3. Using tools myself

    I'm in the situation that I need to build, maintain, and supervise development environments for multiple people at multiple companies.

    I solved homogeneous deployment by using Heroku. I would not use your solution, because if dependencies are not local on my machine, e.g. python pip packages or ruby gems, then I lose autocompletion for them in my IDE.

    How I plan to solve my issue is by acquiring a company that offers Heroku-like hosting. Developers git push to their service (so just like Heroku) and then they can download a docker image that includes the full setup. That way, one can run the image locally and then mount it so that the IDE has access to everything.

    1. 1

      Thanks for the feedback! It's great to have the context of someone who manages this problem themselves professionally.

      The autocomplete part is one that I had not considered, so I'll put more thought into that.

  2. 1
    1. Yep, completely understand it.

    2. How do you factor in file syncing? Is git / version control still managed locally?

    3. I'd pay for it. I use something similar for work but the biggest challenge is file syncing and file indexing by the IDE. You can either mount a remote disc from the ec2 instance so it behaves like a local one, but then indexing is super slow. Or you can configure your IDE to have files sync up with remote on change.

    I personally think that if you were to get people to use this, you would need to make it super simple to get up and running.

    Lots of devs I know are intimidated by docker because it had a slower start and was buggy for a good while.

    Also, allowing the service to be configurable with common dev stacks and corresponding server packages would help.

    Can you share a demo or a link?

    1. 1

      1: cool :)
      2: you "init" a project out of a directory. From then onward, whenever you interact with the remote environment, the contents of the directory are synced (custom implementation of RSYNC). Changes locally are propagated to the server within a half second. Because remote mirrors local, you'd do your normal git workflow out of your local machine. Booste doesn't really care what you do with git, currently.
      3: cool on the would-pay :) Files sync with remote whenever the local system changes.

      re: Super simple - currently simplifying UX, off of similar feedback. Currently it's three commands to truly get up in running (thus you'd need to lean on docs to understand), and I want to get it to 1 command with a walkthrough style interface. High priority.

      There's a time and place for docker, but it has a learning curve.

      I'm currently building out a "clone" system where you can clone an env off of an existing stack, similar to docker hub. Medium priority.

      It's at www.booste.io - Use the top nav bar to see a tutorial, docs, and create a free user account.

      Thanks for the feedback :)

      1. 2

        Great explanation. Bookmarking it to try this week! Will give you feedback.

        By the way you explained it though, it seems pretty easy to work with. And the headache of having docker running locally and taking up resources is always a pain. Especially for simpler projects.

        I definitely like the concept. Great job man!