In software development, it is common to use remote and provisioned workers to execute code and run tasks. These workers can be located in remote data centers or cloud environments, and they can be accessed through a local integrated development environment (IDE) that connects to them over the internet. Using remote and provisioned workers can be beneficial because it allows developers to access powerful hardware and infrastructure without having to set it up locally. It can also be useful for teams that are distributed across different locations and need to collaborate on a project. Local IDEs can be used to write, debug, and deploy code to the remote workers, making it easy to work with and manage the codebase from a single interface. In this post, I will talk about setting up Jetbrains’ new IDE, Fleet, to work with a remote Linux machine.

Why use remote workers for development?

There are many reasons why developers (and their employers) will choose to run IDEs on one machine and actual development workload (testing, compilation, code analysis) on another. These are a few main ones:

1. Improved performance: remote server-side workers can often provide better performance compared to local development environments. If you are developing a large project that your laptop struggles to build, you can offload that to a remote server (your PC, or a VPS, for example) and use the laptop computing powers for text editing only.
2. Centralized development environment: by using the same server-side environment, you (and your team) can save time on setting up new envrionments (especially if you use multiple devices for development) and fixing discrepances between them.
3. Simplified provisioning: for teams that manage many developers, using server-side workers can same money and resources. You no longer need to provide the developers with powerful hardware, instead handing out thin clients that connect to the cloud, which can be scaled up and down with a push of a button.
4. Shared resources: a server-side worker can be connected securely to other development environments that you or your team use: databases, message queues, and other services. This will simplify the Ops and make your development workflow much more secure, as development clients need to connect only to one server, instead of many.

I hope these reasons will convince you to try using remote workers for your development processes. Up next, I will guide you through setting up a server/client development environment using Jetbrains Fleet.

---

Why do I use remote workers for development?

After giving a general idea of why it is great to use such a model for development, I would like to share how I personally use it in my day-to-day life. I have a powerful PC at home which is running Windows 10. I like to use WIndows 10 for regular activity, like editing code, taking notes, browsing internet, and playing games. However, I absolutely hate Windows console and PowerShell, and only use Linux to do development work. So, in my setup, I have a Xubuntu VM running without GUI in VirtualBox, and my Jetbrains Fleet running on WIndows connects to that VM. When I go out and use my slow laptop, it also connects to that VM to use that same environment. I found that it works for me really well, and I hope to help you in meeting your development environment expectations.

---

Step 0: set up your machines

Before we begin, lets first make sure you have the prerequisites necessary for setting up a remote worker development envrironment. In this tutorial, I will assume you have one system that is going to be a client, where you perform development work, and other one that acts as a server, running your builds, tests, and code analysis. You can use either Linux, Mac, Windows, or both. Even more, you can use the same machine to run both Fleet and Fleet server. I, myself, run Fleet client on my Windows PC and Fleet server on a Linux VM on that same PC. You can also use WSL (Windows Subsystem for Linux) to run Fleet server on. Just make sure you have network connectivity between the two systems that you will be using and everything should work perfectly.

---

Step 1: set up Fleet server

We will begin by installing Jetbrains Fleet on your server to handle development workload. Start by downloading the binary using these commands:

• Linux x86_64:
  • curl -LSs "https://download.jetbrains.com/product?code=FLL&release.type=preview&release.type=eap&platform=linux_x64" --output fleet && chmod +x fleet
• Linux ARM:
  • curl -LSs "https://download.jetbrains.com/product?code=FLL&release.type=preview&release.type=eap&platform=linux_aarch64" --output fleet && chmod +x fleet
• macOS Intel:
  • curl -LSs "https://download.jetbrains.com/product?code=FLL&release.type=preview&release.type=eap&platform=macos_x64" --output fleet && chmod +x fleet
• macOS ARM:
  • curl -LSs "https://download.jetbrains.com/product?code=FLL&release.type=preview&release.type=eap&platform=macos_aarch64" --output fleet && chmod +x fleet
• Windows x86_64:
  • curl -LSs "https://download.jetbrains.com/product?code=FLL&release.type=preview&release.type=eap&platform=windows_x64" --output fleet.exe

Note that these links are updated on December 2022, and may become outdated. You can grab new ones from here.

After you have downloaded the binary file, you can move it to your convenient location for binaries (mine is ~/bin) and add to PATH. Then, to start Jetbains Fleet server for remote development, run these commands:

• Linux/Mac
  • fleet launch workspace -- --auth=accept-everyone --enableSmartMode
• Windows
  • fleet launch workspace -- --auth=accept-everyone --enableSmartMode

After running this command, you should see output similar to this (mine is running on Linux):

Workspace version automatically resolved to latest released version '1.12.110', workspace options passed after `--` must be valid for this version.

BOOTSTRAP: 528ms [own=321ms, jvm=207ms]
Configure console log with class ch.qos.logback.classic.AsyncAppender
Configure file log with class ch.qos.logback.classic.AsyncAppender (/home/mk/.cache/JetBrains/Fleet/log/fleet.log)
Loaded logback configuration from:
        file:///home/mk/.fleet/log.conf.toml
        jar:file:///home/mk/.cache/JetBrains/Fleet/artifacts/1.12.110/workspace/./fleet.util.logging.api.jar!/log.conf.toml
Applying new dynamic config FleetLogConfiguration(refreshTimeout=30, default=WARN, perTarget={}, loggers=[Entry(loggerName=fleet, default=DEBUG, perTarget={CONSOLE=WARN, FILE=INFO}), Entry(loggerName=noria, default=DEBUG, perTarget={CONSOLE=WARN, FILE=INFO})])
Dock HTTP Api: 127.0.0.1:38925
Start listening to 127.0.0.1:46635
*** Starting Workspace Server ***
- listening to 127.0.0.1:0
- UID: 
- Supported authorization methods: {"type":"AcceptsEveryone"}
- Smart Mode: enabled
- with FSD
- Host ID: will be resolved or generated
- Published to Jetbrains relay: true
- Lobby address: LobbyAddress(host=lobby.fleet.api.jetbrains.com, isSecure=true, port=443)
- Version: 1.12.110
- Join this workspace using URL:

You can see that we have specified the server to listen on port 4000, which you can change in the command. To make life simpler, you can create a script that will run Fleet with these arguments for you.

---

Step 2: install Fleet client

Once we have our server part done, it is time to install the Fleet editor on your client. You can do it on any platform by firstly downloading Jetbrains Toolbox from here:

Once you have it installed, you can log in to your Jetbrains account and install Fleet:

Once you have it installed, verify that you can run it correctly. On first launch, you should see this window:

Now you are ready for the next step!

---

Step 3: link Fleet client and server

Now you can connect to your workspace using the link that you got in Step 1. It should look like this:

Join this workspace using URL: https://fleet.jetbrains.com/?version=1.12.110&workspaceId=1234&session=1234

Open it in your browser on the system where the client is installed and you will see this page:

If nothing happens, try pressing the blue button. After a few seconds, Fleet window opens and you are finally connected!

You can tell you are connected to a remote workspace by the green dot at the top of the screen. Now you have access to your terminal (on the remote machine), files, and language analysis. Try cloning a repo using the terminal, or opening one using the file menu. I played around with the forked Redux repo, and both browsing and building feels much faster!

---

Conclusion

Jetbrains Fleet is still in very early stages of development, and a lot of features, including this one, feel tacky and unpolished. As of late 2022, you cannot connect to a workplace directly via the local network, or secure it with authentication. For production use, I would advise against this feature, and use SSH/WSL integration instead. However, it is very interesting to follow along Fleet’s development process and I am very exited for the day we will be able to use Fleet Workspaces’ full potential, as this will be something that VS Code does not come even close to.