Coder powers secure, scalable development across key industries — automotive, finance, government, and technology — enabling faster builds, tighter compliance, and seamless AI adoption in enterprise-grade cloud environments.
This article will walk you through exposing code-server securely once you've
completed the installation process.
Expose code-server
Never expose code-server directly to the internet without some form of
authentication and encryption, otherwise someone can take over your machine via
the terminal.
By default, code-server uses password authentication. As such, you must copy the
password from code-server's config file to log in. To avoid exposing itself
unnecessarily, code-server listens on localhost; this practice is fine for
testing, but it doesn't work if you want to access code-server from a different
machine.
Rate limits: code-server rate limits password authentication attempts to
two per minute and twelve per hour.
There are several approaches to operating and exposing code-server securely:
Port forwarding via SSH
Using Let's Encrypt with Caddy
Using Let's Encrypt with NGINX
Using a self-signed certificate
Port forwarding via SSH
We highly recommend using port forwarding via
SSH to access
code-server. If you have an SSH server on your remote machine, this approach
doesn't required additional setup.
The downside to SSH forwarding, however, is that you can't access code-server
when using machines without SSH clients (such as iPads). If this applies to you,
we recommend using another method, such as Let's Encrypt instead.
To work properly, your environment should have WebSockets enabled, which
code-server uses to communicate between the browser and server.
SSH into your instance and edit the code-server config file to disable
password authentication:
# Replaces "auth: password" with "auth: none" in the code-server config.
sed -i.bak 's/auth: password/auth: none/' ~/.config/code-server/config.yaml
Restart code-server:
sudo systemctl restart code-server@$USER
Forward local port 8080 to 127.0.0.1:8080 on the remote instance by running the following command on your local machine:
At this point, you can access code-server by pointing your web browser to http://127.0.0.1:8080.
If you'd like to make the port forwarding via SSH persistent, we recommend
using mutagen
to do so. Once you've installed mutagen, you can port forward as follows:
# This is the same as the above SSH command, but it runs in the background
# continuously. Be sure to add `mutagen daemon start` to your ~/.bashrc to
# start the mutagen daemon when you open a shell.
mutagen forward create --name=code-server tcp:127.0.0.1:8080 < instance-ip > :tcp:127.0.0.1:8080
Optional, but highly recommended: add the following to ~/.ssh/config so
that you can detect bricked SSH connections:
You can forward your
SSH and
GPG agent to the instance to
securely access GitHub and sign commits without having to copy your keys.
Using Let's Encrypt with Caddy
Using Let's Encrypt is an option if you want to
access code-server on an iPad or do not want to use SSH port forwarding.
This option requires that the remote machine be exposed to the internet. Make sure that your instance allows HTTP/HTTP traffic.
You'll need a domain name (if you don't have one, you can purchase one from
Google Domains or the domain service of your
choice)). Once you have a domain name, add an A record to your domain that contains your
instance's IP address.
Replace /etc/caddy/Caddyfile using sudo so that the file looks like this:
mydomain.com
reverse_proxy 127.0.0.1:8080
If you want to serve code-server from a sub-path, you can do so as follows:
mydomain.com/code/* {
uri strip_prefix /code
reverse_proxy 127.0.0.1:8080
}
Remember to replace mydomain.com with your domain name!
Reload Caddy:
sudo systemctl reload caddy
At this point, you should be able to access code-server via
https://mydomain.com.
Using Let's Encrypt with NGINX
This option requires that the remote machine be exposed to the internet. Make sure that your instance allows HTTP/HTTP traffic.
You'll need a domain name (if you don't have one, you can purchase one from
Google Domains or the domain service of your
choice)). Once you have a domain name, add an A record to your domain that contains your
instance's IP address.
We recommend self-signed certificates as a last resort, since self-signed
certificates do not work with iPads and may cause unexpected issues with
code-server. You should only proceed with this option if:
You do not want to buy a domain or you cannot expose the remote machine to
the internet
You do not want to use port forwarding via SSH
To use a self-signed certificate:
This option requires that the remote machine be exposed to the internet. Make
sure that your instance allows HTTP/HTTP traffic.
SSH into your instance and edit your code-server config file to use a
randomly generated self-signed certificate:
# Replaces "cert: false" with "cert: true" in the code-server config.
sed -i.bak 's/cert: false/cert: true/' ~/.config/code-server/config.yaml
# Replaces "bind-addr: 127.0.0.1:8080" with "bind-addr: 0.0.0.0:443" in the code-server config.
sed -i.bak 's/bind-addr: 127.0.0.1:8080/bind-addr: 0.0.0.0:443/' ~/.config/code-server/config.yaml
# Allows code-server to listen on port 443.
sudo setcap cap_net_bind_service=+ep /usr/lib/code-server/lib/node
Restart code-server:
sudo systemctl restart code-server@$USER
At this point, you should be able to access code-server via
https://<your-instance-ip>.
If you'd like to avoid the warnings displayed by code-server when using a
self-signed certificate, you can use mkcert to create a
self-signed certificate that's trusted by your operating system, then pass the
certificate to code-server via the cert and cert-key config fields.
External authentication
If you want to use external authentication mechanism (e.g., Sign in with
Google), you can do this with a reverse proxy such as:
For HTTPS, you can use a self-signed certificate by:
Passing in --cert
Passing in an existing certificate by providing the path to --cert and the
path to the key with --cert-key
The self signed certificate will be generated to
~/.local/share/code-server/self-signed.crt.
If you pass a certificate to code-server, it will respond to HTTPS requests and
redirect all HTTP requests to HTTPS.
You can use Let's Encrypt to get a TLS certificate
for free.
Note: if you set proxy_set_header Host $host; in your reverse proxy config, it will change the address displayed in the green section of code-server in the bottom left to show the correct address.
Accessing web services
If you're working on web services and want to access it locally, code-server
can proxy to any port using either a subdomain or a subpath, allowing you to
securely access these services using code-server's built-in authentication.
Using a subdomain
You will need a DNS entry that points to your server for each port you want to
access. You can either set up a wildcard DNS entry for *.<domain> if your
domain name registrar supports it, or you can create one for every port you want
to access (3000.<domain>, 8080.<domain>, etc).
You should also set up TLS certificates for these subdomains, either using a
wildcard certificate for *.<domain> or individual certificates for each port.
To set your domain, start code-server with the --proxy-domain flag:
code-server --proxy-domain <domain>
Now you can browse to <port>.<domain>. Note that this uses the host header, so
ensure your reverse proxy (if you're using one) forwards that information.
Using a subpath
Simply browse to /proxy/<port>/.
Stripping /proxy/<port> from the request path
You may notice that the code-server proxy strips /proxy/<port> from the
request path.
This reasoning is why the default behavior is to strip /proxy/<port> from the
base path. If your application uses relative URLs and does not assume the
absolute path at which it is being served, it will just work no matter what port
you decide to serve it off or if you put it in behind code-server or any other
proxy.
However, some prefer the cleaner aesthetic of no trailing slashes. Omitting the
trailing slashes couples you to the base path, since you cannot use relative
redirects correctly anymore. If you're okay with this tradeoff, use /absproxy
instead and the path will be passed as is (e.g., /absproxy/3000/my-app-path).
Proxying to create a React app
You must use /absproxy/<port> with create-react-app (see
#2565 and
#2222 for more information).
You will need to inform create-react-app of the path at which you are serving
via $PUBLIC_URL and webpack via $WDS_SOCKET_PATH:
