velxio/backend/app
David Montero Crespo b7a191eaab feat(pi): techo de capacidad para los guests QEMU (multiusuario)
Cada guest es un proceso QEMU con su propia RAM (1-2 GB segun placa) y
sus hilos de vCPU, asi que el limite lo pone la maquina, no el codigo.
No habia ningun tope: el usuario N simplemente empujaba la caja a swap y
la sesion de TODOS se volvia lenta, que es peor que decirle al usuario N
que espere un minuto.

  VELXIO_PI_MAX_INSTANCES   (6)  guests simultaneos en la maquina
  VELXIO_PI_MAX_PER_OWNER   (2)  guests por persona

El "owner" es el hash de la cookie de sesion: sirve solo para contar, no
se guarda ni se lee de vuelta, y cae al host del cliente cuando no hay
cookie (sidecar de escritorio, tests). Sin identidad solo aplica el tope
global.

El rechazo llega como un mensaje que dice que hacer ("prueba en un
minuto" / "para una de tus sesiones"), no como un fallo mudo, y se
comprueba ANTES de lanzar el proceso.
2026-07-29 21:15:04 +02:00
..
api feat(pi): techo de capacidad para los guests QEMU (multiusuario) 2026-07-29 21:15:04 +02:00
core feat(opencore): extract Pico W WiFi to a pluggable PIO peripheral seam 2026-06-15 08:33:28 +02:00
database
mcp
models
schemas
services feat(pi): techo de capacidad para los guests QEMU (multiusuario) 2026-07-29 21:15:04 +02:00
utils
__init__.py
main.py feat(flash): write compiled sketches to real USB boards (phases D1+D3) 2026-05-27 00:20:20 -03:00