Stay local, let your IDE do remote work for you!

CLion’s issue tracker has dozens of important and interesting feature suggestions to implement. With limited resources, we are always having to prioritize the features we include with the direction we have in mind for the product’s evolution. 3-digit issues with over 800 supportive votes – these are the kinds of requests we can’t leave out! Can you guess the one we’re working on for v2018.3? It is all about remote projects support!

Initial remote projects support – what’s that?

We’ve started with a particular set-up, though we do plan to cover and come to up with more cases in the future. So we are calling the current support state – initial. What exactly was implemented then?

  • Local client machine: Unix-like (macOS, Linux)
  • Remote host: Linux
  • Sources location: originally on the local host, CLion will synchronize to the remote machine for you.
  • Project model: only CMake projects
  • rsync is required to be installed on a remote host

We know there are many other cases for remote development and we are planning to extend our support for it in the future. Just sit tight and stay tuned!

How to configure a remote project in CLion?

It is much easier than you imagine! Just follow these steps.

  1. First of all, go to Settings/Preferences | Build, Execution, Deployment | Toolchains:

    • Create a new toolchain (we call it Remote in our sample)
    • Check the Remote Host option
    • Configure the credentials to access the remote host:
    • Set paths to the CMake executable and debugger on the remote host (it has to be done manually for now, while the default /usr/bin/cmake and /usr/bin/gdb are set for you)

    Now, if the remote host is accessible by ssh with the given address, port, username and password, the toolchain check will finish successfully and the toolchain will be available for use in CLion:

  2. Now you need to connect a CMake profile (the one that currently exists, or a newer one) to the newly added remote toolchain. Do this under Settings/Preferences | Build, Execution, Deployment | CMake:
    Later in this blog post, we’ll see how we can skip this step by simply making the remote toolchain the default one.

After applying these changes, CLion will reload the CMake on this project and you’ll then be ready to start working remotely with your project in CLion:

Remote development – what can I do?

Now you have a remote toolchain configured and a CMake profile that uses it. Using then our Debug-Remote as an example. You can now:

  • run your app
  • debug your app
  • run tests
  • debug tests

All completely remotely from the instance of CLion on your local machine. And it’s really then as easy as just selecting a proper CMake profile in the build type switcher:
remote run ap
The same goes for tests:
remote run tests

We hope to enable Valgrind and Google Sanitizers in the remote mode soon as well.

What’s going on in CLion under the hood?

Let me now briefly explain what CLion actually does when the described ‘remote configuration’ operations are performed. If you are not interested in the inner mechanics, then feel free to simply skip this part.

During the first step the connection entity is created, you can review the settings under Settings/Preferences | Build, Execution, Deployment | Deployment:
Mappings tab settings, the deployment path, in particular, is configured automatically by CLion and has the path to the remote host where CLion synchronizes your project code:
The synchronization process is displayed in the File Transfer tool window (View | Tool Windows | File Transfer):
Apart from synchronizing the local files to the remote host, CLion also grabs header search paths with all the content to the local host, so it can resolve your code correctly. This means that the standard library headers, for example, are taken from your remote machine, but you can navigate to them as you would to the local files with CLion’s editor.

Stay fully remote all the time with ease

To end this introduction into this awesome new feature, we’d like to share with you a very simple way to use CLion in this remote mode for all your projects, existing and new.
Go to Settings/Preferences | Build, Execution, Deployment | Toolchains and make your remote toolchain a default one by simply moving it to the top of the toolchains list:
remote default toolchain

Now, this remote toolchain will be used automatically for all the projects you open in CLion. For example, when you checkout a new project from Git:
open remotely

There are a few known issues already, they are linked to the parent ticket here. For example, a potential performance issue when too many remote toolchains are created.

That’s it! Give this CLion remote development feature a try and let us know what you think!

Download CLion 2018.3 EAP

Your CLion Team

The Drive to Develop

This entry was posted in Announcement, Tips'n'Tricks and tagged , , . Bookmark the permalink.

58 Responses to Stay local, let your IDE do remote work for you!

  1. fenrir says:

    Since I’m apparently too dumb to create a working modern tool chain for the Raspberry Pi and running CLion on it is not an option, this is really great news.

  2. AJ Lewis says:

    Looks like this doesn’t work yet for Windows -> remote linux, which is where I really need it. Is that in the plans?

  3. Mark says:

    This is a great start, but since my project uses Make (CPP-494 which is slightly higher in +1 than this feature) I will need to wait to test this feature out. Still, I am glad to see that JetBrains is at least working on one of the top request features.

      • Mark says:

        Yes, I know about this, but I am hoping for something other than a workaround. So, based upon your comment, do I take it that JetBrains does not plan on implementing CPP-494 and the solution is a workaround?

        • Anastasia Kazakova says:

          We plan to implement native makefiles support in the future, but can’t provide exact estimations here. From the other hand, the workaround should work nicely for many cases.

          • Alexey says:

            From the article I understood the remote debugging will work only for CMake project, implying the makefile workaround above will not support remote debugging. Am I wrong?
            I’ve been successfully using the above makefiles workaround for a couple of months now, but only for development and refactoring of a code running on a remote machines (and manual debug). If it becomes possible now to also debug it from Clion, that would be a game changer in our team.
            If indeed possible, perhaps you could update that article (or add a new one?) on how to achieve that with makefile project? I hope it’s not “convert your project to CMake” :-)

          • Anastasia Kazakova says:

            Currently it works only for CMake, will consider wider functionality a bit later. This is a huge piece of work and we just started from CMake. But we won’t limit it with CMake in general in future.

  4. Alexander says:

    I have failed to select compilation profile in EAP edition. It using default toolchain (some toolchain – I have tried to change default). So, I have no chance to change it.
    Remote Cmake have completed successfully but I didn’t managed to get remote compilation.

    • Anastasia Kazakova says:

      Do you mean that CLion can’t detect remote compilers? Can you please attach a screenshot of the Toolchain settings. Here or create an issue in

      • Alexander says:

        I have located the problem
        1. I have opened project (it was automatically build by default toolcahin)
        2. I have changed toolchain in CMake settings (got new profile Debug-remote)
        3. This profile didn’t appear in configuration selector (first problem!). So I have renamed it to Debug
        4. Because cmake-build-debug already existent CLion try to build it on default toolchain. Removing local cmake-build-debug folder didn’t helps.
        5. now if you go to remote server and remove cmake-build-debug folder from the temporary folder /tmp/tmp.XXXXXXXX and reload cmake project you will be able to build it remotely. :)

  5. Daniel says:

    Supporting toolchains on a remote host is great and good, but what about CLion support for cross compilation toolchains actually running on the same machine? This would be much more trivial to support.

    • Anastasia Kazakova says:

      What you mean under cross-compilation support? Since CLion calls CMake directly for CMake projects and CMake works nicely with cross-compilation toolchains, it should work successfully in CLion. If you mean some particular issue with that, please let us know.

  6. Hu Bo says:

    Does it work for ARM development as well, e.g. Raspberry pi?

    • Vasily Romanikhin says:

      Yes, I’ve just checked it. I installed cmake and compilers on my Paspberry Pi (os: Raspbian). After that configured appropriate remote toolchain, as result CLion can successfully build, run and debug my program on RaspberryPi.

      • Hu Bo says:

        Great! Keep up the good work.

      • Max Hadley says:

        I just tried it, creating a hello world project on my Mac and configuring remote operation as the post describes. A couple of very minor things:
        – The spinning gearwheel for compiler autodetection continues to spin even when you manually enter the executables’ paths. Ignore it.
        – The version of cmake in the Raspbian repos is well behind that installed on the Mac. I had to manually edit CMakeLists.txt (on the Mac) to use version 3.7 instead of 3.12.

        So far so good!

        • Max Hadley says:

          Also, it is necessary to run ‘File>>Reload CMake Project’ after each reboot of the Pi (as I discovered after the power here went out, briefly)

  7. Andrew Smith says:


    I have two questions:

    1. Does remote debugging still require gdbserver (and therefore require transferring potentially huge symbols from the remote host to the local client)?

    2. Will the remote development experience eventually support code analysis on the remote host (auto-complete, find all references, etc), to avoid pegging local CPU/RAM?

    • Vasily Romanikhin says:

      1. If you configure remote-toolchain (as described in this post) remote debugging doesn’t require gdbserver.

      2. Code assistance like navigation, code completion and etc is available in remote mode. The development experience looks like you work locally, but CLion uses remote header search paths and tools like compilers, cmake, make and gdb.

      What about CPU/RAM? If we talking about running cmake and project compilation that processes consume resources of your remote machine. So the compilation can be much faster if your remote host is more powerful than local laptop. Other processes, e.g. building symbols are local.

      • Andrew says:

        1. In that case, is there any server component/process running (if not gdbserver) set up by CLion that allows remote debugging? Does that process require full debug symbols to be transferred from the remote host to the local client?

        2. For me, in local mode, CLion frequently uses many GB of RAM in the background (which slows the computer and also causes frequent garbage collection and associated UI pauses). Similarly, it often uses a lot of CPU. I’m assuming this is related to building symbols and maintaining in-memory indices as code changes. I was hoping that eventually (even if not for this initial release), there would be a server component that would do all of this (just communicating the results to the client on demand), that could take advantage of the much more powerful remote host to do the resource-intensive work.

        I’m not talking about actually compiling the code via clicking build in CLion. (CLion doesn’t support our build system, so I need to build with a different process regardless.) I’m just talking about the work it needs to do in order to support navigation/autocomplete/refactoring/etc.

        • Vasily Romanikhin says:

          1. If your build system is CMake there is no additional component/process set up by CLion which allows remote debugging. We sync sources to remote host, build/compile them using remote cmake and remote compilers and finally run remote GDB and communicate with this remote GDB-process via stdin/stdout. As result we no need to transfer debug symbols.

          Below you mentioned that you use other build system, as result it’s impossible to build/run your program via CLion and, as result, at the moment it impossible to debug in that way.

          2. I see, in the platform there were some discussions about remote indexing (or even headless IDE). But at the moment CLion’s remote-mode works in different way.

  8. Mike says:

    Any plans on supporting WIndows -> Unix ?
    Any plans on support Windows with Cygwin -> Unix ?

  9. Sanhu Li says:

    Can I know how to change the mapping folders? I find if I change the mapping folder under “Deployment”, the files will not sync to the new mapping path. Since not all the time we have enough space in tmp on remote host and it’s much better if we could map the code to some place under home folder

    • Vasily Romanikhin says:

      If you change mapping folder in “Deployment” section, please run “Reload CMake Project” (Tools -> CMake -> Reload CMake project). In this case CLion automatically sync you sources with remote-host using new path-mapping.

  10. Chris Thompson says:

    This seems like a great feature! It will help me maintain my sanity with regards to different keyboard layouts. I ran into a problem, though – I had to change my mapping for the local and remote dir, since I needed some config files one folder up in my tree. When I changed the mapping the file sync worked like a charm. Then I switched git branches and it won’t sync additional files from the new branch. I modified one of the new files locally, and it was sent to the remote machine, but the other files are still only local. “Reload CMake Project” didn’t help. How can I trigger a sync of the full tree?

    • Vasily Romanikhin says:

      > How can I trigger a sync of the full tree?

      1. Because of you need some config files one folder up your project directory, you can “Change Project Root” (Tools -> CMake -> Change Project Root)
      2. In “Deployment” section set appropriate path mapping – one folder up (according to your description you already did that)
      3. Select required folder and upload it to the server by “right click” -> Deployment -> Upload_To -> select server.

      Also I filed the ticket about automatic synchronisation with remote host after VCS branch switching (

  11. Vladimir Bondarevskiy says:

    Is there support for connecting to IPv6 addresses? I could not connect.

  12. Joshua Bambrick says:

    I have a proxy setup in /etc/ssh/ssh_config which uses ProxyCommand to connect to some hosts via a proxy. Whenever, I attempt to connect set up a connection, I repeatedly get “Cannot establish a connection” from CLion.

    It is possible that this is unrelated to my proxy setup, as I get the same message whenever I enter localhost as the host to connect to.

  13. Alexey says:

    It would be nice to take ssh configuration defined in ~/.ssh/config and make them available.
    But unfortunately it doesn’t work… Or am I miss something (about how to config)?

    Say, I have a record there:

    host ubuntu64
    Port 333
    User alexey
    ProxyCommand ssh homerouter -W %h:%p

    That is, from console I simple type ‘ssh ubuntu64’ and have nothing to know about any proxies, ports, different usernames, keys, etc. It ‘just work’.

    How can I just point the name of the section without repeating these boring things like port, username, address, etc, since everything actually necessary is already typed once in ~/.ssh/config? Could it also ‘just work’?

  14. Kirill Martynov says:

    Unfortunately Exclude paths in Deployment tab doesn’t work.
    If I use my vagrant machine and connect using ssh with CLion, it starts uploading .vagrant folder of my project to vagrant machine, and that takes forever, since this folder contains disk images (>50 Gib)

    • Vasily Romanikhin says:

      Seem I could reproduce the problem,

      As temporarily workaround I can suggest the follow:
      1. Create remote toolchain, interrupt automatic project uploading
      2. Add appropriate exclude path
      3. Synchronise project manually ( select project directory
      –> “right click” -> Deployment -> Upload_To -> select server.)
      4. On remote host, in project directory create empty file .clion.source.upload.marker (you can just run touch .clion.source.upload.marker)

  15. David Rees says:

    I’m excited to see CLion is looking at remote development options. But for my company’s use cases we really need a model where a CLion server would run on the remote server and do all indexing there. Bringing all the source over to the client (or doing all the indexing over sshfs) just isn’t an option due to the size of the codebase.
    So we are looking for something similar to the Language Server Protocol model (but with CLion’s richer support).

    • Anastasia Kazakova says:

      The setup you describe is another version of remote, which we have in mind but for the future, no estimations here.

  16. Iurii Pelykh says:


    I found that CLion doesn’t preserve symlinks and file permitions while sync with remote host.
    Is it possible somehow to set appropriate options for rsync?


Leave a Reply

Your email address will not be published. Required fields are marked *