Adam Shiervani
2614db6b89
* feat(ui): add log level selector in Troubleshooting Mode Add a UI dropdown in Advanced > Troubleshooting Mode that lets users set the system log verbosity (Error, Warning, Info, Debug, Trace). Changes take effect immediately without restart via new getDefaultLogLevel/setDefaultLogLevel JSON-RPC endpoints. Also downgrades the noisy wakeup_on_write permission denied warning from Warn to Debug level, and removes the INFO→WARN config migration so users can actually select INFO. Localized for all 14 languages. * chore(ui): disable no-floating-promises in oxlint The rule is not actionable for the current codebase; turn it off explicitly. * refactor(ui): drop void prefixes on JSON-RPC send in advanced settings no-floating-promises is disabled in oxlint; match the rest of the codebase. * fix(ui): localize log level dropdown and fix optimistic update - Replace hardcoded English dropdown labels with localized m.*() calls - Replace hardcoded error string with m.advanced_error_set_log_level() - Optimistically update dropdown on change and revert on RPC failure - Add 6 new i18n keys across all 14 locales * chore: add remote-agent to .gitignore and auto-sort i18n in pre-commit - Ignore the compiled e2e/remote-agent/remote-agent binary - Add lint-staged rule to run i18n:resort on message JSON changes * copy(ui): improve log level setting description Apply outcome-oriented copy: explain what the setting does for the user and when to change it, rather than restating the control's mechanics. Updated across all 14 locales. * fix(logging): scope loggers not rebuilt when config level matches base default UpdateLogLevel compared the new config level against the base default (ErrorLevel) instead of the previous config level. When switching from WARN back to ERROR, the comparison was equal so scope loggers kept their old WarnLevel filter — WRN messages continued appearing despite the user selecting Error. Compare against the previous defaultLogLevelFromConfig instead. * test(logging): add RPC probe for log level filtering Add a dedicated emitTestLog JSON-RPC method and a focused e2e spec that verifies live TRACE/DEBUG/INFO/WARN/ERROR filtering against last.log. * chore(ui): update .gitignore to exclude screenshot.png file
JetKVM is a high-performance, open-source KVM over IP (Keyboard, Video, Mouse) solution designed for efficient remote management of computers, servers, and workstations. Whether you're dealing with boot failures, installing a new operating system, adjusting BIOS settings, or simply taking control of a machine from afar, JetKVM provides the tools to get it done effectively.
Features
- Ultra-low Latency - 1080p@60FPS video with 30-60ms latency using H.264 encoding. Smooth mouse and keyboard interaction for responsive remote control.
- Free & Optional Remote Access - Remote management via JetKVM Cloud using WebRTC.
- Optional Tailscale Networking - Built-in Tailscale status and control-server configuration, including custom Headscale-compatible endpoints.
- Open-source software - Written in Golang on Linux. Easily customizable through SSH access to the JetKVM device.
Contributing
We welcome contributions from the community! Whether it's improving the firmware, adding new features, or enhancing documentation, your input is valuable. We also have some rules and taboos here, so please read this page and our Code of Conduct carefully.
I need help
The best place to search for answers is our Documentation. If you can't find the answer there, check our Discord Server.
I want to report an issue
If you've found an issue and want to report it, please check our Issues page. Make sure the description contains information about the firmware version you're using, your platform, and a clear explanation of the steps to reproduce the issue.
Development
JetKVM is written in Go & TypeScript. with some bits and pieces written in C. An intermediate level of Go & TypeScript knowledge is recommended for comfortable programming.
The project contains two main parts, the backend software that runs on the KVM device and the frontend software that is served by the KVM device, and also the cloud.
For comprehensive development information, including setup, testing, debugging, and contribution guidelines, see DEVELOPMENT.md.
For quick device development, use the ./dev_deploy.sh script. It will build the frontend and backend and deploy them to the local KVM device. Run ./dev_deploy.sh --help for more information.
Backend
The backend is written in Go and is responsible for the KVM device management, the cloud API and the cloud web.
Frontend
The frontend is written in React and TypeScript and is served by the KVM device. It has three build targets: device, development and production. Development is used for development of the cloud version on your local machine, device is used for building the frontend for the KVM device and production is used for building the frontend for the cloud.