Memos 0.29 en municipios: notas, tareas y respaldo
Un caso técnico para registrar notas operativas con Memos: Markdown, visibilidad, tareas, API, backup y prueba de restauración.
Una minuta de guardia quedó escrita en un grupo y nadie pudo mostrar quién cerró la tarea. En una municipalidad chica del Gran Mendoza, ese hueco alcanza para perder una reparación, duplicar un pedido o discutir una inspección. Memos 0.29.1 permite armar una bitácora liviana con notas Markdown, visibilidad, tareas y API. Este caso muestra qué instalar, cómo separar permisos y cómo probar respaldo.
Dónde aparece la nota perdida
La versión 0.29.1 de Memos fue publicada el 5 de junio de 2026. El release corrigió el diseño de listas de tareas, mejoró vistas previas de enlaces y ajustó miniaturas de video en móviles. Para una cuadrilla, esas correcciones importan porque muchas notas nacen desde teléfono, con enlace, foto o tarea de seguimiento. El antagonista es el chat operativo sin cierre. La camioneta municipal vuelve con una orden marcada en lapicera, una foto de cuneta y tres mensajes de audio. Si la nota queda mezclada con saludos y urgencias, el área técnica no puede saber qué se hizo, qué falta y quién tomó la decisión. El repositorio de Memos describe la herramienta como un sistema de notas autoalojado, basado en Markdown y pensado para captura rápida. GitHub informó en su Octoverse 2025 que más de 36 millones de desarrolladores se sumaron en un año y qué se crearon más de 230 repositorios por minuto. Esa escala explica por qué conviene elegir proyectos con releases, documentación y comunidad visibles.
Cómo funciona por dentro
El flujo empieza con una nota. Mesa de entrada o guardia crea memo con fecha, área, etiqueta y tarea. El responsable agrega foto, enlace o archivo. Un coordinador cambia visibilidad si debe verla otra área. El IT manager revisa usuarios, permisos, API y respaldo. El tablero se consulta por etiqueta, fecha o texto. Memos recibe texto Markdown, etiquetas, tareas, adjuntos, usuarios y eventos de API. Entrega una línea de tiempo, búsqueda, notas públicas o privadas, RSS, webhooks y API REST o gRPC. La documentación oficial organiza instalación, configuración, administración, uso, integraciones y operaciones. Para producción, la base puede ser SQLite en casos simples o PostgreSQL cuando hay usuarios concurrentes. Los permisos deben copiar la rutina real. Guardia carga notas. Obras Públicas edita sus tareas. Hacienda solo lee compras. Sistemas administra usuarios, base, adjuntos y copias. Una nota pública sirve para comunicar un corte o aviso; una privada sirve para seguimiento interno. El primer usuario debe quedar documentado como administrador y la creación abierta de cuentas se cierra después del alta inicial. Los adjuntos viven separados del texto. PostgreSQL guarda usuarios, notas, etiquetas, visibilidad y eventos. El volumen persistente guarda imágenes, videos o documentos. El backup toma base y volumen en la misma ventana horaria. Si solo se copia la base, una inspección puede conservar texto y perder la foto.
Qué se instala o configura primero
La pila inicial usa Memos 0.29.1, PostgreSQL 17, volumen persistente, HTTPS, roles de área, exportación por API y backup diario. El primer entregable verificable es una bitácora de guardia con diez notas, tres tareas, dos adjuntos, visibilidad separada, búsqueda por etiqueta y restauración en otro servidor. Con dólar oficial vendedor de referencia a ARS 1.470, un servidor de USD 12 a 25 mensuales queda entre ARS 17.640 y ARS 36.750. El piloto demanda 12 a 22 horas: instalación, usuarios, etiquetas, plantillas de nota, permisos, carga de ejemplo, API de exportación, backup y restauración. UMSA puede aplicar el caso en municipios, cooperativas, escuelas técnicas o cámaras con muchas tareas chicas y poca tolerancia al olvido. El alcance inicial conviene limitarlo a guardia, obras menores o reclamos internos. Si entra todo el municipio el primer día, nadie aprende qué campo sostiene la evidencia.
Dónde se rompe y cómo probarlo
El primer riesgo es usar etiquetas libres sin convención. La señal aparece cuando una misma área queda escrita con tres nombres distintos. La prueba carga diez notas y exige lista cerrada para área, prioridad y estado. El segundo riesgo es publicar una nota privada. La señal aparece cuando una URL pública muestra datos internos. La prueba crea usuarios con lectura distinta y abre la misma nota desde una sesión sin permiso. El tercer riesgo es perder adjuntos. La señal aparece cuando la nota abre, pero la foto de obra devuelve error. La prueba restaura base y volumen en otro host y abre nota, tarea, usuario, archivo y etiqueta. El cuarto riesgo es usar la API sin registro. La señal aparece cuando un script exporta notas y nadie sabe con qué token. La prueba crea token de servicio, exporta diez notas, revoca el token y verifica que el acceso corte. El quinto riesgo es cambiar de versión sin lectura de release. La página de release 0.29.1 muestra correcciones concretas en tareas, enlaces y video móvil. La prueba de preproducción revisa login, carga, búsqueda, adjunto, tarea y exportación antes de actualizar. Una bitácora sirve si una persona nueva puede abrir una tarea y ver decisión, fecha, archivo y responsable. El resto es conversación acumulada.
Para seguir leyendo
Para avanzar
Ver también
Continuá hacia capacidades técnicas, sectores o notas relacionadas.