Construyo sistemas que se mantienen solos. Me interesan los servidores pequeños, la automatización que no necesita que estés mirando, y el código que alguien más pueda auditar.
- Servidores domésticos que no gastan nada. El proyecto del que más presumo es ezarr-stack: un servidor completo de medios y *arr corriendo dentro de un teléfono Android muerto. Chroot sobre TWRP, sin Docker y sin systemd, 7 GB de RAM, consumo eléctrico ridículo.
- Software de escritorio. Syncify es una app Tauri (Rust + Vue) para tener tu música en máxima calidad y bajo tu control: importar, migrar y descargar tu catálogo desde Qobuz, Tidal, Spotify, Deezer y SoundCloud.
- Auditoría automática. Improvement revisa un repositorio y repara lo que encuentra, con hallazgos verificados contra tus propias pruebas en vez de suposiciones.
| ezarr-stack | Servidor de medios y *arr en Android con chroot. Instalable en un solo comando. |
| Syncify | Gestor de música FLAC en Rust + Vue + Tauri. |
| Improvement | Auditoría y reparación de repositorios con agentes locales. |
| oci-a1-capacity | Instancia OCI Always Free que se recupera sola. |
| RehabWeb · API | Proyecto de tesis: fisioterapia en web (Django + TypeScript). |
Un par de reglas que se notan en el código:
- Nada de estado oculto. Los servicios se manejan con scripts explícitos, no con un supervisor que nadie puede inspeccionar cuando algo falla a las 3 de la mañana.
- Un fallo se avisa solo. Si el servidor está caído, me entero por el móvil, no por un cliente quejándose.
- El plan de recuperación se escribe antes de necesitarlo. Cada proyecto tiene un runbook con el triaje paso a paso.
El Poco X3 Pro que hace de servidor murió de muerte súbita, un fallo conocido de ese modelo: ya no arranca el sistema operativo. Lo que sí arranca es el recovery, y ahí vive todo el stack. No es un experimento de laboratorio: sirve medios y gestiona descargas a diario, con respaldos cifrados fuera del dispositivo.
La lección no es que los teléfonos sean mejores servidores. Es que un teléfono que ya no da boot puede seguir siendo un servidor, con el suficiente cuidado — y que el plan de recuperación se escribe antes de necesitarlo, no después.
Trabajo en sistemas, open source y automatización. Si tienes un proyecto donde importe que las cosas se reparen solas, escríbeme.