Workspace Overview

What is a Workspace?

A workspace is your personal Dev Container - an isolated, fully-configured development environment that runs in the cloud. Each workspace comes with everything you need to code, including a complete Linux environment, your choice of packages and tools, and multiple ways to access and work with your code.

Dev Container

Unlike traditional development environments that run locally on your machine, workspaces run as containerized environments on remote infrastructure. This provides:

  • Consistent environment across team members
  • Access from any device with a browser
  • Isolation from your local machine
  • Reproducible setup with package management

Instant Development

Start coding immediately without setting up local development environments, installing dependencies, or configuring tools.

Isolated & Safe

Each workspace runs in isolation with its own network namespace, preventing conflicts and keeping your development secure.

Key Features

Multiple Access Methods

Access your workspace through various methods depending on your workflow:

  • Web-based IDE in your browser
  • SSH access for any desktop IDE (VS Code, Cursor, IntelliJ, etc.)
  • Web terminal for quick access
  • AI-powered coding assistants

Package Management

Powered by Nix package manager, packages are installed and persisted at the workmachine host level. Each workspace gets access to packages based on its configuration, making binaries instantly available in the workspace PATH without reinstallation.

Environment Connection

Connect your workspace to environments to access services like databases, caches, and APIs using simple service names. The workspace's network namespace switches to enable seamless service access.

Service Interception

Intercept services running in connected environments to route their traffic to your workspace. Debug and test with real traffic without affecting the actual service.

Workspace Architecture

Workspace Container
Access
Web IDE, SSH, Terminal
Nix packages
Code
~/workspaces/[name]
Shared Home
Configs, dotfiles

Workmachine Host

Workspaces run on workmachines - virtual machines that host multiple workspaces. Each workmachine provides:

  • Shared Home Directory (~): All workspaces on the same workmachine share the home directory, persisting tool configurations, SSH keys, and git settings
  • Package Storage: Nix packages installed at the host level and shared efficiently across workspaces

Workspace Container

Each workspace is a containerized environment with:

  • Dedicated Code Directory: Workspace code stored at ~/workspaces/[workspace-name]
  • Package Access: Configured packages available in PATH based on workspace spec
  • Resource Limits: CPU, memory, and storage quotas per workspace
  • IDE Server: Running IDE server for browser-based editing and SSH access for desktop IDEs

Access Methods

Web-Based IDE

Full IDE experience in your browser with extensions, debugging, and terminal access. No installation required.

SSH Access for Desktop IDEs

Connect via SSH with your preferred desktop IDE (VS Code, Cursor, IntelliJ, etc.) for native development experience.

Web Terminal

Quick browser-based terminal access for running commands and checking workspace status without full IDE.

AI-Powered Coding Assistants

Integrate AI assistants that work directly with your workspace for enhanced development productivity.

Storage & Persistence

Shared Home Directory

All workspaces on the same workmachine share the home directory (~). This means:

  • Tool configurations (.bashrc, .vimrc, .gitconfig) are shared
  • SSH keys and credentials persist across workspaces
  • Global tool installations remain available

Workspace Code Storage

Each workspace has its own dedicated directory for code:

~/workspaces/[workspace-name]/

This keeps each workspace's code isolated while sharing common configurations in the home directory.

Package Persistence

Packages installed via Nix are stored at the workmachine host level and persist across workspace restarts. When a workspace starts, packages specified in its configuration are immediately available in the PATH without reinstallation.

Data Persistence

All data in the home directory and workspace directories persists across workspace suspensions and restarts. Only when a workspace is deleted is its data removed.

Networking

Network Isolation

Each workspace has its own network namespace, providing complete network isolation. By default, workspaces can access the external internet but cannot directly access environment services.

Environment Connection

When you connect a workspace to an environment using kl env connect, the workspace's network namespace switches to the environment's namespace. This enables:

  • DNS resolution of service names (e.g., postgres, redis)
  • Direct access to environment services by name and port
  • Ability to intercept services for debugging

Diagnostics

Workspaces are long-lived containers. When something feels off—slow startup, missing services, broken SSH—the quickest path to a fix is to inspect the workspace state from inside the container.

Quick Health Checks

kl status               # Workspace overview
kl env status           # Active environment connection
kl intercept list       # Running intercepts
df -h /workspaces       # Check remaining disk space

SSH & Network Troubleshooting

  • Verify SSH tunnel availability: ssh -T workspace-name.
  • Confirm DNS resolution: getent hosts postgres.
  • Check intercept health: kl intercept status api-server.
  • List listening ports for conflicts with ss -plnt.

Tip

If a workspace becomes unhealthy, suspend and resume it from the dashboard. This reprovisions the container while preserving your home directory and package cache.

Collaboration Patterns

Share What Matters

  • Use Git or cloud storage inside ~/workspaces to collaborate on code.
  • Keep team-wide tooling in the shared home (~/) so everyone benefits from the same dotfiles.
  • Define reusable package groups in the installation so new workspaces start with the same toolset.

Coordinate with Environments

  • Use service intercepts for pair debugging—one person intercepts while teammates observe live traffic.
  • Create dedicated environments for feature branches; tear them down once merged to keep costs low.
  • Leverage labels on services/workspaces to indicate ownership, review status, or required approvers.