Desktop Native AWS Cloud9 Environment

Today I wanted to write about a recent change I made in my development stack. I’ve been spending more time hacking recently, and when it’d all started up again, I noticed myself feeling a little bored of my common IDE / local stack, so I decided to venture down a completely different path. For many years I was a vim zealot, any remarks about your love for emacs can be withheld. I had everything configured just how I like it, plugins for golang, ruby, command-t, auto formatting code, and the like. Now that we’re in 2018 there are so many great choices.

So background behind us, it’s 2018 what does that mean. As I started looking into what was available, I noticed a lot of people using VS Code and really liking it. Also we still have the heavy vim users and atom users, all great tools. I wanted something more portable, and something that I could maybe start to think of as Desktop-less, I mean come on, we’re in 2018. Internet is basically prevalent everywhere we go; on planes, on boats, available via 3G, 4G the impending 5G, so with all that in mind I started to think about “The Cloud”. Enter AWS Cloud9.

AWS Cloud9 is just an IDE in the browser, but taking that one step farther it’s an IDE backed by an Amazon EC2 instance. Having EC2 backing it means it has the full gamut of EC2 available to it, if I want a massive m4.10xlarge with 160 Gib RAM + 40 vCPUs I can have that, if I want a 2TB SS, I can have that. imagine how fast your apps would compile with that or if I don’t need the env for a couple days it will auto shut it’s self down and will save its spot and restart whenever… and where ever I am. Sounds fantastic, right? I think it is!

But that leads me to my next issue, I don’t want to code in the browser, this might just be me, but I personally love the separation between your IDE and console and the browser that I’m using for documentation or testing. So I started contemplating my options and realized, I could use the same mechanism I use to make my AWS Chime instance feel local while using the Web version, Nativefier.

Nativefier is a tool that behind the scenes uses an Electron App to wrap a URL into what looks and feels like a local app. So how does this work and how can I do it, I know you’re dying to know.



First, you’re going to need to configure your own AWS Cloud9 environment; this blog is going to assume you have already done this and start purely from the nativefier space.

Next, we’re going to need to install Nativefier Simple and easy to do using npm.

npm install nativefier -g

Once you have installed the CLI, let’s make sure we have it in our path. Check this by running nativefier --help this should return you all the documentation about `nativefier.

Now let’s discuss some settings, to get started we’re going to need the URL for our Cloud9 instance. For this example, we’ll use

If we check out the --help command again we’ll see all the options we can pass into `nativefier to help make the App feel more “native.”

Before we get to the nativefier command if you’d like to use the AWS Cloud9 icon I use you can download that from here.

Here are my typical settings:

nativefier --single-instance \
           --icon=./AWSCloud9.icns \
           --internal-urls "" \
           --name="AWS Cloud9" \
           --disable-dev-tools \
           --counter \
           --hide-window-frame \
           --file-download-options '{"saveAs":true}' \

As you can see by the above options you can really customize the UX, there is even and --inject command which I use for other apps to automatically load additional JS files. But to walk through these options.

Flag Value Description
single-instance bool allow only a single instance of the application
i, icon ./icon.png the icon file to use as the icon for the app (should be a .png)
internal-urls ”” regular expression of URLs to consider “internal”; all other URLs will be opened in an external browser.,(default: URLs on same second-level domain as app)
name AWS Cloud9 app name
disable-dev-tools bool disable developer tools
counter bool if the target app should use a persistent counter badge in the dock (macOS only), defaults to false
hide-window-frame bool disable window frame and controls
file-download-options '{"saveAs":true}' a JSON string of key/value pairs to be set as file download options.,See for available options.

With all these set it makes it incredibly simple to start using AWS Cloud9 as a local IDE, any time you drag and drop a file into the environment it will automatically upload it, if you drag something to your Desktop it will trigger a Save As dialog, if you try to open up another IDE session it will load your current application, all the Window treatments are hidden from view, so you’re left with an IDE and Terminal instance backed by an Amazon EC2 instance and accessible from anywhere. Think about the possibilities!

What’s Next

I have a dream; I hope we get there one day. I want my whole environment completely separated from the local environment; maybe we have a local cache for those off times where internet isn’t directly available, like the way Notion works. Truly portable, to the point where I could log into AWS Cloud9 on one of those new 2018 12.9” iPad Pro’s and I could develop everything from there, then when I was at my Desktop I could load up the same env in my local like app and continue, this would be perfection in my eyes.

Thanks for reading, if you’d like more about my AWS Cloud9 Environment send me a Tweet and I’ll write some more. @christopherhein

comments powered by Disqus