Deploying code-server development environments in the cloud ☁️

Overview

Ben demonstrates how quickly you can deploy code-server on Railway using our guide to deploying on Railway.

Be sure to check out our full list of guides, which also includes guides to deploying on AWS, Digital Ocean, Vultr, Linode, Heroku, and Azure App Service.

Introduction to code-server

Hey everyone. This is Ben with Coder and today we're going to be taking a look at a really fast way to get started with code-server which is highlighted in my new project deploy-code-server. This is open source and it's on GitHub, and I'll be sure to have it linked below.

For those who aren't familiar with code-server, it allows you to code in VS Code on the web browser. Normally maybe you have VS Code on your Mac or Windows or Linux machine. In this case you can connect to VS Code right through the web browser, and this project is open source. So I'm showing a demo of it here in my my guide for deploying to Linode, but I just kind of wanted to show you what it looks like before I go ahead and deploy. We'll notice that this is VS Code and it's in my Chrome browser. And I'm actually able to do normal VS Code things. So I'm changing the theme and I can interact with different things.

We'll notice that those who are familiar with code-server, it actually created a secure connection for us and in this case it uses your GitHub account to authenticate so you don't have to worry about other people getting access to your code-server or your files.

The advantage of deploying onto a container

This was a guide for Linode. I have guides for a lot of other cloud providers and I'm working with the community to get even more. If you're seeing this probably in a few days from now you'll see AWS on here as well as probably some other ones as well. I've also written a little guide or how-to on the differences between a VM and a container and kind of the benefits and drawbacks of both.

In this case I'm going to be deploying code-server on Railway because it's really fast and so I can talk a little bit about the container flow.

The main difference with the container flow is all of your dependencies--so like maybe Node.js, maybe global packages you'd be using, maybe python--you would modify the container and then you would redeploy it out so every time the container redeploys you would get a new copy. You get a fresh start of your dev environment.

Demo of deploying code-server on Railway

And I'm going to go ahead and show that. So I'm going to go ahead and go to the Railway guide. Again we'll see a screenshot of VS Code in the web browser in this case on a Railway domain. The deployment's actually really easy. You just click this button. I'm gonna go ahead and open it in a new tab. If you don't have an account it might ask you to auth with GitHub. I have an account. It's actually asking to create a new repo on your GitHub account. The reason it's doing that kind of goes back to what I said earlier which is if you need to install new dev tools on this environment you would actually modify the Git repository--I mean you'd push to it and and then your dev environment would update so that's again great if you want like a consistent starting point for your dev environment.

So I'm gonna for this example I'm gonna create a Node project. So I'm going to name this dode-dev-environment, but you can name this whatever you want. I'm just going to make it private because I think that's probably a normal thing for a private dev environment. I'm not going to have anything secret on there but nonetheless. I'm also going to set a password so I'm just going to do one 12345 for this demo. It's asking for a Git repo. So I'm gonna go ahead and copy this example repo, which is for our docs, and that will just make it so it'll automatically open this Git repository in VS Code

Now I can go ahead and just click deploy. You might have seen some other options there as well it's possible that since this video has been recorded we've added a few new options.

The deployment's pretty quick. It's only 30 seconds or so. There you go it was even quicker than that.

So I can go ahead and click this link now and get into my code-server. So I can type 12345 which was that password I had set earlier and there we go. Now I have VS Code from the web browser and I can access this url from anywhere. I can access from my iPad; I can use a Chromebook; or I can just use my machine here. We also have a nice little progressive web app that you can use. Let me go ahead and bring this into the window and move this out. This kind of makes it feel a little bit more like traditional VS Code. It's just up to preference really.

Installing dependencies using the Dockerfile

What I wanted to show you though was you can also just get a terminal like you would in VS Code. If I was to type Node for example, it wouldn't work. The reason this doesn't work is because we don't have Node.js installed on this dev environment.

The way you might want to do it is maybe you'd want to do a sudo because this is a linux environment you can do sudo apt install Node but with the container workflow we don't want to do that.

We actually want to define that in our Dockerfile so that every time this environment is built it will have Node because containers rebuild quite frequently. So I'm going to go ahead and exit out of this. Back in Railway, I can actually go to the trigger section and it will say it's connected to this repo and it's building from the main branch. So I'm gonna go ahead and click into this repo. We'll notice this is the new repository that it said it created for me and it's private. And I actually want to edit this Dockerfile here to be able to to add Node into my environment. For those who aren't familiar with Docker, I'll be sure to link a tutorial on how to write Docker files and how to build Docker containers.

We'll notice here I have some examples of different software that you can add to the environment, such as maybe installing ABS code extension, maybe installing some tools, or just maybe copying files. But in this case I want to install Node. Already oh I did have that copied, but I can actually go back to to the tutorial. And I actually have an example of installing Node, so I'm just going to be following that. Now I just want to commit this. So I can give it a commit message. I can put added Node and I can commit the changes.

New deployments

Something really nice about Railway now is if we go back into Railway and go into deployments we'll notice that it just created a new deployment and that was fairly quick and that's because I've done this demo a few times. It might take a little bit longer for you but and it is attached to the commit message added Node so if I go ahead and click into this new environment and open up a terminal I can type Node and we'll notice that now I'm in Node version 15 which was what I installed on the -- let me give it a refresh -- Dockerfile. There we go. This is how you would kind of configure your different settings and options for your dev environment.

Something else that's important to mention is while I have this project cloned anything that I do not commit up to Git will get reset when the environment is rebuilt in Railway. So I want to be sure to be able to use Git to be able to push things up and things like that but if you don't want to use Git or maybe you have some other files that aren't version controlled that you still want to to sync up we have a solution for that as well.

Syncing files using Rclone

Going back to the Railway tutorial, we'll see in step five there's an optional step to configure Rclone. This will allow you to sync files from your code environment up to a storage service, maybe such as Google Drive or an Amazon S3 bucket or a Dropbox. There's a few different options. And I have a demo for that, just so that you guys can kind of see how that works. It does take a little bit longer to set up, so I figured I just have one ready.

This is my with Google Drive example. Let me go into the deployment. This is the same kind of normal Dockerfile. I also have the docs as the the thing and you'll notice that I have some files here that have not been committed. The reason that we're able to do this is because we're actually syncing our files up to Google Drive as well. In my Google Drive I created a folder called code-server-files, and all of my files are being pushed and pulled up here. As a demo I'm going to go ahead and create a new file. I'll name it google-drive-sync.txt. We'll just put "hi". We'll save it. We'll notice down here we have--I can make my screen a little bit bigger I think it was but it it reset--I have a push and a pull option. This is kind of just like it except instead of it pushing to a Git repo it's pushing to the remote of Rclone, and in this case it's Google Drive.

Like I said, it can be a few different things. If I hit push it will run an automated task in VS Code that runs a script that it has on this workspace that is going to push all the different files I have up to Google Drive. It looks like it's doing a few new things. Now it's done. If I go over over to the code-server files we'll see that we have the new google-drive-sync.txt and it has "hi". What that means is when this environment is rebuilt so maybe I need to add Node maybe it just naturally rebuilds because it's a container and the storage isn't meant to persist and stuff like that, it will be taking the files from Google Drive making sure that everything's synced up. If I was to do a pull for example, maybe I would delete this file, go ahead and remove.

I can do a pull and the Google Drive sync was deleted because Google Drive doesn't have that file. That's how you'd be able to kind of sync up this container-based deployment. But it's really nice. There's a few reasons why you might want to do this. Maybe if you have a very simple project or a project that has a specific amount of dependencies you just want the same starting slate every single time; you want the latest copy of the Git repo; you want all your tools and nothing else. And I think that's a pretty cool use case.

Wrapping up

So I'd really be curious to hear what you think with the VM option you don't have to to define things in a Dockerfile. You just basically run this launch code-server script on a VM, and I have instructions on how to do that with different providers. Then you just install things normally as you would on your local machine.