Saltar al contenido principal

Septiembre de 2026

Modo SaaS: varias bases de datos en un proyecto​

Un solo proyecto puede servir ahora varias bases de datos Odoo independientes desde su despliegue de producción, todas con el mismo código: lo que necesitan los partners y proveedores de software para ofrecer una solución Odoo a muchos clientes. Cada base de datos tiene su propia dirección (<base>.skysize.io o un dominio personalizado que empiece por su nombre) y sus propias copias de seguridad, y se crea, importa, restaura o elimina desde la nueva pestaña Bases de datos. Un push a producción actualiza todas las bases de datos a la vez, con una reversión de todo o nada.

El modo SaaS es un complemento de la suscripción que activa nuestro equipo: contacta con ventas para activarlo. Consulta Modo SaaS.

Tu propio dominio para cada despliegue (BYOS)​

Los proyectos en Bring Your Own Server ahora pueden servir todos sus despliegues bajo tu propio dominio con dos registros DNS creados una sola vez: producción en el propio dominio, y las ramas de staging y los builds de desarrollo en subdominios. Los certificados se emiten automáticamente en tu servidor, y adjuntar un dominio elimina el límite de frecuencia que se aplica a las direcciones skysize.io predeterminadas.

Configúralo desde la pestaña Configuración del proyecto, en Su dominio. Consulta Tu dominio en BYOS.

Imagen Docker personalizada por servidor (BYOS)​

Tus servidores ahora pueden ejecutar tus despliegues desde tu propia imagen Docker, derivada de la imagen oficial de Odoo. Es la forma de añadir paquetes apt, bibliotecas del sistema, fuentes o paquetes Python compilados que un requirements.txt no puede instalar. La imagen se define una vez por servidor en Imagen Docker personalizada y se usa a partir del siguiente despliegue, actualización o reinicio de cada rama.

Las imágenes también pueden incluir Odoo Enterprise. La documentación explica ahora exactamente dónde deben ir los módulos Enterprise para que Odoo los encuentre, con un Dockerfile listo para usar y un comando para comprobar el resultado.

Consulta Imagen Docker personalizada.

Submódulos Git privados​

Los repositorios que obtienen módulos de submódulos privados ahora se despliegan, tanto en el alojamiento gestionado como en BYOS. Cada repositorio de submódulo privado recibe su propia clave de despliegue: si tu cuenta Git está conectada, Skysize registra la clave en el repositorio del submódulo por ti; si no, la configuración del proyecto muestra la clave pública para que la añadas tú.

Consulta Submódulos privados.

Migrar desde otro proveedor de Odoo​

Una nueva guía recorre una migración desde otro proveedor (CloudPepper, Odoo.sh, Odoo Online o tu propio servidor): inventario, exportación de una copia de seguridad limpia, ensayo en staging y paso a producción.

Las importaciones también son más tolerantes: las copias de seguridad cuyo volcado SQL contiene instrucciones de propiedad y privilegios (OWNER TO, GRANT), como las que exportan varios proveedores, ahora se importan tal cual en lugar de fallar.

Consulta Migrar desde otro proveedor de Odoo.

Instantánea previa a la actualización opcional​

Antes de actualizar los módulos, cada actualización copia las bases de datos del despliegue para que una actualización fallida pueda revertirse por completo. En bases de datos grandes, esta copia es la mayor parte de la interrupción de una actualización. Los administradores del proyecto ahora pueden desactivarla en Configuración con Snapshot de la base de datos antes de actualizar.

Desactivarla requiere aceptar un aviso: las actualizaciones se ejecutan entonces sin punto de reversión, y conservar una copia de seguridad reciente antes de una actualización arriesgada pasa a ser tu responsabilidad. La página de configuración y cada actualización ejecutada sin instantánea muestran quién la desactivó y cuándo.

Consulta Actualizar build.

Reconstrucciones de staging más seguras y útiles​

  • Staging ejecuta ahora el código de tu rama de staging. Una rama de staging reconstruida conservaba el código de producción sobre los datos de producción copiados. Tras la copia, la plataforma despliega ahora la propia rama de staging y actualiza sus módulos, así que staging prueba realmente tu rama con datos de producción. Si la rama no puede aplicarse, el build falla y staging sigue sirviendo la copia intacta.
  • Los datos de staging se neutralizan antes de que arranque Odoo. Los servidores de correo saliente, las acciones planificadas y las integraciones activas se desactivan antes del primer arranque del servidor de staging, no poco después. Una copia de producción ya no puede enviar correos ni renovar conexiones bancarias durante sus primeros segundos. Si la neutralización falla, el build falla y el servidor nunca se inicia.

Los cambios de workers se aplican con un reinicio​

Cambiar los workers, los workers de cron o la memoria por worker lanzaba un build de actualización completo, con su instantánea y la actualización de módulos. Ahora estos cambios solo reinician el despliegue de producción con la nueva configuración, seguidos de la comprobación de salud habitual y de una reversión automática si falla.

Reglas más claras para los dominios personalizados​

Un dominio personalizado no puede funcionar mientras la dirección de la rama pase por el proxy de Cloudflare: los visitantes reciben errores de certificado, o el error 1014 de Cloudflare si tu propio DNS también está en Cloudflare. El panel ahora rechaza añadir un dominio personalizado en ese caso y te indica que desactives primero el proxy. Si el DNS de tu dominio está en Cloudflare, crea su registro como DNS only.

Consulta Dominios.

Primer despliegue desde un repositorio vacío​

Un proyecto creado sobre un repositorio sin ningún commit no mostraba nada ni desplegaba nada. Las pestañas Builds y Ramas explican ahora qué hacer, con los comandos Git para subir un primer commit y un botón Actualizar ramas. La primera rama que subas se convierte en la rama de producción y se despliega automáticamente.

Consultas lentas que importan​

La lista de consultas lentas de la pestaña Monitoring muestra ahora solo las sentencias realmente lentas: las que tienen una media de al menos 100 ms, o una ejecución de al menos 1 segundo, ordenadas por tiempo total. Las sentencias muy rápidas que Odoo ejecuta millones de veces y los comandos de transacción ya no ocultan las consultas que vale la pena optimizar. En los servidores BYOS, esto requiere la versión 1.4.1 del agente o posterior.