General FAQsWhat is Nimbus?What IDE do you support?What tech stacks does Nimbus support?How do I move my dev environment into Nimbus?How do I update my Nimbus dev environment template?How do I access my repo in Nimbus?Pricing FAQsHow are storage fees calculated?How are usage fees calculated?Technical FAQsCan I use my own cloud provider?Do I have root access to the Nimbus server? Why can’t I access my webapp from my browser with the host URL?How should I install new packages/tools after I connect to Nimbus Server?How to set ‘root user’ as default?How can I forward port if I’m not using VSCode?How can I resolve the VSCode SSH connection timeout?
General FAQs
What is Nimbus?
Nimbus is an easy way to code and manage environments on cloud VMs that are configured for projects you’re working on. There are 3 important concepts in Nimbus:
Templates: These are the images that are used to set up the cloud VM devs work on.
Workspaces: These are the cloud VMs devs work on. Each workspace is an independent (i.e. unshared) instance. Workspaces are disposable but persistent - meaning devs can keep them around until they aren’t needed anymore.
Snapshots: These are images that reflect the state of a ‘Workspace’ at a specific point in time. Snapshots can be used to create ‘Workspaces’ or ‘Templates’
What IDE do you support?
Nimbus works with any IDE that supports remote development.
We have an extension into local VSCode that provides a fully integrated experience available here. And provide documentation to support use from any Jetbrains Gateway supported IDE (e.g. IntelliJ, PyCharm, GoLand, etc.): 
Setup on JetBrains
Setup on JetBrains If you are looking to use Nimbus on another IDE, please reach out to hello@usenimbus.com and we’ll be happy to help.
What tech stacks does Nimbus support?
Nimbus supports nearly all backend and frontend development tech stacks. We have official “quick install” packages to support some popular languages and tools (e.g. Node, Golang, PHP, Python, Kubernetes, Minikube, MySQL, etc.) but are not limited to these languages and tools.
How do I move my dev environment into Nimbus?
Nimbus works just like a computer. Setting up an environment for the first time will be a familiar process. To set up an environment for yourself or a team for the first time:
- Create a ‘Template’ and a ‘Workspace’ in the webapp.
- During this process, you will configure the OS, machine specs, etc.
- Launch the workspace and configure the machine as necessary (e.g. install the necessary packages and tools).
- Test the configuration to ensure the setup has been done correctly.
- Return to the webapp and ‘Snapshot’ the workspace.
- Convert the ‘Snapshot’ into a ‘Template’.
Now, any workspace built off of this ‘Template’ will have the same image as the workspace that was ‘Snapshot’. If the workspace configuration drifts, a developer can easily refresh their workspace with the ‘Template’ configuration.
How do I update my Nimbus dev environment template?
To update your ‘Template’, simply create a workspace and make the necessary changes before taking a ‘Snapshot’ and converting the ‘Snapshot’ to a ‘Template’.
How do I access my repo in Nimbus?
There are multiple ways to bring your repo into Nimbus:
- Github Integration. You can sync your Github account to Nimbus in the Nimbus webapp (see the Account page). When synced, you can select which repo(s) are pulled into every workspace created from the template.
- Git clone. Use the
git clonecommand to clone from a specific repo or directory
- Github CLI. The default image provided includes the Github CLI. You can clone a repo using
gh repo clone <repository>
- GitLab and BitBucket integrations are in progress
Pricing FAQs
How are storage fees calculated?
Storage fees are calculated based on the average GB reserved for storage in a month.
- Reserved storage is different from used storage. Storage is reserved based on the storage made available at the template, workspace, or snapshot level.
- For example: Workspace A has 100 GB of storage and utilizes 20 GB. This workspace will be charged for 100 GB of storage because all 100 GB (including the unused 80 GB) are reserved in that workspace.
- Average GB reserved is used to reflect the variability in storage reserved at a user and team level. This means 1 GB for 30 days and 30 GB for 1 day will incur the same costs.
- Each and every workspace and snapshot will incur storage fees. A team of 10 engineers with one 10 GB workspace will incur fees for 100 GB of storage (10 GB x 10 engineers).
How are usage fees calculated?
Usage fees are calculated based on workspace activity. Workspaces are considered active when:
- Scheduled for activity. Developers can determine what hours a workspace is active.
- Active via an SSH connection. When developers connect to a workspace (through an IDE or the webapp), the workspace is started and activity begins. The workspace will continue to be active for as long as the SSH connection remains.
- Active during the inactivity timeout period. When an SSH connection is terminated, workspaces are kept active for a configured amount of time. This is done to enable quick reconnections to the workspace.
Usage fees include all fees associated with other tooling (e.g. load balancers, global accelerators, workspace and template management, data transfer, etc.)
Technical FAQs
Can I use my own cloud provider?
Not yet. We are actively working on enabling teams to launch templates and workspaces from their own cloud accounts (with AWS arriving in Q3 or Q4 2022).
Do I have root access to the Nimbus server?
Yes. It is your personal computer. You can run commands with root access. For example:
javascriptsudo apt-get -y install zip
Why can’t I access my webapp from my browser with the host URL?
There could be multiple reasons but the most common ones are:
- The app is not running on the Nimbus server
- The URL you input does not include the correct port number
- The port you try to access is not public. (You can see this DOC about how to open a port to the public)
How should I install new packages/tools after I connect to Nimbus Server?
You can treat the Nimbus server as your personal laptop and it indeed functions exactly the same. The default server is Ubuntu. So you can use `apt` or `apt-get` to install packages. For example, you can install docker like this:
javascript- sudo apt-get update - sudo apt-get -y install apt-transport-https ca-certificates curl software-properties-common - curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo apt-key add - - sudo add-apt-repository "deb [arch=$(dpkg --print-architecture)] https://download.docker.com/linux/ubuntu $(lsb_release -cs) stable" - sudo apt-get update - apt-cache policy docker-ce - sudo apt-get -y install docker-ce - sudo docker -v - sudo groupadd docker - sudo apt-get -y install python3-pip - sudo pip3 install docker-compose
How to set ‘root user’ as default?
By default, when you connect to the Nimbus workspace from VSCode, you log in as `nimbus-user`. However, some of you may want to log in as root because of your own use cases. So in this section, I will explain how to log in as a root user by default and some other underline implementation details you may want to be aware of.
There are two major steps to this:
Update ssh config:
We generate a new entry in your ssh config file like the following when you ssh into the Nimbus workspace for the first time.
javascriptHost cacko.we.usenimbus.com HostName cacko.we.usenimbus.com User nimbus-user IdentityFile "/Users/user/Library/Application Support/Code/User/globalStorage/usenimbus.nimbus/ssh/nimbus_61c874cbc5a098006b0214cf_id_rsa"
In the example above, the default `User` is `nimbus-user`. This is based on the third line in the config file.
To set the ‘User’ to ‘root’, you can simply replace “nimbus-user” with “root”. See example below.
javascriptHost cacko.we.usenimbus.com HostName cacko.we.usenimbus.com User root IdentityFile "/Users/user/Library/Application Support/Code/User/globalStorage/usenimbus.nimbus/ssh/nimbus_61c874cbc5a098006b0214cf_id_rsa"
Update Nimbus workspace home directory:
Behind the scenes, Nimbus attaches two different EBS volumes to a single EC2 instance. One is for the home directory
/home/nimbus-user and the other is for /workspace/nimbus where we expect the user to put the source code and repos. This design is intended to enable backup and snapshot of two different directories separately.To update the home directory, you will need to mount the EBS volume related to `/home/nimbus-user/` directory to `/root/`. You can do that through the following steps:
- Ssh into your Nimbus workspace
- Show all EBS volume info by running the following command
javascript➜ nimbus lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 25M 1 loop /snap/amazon-ssm-agent/4046 loop1 7:1 0 26.7M 1 loop /snap/amazon-ssm-agent/5163 loop2 7:2 0 67.2M 1 loop /snap/lxd/21835 loop3 7:3 0 61.9M 1 loop /snap/core20/1328 loop4 7:4 0 55.5M 1 loop /snap/core18/2284 loop5 7:5 0 43.6M 1 loop /snap/snapd/15177 loop6 7:6 0 61.9M 1 loop /snap/core20/1405 loop7 7:7 0 55.5M 1 loop /snap/core18/2344 loop8 7:8 0 67.8M 1 loop /snap/lxd/22753 loop9 7:9 0 43.6M 1 loop /snap/snapd/14978 nvme1n1 259:0 0 20G 0 disk /home/nimbus-user nvme0n1 259:1 0 30G 0 disk └─nvme0n1p1 259:3 0 30G 0 part / nvme2n1 259:2 0 20G 0 disk /workspace/nimbus
- Identify the device name of the home directory. In this case, it is nvme1n1. Also, you can see the `mountpoint` for that device is `/home/nimbus-user`
- Mount the device to the new location by running the following command:
javascriptsudo mount -o nouuid /dev/nvme1n1 /root/
- Confirm the new mountpoint by running the following command in a new terminal window.
javascript➜ ~ lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT loop0 7:0 0 25M 1 loop /snap/amazon-ssm-agent/4046 loop1 7:1 0 26.7M 1 loop /snap/amazon-ssm-agent/5163 loop2 7:2 0 67.2M 1 loop /snap/lxd/21835 loop3 7:3 0 61.9M 1 loop /snap/core20/1328 loop4 7:4 0 55.5M 1 loop /snap/core18/2284 loop5 7:5 0 43.6M 1 loop /snap/snapd/15177 loop6 7:6 0 61.9M 1 loop /snap/core20/1405 loop7 7:7 0 55.5M 1 loop /snap/core18/2344 loop8 7:8 0 67.8M 1 loop /snap/lxd/22753 loop9 7:9 0 43.6M 1 loop /snap/snapd/14978 nvme1n1 259:0 0 20G 0 disk /root nvme0n1 259:1 0 30G 0 disk └─nvme0n1p1 259:3 0 30G 0 part / nvme2n1 259:2 0 20G 0 disk /workspace/nimbus
- [Optional] Change the ownership/permission of the directories under the home since some of the directories were originally owned by `nimbus-user`
How can I forward port if I’m not using VSCode?
If you are a VSCode user, the VSCode server automatically forwards the port from the Nimbus workspace to your local laptop when it detects a program is running on a given port.
If you are not a VSCode user, you can do so easily by running the following command on your laptop:
javascriptssh -L localhost:[local_port]:[nimbus_workspace_host]:[remote_port] nimbus-user@[nimbus_workspace_host]`
For example, if I am running a program on port 8090 on my Nimbus workspace with the hostname as “boabn.dev.usenimbus.com”, I can forward the port with:
javascriptssh -L localhost:8090:boabn.dev.usenimbus.com:8090 nimbus-user@boabn.dev.usenimbus.com
You can also find more details from:
www.osradar.com
https://www.osradar.com/how-to-enable-local-port-forwarding-using-ubuntu-20-04-and-ssh/
How can I resolve the VSCode SSH connection timeout?
We are aware that sometimes VSCode throws an `ssh timeout` error while connecting to a Nimbus workspace, even when the workspace is healthy and the internet is connected. In some rare scenarios, it may take more than 15 seconds for an ssh connection to be established with Nimbus workspaces. However, the default ssh connection timeout is 15 seconds on VSCode.
So if you run into this issue, we recommend you run the following command from your terminal first to make sure you can actually connect without VSCode
javascriptssh nimbus-user@[nimbus_workspace_hostname] # for example: ssh nimbus-user@boabn.dev.usenimbus.com
If you can connect via your terminal, then it is likely the VSCode timeout is the issue and it can be mitigated by updating the default ssh connection timeout as the following.
Steps:
- go VSCode
- open settings (in the search bar type
timeout) => User => Remote - SSH
- change the default setting to 60 seconds.
- You can refer to the screenshot for an example.