kftui terminal interface

the kftui terminal interface provides keyboard-driven management of kubernetes port forwards through a text-based application. this works well for developers who prefer command-line workflows, need minimal resource usage, or work in environments without graphical interfaces.

when the terminal interface makes sense

the terminal interface becomes useful when someone prefers keyboard navigation over mouse interactions, needs to work over SSH connections, or wants minimal resource overhead. this comes up especially in server environments, remote development scenarios, or when working with resource-constrained systems.

compared to the desktop interface (kftray), the terminal version uses significantly less memory and CPU while providing the same core port forwarding capabilities. it lacks some features like http traffic logging and github sync, but handles all essential configuration and forwarding tasks.

someone already working primarily in terminals might find the text interface more natural than switching to a graphical application. the choice often depends on existing development environment preferences.

interface design and navigation

screen layout and organization

the interface uses a standard terminal layout with a top menu bar showing available actions and keyboard shortcuts. the main area displays configurations in a table format with columns for service name, port mapping, namespace, and status.

┌─ kftui ──────────────────────────────────────┐
│ [Tab] Menu   [F] Forward   [H] Help          │
├─────────────────────────────────────────────┤
│ Running Configurations                       │
│ □ web-app     8080:80    default   Running  │
│ □ database    5432:5432  data      Stopped  │
│                                             │
│ [Space] Select   [Ctrl+A] Select All        │
└─────────────────────────────────────────────┘

status indicators show the current state of each configuration (running, stopped, error) and selection checkboxes allow batch operations on multiple configurations.

keyboard-driven workflow

navigation happens entirely through keyboard shortcuts: arrow keys move between configurations, space bar selects items, and function keys trigger actions. tab switches between different interface sections when available.

common operations use memorable shortcuts -- 'f' for forward/start, 's' for stop, 'i' for import, and 'e' for export. help screens show all available shortcuts, making the interface discoverable for new users.

multi-select operations work through space bar selection followed by action keys. this allows starting or stopping multiple port forwards simultaneously.

resource usage and performance characteristics

the terminal interface typically uses around 30MB of RAM and minimal CPU during normal operation. this represents a significant reduction compared to the desktop version, making it suitable for resource-constrained environments.

disk usage is minimal -- just the binary (~20MB) plus shared configuration database. the interface doesn't include graphics libraries or desktop dependencies, keeping the footprint small.

network usage depends only on active port forwards, not the interface itself. the terminal version handles the same number of simultaneous forwards as the desktop version with lower overhead.

terminal compatibility and requirements

terminal emulator support

the interface works with standard terminal emulators that support UTF-8 character encoding and basic input handling. this includes virtually all modern terminals on unix systems and windows terminal applications.

minimum terminal size is 80x24 characters, though larger terminals provide better layout. the interface adapts to different terminal sizes automatically.

color support enhances the visual experience but isn't required -- the interface works in monochrome terminals when necessary.

remote access scenarios

the terminal interface works well over SSH connections, making it useful for managing port forwards on remote systems. someone can SSH to a development server and use kftui to manage forwards without requiring X11 forwarding or VNC.

terminal multiplexers like tmux or screen work normally with the interface. developers often run kftui in a dedicated tmux session that persists across SSH disconnections.

latency tolerance makes the interface usable even over slow network connections where graphical applications would be unresponsive.

workflow integration patterns

command-line development environments

developers working primarily in terminals often integrate kftui into their existing workflow. launch the interface in a dedicated terminal tab or tmux window, configure forwards, then switch back to development work.

the shared configuration database means forwards started in kftui remain active even after closing the interface. this allows using the terminal interface for setup, then continuing development work without keeping the interface open.

server and headless environments

development servers or CI/CD environments often lack graphical interfaces entirely. the terminal interface enables port forward management in these environments without desktop dependencies.

automated scripts can interact with kftui through expect or similar tools, though direct configuration file manipulation might be simpler for programmatic access.

remote development workflows

when developing against remote kubernetes clusters, someone might SSH to a jump host and use kftui to establish forwards. this keeps the port forwards close to the cluster, reducing network latency.

the terminal interface also works well in container environments where running a full desktop application would be impractical.

feature comparison with desktop interface

shared core functionality

both interfaces provide the same port forwarding capabilities: TCP and UDP support, automatic reconnection, multiple kubernetes contexts, and custom kubeconfig files. configuration management works identically through the shared database.

auto-import from kubernetes service annotations and basic configuration import/export work the same way in both interfaces.

terminal-specific limitations

http traffic logging currently only works in the desktop interface. github sync also requires the desktop version for the integrated authentication and sync management.

visual configuration editing is more limited in the terminal interface -- complex configurations often need to be created through JSON file import rather than interactive editing.

terminal-specific advantages

lower resource usage makes the terminal interface suitable for environments where the desktop version would be too heavy. SSH accessibility enables remote management scenarios impossible with graphical applications.

keyboard efficiency appeals to developers who prefer not switching between keyboard and mouse during development work.

integration with development tools

text editor and command-line workflows

the terminal interface fits naturally into vim, emacs, or other text-based development environments. switching between code editing and port forward management happens within the same interface paradigm.

configuration files can be edited directly with preferred text editors, then imported into kftui for activation.

shell integration and automation

while the interface doesn't provide a direct shell API, configuration files can be managed programmatically and imported. this enables integration with shell scripts or other automation tools.

the shared configuration database means other tools can read port forward status even when kftui isn't running.

limitations and operational considerations

interface complexity constraints

the text-based interface limits the complexity of configuration editing compared to the desktop version. advanced configurations might be easier to create as JSON files and import rather than using the built-in editors.

visual feedback is more limited than in graphical interfaces. status indication relies on text symbols and color (when available) rather than rich visual elements.

platform-specific considerations

while the interface works across platforms, terminal capabilities vary. windows command prompt provides a more limited experience than unix terminals, though windows terminal and PowerShell improve the situation.

some advanced terminal features (mouse support, extended color schemes) may not work consistently across all environments.

scalability and organization

managing very large numbers of configurations becomes more challenging in the text interface compared to the desktop version. the linear list format doesn't scale as well as the desktop's search and filtering capabilities.

however, for typical development scenarios with dozens rather than hundreds of configurations, the terminal interface handles the workload efficiently.