PequeRoku - Self-Hosted Replit Alternative with Real QEMU VMs

Replit is brilliant until you hit the sandbox wall — no KVM, no custom kernel modules, no persistent processes between sessions.

GitHub Codespaces is comfortable until the bill arrives.

PequeRoku was built to solve both: a fully self-hosted cloud IDE where each user gets a real, persistent virtual machine they can install anything on, accessible from any browser.

What is PequeRoku?

PequeRoku is an open-source platform for self-hosting cloud development environments. It provisions one persistent QEMU/KVM virtual machine per user — not a container, not a sandbox — and wraps it in a polished web UI: Monaco editor, multiple terminal tabs via Xterm.js, a file tree, CPU and memory charts, and an integrated AI assistant.

“Your own self-hosted Replit. Real VMs, always on, full root access, accessible from any device.”

PequeRoku Source Code on GitHub PequeRoku Wiki

Why self-hosters choose PequeRoku

• 💻 Real VMs — QEMU/KVM instances, not Docker sandboxes — install any package, run any process, load any kernel module
• 🔒 Full root access — the VM is yours; no capability restrictions or seccomp profiles
• 🔄 Always-on — VMs persist between sessions; pick up exactly where you left off
• ✏️ Monaco editor — the same editor engine that powers VS Code, in your browser
• 🖥️ Multiple terminals — open as many Xterm.js terminal tabs as you need, all bridged to your VM via SSH
• 📊 Live metrics — real-time CPU, memory, and thread charts pulled from the VM
• 🤖 AI assistant — OpenAI-compatible chat with memory, web search, and per-user daily quotas
• 👥 Multi-user — invite multiple developers, each with their own VM and resource quota
• ⚖️ MIT licensed — truly free, no per-seat fees

PequeRoku Tech Overview

PequeRoku is a four-service application: a Django web backend, a FastAPI VM microservice, a React SPA frontend, and Nginx tying them together — all backed by PostgreSQL and Redis.

How the VM magic works

The VM service (vm_service/) owns the QEMU lifecycle. When a user creates a container:

1. A copy-on-write qcow2 disk overlay is created from a shared Debian 12 golden image — no full copy, just the diff.
2. A cloud-init seed ISO is generated with the user’s SSH public key injected.
3. QEMU starts the VM with KVM acceleration, virtio networking, and the cloud-init drive attached.
4. The service polls the VM’s SSH port until boot completes (up to 10 minutes by default).

Once running, all terminal I/O and file operations flow through Paramiko SSH connections — the web service bridges them to the browser over WebSocket. The VM never needs to be publicly reachable; only the Nginx proxy port matters.

Architecture at a glance

Browser
    │
    ▼
Nginx (port 80)
    ├── /            → static landing page
    ├── /dashboard/  → React 19 SPA (Monaco + Xterm.js)
    ├── /api/        → Django REST API
    └── /ws/         → Django Channels WebSockets

Django web service
    ├── REST: users, containers, quotas, config, AI logs
    ├── WS /ws/fs/   → file read/write (SSH bridge)
    ├── WS /ws/containers/ → terminal I/O (SSH → Xterm.js)
    └── WS /ws/ai/   → AI assistant (streaming)

FastAPI VM service
    ├── QEMU VM lifecycle (create/start/stop/delete)
    ├── SSH bridge via Paramiko
    └── Redis ← VM catalog (state survives restarts)

PostgreSQL 16 ← all relational data
Redis 7 ← Channels layer, sessions, VM state

Stack summary

Self-Hosting PequeRoku with Docker

Before starting, you need two things that are not in the compose file:

1. A QEMU base image — a Debian 12 qcow2 file placed at source/vm_data/debian12-golden.qcow2. You can create one with virt-install or download a cloud image and convert it.
2. A dedicated SSH key pair for VM access (ssh-keygen -t ed25519 -f ~/.ssh/id_vm_pequeroku -N ""). The public key gets injected via cloud-init; the private key is mounted into the VM service container.

Once you have those, create the two .env files and launch:

git clone https://github.com/HectorPulido/pequeroku
cd pequeroku/source

# Create env files from templates
cp web_service/.env.template web_service/.env
cp vm_service/.env.template vm_service/.env

Edit web_service/.env at minimum:

SECRET_KEY=replace_with_a_long_random_string
DJANGO_SUPERUSER_USERNAME=admin
DJANGO_SUPERUSER_EMAIL=[email protected]
DJANGO_SUPERUSER_PASSWORD=change_this_password

DB_NAME=mydb
DB_USER=myuser
DB_PASSWORD=change_this_too

REDIS_URL=redis://redis:6379/1
ALLOWED_HOSTS=localhost,127.0.0.1,your-server-ip
DEBUG=false

Edit vm_service/.env:

VM_SSH_USER=root
VM_SSH_PRIVKEY=/root/.ssh/id_rsa
VM_QEMU_BIN=/usr/bin/qemu-system-x86_64
VM_BASE_IMAGE=/app/vm_data/debian12-golden.qcow2
VM_TIMEOUT_BOOT_S=600
REDIS_URL=redis://redis:6379/1
NODE_NAME=local-node
AUTH_TOKEN=change_this_auth_token

Then start everything:

docker compose up -d

Open http://your-server-ip — the landing page loads immediately. Log into the dashboard at /dashboard/ with the admin credentials you set.

Services explained

All VM disk images are stored in ./vm_data/ on the host — back this directory up if you care about user data.

cd source
docker compose -f docker-compose-node-only.yaml up -d

What to do after install

1. Set up a VM type — go to Django admin → Container Types. Define vCPU count, memory (MB), and disk (GiB) for each tier you want to offer.

2. Create users — admin → Users. Each user gets their own VM instance within the quota you assign.

3. Create a container — from the dashboard, click “New Container”, pick a type. PequeRoku boots the VM (takes a minute or two on first boot while cloud-init runs), then shows it as ready.

4. Open the IDE — click the container card. You get the file tree, editor, and terminal instantly. Open a terminal tab, run apt install anything — you have full root.

5. Configure AI — set the AI_* config keys in the admin panel if you want the AI assistant enabled for users.

Conclusion

PequeRoku occupies a unique space: it is genuinely closer to Replit than any other self-hosted project in this category, because it uses real KVM-accelerated VMs rather than Docker containers. That means no capability restrictions, no sandbox escape concerns, and no “why can’t I load this kernel module” frustration.

The cost is setup complexity — you need a QEMU base image and an SSH key before anything works, and the host must support KVM virtualisation. But for a homelab with a beefy server or a team that wants permanent cloud dev environments without a SaaS bill, it is a compelling option.

Alternatives worth comparing:

• Coder — enterprise-grade self-hosted dev environments; Kubernetes/Docker-based, much more configuration
• code-server — VS Code in the browser, single user, no VM management layer
• Gitpod — open-core; self-hosting exists but requires Kubernetes
• Replit — the original; excellent UX, cloud-only, sandboxed, per-seat pricing