Antes de configurar una sola aplicación, debe decidir dónde residirá su base de datos de Odoo 19 Enterprise. La elección del alojamiento define qué puede personalizar, quién controla el servidor, con qué frecuencia debe actualizar y quién es responsable de los respaldos.
Odoo ofrece tres vías de alojamiento: Odoo Online, Odoo.sh y on-premise (servidor propio). Las tres ejecutan las mismas aplicaciones estándar de Enterprise, pero se diferencian mucho en cuanto necesita código personalizado, acceso al servidor o un ritmo de actualización determinado.
Una nota sobre las fuentes: esta guía se basa en la documentación oficial de Odoo para la versión 19.0. Las reglas y políticas de alojamiento pueden cambiar, así que confirme cada punto relevante para su proyecto en una base de datos de prueba y contra los términos de su propia suscripción antes de comprometerse.
Las tres opciones en un minuto
- Odoo Online: el software como servicio de Odoo. Odoo administra los servidores y la plataforma, y usted trabaja dentro de las aplicaciones estándar y Studio.
- Odoo.sh: la plataforma oficial en la nube de Odoo para alojar y gestionar Odoo con su propio código, conectada a un repositorio de GitHub y organizada en ramas de desarrollo, preproducción (staging) y producción.
- On-premise: usted instala y ejecuta Odoo en su propio servidor, o en un servidor en la nube que alquila, y registra la base de datos con el código de su suscripción Enterprise.
Personalización: el factor decisivo en la mayoría de los proyectos
La documentación de Odoo indica de forma explícita que Odoo Online no es compatible con módulos personalizados ni con módulos de la tienda de aplicaciones de Odoo (Odoo Apps Store). En Online usted configura las aplicaciones estándar y puede crear personalizaciones con Studio, pero no puede instalar sus propios módulos de Python.
Odoo.sh está diseñado para código personalizado. Usted sube sus módulos a una rama de su repositorio de GitHub y la plataforma detecta automáticamente las carpetas que contienen módulos de Odoo. También se pueden agregar módulos comunitarios de acceso público, por ejemplo como submódulos de Git.
On-premise ofrece la misma libertad que Odoo.sh para módulos personalizados, porque usted controla el servidor y los complementos que carga. La diferencia es que nada de lo que rodea al código se gestiona por usted.
Una regla práctica: si sus requisitos incluyen cualquier desarrollo personalizado en Python o cualquier aplicación de terceros de la Apps Store, Odoo Online queda descartado y la decisión real es entre Odoo.sh y on-premise.
Control y acceso
En Odoo Online usted gestiona la base de datos mediante el administrador de bases de datos de Odoo. Desde allí puede duplicarla para pruebas, cambiarle el nombre, descargar un respaldo, iniciar una actualización cuando haya una disponible, gestionar nombres de dominio y transferir la titularidad. No hay acceso al servidor ni a una consola (shell).
En Odoo.sh cada rama incluye herramientas para desarrolladores en el navegador: una consola web para comandos básicos de Linux y psql, un editor en línea con consolas de Python y del shell de Odoo, acceso SSH con su propia clave y un capturador de correos que intercepta los correos de las compilaciones que no son de producción.
On-premise otorga control total del sistema operativo, PostgreSQL, el proxy inverso y el archivo de configuración de Odoo. La guía de despliegue de Odoo trata la seguridad como un proceso continuo y enumera tareas como servir Odoo por HTTPS detrás de un proxy inverso, definir un filtro de bases de datos en servidores con varias bases, usar un usuario de PostgreSQL que no sea superusuario y desactivar el administrador de bases de datos en sistemas expuestos a internet.
Obligaciones de actualización
Cada tipo de alojamiento tiene una regla de actualización distinta. Suele pasarse por alto durante la selección y luego se vuelve urgente, así que póngala sobre la mesa desde el primer día.
- Odoo Online: según la documentación de actualización de Odoo, una base de datos en una versión mayor debe actualizarse cada dos años, y una base de datos en una versión menor debe actualizarse pocas semanas después del lanzamiento de la siguiente versión. Si no se actúa antes de la fecha límite, Odoo actualiza la base de datos automáticamente.
- Odoo.sh: después de los tres años iniciales de soporte de una versión, usted dispone de otros dos años para completar la actualización y recibe una notificación cuando se requiere.
- On-premise: puede permanecer en la misma versión indefinidamente. Odoo no lo recomienda, y las diferencias de versión más pequeñas facilitan las actualizaciones.
Los módulos personalizados afectan a todas las opciones excepto Online. Odoo indica que una base de datos con módulos personalizados no puede actualizarse hasta que esos módulos estén disponibles para la versión de destino, y que hacerlos compatibles es responsabilidad de quien mantiene el módulo.
Con Odoo Enterprise, el servicio de actualización cubre las aplicaciones estándar, las personalizaciones de Studio mientras Studio siga instalado y la suscripción esté activa, y los desarrollos cubiertos por una suscripción de mantenimiento de personalizaciones. No cubre los módulos internos o de terceros sin ese contrato, la depuración de datos existentes ni la capacitación.
El proceso recomendado es el mismo en todas las plataformas: solicitar una base de datos de prueba actualizada, actualizar los módulos personalizados, probar a fondo, reportar los problemas a Odoo y luego planificar la actualización de producción, durante la cual la base de datos no está disponible.
Respaldos y copias de prueba
Odoo Online: la documentación indica que se realizan respaldos diarios bajo el SLA de Odoo Cloud Hosting. También puede descargar un respaldo en ZIP desde el administrador de bases de datos; si la base de datos es demasiado grande para ello, el soporte de Odoo ofrece otro método.
Odoo.sh: la base de datos de producción se respalda automáticamente todos los días, y cada respaldo incluye el volcado de la base de datos, el filestore, los registros y las sesiones. La documentación menciona siete respaldos diarios, cuatro semanales y tres mensuales, con servidores de respaldo dedicados que conservan copias mensuales adicionales. También puede hacer respaldos manuales de las compilaciones de producción y de preproducción.
Las compilaciones de preproducción y de desarrollo en Odoo.sh no se respaldan automáticamente. Las bases de datos de preproducción son duplicados neutralizados de producción que se eliminan después de un tiempo, y las de desarrollo son de corta duración y se crean con datos de demostración, así que nunca guarde trabajo real solo allí.
On-premise: los respaldos son enteramente su responsabilidad. Programe respaldos tanto de la base de datos PostgreSQL como del filestore, guarde copias fuera del servidor y pruebe las restauraciones con regularidad.
Elija la opción que elija, las bases de datos de prueba de actualización y las de preproducción de Odoo.sh están neutralizadas: las acciones planificadas se desactivan, el correo saliente se intercepta o reemplaza y los conectores de pago y de envío se ponen en modo de prueba. Esto protege la producción, pero las integraciones deben reactivarse de forma deliberada si desea probarlas.
Factores de costo para comparar sin una lista de precios
Los precios dependen de su contrato y cambian con el tiempo, así que compare lo que impulsa el costo en lugar de las cifras de referencia.
- Alcance de la suscripción: Odoo.sh requiere un código de suscripción Enterprise que incluya el alojamiento en Odoo.sh, mientras que on-premise usa una suscripción Enterprise registrada en su propio servidor, con una base de datos vinculada por suscripción.
- Usuarios: una base de datos on-premise debe mantenerse dentro del número de usuarios de su suscripción; excederlo genera una advertencia y un plazo limitado para corregir el conteo antes de que la base de datos caduque.
- Infraestructura: en Odoo.sh usted dimensiona los workers, el almacenamiento y las compilaciones de preproducción dentro de la plataforma; en on-premise usted paga por su cuenta servidores, almacenamiento, ancho de banda y monitoreo, y el servidor debe mantener acceso de red al servicio de validación de Odoo.
- Personas: on-premise requiere a alguien capaz de administrar Linux, PostgreSQL, HTTPS y las actualizaciones de seguridad; Odoo.sh requiere desarrolladores que dominen Git; Odoo Online no requiere ninguno de los dos.
- Ciclo de vida de las personalizaciones: cada módulo personalizado debe mantenerse y migrarse en cada actualización, lo que representa un costo recurrente en Odoo.sh y on-premise, a menos que esté cubierto por una suscripción de mantenimiento.
Para quién es cada opción
Odoo Online es adecuado para empresas que pueden trabajar con Odoo estándar más Studio, quieren el arranque más rápido y se sienten cómodas con el calendario de actualizaciones de Odoo. Los negocios comerciales, de servicios y minoristas con procesos estándar son candidatos típicos.
Odoo.sh es adecuado para proyectos que necesitan módulos personalizados o aplicaciones de terceros pero no quieren administrar servidores, y que valoran probar cada cambio en una copia de preproducción antes de que entre en producción.
On-premise es adecuado para organizaciones con un equipo de TI interno, requisitos estrictos de ubicación de datos o de red, integraciones con hardware local o la necesidad de decidir exactamente cuándo se realizan las actualizaciones.
Si está considerando Odoo Community, tenga en cuenta que Odoo.sh requiere un código de suscripción Enterprise y que el servicio de actualización gratuito descrito arriba es un beneficio de Enterprise, por lo que Community normalmente se aloja en servidor propio y se actualiza por cuenta propia.
Enterprise no es una base de código independiente: la documentación de instalación de Odoo describe el repositorio de Enterprise como un conjunto de complementos adicionales sobre Community, por lo que una instalación de Enterprise en servidor propio necesita ambos. Pasar de Community a Enterprise más adelante es un proyecto en sí mismo, ya que la documentación de actualización de Odoo no considera el cambio de edición como parte de una actualización.
Cambiar de tipo de alojamiento más adelante
La elección no es permanente, pero el cambio es más fácil en unas direcciones que en otras.
- De Odoo Online a Odoo.sh u on-premise: descargue un respaldo desde el administrador de bases de datos e impórtelo o restáurelo. Las versiones intermedias de Online no son compatibles en otros entornos, así que puede que primero deba actualizar a la siguiente versión mayor.
- De Odoo.sh u on-premise a Odoo Online: primero deben desinstalarse todas las aplicaciones no estándar, en una compilación de preproducción o en una base de datos duplicada, y la migración en sí se solicita mediante un ticket de soporte de Odoo.
- De on-premise a Odoo.sh: use la importación en la pestaña Respaldos de la rama de producción. La importación requiere un espacio libre de cuatro veces el tamaño del volcado, sobrescribe los datos actuales de la rama y desactiva los servidores de correo saliente y las acciones planificadas hasta que vuelva a activar las que necesite.
Lista de verificación para decidir
- ¿Necesitamos algún módulo personalizado en Python o algún módulo de la Apps Store, ahora o en el futuro previsible? Si es así, descarte Odoo Online.
- ¿Podemos aceptar el calendario obligatorio de actualizaciones de Odoo Online, o necesitamos más control sobre cuándo se produce cada cambio de versión?
- ¿Necesitamos una copia de preproducción para probar cada cambio antes de salir en vivo?
- ¿Tenemos, o podemos contratar, personal para operar Linux, PostgreSQL, HTTPS, monitoreo y seguridad de un servidor on-premise?
- ¿Existen restricciones de ubicación de datos, de red o de hardware que exijan un servidor propio?
- ¿Quién se encarga de verificar los respaldos y probar las restauraciones, y con qué frecuencia se hará?
- ¿Quién mantiene y migra nuestros módulos personalizados en cada actualización, y está cubierto por una suscripción de mantenimiento?
Cómo puede ayudarle 1CBMS
1CBMS ayuda a empresas de Egipto e Irak a elegir el alojamiento de Odoo adecuado antes de iniciar la implementación. Contrastamos sus requisitos con lo que permite cada plataforma, identificamos a tiempo cualquier necesidad de módulos personalizados, configuramos proyectos en Odoo.sh o servidores on-premise con buenas prácticas de respaldo y seguridad, y planificamos las actualizaciones para que su sistema Odoo 19 Enterprise siga contando con soporte. Contáctenos a través de www.1cbms.com para revisar su caso.