Guardar una API key “solo un momento” en un bloc de notas, reenviar un token por un chat interno o dejar una contraseña en un documento compartido es una de esas costumbres que muchas empresas y equipos pequeños arrastran… hasta que el susto llega. En un mundo donde cada servicio —desde la nube hasta herramientas de analítica o IA— exige credenciales, el problema ya no es únicamente “tener contraseñas”, sino gestionar secretos: claves de API, tokens de acceso, certificados, variables sensibles y credenciales de inicio de sesión que, si se filtran, pueden abrir la puerta a accesos no autorizados y costes imprevisibles.
En ese contexto aparece Keyper, un proyecto open source que se presenta como gestor de credenciales autoalojado y que busca ocupar un hueco muy concreto: permitir que cada organización guarde y ordene sus secretos con una arquitectura de cifrado en el cliente (en el navegador) y un enfoque de “zero-knowledge” —es decir, que el servidor o la base de datos no deberían poder leer el contenido—, apoyándose en Supabase como backend. El repositorio se distribuye bajo licencia Apache 2.0 y cuenta con una versión publicada como paquete en npm, con instalador y arranque rápido.
Un gestor pensado para credenciales modernas, no solo para “passwords”
Keyper no se limita al esquema clásico de “usuario y contraseña”. Su propuesta incluye el almacenamiento y organización de:
- API keys para servicios cloud, plataformas de desarrollo o integraciones.
- Credenciales de acceso (usuario/contraseña).
- Secretos de configuración (valores sensibles usados por aplicaciones).
- Tokens (por ejemplo, de autenticación y acceso).
- Certificados y claves asociadas (como material TLS).
A nivel de “vida real”, este enfoque encaja con cómo trabajan hoy muchos equipos: entornos con múltiples microservicios, automatizaciones, CI/CD, proveedores SaaS, y una colección creciente de credenciales que caducan, rotan o cambian de propietario interno.
“Zero-knowledge” en la práctica: qué promete y qué implica
La etiqueta “zero-knowledge” se ha popularizado, pero en Keyper se concreta en una idea muy específica: el cifrado ocurre en el cliente, no en el servidor. Según su documentación, los datos se cifran con AES-256-GCM y la clave maestra se deriva con Argon2id (con alternativa PBKDF2 como compatibilidad), buscando dificultar ataques de fuerza bruta y elevar el listón criptográfico.
Además, el proyecto incluye una protección práctica para el día a día: un auto-bloqueo tras 15 minutos de inactividad (con detección de actividad), una medida orientada a reducir el riesgo de dejar la bóveda abierta en un equipo compartido o en una sesión olvidada.
Ahora bien, el “zero-knowledge” no es magia: depende de cómo se gestione la clave maestra, de la higiene del dispositivo (malware, extensiones, keyloggers), de la configuración de la base de datos y del modelo de amenazas de cada organización. La ventaja es clara —la base de datos no guarda secretos en claro—, pero el usuario sigue siendo parte crítica del sistema.
Multiusuario y aislamiento en base de datos: el papel de Supabase y RLS
Keyper se apoya en Supabase (PostgreSQL + Auth) y utiliza Row Level Security (RLS), una capa de control de acceso a nivel de filas dentro de la propia base de datos. La idea es que, incluso compartiendo instancia, cada usuario vea solo su “bóveda”. En su documentación se insiste también en buenas prácticas operativas, como refrescar el entorno al cambiar de usuario para evitar conflictos de estado criptográfico.
Esta combinación —cifrado en cliente + aislamiento en base de datos— apunta a un escenario habitual: equipos que necesitan compartir la herramienta, pero quieren que el acceso y la separación de datos estén bien delimitados.
Recuperación “de emergencia”: reset sin “puertas traseras” de administrador
Uno de los puntos más delicados en cualquier gestor de secretos es el eterno dilema: si se pierde la clave maestra, ¿qué ocurre? Keyper presume de un enfoque en el que el usuario puede gestionar un reset de passphrase mediante un sistema basado en bcrypt, y declara que no hay “backdoors” administrativas para recuperar el contenido cifrado. En paralelo, mantiene compatibilidad con un sistema anterior de claves (DEK) para usuarios existentes, indicando una transición de modelo sin romper bóvedas antiguas.
En la práctica, esto significa que la herramienta intenta equilibrar dos exigencias difíciles de conciliar: seguridad criptográfica y recuperación operativa. La letra pequeña, como siempre, está en el proceso: quién puede tocar la base de datos, qué controles hay en Supabase y cómo se protegen las credenciales del propio proyecto.
Instalación rápida y experiencia “app”: CLI + PWA
Keyper apuesta por un despliegue directo: basta con Node.js 18+ y una cuenta de Supabase (su documentación menciona que el plan gratuito puede servir). Para arrancar, propone un flujo simple con npm: instalación global y ejecución en un puerto por defecto 4173, con opción de cambiarlo (por ejemplo, 3000).
La configuración inicial pasa por conectar la instancia a Supabase usando la URL del proyecto y la anon/public key (insiste en no usar la service_role key) y ejecutar un script SQL de creación de tablas y políticas.
En paralelo, Keyper se presenta como Progressive Web App (PWA), lo que permite instalarlo “como app” en escritorio o móvil desde el navegador, con una experiencia más cercana a un cliente nativo.
Un “demo” que no guarda tus secretos… pero sí exige criterio
Keyper ofrece un demo alojado donde el usuario introduce sus propias credenciales de Supabase para probar el producto. El proyecto afirma que el cifrado sigue ocurriendo en el navegador y que, en ese escenario, las credenciales de Supabase se almacenan en el navegador (localStorage) y no se envían a servidores del demo. Es un enfoque práctico para evaluar la herramienta, aunque implica una recomendación evidente: probar con una instancia controlada y con claves y permisos ajustados, no con credenciales sensibles de producción.
La lectura de fondo: por qué este tipo de herramientas gana tracción
Keyper no aparece en el vacío. Es parte de una corriente más amplia: equipos que prefieren autoalojar componentes críticos (incluidos secretos) para mantener control, trazabilidad y autonomía. La promesa es atractiva: cifrado robusto, arquitectura auditable, control del dato y una base de datos bajo la administración del propio equipo.
A la vez, ese enfoque trae una responsabilidad inevitable: parches, copias de seguridad, control de accesos a Supabase, gestión de llaves y procedimientos internos. En otras palabras: autoalojar no es solo instalar; es operar.
Keyper intenta simplificar esa operación con una puesta en marcha rápida, una interfaz moderna (React + TypeScript) y un planteamiento de seguridad que, sobre el papel, se alinea con lo que hoy se espera de una bóveda de secretos: cifrado autenticado, derivación de clave resistente, aislamiento multiusuario y mecanismos de bloqueo y recuperación.
Preguntas frecuentes
¿Cómo montar un gestor de credenciales autoalojado con Supabase para guardar API keys y tokens?
La vía habitual con Keyper es desplegar la aplicación, crear un proyecto en Supabase, configurar URL + anon/public key, ejecutar el script SQL de tablas/políticas y empezar a cifrar los secretos desde el navegador.
¿Qué diferencia hay entre un password manager y un gestor de secretos para equipos de desarrollo?
Un password manager se centra en accesos de usuarios; un gestor de secretos incorpora API keys, tokens, certificados y valores de configuración que suelen alimentar servicios, pipelines y despliegues. En Keyper, la organización por categorías, etiquetas, prioridades y expiración apunta justo a ese uso.
¿Qué significa “zero-knowledge” en un gestor de credenciales y qué límites tiene?
En este enfoque, el servidor almacena datos cifrados y el descifrado sucede en el cliente. El límite práctico suele estar en el endpoint (tu navegador/dispositivo) y en la gestión de la clave maestra: si el equipo está comprometido, el cifrado no salva la sesión.
¿Es recomendable usar un demo para gestionar secretos sensibles de producción?
Para pruebas de interfaz y flujo, sí; para secretos críticos, lo prudente es usar una instancia propia y credenciales de Supabase con permisos mínimos, evitando exponer claves de alto impacto fuera de un entorno controlado.
