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.)

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

> Nimbus is more like local development, we're building for teams that use a wide set of IDEs.

How does that work from the IDE's perspective? VS Code of course loves being a thin-client, and I used Emacs with AWS Cloud9 with SSH tunneling (and since I'm so close to an AWS region, even X forwarding). What about others?

> 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.

I'm not sure what this means in practice. A development environment, regardless of what -first it is, should come with all dependencies required to run the project (app + database + other microservices + local fakes etc.). What does being "machine-first" mean for the end-user experience?

> provide more power (right now up to 8vcpu 32gb ram, but customizable by us).

> Gitpod tops off at 8gb or 12gb of ram

(AFAIK Gitpod's default limit is 8GB but on-prem allows for configuration of this value. Running "free -g" prints 64GB which is wild to me, maybe it's showing me the host server instead of the container?)

Does that mean your target audience is doing data-heaving / processing-heavy development that requires much more powerful machines?

> provide containers instead of VMs

Honest question: As an end-user, how does this affect me? I can stuff _a lot_ into a Docker image. Our largest development environment image right now is at 9GB and can run our whole system end-to-end.

> How does that work from the IDE's perspective?

We have been adding different IDE integrations into our solution so that a user would not even feel they are coding on a remote environment. We support a very smooth VSCode experience now and JetBrains IDE is on the way.

> What does being "machine-first" mean for the end-user experience?

It means you have the full control and flexibility to define how your environment looks like instead of being forced to have one repo per environment. This flexibility enables the exact same experience as the one you have in your laptop from development and env management perspective.

> Does that mean your target audience is doing data-heaving / processing-heavy development that requires much more powerful machines?

Data-heaving / processing-heavy development is definitely a good use case but our target audience is not limited to that. A few examples here:

  1. even though you are running a webapp with micro-services on the backend, the requirement for computing power can increase as the number of services grow. I see some teams are running 20 - 50 micro-services and it is just too much for a laptop.

  2. In some regions, it is not so common that engineers get the high-end macbook pro for their daily work. Some has to work with 8GB ram machines for various reasons.

> As an end-user, how does this affect me?

Theoretically, containers can do everything VMs do but in reality they introduce different complexity. Here are some examples:

  1. If you have two k8s clusters, you can easily run it on a Ubuntu VM and when you run into issues, it is easy for you to find answers support. But running two K8s clusters inside a docker container is much more challenging~ but yes doable.

  2. There are some random issues I run into with containers, like port forwarding (management in general). Again I figured it out but more complex

  3. Easier to integrate with users current configurations. Most users today still code on their laptop directly instead of creating a container and code inside that container. So most settings can be migrated to a VM-based environment directly.

  4. As much as I love containers... still many engineers don't use containers for various reason.

> It means you have the full control and flexibility to define how your environment looks like instead of being forced to have one repo per environment. This flexibility enables the exact same experience as the one you have in your laptop from development and env management perspective.

One thing I love about Gitpod is that everyone gets the same exact environment when they start Gitpod from a repo/PR. It seems like letting every developer customize their cloud machine like they customize their local machine would lead to many of the "but it works on my machine" problems?

haha I want to be clear. I meant you can define your environment however you like in terms of flexibility. You can have 27 different repos with 2 k8s clusters with other integrations you like in an environment.

Nimbus can achieve exactly the same. You can define an environment template and all workspaces your team create from that template will have exactly the same environment.

In short, a team can enforce consistent environment with Nimbus easily.

Got it!

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

Answered in the parent comment! But high level - we aim to be more like local development and flexible.

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.)

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.

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)

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? :-)

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

tricky. unless u can allow my prod environment to be imported into nimbus (or the other way around - export). Otherwise my prod packages and your packages will always be out of sync. And that is too bothersome. The problem is not code merging and branching. But if its a "dev environment", it has to be in sync with my production environment.

Everyone here has been burnt by different version of operating system libraries, so stuff doesnt work properly. Python is notoriously funky about this because most of its libraries are written in C actually.

This is a really great and interesting point.

We'd love to make Nimbus such a flexible platform that engineering teams can configure the Nimbus dev environment as close as possible to production environment. A few opinionated thoughts here:

- it makes sense that dev environment setup follow prod environment setup as much as possible (so that it's reliable to know code in dev environment works on prod environment, for example). However, on the other direction, prod environment should focus on solving its own problems (scalability, stability, etc..), so it might not be a great practice to set up prod environment following the dev environment;

- automatically importing prod environment into Nimbus is definitely a higher level of thinking once engineers can at least manually specify which package should be included in the dev environment (I love this one);

> Otherwise my prod packages and your packages will always be out of sync

From the dev environment perspective, we intend to not enforce everyone to use "our packages" (in fact, our built-in packages should be common ones with least surprises). In the future, we want to have a way so that users can define their own packages on Nimbus.

> Everyone here has been burnt by different version of operating system libraries, so stuff doesnt work properly

Not sure if everyone in your team has consistent dev environment, but just different from the prod environment; or everyone in the team also has inconsistent dev environment, which is also inconsistent with prod environment.

If it's the latter one, that's also a problem we are trying to solve - eventually in a team setup, there should be just one-time set up of the dev environment, and everyone else can just spin up a workspace and write code, without worrying about the version difference etc.

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)

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

with all due respect, ur equivalent plans are far more expensive. because the equivalent on Nimbus is 30 hours per week. But on replit - u can actually host a website. The repl is "always on".

I think we probably have to agree to disagree on wasting energy here. The magic of cloud environments is always on environments where my scratch api is also running for my other developer to ping. Replit is pretty good for this. So is Sagemaker. But I do respect that ur target market is a bit different.

> The magic of cloud environments is always on environments where my scratch api is also running for my other developer to ping.

The magic of cloud environments is efficiency and economies of scale. Scale to 0 services are perhaps some of the most popular in the cloud era; especially for students or side projects which seem to be the inspiration for Nimbus.

I’m not defending any pricing but I think the model is useful.

Yeah - the targets are different. Thats probably why comparing the pricing seems odd too. Even our lowest tier has more dedicated memory (so its more expensive for us too). But don't get me wrong - I think Replit is really cool but just not what we're going for :)

every virtualisation product for 20 years has supported saving the machine state to a file and then restoring it at some point later (maybe years)

I do this a lot on my home machine, with an nvme ssd it's under a second to save or restore the entire machine state

it's a shame the big cloud providers (Azure, GCP, AWS) virtualisation offerings are so... crappy compared to VMware workstation/ESXi/Xen/KVM/... from 20 years ago

Gcp supports it: https://cloud.google.com/compute/docs/instances/suspend-resu...

> "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.

answered on the parent comment - plz let me know if it doesn't answer the question for you

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

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)

> Whats best for developers is having flexibility and choosing the right tool for what their building and their team.

One of the things that's annoyed me about codespaces and gitpods is that they really require/assume the whole team will use that one product. Codespaces does that through their billing and permissions, and gitpods does it via their PR based features etc. Is this something Nimbus is going to try and avoid? What's best for the majority isn't always best for the individual, and that's why we have so many different IDE's. Perhaps my personal workflow is served better by Nimbus and my colleagues is better suited for codespaces.

With some tools, like bug trackers, it makes sense to pick one tool for everyone of course. What do you think about remote dev environments?

I think more people on remote environments does lead to better overall experience. But the incremental benefit for each additional team member drops until everyone is working on the cloud - because then you can do some cool things or stop doing some dull things.

That said, we avoid doing anything that forces an entire team to move to our cloud environments. That's an easy way to piss people off and build a crappy product. Hopefully this approach doesnt burn us.

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.

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).

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.

self-host is definitely on our roadmap. For the first step, at least we want to deploy the EC2s in your own cloud rather than Nimbus's cloud.

I LOVED Codenvy! Kudos.

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

Ha! I maintain a public database and people can navigate it by going to tylerjewell.substack.com. It links into a public google sheet.

The tracking methodology buckets companies by the primary product they advertise. Withcoherence is in a different category that has a broader platform definition.

There are companies like gitlab and Codegiant that also have remote dev envs as features of the broader product line.

Thanks! And appreciate the context here...

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.

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.

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.

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

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?

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!

Hey Neil,

Thanks for explaining! this makes a ton of sense -- the workspace scoped creds I guess would be the only place where they'd be stored (temporarily).

Yes, that's correct!

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.

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!

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)

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.

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 :)

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...

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

Regarding (2), what does it use under the hood? Rsync? Will the files be automatically synced to local on save?

Neil from Nimbus here

Just for a quick clarification - it actually refers to manual file sync on your need at the moment. Syncing files automatically is something the team is discussing right now but may not become available in the product in the near future.

Under the hood, essentially, you can access Nimbus workspace via ssh (with private key/public key pair). With that foundation, if you ever want to download files or upload files, you can do so with scp, rsync, or anything that can transfer files over ssh tunnel.

That also means, technically, you don't have to use VSCode/JetBrain to write code on Nimbus workspace (though we have/are going to have official extension/plugin support, which is recommended). You can directly ssh into the workspace and write code in emacs/vim, or use any editor/IDE with SFTP support.

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-...

Do you mean having a MacOS on a cloud machine?

Yes!

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.

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).

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

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!

Nish from Nimbus here

I was just typing up a response but can't be more succinct than this :)

+1 on "You could run DevSpace on top of Nimbus"

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

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.

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?

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).

Thanks. How does it help the engineer to save time?

For engineers, the most immediate wins here are cutting build/test times with more power, removing new project setup, and reducing environment error rate and troubleshooting.

It also gives more visibility into environments which help SRE like teams resolve issues faster.

What excites me (and many of our users) are the "micro-wins" that save time/let engineers do more. Some of these come from making workflows simpler (e.g. saving time switching context [branches/data/credentials]), improving device performance (e.g. being able to work longer unplugged), and device flexibility.

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.

- 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?

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.

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.

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

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

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

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...

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 :)

Thank you for the support!

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?

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.

Thanks for the detailed explanation. You're right, "consistent" SDLC is what I meant. For compatibility, docker itself is kind of a sort of standard. I say sort of because of OCI. The idea is that if you run your own registry, create your own base images (and include your security team's input) and enforce a policy where you can only pull from your registry than development is forced to use your standard images, your standard environment. We've even gone so far as to then incorporate terraform to standardize the deployments. Having an M1 Mac with 8 cores and 8 gpu feels like overkill if I'm just going to login to a website and code. How do you handle desktop codebases? Electron apps? OpenGL w32 apps? There's still room for an IDE on my mac. I guess my biggest concern with platforms like yours is the fact that big brother can always slip a timeclock in there.

I think you are right :) with a great dev infra and policy setup and proper enforcement, docker can be a great solution of environment consistency/standardization.

One use case I forgot to mention and I want to share. In some scenarios, engineers need to work on more than one project and they have completely different set up, which would be difficult for them to maintain multiple environments on their laptops. Back to our docker example, if project A requires docker desktop 4.1.0 and project B requires 4.7.0 it would difficult for the engineers to manage that. I know this is an extreme example but good enough to make the point. This scenarios happen a lot in consultant business where one engineer need to work for multiple clients at the same time.

In terms of desktop codebases, do you mean native desktop application development? I think that is a tricky one as well for similar reasons as mobile development because you need to run the apps on a specific OS for testing. But if one finds a workaround for testing, then writing code on Nimbus environments should be as good as on your local environments.

About the concern the big brother can always slip a timeclock in there: haha~ as an engineer I feel you. That is never the goal of Nimbus and I would not want my boss to stalk my every single keystroke.

> 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.

Facebook definitely does it. Thats where we first learned about this way of working. Some bigger tech companies have actually written about it (see links below) but a list of ones that we've seen with this kind of infra include LinkedIn, Shopify, Dropbox, Stripe, Slack, DataDog, and Palantir - to name a few.

Eng blog links:

LinkedIn: https://engineering.linkedin.com/blog/2021/building-in-the-c...

Shopify: https://shopify.engineering/modelling-developer-infrastructu...

Slack: https://slack.engineering/development-environments-at-slack/

Doximity: https://technology.doximity.com/articles/github-codespaces-i...

I can say for Meta/Facebook, Shopify, LinkedIn, Microsoft, Doximity...

This is awesome - congrats on the launch!!!

thanks!!

Congrats Liusha and team!!

Thanks!

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.

ok, I couldn't find any info about that on your site in my cursory glance and the only examples I saw looked like node...

Thanks! That's a fair feedback, will take it back to the team and see how we can improve it!