Installing Coder in Kubernetes with Devcontainer Support

2026-06-15T00:00:00+00:00
Introduction#</a> </h1>
I have a Framework Desktop whose main purpose is to be a remote development machine. I'm currently using it with remote SSH access thorugh VS Code, and Docker devcontainers to get reproducible dev environments. And this works fine as is. However, I still need to have a laptop accessible that can run VS Code, and I'd like to able to run a quick development session from everywhere, regardlesss of what hardware I have on hand. I can't run this setup from an iPad, or a browser, or some other machine, which would lighten my travel "tech stack" considerably.
This is where Coder</a> comes in. It will allow me to run my development setup from any browser, and still keep my current VSCode worflow when working from a laptop. It also gives me the flexibility you get from GitHub's Codespaces</a>, without having yet another service I need to pay for.

Existing Setup
The desktop runs K3s</a> as a single node cluster and it already runs a couple of services I use in my daily life. As part of these services, it already has a Postgres instance, that has backups configured 1</a>. The goal is to use this Postgres instance for persistence, so I have one less piece of infrastructure I need to worry about.
Finally, I use helm to manage the services running on this "cluster," so I have a good base set up.

The first step is to set up Coder itself. It already comes with a Helm chart</a>. For my setup, I'll wrap it in my own chart, so I can configure it,
apiVersion</span>:</span> v2</span></span>
name</span>:</span> coder</span></span>
version</span>:</span> 0.1.0</span></span>
dependencies</span>:</span></span>
  -</span> name</span>:</span> coder</span></span>
    version</span>:</span> "2.*"</span></span>
    repository</span>:</span> https://helm.coder.com/v2</span></span></code></pre>
And I will need to define a couple of resources, in order to hook it up into the existing infrastructure.</p>
First, a secret for the DB connection string, that will contain the username and password:</p>
apiVersion</span>:</span> v1</span></span>
kind</span>:</span> Secret</span></span>
metadata</span>:</span></span>
  name</span>:</span> coder-db-secret</span></span>
  namespace</span>: {{</span> .Release.Namespace</span> }}</span></span>
type</span>:</span> Opaque</span></span>
stringData</span>:</span></span>
  url</span>: {{</span> .Values.dbUrl | quote</span> }}</span></span></code></pre>
Secondly, I need an ingress controller, so I can access it from my custom URL:</p>
apiVersion</span>:</span> networking.k8s.io/v1</span></span>
kind</span>:</span> Ingress</span></span>
metadata</span>:</span></span>
  name</span>:</span> coder</span></span>
  namespace</span>: {{</span> .Release.Namespace</span> }}</span></span>
  annotations</span>:</span></span>
    cert-manager.io/cluster-issuer</span>: {{</span> .Values.clusterIssuer</span> }}</span></span>
spec</span>:</span></span>
  ingressClassName</span>:</span> traefik</span></span>
  tls</span>:</span></span>
    -</span> hosts</span>:</span></span>
        - {{</span> .Values.ingress.host</span> }}</span></span>
        - {{</span> .Values.ingress.wildcardHost | quote</span> }}</span></span>
      secretName</span>:</span> coder-tls</span></span>
  rules</span>:</span></span>
    -</span> host</span>: {{</span> .Values.ingress.host</span> }}</span></span>
      http</span>:</span></span>
        paths</span>:</span></span>
          -</span> path</span>:</span> /</span></span>
            pathType</span>:</span> Prefix</span></span>
            backend</span>:</span></span>
              service</span>:</span></span>
                name</span>:</span> coder</span></span>
                port</span>:</span></span>
                  number</span>:</span> 80</span></span>
    -</span> host</span>: {{</span> .Values.ingress.wildcardHost | quote</span> }}</span></span>
      http</span>:</span></span>
        paths</span>:</span></span>
          -</span> path</span>:</span> /</span></span>
            pathType</span>:</span> Prefix</span></span>
            backend</span>:</span></span>
              service</span>:</span></span>
                name</span>:</span> coder</span></span>
                port</span>:</span></span>
                  number</span>:</span> 80</span></span></code></pre>
Like all my other services, this will use Let's Encrypt</a> and DNS verification to generate valid TLS certficate.
The deployment will only be available in my tailnet</a>, but having a valid certificate makes everything a lot easier.
I don't get annoying browser warnings, and it's one step taken care of if I ever want to make the service publicly accessible.</p>
Finally, I need to define the values for our deployment.</p>
The details for the ingress are defined below.
It's the cluster issuer (defined elsewhere in my helm charts), and the domains that we want to serve coder from.</p>
clusterIssuer</span>:</span> lets-encrypt-prod</span></span>
</span>
ingress</span>:</span></span>
  host</span>:</span> coder.caius.dev</span></span>
  wildcardHost</span>:</span> "*.coder.caius.dev"</span></span></code></pre>
For the DB secret, I've defined the dbUrl</code> inside a separate secrets.yaml</code> file that is not added to source control.
The format of this is:</p>
dbUrl</span>:</span> "<user>@<password>:<db_host>:5432"</span></span></code></pre>
Next, I'll wire up the secret DB access string, the access URL, and disable coder's builtin ingress, as we are using our own.
We'll also need to disable the cluster access URL.
Without this, things like the CLI install script will try and use the Kubernetes internal hostname, and that's not resolvable from outside the cluster.</p>
coder</span>:</span></span>
  coder</span>:</span></span>
    envUseClusterAccessURL</span>:</span> false</span></span>
</span>
    env</span>:</span></span>
      -</span> name</span>:</span> CODER_PG_CONNECTION_URL</span></span>
        valueFrom</span>:</span></span>
          secretKeyRef</span>:</span></span>
            name</span>:</span> coder-db-secret</span></span>
            key</span>:</span> url</span></span>
      -</span> name</span>:</span> CODER_ACCESS_URL</span></span>
        value</span>:</span> https://coder.caius.dev</span></span>
      -</span> name</span>:</span> CODER_WILDCARD_ACCESS_URL</span></span>
        value</span>:</span> "*.coder.caius.dev"</span></span>
</span>
    ingress</span>:</span></span>
      enable</span>:</span> false</span></span></code></pre>
Finally, let's set up some resource limits:</p>
    resources</span>:</span></span>
      requests</span>:</span></span>
        cpu</span>:</span> 250m</span></span>
        memory</span>:</span> 512Mi</span></span>
      limits</span>:</span></span>
        cpu</span>:</span> "2"</span></span>
        memory</span>:</span> 2Gi</span></span></code></pre>
Applying this will bring up the deployment.
It takes a few minutes for the cert to be provisioned, but once that was done, I was able to log in and everything worked!</p>
Workspaces namespace#</span></a>
</h2>
For the workspaces themselves, I decided to use a separate namespace, coder-workspaces</code>.
For this, I created a simple namespace resource using helm:</p>
apiVersion</span>:</span> v1</span></span>
kind</span>:</span> Namespace</span></span>
metadata</span>:</span></span>
  name</span>:</span> coder-workspaces</span></span>
  labels</span>:</span></span>
    pod-security.kubernetes.io/enforce</span>:</span> privileged</span></span></code></pre>
We also need an RBAC authorization, so the coder service account can provision the resources we need when creating a new workspace in the coder-workspace</code> namespace:</p>
apiVersion</span>:</span> rbac.authorization.k8s.io/v1</span></span>
kind</span>:</span> Role</span></span>
metadata</span>:</span></span>
  name</span>:</span> coder-workspaces</span></span>
  namespace</span>:</span> coder-workspaces</span></span>
rules</span>:</span></span>
-</span> apiGroups</span>: [</span>""</span>]</span></span>
  resources</span>:</span></span>
  -</span> pods</span></span>
  -</span> pods/exec</span></span>
  -</span> pods/log</span></span>
  -</span> persistentvolumeclaims</span></span>
  -</span> secrets</span></span>
  -</span> services</span></span>
  -</span> serviceaccounts</span></span>
  verbs</span>: [</span>"get"</span>,</span> "list"</span>,</span> "watch"</span>,</span> "create"</span>,</span> "update"</span>,</span> "patch"</span>,</span> "delete"</span>]</span></span>
-</span> apiGroups</span>: [</span>"apps"</span>]</span></span>
  resources</span>:</span></span>
  -</span> deployments</span></span>
  -</span> replicasets</span></span>
  verbs</span>: [</span>"get"</span>,</span> "list"</span>,</span> "watch"</span>,</span> "create"</span>,</span> "update"</span>,</span> "patch"</span>,</span> "delete"</span>]</span></span>
---</span></span>
apiVersion</span>:</span> rbac.authorization.k8s.io/v1</span></span>
kind</span>:</span> RoleBinding</span></span>
metadata</span>:</span></span>
  name</span>:</span> coder-workspaces</span></span>
  namespace</span>:</span> coder-workspaces</span></span>
roleRef</span>:</span></span>
  apiGroup</span>:</span> rbac.authorization.k8s.io</span></span>
  kind</span>:</span> Role</span></span>
  name</span>:</span> coder-workspaces</span></span>
subjects</span>:</span></span>
-</span> kind</span>:</span> ServiceAccount</span></span>
  name</span>:</span> coder</span></span>
  namespace</span>:</span> coder</span></span></code></pre>Workspace Template#</span></a>
</h2>
For the template, I started off with the default kubernetes-devcontainer</code> template.
However there were a couple of things that needed to be addressed.</p>
First, and the most obvious, was changing the namespace from default</code> to coder-workspaces</code>.
This was a single line change.</p>
I also wanted to use SSH keys for repo authentication, as I didn't want to install the coder app in GitHub.
Finally, there were are few quality of life issues, like the directory that code server (and VS Code) opened in, as well as always trusting GitHub's SSH keys.
I will go into detail for each of them in the following sections.</p>
Using SSH keys for git repo authentication#</span></a>
</h3>
To access my private repos, I wanted to use SSH authentication.
I didn't want to install the coder github app, as I didn't really know what info it would syphon out.
Coder already defines a key pair that can be used for this purpose, one for each user.
However, I still need to inject the private key inside the container.
To accomplish this, I created a kubernetes secret with the private key, and then used that to inject it into the container.</p>
resource</span> "kubernetes_secret_v1" "ssh_key" {</span></span>
  </span>metadata</span> {</span></span>
    name</span>      =</span> "coder-</span>${</span>lower</span>(</span>data</span>.</span>coder_workspace</span>.</span>me</span>.</span>id</span>)</span>}</span>-ssh-key"</span></span>
    namespace</span> =</span> var</span>.</span>namespace</span></span>
  }</span></span>
  data</span> =</span> {</span></span>
    id_rsa</span> =</span> data.coder_workspace_owner.me.ssh_private_key</span></span>
  }</span></span>
}</span></span></code></pre>
I then set the correct enviroment variable, so the containers knows where to get the private key from:</p>
"ENVBUILDER_GIT_SSH_PRIVATE_KEY_PATH"</span> :</span> "/tmp/ssh/id_rsa"</span>,</span></span></code></pre>
Finally, I need to mount the newly created secret at the right path inside the container.
I need to tell the container where to mount it to:</p>
volume_mount</span> {</span></span>
    mount_path</span> =</span> "/tmp/ssh"</span></span>
    name</span>       =</span> "ssh-key"</span></span>
    read_only</span>  =</span> true</span></span>
}</span></span></code></pre>
And I'll need to configure the deployment to create the volume, with the secret contents:</p>
volume</span> {</span></span>
    name</span> =</span> "ssh-key"</span></span>
    </span>secret</span> {</span></span>
        secret_name</span>  =</span> kubernetes_secret_v1</span>.</span>ssh_key</span>.</span>metadata[</span>0</span>]</span>.</span>name</span></span>
        default_mode</span> =</span> "0400"</span></span>
    }</span></span>
}</span></span></code></pre>
I can now allow access to coder's public key, and use SSH to authenticate with GitHub, or any other forge.</p>
With this setup, I have the basic dev workflow sorted out.
I can create a new workspace, and it will clone the repo, and spin up the devcontainer.</p>
Mounting the correct path in the editor#</span></a>
</h3>
The default config will mount /workspaces</code> as the "root" path for the editor.
This isn't ideal, as I'm used to working in the repo root.
Some of the VS code tasks also assume this, and will fail otherwise.
Luckily, I can fix this by tweaking the templates a bit.</p>
First, I need to define a local variable that's the repo name.
This can be easily inferred from the repo url:</p>
repo_dir</span> =</span> "/workspaces/</span>${</span>replace</span>(</span>basename</span>(</span>local</span>.</span>repo_url</span>), ".git", "")</span>}</span>"</span></span></code></pre>
I'll then assign this to the folder</code> parameter in our code_server</code> module:</p>
folder</span> =</span> local</span>.</span>repo_dir</span></span></code></pre>
The coder agent will, by default, expose a VS Code Desktop connection option.
However, this will always point to "home", which in this case it's /workspaces</code>, and this is what we're trying to avoid.
The easier solution around this, was to disable it in the agent definition, by adding the following to the terraform config:</p>
display_apps</span> {</span></span>
  vscode</span> =</span> false</span></span>
}</span></span></code></pre>
Then, I can define an explicit vscode-desktop</code> module that will open the correct folder.</p>
module "vscode" {                                                                                </span></span>
  count   = data.coder_workspace.me.start_count                                                  </span></span>
  source  = "registry.coder.com/coder/vscode-desktop/coder"                                              </span></span>
  version = "~> 1.0"                                                                             </span></span>
                                                                                                 </span></span>
  agent_id   = coder_agent.main.id                                                               </span></span>
  folder     = local.repo_dir                                                                    </span></span>
  order      = 2                                                                                 </span></span>
}</span></span></code></pre>Automatically installing extensions#</span></a>
</h3>
The extensions specified in the devcontainer.json</code> file are not automatically installed when I start up the code server, or the desktop VS Code.
While it is possible to specify extensions to install in the terraform templates, I wanted a generic solution, that would install only the required extensions for each specific repo.
The solution is a script that runs at startup, parses the devcontainer.json</code> file, extracts the list of extensions and installs them.
After the install, it generates a .vscode/extensions.json</code> file, so that any remote VS Code desktop instances will pick them up, and suggest that they are installed2</a></sup>.</p>
The final result is the following coder_script</code> resource:</p>
resource</span> "coder_script" "devcontainer_extensions" {</span></span>
  count</span>              =</span> data</span>.</span>coder_workspace</span>.</span>me</span>.</span>start_count</span></span>
  agent_id</span>           =</span> coder_agent</span>.</span>main</span>.</span>id</span></span>
  display_name</span>       =</span> "Install devcontainer extensions"</span></span>
  run_on_start</span>       =</span> true</span></span>
  start_blocks_login</span> =</span> true</span></span>
  script</span>             = <<-EOT</span></span>
    #!/bin/bash</span></span>
    REPO_DIR="</span>${</span>local</span>.</span>repo_dir</span>}</span>"</span></span>
</span>
    DEVCONTAINER_JSON=""</span></span>
    for candidate in "$REPO_DIR/.devcontainer/devcontainer.json" "$REPO_DIR/devcontainer.json"; do</span></span>
      if [ -f "$candidate" ]; then</span></span>
        DEVCONTAINER_JSON="$candidate"</span></span>
        break</span></span>
      fi</span></span>
    done</span></span>
    [ -z "$DEVCONTAINER_JSON" ] && exit 0</span></span>
</span>
    until command -v code-server &>/dev/null; do sleep 1; done</span></span>
</span>
    command -v jq &>/dev/null || { echo "jq not found, skipping extension install"; exit 0; }</span></span>
    EXTENSIONS=$(jq -r '.customizations?.vscode?.extensions[]?' "$DEVCONTAINER_JSON" 2>/dev/null || true)</span></span>
    [ -z "$EXTENSIONS" ] && exit 0</span></span>
</span>
    echo "$EXTENSIONS" | while IFS= read -r ext; do</span></span>
      [ -z "$ext" ] && continue</span></span>
      code-server --install-extension "$ext" 2>&1 || true</span></span>
    done</span></span>
</span>
    # Write .vscode/extensions.json so VS Code Desktop prompts to install the same extensions</span></span>
    VSCODE_EXTS_FILE="$REPO_DIR/.vscode/extensions.json"</span></span>
    if [ ! -f "$VSCODE_EXTS_FILE" ]; then</span></span>
      mkdir -p "$REPO_DIR/.vscode"</span></span>
      jq -n --argjson exts \</span></span>
        "$(jq -c '[.customizations?.vscode?.extensions[]?]' "$DEVCONTAINER_JSON")" \</span></span>
        '{"recommendations": $exts}' > "$VSCODE_EXTS_FILE"</span></span>
    fi</span></span>
  EOT</span></span>
}</span></span></code></pre>Trusting GitHub's public keys#</span></a>
</h3>
The last nagging problem was having to trust GitHub's keys after I restarted a workspace, during the first interaction with git.
To fix this, I added another script that will trust GitHub's keys, so it always restarts in a "good" state.
The scripts will run in parallel, so this adds nothing to the startup time.</p>
resource</span> "coder_script" "github_known_hosts" {</span></span>
  count</span>              =</span> data</span>.</span>coder_workspace</span>.</span>me</span>.</span>start_count</span></span>
  agent_id</span>           =</span> coder_agent</span>.</span>main</span>.</span>id</span></span>
  display_name</span>       =</span> "Trust github hosts"</span></span>
  run_on_start</span>       =</span> true</span></span>
  start_blocks_login</span> =</span> true</span></span>
  script</span>             = <<-EOT</span></span>
mkdir -p /root/.ssh/</span></span>
cat <<'EOF' >> /root/.ssh/known_hosts</span></span>
|1|YcSxwNwqHecLiBTEXmhb3JcKMbg=|LDlb4p4OoJafZDnkMspTODpHdlY= ssh-ed25519 AAAAC3NzaC1lZDI1NTE5AAAAIOMqqnkVzrm0SdG6UOoqKLsabgH5C9okWi0dh2l9GKJl</span></span>
|1|qf+ciiHWdVTQzkK389LmH/RM/Wo=|UaXlxsvDYssHCiqHv9q+aHyf01w= ssh-rsa AAAAB3NzaC1yc2EAAAADAQABAAABgQCj7ndNxQowgcQnjshcLrqPEiiphnt+VTTvDP6mHBL9j1aNUkY4Ue1gvwnGLVlOhGeYrnZaMgRK6+PKCUXaDbC7qtbW8gIkhL7aGCsOr/C56SJMy/BCZfxd1nWzAOxSDPgVsmerOBYfNqltV9/hWCqBywINIR+5dIg6JTJ72pcEpEjcYgXkE2YEFXV1JHnsKgbLWNlhScqb2UmyRkQyytRLtL+38TGxkxCflmO+5Z8CSSNY7GidjMIZ7Q4zMjA2n1nGrlTDkzwDCsw+wqFPGQA179cnfGWOWRVruj16z6XyvxvjJwbz0wQZ75XK5tKSb7FNyeIEs4TT4jk+S4dhPeAUC5y+bDYirYgM4GC7uEnztnZyaVWQ7B381AK4Qdrwt51ZqExKbQpTUNn+EjqoTwvqNj4kqx5QUCI0ThS/YkOxJCXmPUWZbhjpCg56i+2aB6CmK2JGhn57K5mj0MNdBXA4/WnwH6XoPWJzK5Nyu2zB3nAZp+S5hpQs+p1vN1/wsjk=</span></span>
|1|nXxxrVNnRIHD8UKpOVlDGR9oYX4=|+FflYHXVajJijO9egAkU5wPQ+Ac= ecdsa-sha2-nistp256 AAAAE2VjZHNhLXNoYTItbmlzdHAyNTYAAAAIbmlzdHAyNTYAAABBBEmKSENjQEezOmxkZMy7opKgwFB9nkt5YRrYMjNuG5N87uRgg6CLrbo5wAdT/y6v0mKV0U2w0WZ2YB/++Tpockg=</span></span>
EOF</span></span>
echo "Done"</span></span>
EOT</span></span>
}</span></span></code></pre>Conclusions#</span></a>
</h1>
The templates I arrived at are available in this GitHub repo</a>.</p>
The setup works well, and this blog post was written using an iPad and code server.
The goal was to have more flexibility when travelling, to avoid having to carry too many devices.
And I think, so far, I've achieved this goal.</p>
The setup uses the standard devcontainers I've developed, without requiring any custom modfications to be made.
This should make it easy to adapt in any future project, or start up new workspaces as I realize I need to make changes to other projects.</p>



See this blog post</a> on how I set this up. ↩</a></p>
</li>

A simpler option would probably be to check in the extension.json</code> file into version control. But I'm too far down this rabbit hole to change course. ↩</a></p>
</li>
</ol>
</section>
Caius' Lab - Terraform

Installing Coder in Kubernetes with Devcontainer Support
