Before users can create a CVM-enabled workspace, a site manager must enable CVMs. To do so:
Once you've enabled CVMs, you can customize the behavior of your deployment and workspaces.
These settings will apply to workspaces after they have been rebuilt.
Once you've enabled CVMs, you can control whether all new workspaces should be built as a CVM or not.
If you would like all newly created workspaces to be CVMs, toggle Default to container-based virtual machines to On.
While this toggle changes the default workspace creation setting, users can still override this setting. For example, if you enable CVMS and set them as the default, a user can still create non-CVM workspaces (and vice versa).
Cached CVMs are currently an alpha feature.
To improve the startup time for CVM-based workspaces, you can enable caching.
Cached CVMs require the
shiftfs kernel to be present on the node. Some
distributions (such as Ubuntu) include
shiftfs. If you're unsure if
is present on your nodes, you can check by running
modinfo shiftfs. If no
output is returned, you do not have
If you don't want to install
shiftfs yourself, you can have Coder install the
module automatically for you. It is important that you do not have secure boot
enabled and that you have the kernel headers installed if you want Coder to
shiftfs on your behalf.
GPUs are not supported with cached CVMs at this time.
Self-contained workspace builds are currently an alpha feature.
By default, Coder initializes workspaces by running commands inside the
container. Workspaces, however, control the initialization sequence instead when
you enable self-contained workspace builds. This enables cluster operations
that restrict command execution inside containers using the Kubernetes API, such
kubectl exec command.
Workspace process logging is currently an alpha feature.
Workspace process logging enables auditing of commands executed inside the workspace container.
TUN devices currently an alpha feature.
Coder allows the creation of custom network interfaces using the Linux TUN
device. When using the Enable TUN device setting, Coder workspaces will have
/dev/net/tun device mounted into the workspace at build time. VPN usage
often requires a TUN device.
Users may need root (or
sudo) access within their workspace to use the TUN
device and start a VPN client.
At this time, Coder does not support TUN devices for non-Kubernetes workspace types, such as EC2 or Docker.
If you're working with EC2 workspaces, we recommend enabling privileged mode in the workspace provider settings, which will allow users to create their own TUN device.
We've tested this feature using the Tailscale VPN within Coder. Remember that you may have to change your VPN settings to keep any persistent files (such as configuration/identity) files in your home volume, as any data outside the home volume is cleared when the workspace is rebuilt.
FUSE devices are currently an alpha feature.
Coder allows the creation of custom filesystems using the Linux FUSE userspace
filesystem device. By enabling the Enable FUSE device setting, Coder
workspaces will have a
/dev/fuse device mounted into the workspace at build
time. These devices are often used to mount specialized filesystems, such as
Google Cloud Storage buckets, to your workspace.
Users may need root (or
sudo) access within their workspace to use the FUSE
device and start a FUSE filesystem.
At this time, Coder does not support FUSE devices for non-Kubernetes workspace types, such as EC2 or Docker.
If you're working with EC2 workspaces, we recommend enabling privileged mode in the workspace provider settings, which will allow users to create their own FUSE device.
For example, you can mount a directory from a remote SSH server using
mkdir /tmp/mnt sshfs [email protected]:/ /tmp/mnt
Then, in a second terminal, run
ls /tmp/mnt to list the files from the remote
host. You should also be able to see a
fuse.sshfs entry in the output from the