A development environment is an essential day-to-day system, but it can quickly become complex to manage. In this three-part blog post, we will explore how to become more comfortable and productive with it!
Endless meetings, slightly differing Docker environments on each machine, and untimely system updates: maintaining a reliable and consistent development workstation can quickly become a daily struggle.
With each new project, you have to reinstall the same tools, the same CLIs, and reconfigure the same SDKs or frameworks. And above all, hope that the local machine can handle the load when tests, the linter, and the database are all running simultaneously. Meanwhile, with remote work or working while travelling, individuals find themselves developing with a temperamental VPN, from a laptop that is sometimes close to obsolescence.
In this series of articles, we aim to transform this reality by building on a complete development environment hosted in the cloud and accessible from any browser via VS Code Server.
The idea is to have a remote, powerful, and, if necessary, reproducible and independent “workstation”.
This first chapter demonstrates how to easily deploy a Public Cloud instance manually and install VS Code Server on it. The following chapters will improve its security and automation.
1.
Deploying the instance
For the initial tests it may be wise to opt for a smaller, Discovery-type instance so that you can familiarise yourself with the environment and test it. A d2-2 instance will be used here. 1 vCPU and 2 GB of RAM should be enough.
2. Installing the application element
The fountain of knowledge for the following steps is the GitHub for the vscode-server project:
| col0 |
|---|
| ubuntu@vscode-server:~$ sudo apt update && sudo apt upgrade ubuntu@vscode-server:~$ curl -fsSL https://code-server.dev/install.sh | sh |
This step is enough to install the essentials. Activate the service now and check that it is running correctly.
| col0 |
|---|
| ubuntu@vscode-server:~$ sudo systemctl enable --now code-server@$USER ubuntu@vscode-server:~$ sudo systemctl status code-server@$USER ● code-server@ubuntu.service - code-server Loaded: loaded (/usr/lib/systemd/system/code-server@.service; enabled; preset: enabled) Active: active (running) since Wed 2025-12-03 14:55:37 UTC; 15min ago Invocation: 1b393d84bebe415cbb770a17a0c8d399 Main PID: 893 (node) Tasks: 22 (limit: 4532) Memory: 95.1M (peak: 112.1M) CPU: 1.868s CGroup: /system.slice/system-code\x2dserver.slice/code-server@ubuntu.service ├─ 893 /usr/lib/code-server/lib/node /usr/lib/code-server └─1130 /usr/lib/code-server/lib/node /usr/lib/code-server/out/node/entry |
3.
Validate the configuration
| col0 |
|---|
| ubuntu@vscode-server:~$ mkdir workspace ubuntu@vscode-server:~$ cat ~/.config/code-server/config.yaml bind-addr: 127.0.0.1:8080 auth: password password: cert: false |
You need to set a secure password here and verify that the bind-addr corresponds to your desired configuration.
If you wish to directly test the service in its current state, use 0.0.0.0:8080. Then restart the service and access the interface via http://:8080
.After providing the password found in the config.yaml
in the authentication window, you will gain direct access to VS Code in the browser.
From this deployment, you can then partially address the issue of getting a stable development environment.At this stage, it is possible to directly clone your GitHub repositories or to use the workspace
folder to clone them.
This is recommended for greater longevity, as you will see in the second chapter.
| col0 |
|---|
| ubuntu@vscode-server:~$ git config user.email "mail@foo.bar" ubuntu@vscode-server:~$ git config --global user.name "John Doe" |
From this step onwards, you can use the remote development environment with vscode-server, while enjoying nearly all the features you might have locally, but with the advantages of having an environment dedicated to this use.
⚠️ Reminder: in its current state, the deployment made here is not “production ready”!
The aim of this first chapter is to introduce the service, with the instructions here to help you familiarise yourself with the environment. Therefore, please ensure that you do not operate the service as deployed here for more than a few hours!
The environment will need to be secured, as it is directly exposed on the Internet. This is the subject of the following chapters.
By now, you have an operational development environment that is already capable of supporting a real application project!
The instance is online, VS Code Server is responding in the browser, the workspace is ready, and the first repository has been cloned and opened as if on a local machine. This foundation demonstrates that it is possible to abstract from the hardware to gain portability and more easily share a common configuration within a team or a remote development workstation.
In the upcoming chapters, this minimum viable environment will be gradually enhanced with persistent storage, backup mechanisms, and secure access via HTTPS. It will then be fully automated through Infrastructure as Code, in order to transition from a simple technical test to a genuine development platform ready for internal production.