# Deploy and Access Remote VSCode with Code-Server

> Octelium documentation. Canonical page: <https://octelium.com/docs/octelium/latest/management/guide/service/homelab/remote-vscode-code-server>.

> **Note:**
>
> It is much more recommended to use [Cordium](https://octelium.com/docs/cordium/latest/overview/intro.md), the open source sandbox built on Octelium for remote development environments, persistent coding sessions with VSCode, Zed, and other IDEs.

Deploying a secure Remote VSCode via open source [code-server](https://github.com/coder/code-server) is seamless with Octelium. All you have to do is create a publicly exposed web-add *Service* whose upstream is the `codercom/code-server` container image (read more about managed containers [here](https://octelium.com/docs/octelium/latest/management/core/service/managed-containers.md)). This can be done very easily as follows:

```yaml
kind: Service
metadata:
  name: code
spec:
  mode: WEB
  isPublic: true
  config:
    upstream:
      container:
        port: 8080
        image: codercom/code-server:latest
        args:
        - --auth
        - none
        - --bind-addr
        - 0.0.0.0:8080
        - --disable-getting-started-override
        - --trusted-origins
        - code.<DOMAIN>
        - --disable-workspace-trust
        resourceLimit:
          cpu:
            millicores: 2000
          memory:
            megabytes: 4000
```

> **Note:**
>
> The above configuration assumes that you have enough permissions to access the *Service*. Read more about access control and *Policies* [here](https://octelium.com/docs/octelium/latest/management/core/policy.md). You might also want to read about effectively creating a privileged *User* [here](https://octelium.com/docs/octelium/latest/management/core/user.md#privileged-users).

Now you can access the *Service* publicly via the clientless/BeyondCorp using your browser at the address `https://code.<DOMAIN>`. You can read more about publicly exposed BeyondCorp *Services* [here](https://octelium.com/docs/octelium/latest/management/core/service/clientless.md).

> **Note:**
>
> You can also use and mount Kubernetes volumes to have persistent storage. Read more [here](https://octelium.com/docs/octelium/latest/management/core/service/managed-containers.md#volumes)

> **Note:**
>
> Octelium also provides OpenTelemetry-ready, application-layer L7 aware visibility and access logging in real time (see an example for HTTP [here](https://octelium.com/docs/octelium/latest/management/core/service/http.md#visibility)). You can read more about visibility [here](https://octelium.com/docs/octelium/latest/management/core/visibility.md)

Another way is to use vanilla remote VSCode over SSH. In such case, you can define your own `SSH` *Service* whose upstream can be any remote host, or even use the embedded SSH mode for VSCode. For example, you can run an `octelium` client inside your Kubernetes cluster (read more [here](https://octelium.com/docs/octelium/latest/user/cli/connect.md#kubernetes)) that runs an embedded SSH server and from then use it as a remote host for VSCode. Here is an example (read more about deploying `octelium` using Helm [here](https://octelium.com/docs/octelium/latest/management/guide/service/devops/octelium-helm-kubernetes.md)):

```bash
helm install my-octelium-chart oci://ghcr.io/octelium/helm-charts/octelium --set octelium.domain=<DOMAIN> --set octelium.authToken=<AUTHENTICATION_TOKEN> --set "octelium.args={--essh}"
```

And now, from your own machine, connect to the *Cluster* with `octelium connect`. If you embedded SSH *Service* has the hostname `essh` then you just need to use the `<SESSION_NAME>@essh` as the SSH address. You can read in detail on how to SSH into a specific host via embedded SSH [here](https://octelium.com/docs/octelium/latest/user/cli/access.md#embedded-ssh).

Regarding authentication, you can seamlessly authenticate to the *Cluster* via your web browser using an *IdentityProvider* (read more [here](https://octelium.com/docs/octelium/latest/management/core/identity-providers.md)). There are currently 3 types:

- GitHub OAuth *IdentityProvider* as shown in detail [here](https://octelium.com/docs/octelium/latest/management/core/identity-providers.md#github-oauth2)
- OpenID Connect *IdentityProviders* (e.g. Okta, Auth0, etc...) as shown [here](https://octelium.com/docs/octelium/latest/management/core/identity-providers.md#openid-connect).
- SAML 2.0 *IdentityProviders* (e.g. Okta, Entra ID, etc...) as shown [here](https://octelium.com/docs/octelium/latest/management/core/identity-providers.md#saml-20).

Furthermore, you can can register a FIDO2 *Authenticator* (e.g. Yubikeys) in order to directly login later via Passkey (read more [here](https://octelium.com/docs/octelium/latest/management/core/authenticator.md#passkey-login)) without having to use an *IdentityProvider*.