Coder 1.27 is now available for installation or upgrade. Features include workspace process logging, rootless Podman support, code-server 4.0, and more!
This can be useful in cases where your deployment’s Linux kernel version does not support CVMs or if your organization prefers to use Podman. Support for Podman provides additional flexibility in the way that teams can use Coder and allows a wider variety of use-cases and infrastructure stacks.
Documentation for using this capability is found here: https://coder.com/docs/coder/latest/guides/deployments/podman
Workspace process logging
We’ve added a feature that allows Coder admins to audit the commands that are entered into Coder workspaces by users in their deployment. This output is viewable from a sidecar container in the workspace pod and can be sent into a monitoring stack, such as CloudWatch, to filter and view as needed.
With workspace process logging, security-conscious organizations can introduce new technologies to their stack (such as Docker and
containerd) with the necessary auditing capabilities.
This feature is off by default and can be toggled from the admin settings. These logs are not recorded or sent outside of your deployment in any way, shape, or form.
The core of this feature is also open source and can be found at this Github repo here: https://github.com/coder/exectrace
Bundled code-server upgraded to 4.0
code-server is our open source implementation of VS Code in the web browser. This month, we released code-server 4.0. In this Coder release, we’ve upgraded the bundled code-server that runs in a Coder workspace to the latest version.
Disabling workspace auto-off
By default, Coder workspaces have a set auto-off where they are shut down and then auto-started the following day. In some cases, it may be necessary to have a workspace running overnight or for a longer duration. We’ve introduced a UI toggle that allows the auto-off feature to be disabled, so a job in a workspace can continue to run without being interrupted.
Admin control to force OIDC
We’ve heard your feedback and made it possible to disable username/password logins for deployments that have OIDC single sign-on enabled. There is still an admin bypass to access the instance using the set admin username and password as an “escape hatch”.