#Instalación Odoo Local

Informe ejecutivo de factibilidad para instalar, operar e integrar Odoo Enterprise 19.0 en infraestructura local.

Informe ejecutivo de factibilidad

Instalación local, operación e integración de Odoo Enterprise 19.0 en Codimat

Versión: 0.4 — borrador para entrega Fecha: 20 de agosto de 2026 Conclusión: viable con condiciones

Resumen ejecutivo

La instalación de Odoo Enterprise 19.0 en infraestructura local de Codimat es técnicamente viable, siempre que se cumplan las condiciones de infraestructura, seguridad, operación, licenciamiento y gobierno indicadas en este informe.

También es viable integrar Odoo con el sistema externo utilizado por Codimat para procesos operativos y financieros. La integración deberá validarse mediante un relevamiento funcional y técnico y, antes de su implementación definitiva, mediante una prueba de concepto.

La recomendación es avanzar en cuatro etapas:

1. Relevamiento de infraestructura, usuarios, procesos e integración.
2. Diseño y dimensionamiento de la solución.
3. Prueba de instalación, respaldo, recuperación e integración.
4. Implementación controlada, homologación y salida a producción.

No se recomienda iniciar la instalación productiva hasta completar el relevamiento, confirmar las licencias y aprobar la arquitectura.

1. Contexto

Codimat solicitó evaluar:

1. Las implicancias técnicas de instalar Odoo Enterprise 19.0 en infraestructura local.
2. La forma de trabajo entre el área técnica de Codimat y nuestra empresa.
3. Los mecanismos para controlar, supervisar y eventualmente intervenir en desarrollos.
4. La integración de Odoo con un sistema externo de gestión operativa y financiera.

Este documento presenta una factibilidad preliminar y las condiciones necesarias para tomar una decisión definitiva.

2. Objetivo

Determinar si Codimat puede instalar, operar, mantener e integrar Odoo Enterprise 19.0 en infraestructura propia de manera segura, controlada y sostenible.

3. Alcance

Incluye

• Arquitectura y requerimientos técnicos.
• Ambientes de desarrollo, homologación y producción.
• Seguridad, backups, monitoreo y continuidad.
• Integración con sistemas externos.
• Gobierno del desarrollo y control de cambios.
• Roles, tareas y tipos de asistencia.

No incluye

• Instalación o migración efectiva.
• Desarrollo final de la integración.
• Presupuesto y cronograma contractual.
• SLA definitivo.
• Dimensionamiento final sin métricas reales.

4. Condiciones para la factibilidad

La implementación será factible si Codimat y nuestra empresa acuerdan y verifican:

• Infraestructura Linux compatible con Odoo 19.
• Licencia Odoo Enterprise y plan apto para instalación local e integración.
• Ambientes separados de desarrollo, homologación y producción.
• PostgreSQL, almacenamiento y red dimensionados para la carga real.
• HTTPS/TLS, DNS, proxy reverso y correo correctamente configurados.
• Backups automatizados y restauraciones probadas.
• Monitoreo, logs y alertas.
• Accesos nominados, mínimo privilegio y protección de credenciales.
• Repositorio Git, revisión de código y despliegues controlados.
• Responsables técnicos y funcionales de ambas empresas.
• Documentación y ambiente de prueba del sistema externo.

5. Arquitectura e infraestructura

5.1 Stack tecnológico de referencia

La solución deberá contemplar, como mínimo:

Como ejemplo técnico puede consultarse el script comunitario de instalación de Yenthe Van Ginneken. El script muestra la orquestación habitual de usuario de sistema, dependencias, PostgreSQL, fuentes Community y Enterprise, servicio Odoo, Nginx, certificados y generación de configuración.

Este repositorio es una referencia comunitaria, no documentación oficial de Odoo. No debe ejecutarse directamente en producción sin revisar el código, fijar versiones, adaptar seguridad, backups, rutas, credenciales y parámetros a la arquitectura aprobada por Codimat.

5.2 Sistema operativo e instalación

Para producción se recomienda Linux. La documentación oficial de Odoo 19 desaconseja Windows para despliegues productivos. Odoo ofrece instalación mediante paquetes y desde código fuente; la opción deberá definirse según el modelo de mantenimiento y desarrollo.

5.3 Dimensionamiento preliminar

La siguiente tabla es una referencia inicial, no un dimensionamiento definitivo. Supone una instalación optimizada, carga transaccional normal y almacenamiento rápido. Debe ajustarse con métricas, módulos, adjuntos, reportes, automatizaciones, tareas programadas e integraciones reales.

\* El almacenamiento debe incluir crecimiento de PostgreSQL y filestore, espacio operativo, logs y backups según la política de retención. Las copias de seguridad no deben depender únicamente del mismo servidor.

La guía oficial de Odoo utiliza como referencia aproximadamente un worker por cada seis usuarios concurrentes, con un máximo orientativo de workers condicionado por CPU. La memoria debe calcularse según cantidad y tipo de workers. Las integraciones, cron y procesos pesados consumen capacidad adicional.

5.4 Ambientes

Homologación deberá reproducir las versiones, módulos y configuración relevante de producción. Para pruebas de rendimiento deberá contar temporalmente con capacidad equivalente a producción.

5.5 Tecnologías recomendadas para ambientes, despliegues y recuperación

Se recomienda separar la administración de infraestructura, los despliegues y los respaldos. La arquitectura propuesta es la siguiente:

Producción y staging deberán ejecutarse en VPS separadas, sin compartir base de datos, filestore, secretos ni credenciales. Staging deberá reproducir las versiones y la configuración relevante de producción, utilizando datos anonimizados y credenciales neutralizadas.

Proxmox VE administrará la infraestructura y Dokploy administrará los despliegues. Los cambios continuarán pasando por Git, revisión, homologación, aprobación y rollback. Los snapshots se utilizarán como apoyo operativo, pero no reemplazarán los backups de PostgreSQL, filestore y configuración.

La combinación recomendada es Proxmox VE + Dokploy + Proxmox Backup Server + pgBackRest + Restic/S3. Esta arquitectura es modular, auditable y evita depender de una única herramienta para el despliegue y la recuperación.

5.6 Equivalencia de servicios Odoo.sh en infraestructura local

Odoo.sh concentra en una plataforma administrada el alojamiento, los ambientes, la integración continua, los despliegues, los backups, el monitoreo y distintas herramientas operativas. Una instalación local puede reproducir estas capacidades, pero requiere combinar tecnologías y asumir explícitamente su administración, seguridad y continuidad.

La clasificación indica el orden recomendado. “Mínimo inicial” reúne lo necesario antes de operar producción con seguridad, recuperación y trazabilidad. “Etapa posterior” identifica mejoras que pueden incorporarse después de estabilizar la operación, salvo que los requisitos de disponibilidad, escala o cumplimiento de Codimat las vuelvan obligatorias desde el inicio.

Etapa posterior: alta disponibilidad, entornos efímeros por rama, registro dedicado de artefactos, backup integral de VMs, centralización avanzada de logs y editor/consolas web. En el caso de los logs, la consulta local y la rotación son parte del mínimo inicial; únicamente se posterga su centralización avanzada. Estas capacidades no se eliminan: se difieren hasta contar con una operación base estable o se adelantan si el RPO, el RTO, la cantidad de desarrollos, la auditoría o el nivel de servicio contratado lo requieren.

Equivalencia recomendada: Proxmox VE + Dokploy/Docker Compose + GitHub Actions o GitLab CI + PostgreSQL/pgBackRest + Restic/S3 + Proxmox Backup Server + Prometheus/Grafana/Loki + Uptime Kuma + Mailpit + VPN/SSH controlado.

La equivalencia local no se obtiene instalando una sola herramienta. Odoo.sh incluye operación administrada; en local deberán diseñarse, documentarse, monitorearse y sostenerse cada servicio, sus procedimientos y sus responsables. La asignación definitiva se completará con Codimat mediante una columna o matriz de responsabilidad: Infraestructura Codimat, HitoFusion o responsabilidad compartida.

5.7 Datos necesarios para cerrar el dimensionamiento

• Usuarios nominales y concurrentes.
• Módulos y procesos críticos.
• Tamaño actual y crecimiento de datos y adjuntos.
• Cantidad y duración de tareas programadas.
• Volumen y frecuencia de integraciones.
• Uso de reportes, contabilidad, inventario, manufactura y comercio electrónico.
• Requisitos de disponibilidad, RPO y RTO.

6. Seguridad, continuidad y operación

Seguridad mínima

• Accesos nominados y mínimo privilegio.
• MFA, VPN o bastión para administración remota.
• Credenciales fuera del código y rotación periódica.
• HTTPS/TLS y restricción de puertos.
• Revisión de módulos propios y de terceros.
• Actualizaciones controladas de sistema operativo, dependencias y Odoo.
• Registro de accesos, errores, cambios e incidentes.

Backups y recuperación

Se aplicará la regla 3-2-1: tres copias, en dos medios distintos y al menos una fuera de la infraestructura principal.

• PostgreSQL: pgBackRest con backups completos e incrementales, archivo continuo de WAL y recuperación a un punto en el tiempo.
• Filestore, configuraciones y volúmenes persistentes: Restic o la función de backup de volúmenes de Dokploy, con destino S3 compatible fuera del servidor productivo.
• Instancias completas: Proxmox Backup Server alojado en hardware o almacenamiento independiente para recuperación ante desastre.
• Código y módulos propios: repositorio Git y copia externa del repositorio.

La base de datos y el filestore deberán respaldarse de forma coordinada. Se definirán el punto máximo de pérdida aceptable (RPO), el tiempo objetivo de recuperación (RTO) y la política de retención. Las restauraciones completas deberán probarse y documentarse periódicamente; un backup no se considerará válido hasta verificar su restauración.

Los snapshots de Proxmox o Docker facilitan una vuelta atrás operativa, pero no reemplazan los backups independientes de datos, archivos y configuración.

Cambios y actualizaciones

Todo cambio deberá pasar por:

Ticket → análisis → desarrollo/configuración → revisión → prueba en homologación → aprobación → despliegue → validación → cierre o rollback

No se realizarán cambios directos en producción salvo emergencia documentada.

7. Integración con el sistema externo

7.1 Alternativas

Odoo 19 incorpora la API externa JSON-2. También admite automatizaciones y webhooks. Para procesos complejos puede utilizarse un servicio intermedio que gestione transformación, colas, reintentos y trazabilidad.

La documentación de Odoo indica que la API externa requiere un plan Custom. Esta condición deberá confirmarse antes de aprobar la arquitectura.

7.2 Criterios obligatorios

Cada flujo de integración deberá definir:

• Sistema de origen y sistema maestro del dato.
• Entidades y campos.
• Dirección y frecuencia.
• Autenticación y permisos.
• Validaciones y reglas de negocio.
• Idempotencia y prevención de duplicados.
• Timeouts, reintentos y recuperación de errores.
• Trazabilidad y conciliación.
• Responsable funcional y técnico.

7.3 Referencia Hitofusion

La documentación interna de Hitofusion deberá utilizarse como estándar para diseñar y documentar las integraciones. Cada integración deberá registrar objetivo y alcance, arquitectura y secuencia, endpoints y payloads, autenticación, mapeo con Odoo, idempotencia, errores, límites, orden de carga y pruebas. El objetivo es centralizar contratos, flujos, transformaciones, estados y evidencias operativas en un proceso mantenible y auditable.

Los casos ya publicados por Hitofusion son antecedentes metodológicos. No reemplazan el análisis específico del sistema externo de Codimat ni demuestran por sí solos compatibilidad con Odoo 19.

Antes de construir el conector se realizará una prueba de concepto con al menos un flujo operativo y uno financiero.

8. Comunicación y gobierno técnico

Cada empresa designará un referente titular y uno alterno.

Los tiempos de respuesta, horarios de cobertura y severidades deberán quedar definidos en el acuerdo de servicio correspondiente.

9. Control e intervención sobre desarrollos

Codimat podrá supervisar y participar mediante:

• Acceso al repositorio según el rol acordado.
• Tickets relacionados con commits y entregas.
• Ramas protegidas y pull/merge requests.
• Revisión técnica y funcional.
• Pruebas automáticas y evidencias de homologación.
• Versionado y notas de cambio.
• Documentación de módulos e integración.
• Aprobación previa al despliegue productivo.
• Plan de rollback.

Toda intervención de Codimat deberá respetar el mismo proceso. No se admitirán cambios no trazados en producción.

10. Tareas y etapas

11. Roles principales

La asignación definitiva se formalizará mediante una matriz RACI.

12. Tipos de asistencia

• Consultoría técnica y funcional.
• Diseño y revisión de arquitectura.
• Instalación y configuración.
• Desarrollo e integración.
• Auditoría de código y despliegues.
• Mesa de ayuda y soporte reactivo.
• Monitoreo y mantenimiento preventivo.
• Mantenimiento correctivo y evolutivo.
• Capacitación y transferencia de conocimiento.
• Acompañamiento a producción.

Cada asistencia deberá indicar alcance, responsables, horario, tiempos objetivo, exclusiones y evidencia de cierre.

13. Riesgos principales

14. Decisión y próximos pasos

Decisión preliminar

La instalación local de Odoo Enterprise 19.0 en Codimat es viable con condiciones.

Acciones requeridas

1. Designar responsables de ambas empresas.
2. Completar el relevamiento técnico y funcional.
3. Confirmar licencias y plan Odoo.
4. Obtener documentación y acceso de prueba del sistema externo.
5. Definir arquitectura y dimensionamiento.
6. Ejecutar una prueba de concepto de instalación e integración.
7. Probar backup y restauración.
8. Aprobar seguridad, operación, alcance, cronograma y costos.

Solo después de completar estas acciones se emitirá la recomendación definitiva de implementación.

15. Fuentes

Documentación oficial de Odoo 19

• Instalación on-premise
• Instalación desde código fuente
• Paquetes oficiales
• Configuración de producción, workers y memoria
• API externa JSON-2
• Automatizaciones y webhooks

Documentación oficial de Odoo.sh

• Funcionalidades de Odoo.sh
• Builds y ambientes
• Configuración, roles e integración con GitHub
• Contenedores y dependencias
• Editor y consolas

Documentación oficial de infraestructura y operación

• Proxmox VE — guía de administración
• Proxmox Backup Server — documentación
• Dokploy — despliegues con Docker Compose
• Dokploy — backup de volúmenes
• pgBackRest — guías de usuario
• Restic — documentación
• MinIO — documentación
• Prometheus — documentación
• Grafana — documentación
• Uptime Kuma — repositorio oficial

Referencias complementarias

• Documentación interna de Hitofusion
• Script comunitario de instalación de Odoo

Información pendiente para la versión final

• Inventario de infraestructura de Codimat.
• Usuarios nominales y concurrentes.
• Volumen de datos y crecimiento.
• Requisitos RPO, RTO y disponibilidad.
• Documentación del sistema externo.
• Responsables y matriz RACI definitiva.
• Alcance comercial, cronograma y costos.