Tuxee: persistent terminals and a file manager in your browser, in a Proxmox LXC
Tuxee is a very small web interface for a Linux machine: a file manager and terminals that keep running after you close the tab. It was made so AI agents have somewhere comfortable to work, but it is just as useful for plain server admin from a laptop, a tablet or a phone.
We ran it in a Proxmox LXC container on 2026-11-08 (Tuxee 1.2.1, Debian 13). The numbers below are our own measurements. The project says itself that it is a prototype and not a production release, so read the security section before you expose it anywhere.
What Tuxee is and is not
It is one Go program with the whole web interface built in. You sign in with a real Linux user name and password (it uses PAM), then you get a desktop of windows: file managers and terminals, in tabs, that you can drag, resize and snap to a grid. Terminals are retained, so a long job keeps running when you log out and you find it again when you come back.
It is not an agent and it does not talk to any AI model. Agents such as aider, OpenCode or Codex CLI are ordinary programs that you start inside a Tuxee terminal. That is the idea: Tuxee is the desk, the agent is the worker.
Licence: MIT (we checked the LICENSE file in the repository). Source: github.com/agent0ai/tuxee.
Step 1: create a small LXC container
Tuxee itself is tiny, so the container can be too. We used 2 cores, 1 GB of RAM and an 8 GB disk, unprivileged, Debian 13 template. See the commands below.
Give it more RAM only if you plan to install coding agents in it. Installing Node packages and aider with pip is what needs memory, not Tuxee. We raised ours to 3 GB while installing the agents.
No GPU and no privileged mode are needed. If you want a local AI model, run it in another container and call it over the network (see the guide on local coding agents).
The official installer is a short shell script. We downloaded it and read it before running it: it finds the latest release on GitHub, downloads the binary, checks the sha256 and puts it in /usr/local/bin. It does not start anything on its own.
Then create a normal user to sign in with, install the systemd service and start it. Tuxee listens on HTTP port 80 and HTTPS port 443 by default.
Use a normal user instead of root for daily work. Root sign-in works too, but then every command from the browser runs as root.
Install and start
curl -fsSL https://tuxee.agent-zero.ai/install.sh -o install.sh
less install.sh # read it first
sh install.sh
useradd -m -s /bin/bash dev && passwd dev
tuxee service install
tuxee service start
tuxee status
What it looks like
Open https://<container-ip> in your browser. The certificate is self-signed, so the browser warns once. Sign in with the Linux user you created.
You get a file browser and a terminal side by side. The top bar shows CPU, RAM, disk and network of the machine. Drag a file from your computer onto the page to upload it, or onto a terminal to drop its path in. You can also run graphical programs from a terminal and they appear inside the page, but we did not test that.
What it cost us (measured 2026-11-08)
Binary: about 26 MB on disk.
Memory: the Tuxee process used about 21 MB right after start and about 50 MB with a browser attached. The whole container showed about 53 MB of used memory when idle, and the page's own top bar read 62 to 67 MB while we worked.
CPU: around 7 percent of one core while a browser was connected and a terminal was open, near zero when idle.
Disk: the 8 GB disk was 28 percent used after Node, git, pipx and Tuxee. Coding agents added about 2 GB more (npm packages 1.3 GB, aider 0.7 GB).
Docker image, from the project's own README: about 60 MB. We ran it natively in the LXC, not with Docker.
Security: read this before you open it up
Anyone who can sign in gets a real shell on that container. Treat it like SSH with a web page on top.
Keep it on your LAN, or put it behind Tailscale or a VPN. Do not forward port 443 from the internet.
Use a long password and a normal user. Passwords are checked with PAM, so there is no Tuxee-specific second factor in what we tested.
The project calls itself a built and locally validated prototype. Run it in its own container with nothing valuable inside, and do not mount your other containers' data into it.
Sessions end when the Tuxee service restarts, but retained terminals and the programs in them keep running. That is useful and it is also something to remember.
Limits and gotchas
Tuxee is not a remote desktop. It is files and terminals, plus the occasional GUI program.
Some code editors and TUI programs behave differently in a browser terminal than in a normal one. Test the tools you rely on.
A mobile keyboard is awkward for a terminal. It works for checking on a job, not for typing a lot.
Our install was native, not Docker. The Docker image is the project's recommended route and keeps data in three volumes (server state, /root and /init), but we have not run it ourselves.
Next
With Tuxee running, the obvious use is to put a coding agent in it and point that agent at a local model. We tested aider, OpenCode and Codex CLI against gpt-oss:20b running on an RTX 3090 in another container. The results, including where it fails, are in the guide on local coding agents.