Systems · 2026
Sutradhar — every app on one laptop, on and off, from anywhere
One page for everything that uses my laptop as its brain: running or not, since when, what it costs, what its timers will do next, and the few buttons each app allows. From the machine, from my tailnet, and from a phone through this site.
Several things I have built run on the same laptop as long-lived services — a WhatsApp assistant for a club, another for me, a node in a lab's calculation cluster, a local language model. I wanted to switch them on and off from my phone and see what each was costing me in memory and GPU. That was the whole brief, and it started as a script inside my personal workspace; it became a project on the afternoon it turned out to have a security boundary.
Sūtradhāra is the stage manager of Sanskrit drama, the one who holds the strings. He starts and stops the play and knows every player's state.
Nothing calls the laptop
A daemon on the laptop serves a page locally and on my tailnet. For the phone, there is a small PHP half on this site that holds the laptop's last snapshot and a queue of commands; the laptop polls it every two seconds while someone is watching the page and every twenty otherwise. Shared hosting cannot keep a process alive and my laptop has no public address, so this is the only shape that works — and it is the same shape my personal assistant uses to fall back to when WhatsApp is unavailable, which is why the two share a pattern.
An app is a bundle of systemd units named in a registry file, and "off" stops all of them. Readings come from the cgroup rather than from a process id, so an app that forks is counted whole. Each project carries a short file saying how it registers, and the registry can also describe switches — a command that reads an app's toggles as JSON and a command that sets one — so a flag deep in another project's config becomes a toggle on the board without that project knowing about the board.
The page
The first page was one scroll of cards showing everything at once, and it was neither intuitive nor navigable. The second is three columns, desktop first, because the laptop turned out to be where I actually use it. A board on the left: one row per app, its state, one reading, and the switch. The selected app in the middle: its toggles, its buttons, each result appearing under the button that asked for it. Everything asked of the laptop on the right, newest first, and the shell. One sentence in the header answers the glance question — "Nothing is wrong." or "Setu has failed."
The one dangerous button
The shell is the only thing on the page that can do arbitrary harm, and it is treated accordingly. From the site it needs the admin login and a PIN, and the command is sealed in the browser to the laptop's public key, so the site's database only ever holds ciphertext with nothing to guess against. The laptop counts wrong PINs and locks at five until reset at the keyboard. On the local machine it needs no PIN at all.
It was tested end to end in a real browser on all three surfaces, driven over the DevTools protocol through the site's own login form, exercising every command kind and every error path. That found four bugs on the first day, none of them visible in a diff: a sealed command given a second id after sealing, so the laptop refused every one; the site's copy of the page drifting from the local one; "on at boot" also starting the app; and two PIN checks racing to count one wrong answer twice. It also found a fifth bug that was not this project's — a lab node that died on start — and reported it correctly, which is the first useful thing a monitor can do.