--- title: "Build your own cyberdeck on KyberLinux in a weekend" url: "https://kyberdeck.com/blog/build-your-own-cyberdeck" description: "A weekend plan for a cyberdeck that is yours down to the microphone. The SDKs are not released yet, so the commands are illustrative; the habits are not." --- # Build your own cyberdeck on KyberLinux in a weekend October 8, 2026·4 min read·Editorial team The parts of an unassembled pocket deck laid out in neat rows: shell halves, circuit board, battery, keyboard, screen and screws There is a single-board computer in your drawer, a small screen left over from another project, a USB microphone and a thumb keyboard from a kit. On Saturday morning you decide to build a pocket computer that listens to you and answers. By Sunday night you have a lovely printed case, a general-purpose distribution with hundreds of packages you did not choose, and a script that sends every word you say to someone else’s model, with an API key pasted into a text file. The deck looks like yours. The intelligence inside it is rented, by the word. ## The real cause: the case gets the weekend, the brain gets an hour Cyberdeck builds are judged by what photographs well: the hinge, the screen, the keyboard. The software is whatever boots, and the assistant is whatever API answers. The result is a beautiful body around somebody else’s brain — exactly the arrangement a home-built device was supposed to escape. ## Where weekend decks go wrong **The brain is rented.** A cloud model behind an API key means every sentence leaves the device, is billed by volume and depends on an account somebody else can close. **The microphone is a setting.** A USB microphone that is always powered, muted in software, is a phone’s privacy model in a nicer case. **A general-purpose base.** A full desktop distribution brings services you never asked for, updates that can break the build, and no verified boot. [KyberLinux on hardware you already own](https://kyberlinux.com/blog/kyberlinux-on-hardware-you-own) makes the case for the alternative. **Power and heat arrive last.** The battery is chosen to fit the case, and the board throttles the first time a model runs for more than a minute. **Nothing remembers.** Each session starts cold, and the only memory is a chat history kept by the provider. ## The weekend plan, once the SDKs ship The honest part first. **Neither KyberDeck SDK is released.** The commands below show the shape we intend them to take; today they do nothing, and there is nothing to download. The boards we name are a plan, not a compatibility claim, and every figure on [the homepage](https://kyberdeck.com/) is a design target, not a measurement. What follows is the plan we are building towards — and most of its habits you can practise now. **Saturday morning: pick a path.** Two routes, depending on the board. - _Microcontroller path._ An ESP32-S3-class board with a microphone, a small screen and a button. It listens and shows; KyberBot itself runs on a Node or a Pocket nearby. - _Linux path._ A single-board computer — a Raspberry Pi 5 or an RK3588 board — or an x86 mini PC. KyberLinux goes on the device, and the full KyberBot runs there, small models included. ``` # illustrative: not a released CLI, does nothing today kyber sdk init --target esp32-s3 # microcontroller path kyber install --profile deck # Linux path ``` **Saturday afternoon: cut the microphone in hardware.** Run the microphone’s power through a physical switch, and put the indicator LED on that same line instead of under software control. This step needs no SDK at all, and it is the one that matters most. With the switch off, the deck is deaf, not politely ignoring you. **Saturday evening: measure power before you choose a battery.** Put a USB power meter between the supply and the board, and note the draw at idle and while a small model is running. Choose the battery and the cooling from those numbers, not from the shape of the case. **Sunday morning: give it your identity.** On the Linux path the deck joins your KyberBot under the same identity as your other devices, so it becomes one more body for the same assistant rather than a new assistant with its own login. The idea behind that is [one assistant, many bodies](https://kyberbot.com/blog/one-assistant-many-bodies). ``` # illustrative kyber whoami # the same identity on every form you own kyber mute --hard # confirms the circuit, not a setting kyber offline # capture and context keep working without a link ``` **Sunday afternoon: the case.** Last, not first. By now you know how much heat leaves the board, where the switch has to sit so you can find it without looking, and how big the battery really is. The habits that make KyberLinux pleasant on a small screen are in [keyboard-first and opinionated](https://kyberlinux.com/blog/keyboard-first-and-opinionated). When the SDKs ship, a bricked board or a voided warranty will be yours, and so will everything you build. If you would rather wait for a ready-made one, the [five forms](https://kyberdeck.com/blog/five-forms-of-kyberdeck) are where to start. ## A test you can run today You do not need our SDK to find out whether the board in your drawer is a good start. Boot whatever Linux it has and run: ``` arecord -l # which capture devices exist fuser -v /dev/snd/* # which processes hold the sound devices right now ``` (If either command is missing, it comes from the `alsa-utils` or `psmisc` package.) Then pull the network cable or switch off Wi-Fi, and try the thing you would want your deck to do: dictate a note, find something in your own files. Everything that stopped working is a part of your future deck that currently lives somewhere else. Write that list down. It is your build plan. - cyberdeck - DIY - KyberLinux - SDK ## Keep reading - [A robot is a deck with wheels](https://kyberdeck.com/blog/a-robot-is-a-deck-with-wheels) - [Buy it or build it: the five forms of KyberDeck](https://kyberdeck.com/blog/five-forms-of-kyberdeck)