Launch HN: Nimbus (YC W22) – Cloud dev environments for teams

[liushh]

Hey HN! We’re Nish, Liusha and Neil, the founders of Nimbus (https://www.usenimbus.com). We’re building an easy way to code and manage environments on cloud VMs that are configured for projects you’re working on. There’s a video demo here: https://www.youtube.com/watch?v=0g6Jk5zyQG4.

Initially, we were working on simplifying dev environments for coding school students. But when we found ourselves using what we were making and finding it useful for our own work, we pivoted to dev teams like us.

Big tech companies like Facebook, LinkedIn, Shopify, Slack, Dropbox, etc. all have in-house cloud environment solutions. This lets engineers spend more time on software design and writing production code and less time waiting, testing or troubleshooting. With Nimbus, we’re bringing the same convenience to everybody else.

The three biggest pains Nimbus alleviates are compatibility issues, scaling challenges and not having a powerful enough dev machine.

Compatibility issues touch hardware, software, and users. The leading cause is poorly supported tooling on M1 and M2 architecture or a varied fleet of Mac, Linux and Windows devices of various specs. This is made more complex by tool/package updates that break support for that fleet and the impossible task of writing and maintaining perfect documentation.

Scaling challenges build on the compatibility issues. Engineers can spend days to get access and setup environments for every project they touch. Containers help but it’s only part of the solution and tools like Docker can be so resource intensive that slow devices to a crawl. And then, once everything is set up, important data and code sits on the laptop - which is a hugely vulnerable endpoint (probably second to smartphones).

Nimbus lets engineers always pull the right environment, eliminates local env management and debugging, and makes environments portable - engineers can work from any machine because the code runs and stays in the cloud.

We want Nimbus to be easy to use and flexible enough for any developer, so we provide persistent and ephemeral VMs (EC2) that work just like local development. You create a ‘template’ that tells us what kind of machine and OS you want. Then you load up a ‘workspace’, which is a cloud machine near you for the lowest latency possible. You can jump into that server via our local VS code plugin (Jetbrains coming soon) or the remote dev capability of your IDE and get to work. At any point, you can ‘snapshot’ the image and use that as a ‘template’ for future workspaces.

Here are some examples of ways we’re being used today: a European logistics software company replaced their internal cloud infra with Nimbus to improve reliability and reduce engineering and cloud costs; a fast-growing international fintech company is using Nimbus to bring reliability and consistency to dev environments that broke often; a software development agency is using Nimbus to cut onboarding for their engineers from days to hours; some developers are personally using Nimbus to work at home from their gaming PC and extend their laptop battery life when away from home.

Other products in this space focus on simpler use cases (e.g. Replit) or have design choices and limitations that we weren’t happy about. Codespaces is the best-known offering but it’s expensive, not platform-agnostic, and has limits from its repo-based workspace design. Some people ask if we compete with Docker but most of our users use Docker in Nimbus - and Docker’s poor performance on Mac is one of the main reasons people try Nimbus.

We have a free trial if you want to check it out: https://app.usenimbus.com/. We’re currently working on self-hosting capabilities, enabling prebuilds, and easier templated environment creation – but we’d love to hear what you want. And we look forward to your thoughts and feedback on Nimbus and coding on the cloud in general!

[rsstack]

We're Gitpod users and we absolutely love it. Clean environments for every feature, fast onboarding, easy multitasking, easy PR reviews, great. I also used AWS Cloud9 in the past and GitHub Codespaces. I'd also include Stackblitz in the category.

What's the differentiation of Nimbus? Why should I get my team to try out Nimbus?

(Not a trick question, I'm just trying to understand how I should remember Nimbus for the next time the question of picking a cloud dev env solution comes up.)

[nithayakumar]

Nimbus is more like local development, we're building for teams that use a wide set of IDEs. Think of us as a "machine first" cloud environment instead of "repo first". So its like having a laptop in the cloud for every project.

Our differences means we've prioritized local editor integrations, use a full EC2 machine dedicated to each user, aim to be more flexible (e.g. you can schedule when your machines are active), and provide more power (right now up to 8vcpu 32gb ram, but customizable by us).

Codespaces, Gitpod and the like are repo first and provide containers instead of VMs. Codespaces doesnt support non-VS Code Users. Gitpod tops off at 8gb or 12gb of ram. We also decided not to go the browser based IDE path that Stackblitz took because the engineers we talked to really didnt want a new IDE.

Hope that helps!

Edit: Want to clarify that I'm Nish from Nimbus

[gigatexal]

+1 to this. I came to ask the same questions.

[8organicbits]

I don't see a lot of discussion about security at the moment, other than a potential for self-hosting. I created an account but I don't see MFA, which is a hard requirement for me. I'd love to look again once virtual MFA or hardware MFA is supported. I'd also be comfortable with GitHub OAuth as well, since I can manage MFA there and I think I'd integrate GitHub anyway. I'd love to see a paid bug bounty program for a product like this.

If that's addressed, I'm interested, although my use case is different. I do contract work, mostly short-term time-sensitive projects where I need to rapidly get productive on client systems. So far I've managed this by working from a beefy machine and putting each client's environment in their own local VM. The separation of clients is important since I work with multiple clients at a time, and mixing would be a huge issue.

This works fairly well. At the start of the contract I spin up a new VM. I've got standard dotfiles and install scripts I copy/paste from a Gist, then I manually install anything client specific. I needed to spin up a cloud env recently for a client who had a very memory hungry web app. The cloud env worked well, although I noticed the latency.

It looks like Nimbus will let me spin down my "beefy cloud VM" when I'm not using it, to save costs. I don't do that currently, mostly because I don't see a _trivial_ one-click way to do it. This looks like roughly 2x EC2 pricing (8cpu/32G $0.26 vs $0.58), so reducing running hours is key. I'd want fast VM start times, I don't want to wait too long. I'd probably be interested in even larger instance types, as throwing more hardware on a project is worth it to me if it helps me work faster and justify higher rates.

(edit, looks like there's a 14 day trial. I won't try this before there's an MFA solution, but it would be nice if the trial would start when I spin up the first VM.)

[liushh]

Liusha from Nimbus here.

>I'd love to look again once virtual MFA or hardware MFA is supported.

MFA is not far. We have already started to work on MFA across our solution. I will ping you as soon as we have it ready for you.

Actually your use case is also something we are really interested in. Engineers who work on contracts or work at IT consultant companies switch between different environments way more frequently than other use cases. I wonder how you mitigate that problem today?

> The cloud env worked well, although I noticed the latency.

About latency, can I ask what your geolocation is? (country?) and which region did you select from Nimbus?

> I'd want fast VM start times

We have provided a `active hours` feature (not available for trial user). You can have your server start/stop at a given time of the day. During that time range your server will always be active. only takes about 10-15 seconds to connect.

[sandGorgon]

how does it work ? it is git integrated i assume...and do u export a Dockerfile or something to replicate the exact runtime ?

my fundamental question is : how easy is it to go from writing code to production deployment ? This has been the big issue with cloud dev. Take an example of Python flask with Pandas. There are problems depending on whether u used an alpine dev environment or debian. Now if i just take the code and try to deploy it on redhat...it goes all screwy. lots of the c library extensions start screwing up.

Can i single click create a running docker environment with my running code EXACTLY like the code dev environment.

Funnily enough, the only good one here is AWS Sagemaker - https://docs.aws.amazon.com/sagemaker/latest/dg/docker-conta...

They do this for machine learning code. You can take your data and algorithms out of the ide and get a running docker container with all the build scripts and everything.

second - ur pricing is off. part of the charm of a cloud dev environment is never turn it off. like shutting the lid of my macbook m1 and opening tomorrow morning. even the cursor is in the same place. There is zero incentive for me to shutdown a system and reopen tomorrow morning. In that scenario, ur pricing for an 8 core 32 gb instance is 421 USD per month. Comparitively a Google Cloud 8core 32 gb instance with 100 GB SSD is 212 USD.

Sagemaker Python notebooks ml.t3.2xlarge are 0.399 USD per hour - about 288 USD per month. you will need to adjust pricing.

replit pricing of 7$ hacker plan is cheaper than equivalent Sagemaker pricing (about 36$ per month)

[neilxchen]

Neil from Nimbus here.

You can view Nimbus workspace as a linux machine that you have, but on the cloud. We built an internal Dockerfile-like IDL to replicate the exact dev environment every time when a new workspace is being created.

- We love Dockerfile, but we didn't directly build on top of it because there are more configurations we want to enable (such as on create/start/stop/delete lifecycle hooks, and personal/team configs).

- That being said, I can imagine exporting a Dockerfile can be feasible on Nimbus for the future (sufficient to replicate a new dev environment), but with certain Nimbus specific features missing there.

> it is git integrated i assume...

And yes, you are right! It's has git integration, and we are working on more tooling integrations right now to build better developer experiences (talking about all the source code management tool the team is using, credentials/env variable tools, etc)

> how easy is it to go from writing code to production deployment?

I'm totally with you. As an engineer myself, to me, only having code deployed on the production marks the completion of something, instead of just merging the code to the main branch. So it's important to have an efficient/stable way to move a piece of code to PR, to staging, and eventually to production.

As for Nimbus team, we don't solve this question as our main value prop, but we do facilitate that for sure, by

- making Nimbus a seamless part of engineers dev workflow (among all your task tracking, SCM, CI/CD tools)

- providing flexibly on setting up the dev environment (e.g. you can set it up in a way that is more consistent with the production setup, but still contain development-specific tools)

> Can i single click create a running docker environment with my running code EXACTLY like the code dev environment.

Not an expert of Sagemaker myself - do you mean auto-generating a Dockerfile based on your codebase? :-)

[nithayakumar]

Nish here. Let me address the run time and pricing question - my cofounder wants to touch on the other question.

Teams have told us that they want to avoid 24/7 machines. It gets really expensive (and wastes energy) when people keep creating instances and leave them on. Our approach is to let people keep them on 24/7 if they want, but we want them to stop the instances too (we have automation for this).

That said, the way we’ve set up our environments is that the machine doesnt “turn off” - we just stop it. So its like closing your macbook lid and reopening it. You don’t lose your progress and youre not charged for the time in between.

And Replit’s Hacker plan is cheap but they aren’t very powerful (just 2vCPU and 2GB ram)

[chrisweekly]

> "my fundamental question is : how easy is it to go from writing code to production deployment ? This has been the big issue with cloud dev."

This is my question too.

[TylerJewell]

The remote dev environment space is heating up. Quite a few variants and competitors now emerging in this generation of vendors. I started and sold Codenvy to Red Hat which implements Eclipse Che and Eclipse Theia as CodeReady Workspaces.

There are increasingly limited differentiation between various vendors. The biggest improvement areas needed now are simpler configuration, faster boot times for complex projects (pre-built code, cached artifacts, IDE plug-ins configured).

Cloud9 IDE Appvia Coder CodeSandbox CodeZero.io DevSpace Desktop Tilt Env0 Floxdev Gitpod Itopia Spaces LocalStack MetalBear Azure DevTest Labs Visual Studio Codespaces Nimbus Okteto SourcePro Porter Codeready Workspaces Repl.it Stackblitz Strong.network Subpoint Solutions Tangram.dev

[nithayakumar]

Nish from Nimbus here.

Personally, I dont think this is going to be a space where one company "wins the market". Whats best for developers is having flexibility and choosing the right tool for what their building and their team. So I'm hoping that these products become/stay more open and let people pick them up and drop them as needed.

On the differentiation front.. there's some common differentiation points, but to your point there's going to be someone doing things like you when theres more and more competitors.

Also - brilliant job with Codenvy! You're one of the pioneers in the field. When we started Nimbus we did our research (even talking to the folks at Koding, NitrousIDE, etc)

[liushh]

There are definitely more alternatives in the market now. But I do see the differentiation pretty clear (maybe because I am building it) Actually I think you are pointing out some great categories for differentiation, simpler config, faster boot time, and so on.

A few more things we learned based on the current market is that the team is way more distributed geographically now. So the latency and collaboration across different geolocation are also two areas we really focus on.

[verdverm]

Those are the public ones. We manage our own with packer and Ansible, technical a suite of dev VM images, depending on the role or tasks (i.e. reg vs ML).

[emptyparadise]

I wonder if there are any drop in self-hosted solutions for this? Would be great to just use a tool like this even for personal dev.

[dataminded]

I LOVED Codenvy! Kudos.

[zoomzoom]

Tyler, don't forget about Coherence! (withcoherence.com)

[jedberg]

I like this idea, but on a side note:

Mainframes are back baby!

> engineers can work from any [network connected] machine because the code runs and stays in the cloud.

Now that we have pervasive and quick internet in most of the places people want to work, we can start offloading the work back to centralized machines.

It's honestly a more efficient use of resources to have shared central systems, we just had to move away from them for a few decades because the networks couldn't keep up with where people wanted to work.

[neilxchen]

Neil from the Nimbus here.

Yeah, we are actually huge fans of writing code on the cloud!

To me personally, It feels awesome to offload the package/repo download to the data centers, which can be way more faster than my own network. Not even mention that my laptop no longer heats up crazily - I can just put it on my lap and write code.

[thegandhi]

One of the biggest problems with dev environments is maintenance just like documentation. As a dev, when I am working on my local environment, if something breaks, I usually end up finding some hack to fix it and move on with my feature/assigned task. Most devs leave it to the "new guy" who is onboarding. I also think having templates as code might be a way to alleviate that issue to certain extent.

[nithayakumar]

Nish from Nimbus here.

This is on the money. The challenge though is still giving engineers flexibility/freedom. Our approach is to have templates that engineers can use but they can fork it and play around with it, make a snapshot of that fork and share it, etc. Its a fine balance though and every team has to figure out what works best for them

[hardwaresofton]

Congrats on the launch -- great minds think alike I guess... I've got a little think I'm still churning on @ https://nimbusws.com

Love the site, digging into the concept...

One question, how does Nimbus manage secrets/creds? Integration with KMS?

[neilxchen]

Neil from Nimbus here

Thanks for the support!

> One question, how does Nimbus manage secrets/creds? Integration with KMS?

It actually depends on what type of secrets/credentials that you are referring here

- For third-party tool login credentials (e.g. the GitHub authorization that we currently support), we are handling that with OAuth. That means we don't directly store secrets/creds on our end and developers can revoke the authorization any time on that tool and/or Nimbus;

- For any secrets/credentials that may be used in environment variables and dotfiles. They are currently lives within the "workspace" scope. That means, if developers delete the workspace, the credentials will be gone, and we don't persist them at the moment.

We are actively working on persisting env variables and dotfiles as part of settings of org/template/user, and the feature will become available soon.

We are also actively working on self-hosting Nimbus on customer's cloud - so if security is the top concern in your mind, with self-host solution, any secrets/credentials will never leave your cloud (together with codebases, user data, etc.)

Happy to provide more insights if you have more questions!

[mvice]

This looks really cool! I use various different environments on a daily basis (windows, mac, linux) so being able to access my dev environment regardless of what machine I'm on is awesome.

[neilxchen]

Neil from Nimbus here.

Thanks for the support! I'm also switching between mac (laptop) and windows (desktop) multiple times throughout the day (depends on where I'm sitting at that moment). Using Nimbus to build Nimbus definitely helped me a lot in this scenario!

[dianaviolet]

Sound like it could be really useful. Wondering if there will be a method to load the remote workspace locally if I need to do development without internet (travelling, etc)

[liushh]

Great question! (Also a tough one)

I have been using Nimbus on my flights and it works well. Of course depends on your geolocation, the latency can be higher than normal but the internet speed should not be a blocker because all the intense internet traffic happens on the data center.

However, without internet it would be challenging to leverage Nimbus solution at this moment since the environments live on the cloud 100% now. But in the future, we will look into a hybrid solution. In short, we can offer the option to rsync (or similar tools) the cloud environments into your local or the other way around to facilitate this corner case.

[nithayakumar]

Nish from Nimbus here

We have some loose plans but not really high up to be honest.

From a traveling perspective, it works well... as long as you have internet..you get fast download speeds (based on AWS data center transfer speeds), can work on an env more powerful than ultrabooks, and your battery life is longer.

But you can't work from a jungle or a plane without wifi :)

[boundlessdreamz]

1. Your pricing assumes 30 hour / week. What happens if we use it beyond that?

2. What do you mean by "Local File Sync" here - https://endurable-podium-3d4.notion.site/Nimbus-vs-the-compe...

[nithayakumar]

1. The usage based fee goes up or down based on the hours used. So if you use 60 hours / week, expect it to be double the estimates. In a few months, we'll be launching our "self-hosted" option that lets you avoid usage fees from us by running it on your own AWS.

2. Basically, you'll be able to keep the files synced between your local environment and your Nimbus workstations

[vyrotek]

Looks interesting. We're actively looking at Azure DevBox right now but we need Macs too. We'll check it out.

https://azure.microsoft.com/en-us/blog/announcing-microsoft-...

[liushh]

Do you mean having a MacOS on a cloud machine?

[jeffbee]

All I really want is to open VSCode and remote into a thing, no matter what it is, where my repo is available, and to build my bazel targets with remote execution and caching. But at 4x the price of EC2 instances I'm honestly not seeing what's being offered here or how it helps me.

[nithayakumar]

We're working on self-hosted right now. When that comes out, you'll be able to do exactly what you want without any usage fees from us (you'll take on the AWS usage, storage, load balancer, and other fees though).

[jcolella]

Awesome work on the launch!. I was wondering what the main difference between Nimbus and something like https://devspace.sh/ is?

[zdloft]

Hey there! Ziyad from Loft here.

Nimbus is more like GitPod/Codespaces and not intrinsically linked to Kubernetes like DevSpace is. DevSpace is optimized for cloud native development and you could run it on top of Nimbus to connect your dev environment to a k8s cluster.

Hope that helps!

[erikpukinskis]

As a Codespaces user, glad to see competition in this space!

[liushh]

As a Codespaces competitor, glad to see a Codespaces user giving us some attention.

Love to see how you like Nimbus and how you feel the difference between different alternatives.

[zerop]

Are Cloud environments/IDEs going to replace the desktop/laptop we give to dev teams. What's the comparison wrt cost and ease between two?

[nithayakumar]

Nish from Nimbus here.

The cost of a laptop is a factor but its a drop in the bucket relative to the cost of an engineer. A $4k machine over 2 years on an engineer that has a fully loaded cost of over $200k/yr is only 1% of the total cost - not huge.

The real win is in helping engineers do more while saving time. This has huge impacts on the dev experience, productivity and general happiness in a role where many experience burnout.

But to answer more plainly, in some cases it will replace laptops (e.g. some companies ship laptops to their contractors to keep their code and data secure. They wont have to anymore). In other cases, teams save money on laptops (through lower spec'd machines with a longer lifespan).

[Vendan]

Where I work, IT owns laptops, and is not a part of engineering. Getting things installed on new laptops is apparently not possible. On the other hand, a cloud instance (either this or something similar) is owned by engineering, so it's much easier to control the base image and such.

[vladdoster]

- How do users that don't use VScode (i.e., Jetbrains IDEs, Vim) use Nimbus?

- Why EC2 instead of EKS or container oriented AWS service for running workspaces?

[radiojasper]

Your documentation in Notion is annoying me because at the bottom of each page you have no footer, no navigation, nothing. So after each page I've read, I have to use the top left breadcrumb, remember which page I've just read and find the next page in the list to continue reading through your documentation.

[yabatopia]

Maybe they should use Nimbus for their documentation? Nimbus Note, that is: https://nimbusweb.me/ . I use Nimbus Note occasionally, it’s a bit confusing, both using the same name.

[nithayakumar]

Noted and very fair comment - thats definitely an area that we want to upgrade.

[nih0]

Is there any cloud dev env that supports development of graphical applications that aren't webapps ?

[jn31415]

Are you hiring for customer service or engineering roles by any chance?

[fuzzmuzzy]

Great stuff. Looking forward to JB Gateway compatibility! Really looking forward to cloud environments being more of a "thing". All the places I've worked at have struggled with various Dev environment issues

[liushh]

Nimbus is now compatible with JB Gateway actually even though we don't have an official JB plugin, which we are actively working on already!

Feel free to check out our doc about how to set it up here: https://www.notion.so/Connect-to-Nimbus-workspace-8c7c5b41d9...

[nithayakumar]

Yes! I think the problem is that it looks simple to build. But once you get in the weeds - its not so easy to manage performance, flexibility and stability :)

[tomasHokali]

Great product, it's true that there are not many options to optimize and make more efficient the day to day of an engineer working on small-medium size companies. This product has great future.

[neilxchen]

Thank you for the support!

[gabereiser]

Not to pull attention away from the OP but do these web-based dev environments have any traction in larger organizations? To me this seemed like a novel way to enforce strictness in SDLC for junior devs writing javascript-like code but never came close to having the real IDE on your machine.

The only area where I can see this making sense is in the realm of AI/ML where you need beefy GPU's and resources to train models and it's easier to keep them close to the runners.

What's the value prop for something like this (or code spaces, or <insert name of some cloud dev ide service>)?

If you need reproducible builds? Why not just use docker?

[liushh]

Liusha from Nimbus here.

Actually the larger the organizations the more necessary a cloud-based dev environment solution. That is why all the tech giants have a solution internally like Nimbus and all organizations with more than 500 engineers that I have talked to have something like Nimbus.

> To me this seemed like a novel way to enforce strictness in SDLC for junior devs writing javascript-like code...

The key is not to enforce a strict SDLC. The key word is `Consistent`. I can see some exceptions where teams want to have inconsistent environments but I believe vast majority of the teams want to have consistent environment within their eng org. It means easier onboarding, fast recovery, and better collaboration.

> ... but never came close to having the real IDE on your machine.

If you are doing iOS development or something similar I would agree that IDE on your machine is a necessary. After all, you still need XCode. (even that, I see technologies are catching up...) But other than those native apps, I don't see real difference between a local vs cloud dev environment.

Can you share some examples? What can you do on local but very difficult/impossible to do on cloud dev env?

> If you need reproducible builds? Why not just use docker?

Here are some of my thoughts:

  1. in a small scale (3 micro-services + 1 DB + 1 webapp), I think docker does an amazing job to ensure reproducible builds. But as the complexity grow, docker starts to shift from part of the solution to part of the problem. Just to throw out some questions: how to manage compatibility if a team uses Windows, Mac, Linux at the same time, even with different versions? How to ensure 237 of my engineers do not have a broken environment when I want to bump the docker version? 

  2. There are things should not be part of docker images and those things are more troublesome than the build itself sometimes. For example: credentials, env vars, and so on. I don't remember how many times I need to ask a bunch of people just to get the credentials right. 

  3. Even an amazing tool like Docker does not have 100% of the market. So we may be a good alternative for the teams who choose not to use Docker.

Of course, there are various solutions to those different problems. I believe we are one of them. Moreover, I believe we can integrate with other solutions to solve the bigger problems.

[jatins]

> do these web-based dev environments have any traction in larger organizations

They have traction _especially_ in larger organisations imo.

afaik at least Google and Amazon rely on remote development where your laptop is just a terminal to some remote machine. Not sure about other BigTech but maybe others can comment.

[aklarfeld]

This is awesome - congrats on the launch!!!

[neilxchen]

thanks!!

[jchap]

Congrats Liusha and team!!

[neilxchen]

Thanks!

[emeraldd]

What does this support outside of Javascript?

[neilxchen]

If you are talking about programming languages - it supports Golang, PHP, Java, Ruby and more. Mostly any frontend/backend languages (other than mobile development languages)

You can actually treat the Nimbus workspace as your laptop on cloud. If there's anything you see not supported on Nimbus at the moment, you can create a workspace, install as many packages as you need. And once you want to share the set up with the team, you can snapshot it and create a public (org-wide) template out of it.