Pequeñas actualizaciones.
Grandes giros de guion.

• ✳Corrige la publicación cuando el controlador de Orbit y el Space están en servidores diferentes.
• ✳La verificación usa el enrutador compartido del clúster: un controlador que no recibe tráfico HTTP público también puede confirmar el despliegue. Se siguen comprobando el dominio público y la suma de verificación de la versión.
• ✳El acceso al Space elegido sigue a los controladores actuales sin abrir las redes de otras aplicaciones. Se conservan los sitios, archivos y ajustes existentes.

Notas completas de la versión en GitHub ↗

• ✳La configuración de proyectos y aplicaciones incorpora secciones y controles adecuados al modo de publicación.
• ✳Los sitios publicados como archivos ocultan la pestaña Kubernetes y los controles exclusivos de contenedores. Los proyectos estáticos que aún usan contenedores conservan esos controles.
• ✳La actualización conserva los ajustes y el modo de publicación actual. No mueve el sitio a un Space ni inicia un despliegue.

Notas completas de la versión en GitHub ↗

• ✳Publica sitios estáticos en un Space con servidores de archivos compartidos, en lugar de una imagen y un pod por sitio.
• ✳Los archivos de cada versión se separan por sitio, entorno y despliegue bajo un prefijo reservado. Los archivos existentes quedan intactos y el tráfico cambia solo después de verificar los nuevos archivos.
• ✳Conserva diez versiones publicadas con reversión. El renderizado y las funciones de servidor siguen necesitando un contenedor; las cachés locales no sustituyen las copias del Space.

Notas completas de la versión en GitHub ↗

• ✳Corrige las compilaciones Git y la ubicación de aplicaciones cuando una copia de reserva de Orbit pasa a ser el servidor activo.

Notas completas de la versión en GitHub ↗

• ✳Conecta servidores de distintos proveedores y detrás de NAT mediante una red WireGuard gestionada, incluso en instalaciones existentes.

Notas completas de la versión en GitHub ↗

• ✳Spaces, copias de seguridad, actividad y operaciones adoptan el estilo ilustrado de Orbit; el uso de almacenamiento de las bases queda más claro.

Notas completas de la versión en GitHub ↗

• ✳Las bases de datos estrenan tarjetas ilustradas, navegación más clara y áreas dedicadas a las tareas diarias.

Notas completas de la versión en GitHub ↗

• ✳La configuración incorpora categorías, búsqueda, vistas previas de temas y a Ted acompañando los ajustes.

Notas completas de la versión en GitHub ↗

• ✳La configuración de tres servidores identifica cuáles pueden comunicarse; la flota adopta el estilo ilustrado de Orbit.

Notas completas de la versión en GitHub ↗

• ✳Crear un proyecto cobra vida y el catálogo de aplicaciones tiene su propio lugar en la navegación.

Notas completas de la versión en GitHub ↗

• ✳Si un servidor no logra unirse al plano de control, vuelve a funcionar como agente en lugar de quedar inutilizado.

Notas completas de la versión en GitHub ↗

• ✳Terminal en el navegador, catálogo de aplicaciones e importación desde Coolify, Dokploy, Heroku y Render. La validación de alta disponibilidad en servidores reales se ejecuta con un comando.

Notas completas de la versión en GitHub ↗

• ✳Configura el DNS de un dominio existente desde Orbit, empezando por Cloudflare.

Notas completas de la versión en GitHub ↗

• ✳La vista general del proyecto se convierte en un centro de misión, con Ted reaccionando al estado de la aplicación y una selección de rama más clara por entorno.

Notas completas de la versión en GitHub ↗

• ✳La migración desde DigitalOcean incorpora un flujo guiado, desde el descubrimiento de recursos hasta el cambio de DNS verificado.

Notas completas de la versión en GitHub ↗

• ✳La retención puede mantener un número de copias válidas; la copia espera a que la base termine de reiniciarse antes de empezar.

Notas completas de la versión en GitHub ↗

• ✳Inicia sesión o acepta invitaciones con GitHub y Google, usando el correo verificado por el proveedor para encontrar tu cuenta.

Notas completas de la versión en GitHub ↗

• ✳El almacenamiento S3 se convierte en Spaces, con su propia lista, botón de creación y una página dedicada a los archivos.

Notas completas de la versión en GitHub ↗

• ✳Elige un dominio para la consola al instalar o en la configuración, con comprobaciones para conservar el acceso.

Notas completas de la versión en GitHub ↗

• ✳La página de la base detalla qué ocupa el almacenamiento y por qué crece; el uso se muestra con un decimal.

Notas completas de la versión en GitHub ↗

• ✳Ajusta memoria y almacenamiento previsto desde la consola. La falta de memoria abre un incidente y las copias usan memoria separada de la base.

Notas completas de la versión en GitHub ↗

• ✳Protege el acceso con códigos de una aplicación autenticadora; el administrador puede exigir esta protección a todos.

Notas completas de la versión en GitHub ↗

• ✳Recibe alertas de disco, memoria y CPU, almacenamiento de bases, certificados próximos a vencer y copias programadas que no se ejecutaron.

Notas completas de la versión en GitHub ↗

• ✳Las aplicaciones disponen de un bucket S3 para archivos, con referencias y copias como los demás servicios de datos.

Notas completas de la versión en GitHub ↗

• ✳Orbit comprueba que cada aplicación web responda, abre incidentes cuando deja de hacerlo y puede publicar una página de estado.

Notas completas de la versión en GitHub ↗

• ✳Las pruebas de restauración incorporan su propia programación, ejecución manual y límite de tiempo.

Notas completas de la versión en GitHub ↗

• ✳La consola y los entornos de vista previa también pueden publicarse mediante Cloudflare Tunnel.

Notas completas de la versión en GitHub ↗

• ✳Los servidores que no reciben tráfico en los puertos 80 y 443 pueden servir aplicaciones mediante Cloudflare Tunnel.

Notas completas de la versión en GitHub ↗

• ✳Los scripts y pipelines usan la API con tokens del espacio de trabajo; orbit deploy publica aplicaciones desde el pipeline.

Notas completas de la versión en GitHub ↗

• ✳Los nuevos servidores reciben un token que solo permite añadir agentes; los tokens de incorporación al clúster pueden renovarse desde la consola.

Notas completas de la versión en GitHub ↗

• ✳La página de PostgreSQL informa cuando el clúster está cambiando o no puede recuperarse.

Notas completas de la versión en GitHub ↗

• ✳Cada servidor mantiene actualizadas en su cortafuegos las direcciones de los demás servidores.

Notas completas de la versión en GitHub ↗

• ✳Las copias de mayor tamaño vuelven a superar la prueba de restauración y se transfiere el archivo completo al restaurar.

Notas completas de la versión en GitHub ↗

• ✳Las aplicaciones en servidores de otra red pueden alcanzar el clúster; cada nueva incorporación comprueba ese acceso.

Notas completas de la versión en GitHub ↗

• ✳Los servidores en redes separadas con el mismo rango privado se incorporan correctamente mediante sus direcciones públicas.

Notas completas de la versión en GitHub ↗

• ✳Los servidores en redes separadas, como dos redes privadas de Oracle Cloud, pueden compartir un clúster mediante direcciones públicas.

Notas completas de la versión en GitHub ↗

• ✳Orbit explica si el servidor está en otra red con el mismo rango privado y permite descartar una instalación fallida.

Notas completas de la versión en GitHub ↗

• ✳Puedes descartar un servidor en cualquier paso previo a la instalación; se explican las redes privadas inaccesibles.

Notas completas de la versión en GitHub ↗

• ✳Indica los precios de los servidores y consulta cuánto cuesta cada proyecto al mes.

Notas completas de la versión en GitHub ↗

• ✳Reintentar una instalación detenida en Instalar el agente vuelve a funcionar después de reiniciar Orbit.

Notas completas de la versión en GitHub ↗

• ✳Un fallo de conexión en Oracle Cloud indica la regla exacta y dónde añadirla; Orbit también ajusta el cortafuegos de las imágenes del proveedor.

Notas completas de la versión en GitHub ↗

• ✳Las operaciones que dejaron de ejecutarse pueden cancelarse de nuevo y ya no bloquean las actualizaciones.

Notas completas de la versión en GitHub ↗

• ✳Añadir un servidor en una red privada, como la de Oracle Cloud, ya no se bloquea en Iniciando servicios.

Notas completas de la versión en GitHub ↗

• ✳Las vistas previas de pull requests pueden usar tu dominio con un único certificado comodín.

Notas completas de la versión en GitHub ↗

• ✳Los clientes pueden guardar el túnel hacia la base; Lily DB abre la conexión con un clic.

Notas completas de la versión en GitHub ↗

• ✳Orbit puede crear en Cloudflare los registros DNS de tus dominios personalizados.

Notas completas de la versión en GitHub ↗

• ✳Añadir un servidor deja de fallar al instalar el entorno de ejecución.

Notas completas de la versión en GitHub ↗

• ✳Orbit puede enviar notificaciones a una lista de correos e invitaciones a los espacios de trabajo.

Notas completas de la versión en GitHub ↗

• ✳Un proyecto puede tener varias aplicaciones que usen la misma base de datos.

Notas completas de la versión en GitHub ↗

• ✳Perder el servidor principal ya no deja al clúster sin DNS cuando otro servidor había reiniciado antes.

Notas completas de la versión en GitHub ↗

• ✳Los espacios de trabajo incorporan miembros con roles de propietario, administrador, desarrollador y lector.

Notas completas de la versión en GitHub ↗

• ✳Envía notificaciones de Orbit a canales de Discord.

Notas completas de la versión en GitHub ↗

• ✳Orbit avisa a un canal de Slack cuando algo necesita tu atención.

Notas completas de la versión en GitHub ↗

• ✳Orbit puede compilar y publicar aplicaciones desde Bitbucket Cloud.

Notas completas de la versión en GitHub ↗

• ✳Conecta GitLab.com o tu propio GitLab para compilar y publicar aplicaciones.

Notas completas de la versión en GitHub ↗

• ✳Orbit puede ejecutar MongoDB junto a PostgreSQL, MySQL y Redis.

Notas completas de la versión en GitHub ↗

• ✳Una prueba de aceptación cubre la pérdida de cualquier servidor; esta versión corrige los problemas encontrados en esos escenarios.

Notas completas de la versión en GitHub ↗

• ✳Orbit puede mantener copias de sí mismo en el plano de control y volver en otro servidor cuando se pierde el principal.

Notas completas de la versión en GitHub ↗

• ✳Orbit funciona en proveedores que solo asignan una dirección interna a la interfaz de red, como Oracle Cloud, AWS, Google Cloud y Azure.

Notas completas de la versión en GitHub ↗

• ✳El plano de control de Kubernetes puede ejecutarse en tres servidores y mantener el clúster funcionando si se pierde el principal.

Notas completas de la versión en GitHub ↗

• ✳Recibir tráfico, en la tarjeta de un servidor, ejecuta también el router allí. Orbit lo espera, comprueba que el servidor responde en el puerto 80 y revierte el cambio si no lo hace, indicando la regla de firewall que hay que añadir.
• ✳Con más de un servidor recibiendo tráfico, cada dominio personalizado muestra un registro A por servidor, subdominios incluidos. Un dominio que ya estaba verificado vuelve a mostrar los registros y se sigue comprobando hasta que todos resuelvan.
• ✳La página Servidores marca los servidores que reciben tráfico, y la actividad indica por qué direcciones entra el tráfico.
• ✳Límite — Las direcciones sslip.io generadas siguen apuntando solo al servidor principal.
• ✳Límite — Cuando se pierde un servidor que recibe tráfico, los visitantes cuyo DNS lo eligió no obtienen respuesta hasta que su resolver deja de devolverlo. En las pruebas, las solicitudes a través del servidor principal siguieron funcionando, salvo las enviadas a la instancia del servidor perdido: 8 de 71 fallaron en los primeros 52 segundos.
• ✳Límite — Si se pierde el servidor principal, los demás siguen respondiendo, pero las solicitudes enviadas a las instancias que se ejecutaban en él fallan, porque el plano de control que las retiraría de las listas de los routers se ejecuta allí.

Notas completas de la versión en GitHub ↗

• ✳La vista previa de Servidores simula la pérdida de cada servidor elegido. Si los demás no tuvieran espacio para las instancias que se trasladarían a ellos, además de todo lo que ya tienen, rechaza el cambio e indica el servidor y la memoria que falta. Si cabe, indica cuánto espacio quedaría libre.
• ✳Cada servidor conserva ese espacio. Un cambio posterior en él, como otra aplicación, una base de datos o un redimensionamiento, se rechaza si le quitara ese espacio.
• ✳Redimensionar una aplicación repartida pasa por la misma comprobación.
• ✳La página Servidores muestra cuánta memoria reserva cada servidor para las instancias que se trasladarían a él, y qué pérdida la necesita.

Notas completas de la versión en GitHub ↗

• ✳Servidores, en los ajustes de una aplicación, la traslada a otro servidor o reparte sus instancias entre varios. Una vista previa muestra cuántas instancias tendría cada servidor y qué queda libre, y rechaza un servidor que no está listo, no tiene espacio o tiene una arquitectura de CPU distinta a la de una imagen compilada.
• ✳Cuando se pierde un servidor, las instancias que ejecutaba vuelven a arrancar en los demás servidores. En las pruebas tardó alrededor de un minuto y medio, y las demás instancias siguieron sirviendo mientras tanto.
• ✳Las imágenes compiladas se copian a cada servidor elegido antes de que una instancia arranque allí.
• ✳Límite — Con una sola instancia, la aplicación sigue deteniéndose hasta que esa instancia arranca en otro servidor. Usa dos o más.
• ✳Límite — El tráfico sigue entrando por el servidor principal, y trasladar instancias requiere el plano de control que se ejecuta allí. Perder el servidor principal detiene ambas cosas. Por eso Orbit todavía no lo llama alta disponibilidad.

Notas completas de la versión en GitHub ↗

• ✳La documentación de Orbit es pública en orbit.getcortexlabs.com, en inglés y en portugués.
• ✳La documentación cubre la instalación, los proyectos, las aplicaciones, GitHub y las vistas previas, las importaciones de Compose, las bases de datos, las réplicas y el failover, las copias de seguridad y la recuperación, más servidores, cómo ejecutar y actualizar Orbit, la seguridad y lo que Orbit no promete.
• ✳Los avisos de la consola que indican un límite ahora enlazan con la página que lo explica, en tu idioma. Esto abarca el plano de control único, la pérdida de datos con replicación asíncrona, la replicación síncrona con dos instancias y varias instancias en un mismo servidor.
• ✳La guía de recuperación que se muestra cuando se interrumpe una actualización, y la línea Documentation= de las unidades de systemd, apuntan al nuevo sitio en lugar de a un repositorio privado.

Notas completas de la versión en GitHub ↗

• ✳Reconstruir desde el archivo. Cuando todas las instancias de una base de datos PostgreSQL han desaparecido, su página ofrece reconstruirla a partir de la última copia de seguridad base y del WAL archivado. Orbit recrea las instancias en los mismos servidores y te dice hasta qué commit se recuperaron los datos.
• ✳Failovers medidos. Cada failover y cada switchover registra cuánto tiempo estuvo la base de datos sin primario. También registra lo que se conservó: todas las escrituras confirmadas con replicación síncrona, o la hora de la escritura más reciente que tiene el nuevo primario con replicación asíncrona. La actividad, la línea de tiempo y la página de la base de datos muestran ambas cosas.
• ✳El panel de la base de datos ahora se llama Instancias y replicación. Orbit no lo llama alta disponibilidad mientras su plano de control se ejecute en un solo servidor.
• ✳Con replicación asíncrona, un primario aislado de la red ahora deja de aceptar escrituras aproximadamente medio minuto después del corte, mucho antes de que una réplica tome el relevo. Antes, las sesiones que ya tenía podían seguir escribiendo hasta tres minutos, así que dos primarios podían aceptar escrituras al mismo tiempo.
• ✳La replicación síncrona solo promueve una réplica que tenga todas las escrituras confirmadas.
• ✳La vista previa rechaza la replicación síncrona con dos instancias, ya que perder cualquiera de los dos servidores detendría todas las escrituras.
• ✳Un archivo WAL que no está lleno se archiva al cabo de un minuto en lugar de cinco, así que perder todas las instancias pierde como máximo alrededor de un minuto de escrituras.
• ✳Un servidor detenido supuso unos 64 segundos sin primario, y no se perdió ninguna escritura confirmada.
• ✳Un servidor aislado de la red supuso 96 segundos sin primario, y nunca hubo dos primarios aceptando escrituras.
• ✳Restaurar al segundo anterior a un cambio destructivo tardó alrededor de un minuto.
• ✳Reconstruir desde el archivo devolvió las escrituras 51 segundos después de perder todas las instancias.

Notas completas de la versión en GitHub ↗

• ✳Una base de datos PostgreSQL en CloudNativePG ejecuta de una a tres instancias, cada una en un servidor distinto. La vista previa elige los servidores y rechaza el cambio cuando no hay suficientes con espacio para la base de datos.
• ✳La replicación es asíncrona por defecto. La replicación síncrona hace que cada commit espere a una réplica.
• ✳Cuando se pierde el servidor del primario, se promueve una réplica y la dirección de la base de datos la sigue, así que las aplicaciones conservan sus variables.
• ✳Convertir en primario promueve una réplica a propósito. En las pruebas tardó unos 10 segundos.
• ✳La página de la base de datos enumera cada instancia con su servidor, su rol y cuánto retraso lleva. Los failovers y switchovers aparecen en la actividad y en la línea de tiempo.

Notas completas de la versión en GitHub ↗

• ✳Una base de datos en CloudNativePG cuyas copias de seguridad van a un almacenamiento externo también archiva allí su WAL, de forma continua.
• ✳La página de la base de datos muestra la ventana a la que puedes restaurar, desde la copia de seguridad base más antigua conservada hasta el último WAL archivado. Avisa cuando el archivado se retrasa o falla, y la base de datos aparece como degradada.
• ✳Restaurar a un punto en el tiempo acepta cualquier segundo de esa ventana. Orbit primero guarda una copia de los datos actuales, recupera el archivo en un clúster temporal en ese momento, vuelve a copiar los datos en una sola transacción y reinicia las aplicaciones que usan la base de datos.

Notas completas de la versión en GitHub ↗

• ✳Orbit instala el operador de CloudNativePG y su plugin Barman Cloud cuando se crea la primera base de datos PostgreSQL.
• ✳Las bases de datos PostgreSQL existentes muestran Mover a CloudNativePG. Una vista previa indica cuánto tiempo se pausan las escrituras, adónde va la copia de seguridad y si el servidor tiene disco para una segunda copia. Orbit hace la copia de seguridad, copia los datos mientras las lecturas siguen funcionando, cambia la dirección de la base de datos y reinicia las aplicaciones que la usan.
• ✳Si falla un paso del traslado, se restablece la base de datos anterior y vuelve a aceptar escrituras. Su volumen permanece en el servidor, en solo lectura, hasta que lo elimines.

Notas completas de la versión en GitHub ↗

• ✳Escalar automáticamente, en los ajustes de una aplicación, añade instancias mientras la CPU se mantiene por encima de un objetivo, y las retira tras 5 minutos por debajo.
• ✳La vista previa de recursos reserva espacio para el número máximo de instancias, así que al escalar nunca falta espacio en el servidor.
• ✳Los despliegues y los cambios de recursos mantienen el número de instancias que eligió el autoscaler.
• ✳Un gráfico de Instancias muestra el escalado, y la línea de tiempo enumera cada cambio con la CPU que lo provocó.

Notas completas de la versión en GitHub ↗

• ✳Ajustes > Actualizaciones de Orbit muestra la versión en ejecución y cualquier versión más reciente, con sus notas.
• ✳Antes de que empiece una actualización, una comprobación previa verifica la firma de la versión, el disco libre, las operaciones en curso y el agente del servidor.
• ✳Una actualización hace una copia de seguridad de los datos de Orbit, descarga y verifica la versión, se reinicia con la nueva versión y aplica sus migraciones.
• ✳Si la nueva versión nunca llega a arrancar, una salvaguarda restablece la anterior al cabo de tres minutos. Si la consola no está accesible, orbit update rollback hace lo mismo desde el servidor.
• ✳Las versiones ahora se firman con Ed25519. Orbit se niega a actualizar desde una versión cuya firma no coincida con la clave que trae incorporada.

Notas completas de la versión en GitHub ↗

• ✳Cuando el sistema mata una aplicación por quedarse sin memoria dos veces en 30 minutos, Orbit abre un incidente.
• ✳El incidente muestra los reinicios, la memoria frente al límite, el tráfico entrante y el último despliegue, cada uno con su origen, y separa las posibles causas de los hechos.
• ✳Aumentar el límite desde el incidente pasa por la vista previa de recursos. El incidente se resuelve tras 10 minutos sin reinicios.

Notas completas de la versión en GitHub ↗

• ✳La memoria, la CPU y el número de instancias de una aplicación se pueden cambiar desde sus ajustes en un servidor real.
• ✳Una vista previa muestra lo que el cambio reserva en el servidor y cómo se aplica. Avisa cuando las compilaciones pierden su margen o el nuevo límite queda por debajo del uso reciente, y bloquea un cambio que no cabe.
• ✳Si las nuevas instancias no llegan a estar listas, se restablecen los valores anteriores.

Notas completas de la versión en GitHub ↗

• ✳Métricas. Cada 30 segundos, Orbit toma muestras de CPU, memoria, red y reinicios de cada aplicación, del almacenamiento y las conexiones de cada base de datos, y del uso de cada servidor. Conserva ocho días. Los gráficos muestran huecos donde se detuvo el muestreo, y una línea de tiempo enumera despliegues, rollbacks, reinicios y cambios.
• ✳Explorar datos. Las tablas de una base de datos, sus filas y las claves de Redis se pueden explorar desde la consola. La pestaña Consulta ejecuta una única sentencia SQL de solo lectura, limitada a 15 segundos y 500 filas, y cada consulta queda registrada en la actividad.

Notas completas de la versión en GitHub ↗

• ✳Importar datos trae una base de datos desde otro servidor, usando su URL de conexión, o desde un archivo de volcado de hasta 64 GiB. La importación se convierte en una copia de seguridad marcada como importada y pasa por la misma prueba de restauración aislada antes de que la restaures. La URL nunca se escribe en los logs.
• ✳Corregido — Una aplicación que se detiene justo después de arrancar ahora falla con su código de salida y sus últimas líneas, en lugar de parecer una comprobación de estado que nunca respondió.

Notas completas de la versión en GitHub ↗

• ✳Mostrar credenciales, en la página de una base de datos, te da el usuario, la contraseña y el comando para un túnel SSH a través del servidor principal. Así puedes conectar psql, DBeaver o TablePlus desde tu equipo sin hacer pública la base de datos. Cada vez que se muestran queda registrado en la actividad.

Notas completas de la versión en GitHub ↗

• ✳Las copias de seguridad pueden ejecutarse cada hora o cada pocas horas en el minuto que elijas, cada día a la hora que elijas, en los días de la semana que elijas o con un cron personalizado. Siguen cualquier zona horaria, incluidos los cambios de horario de verano.
• ✳La política muestra las tres próximas copias de seguridad antes de guardarla. Una base de datos nueva pide la hora y la zona horaria de su copia de seguridad diaria.
• ✳Corregido — Crear una base de datos desde el diálogo de nueva base de datos o desde una importación de Compose ya no falla en un servidor real por falta de una programación de copias de seguridad.
• ✳Corregido — La consola ya no muestra texto de ejemplo de la demo en una instalación real.

Notas completas de la versión en GitHub ↗

• ✳Los proyectos se pueden renombrar y cambiar de color. Los entornos de staging y de desarrollo se pueden eliminar, igual que proyectos, aplicaciones y bases de datos enteros. Cada eliminación te pide que escribas el nombre. Los archivos de copia de seguridad se conservan.
• ✳Corregido — Volver a registrar un agente revoca los certificados que tenía antes su servidor.
• ✳Corregido — Orbit rechaza los comandos de un agente registrado para un servidor que no conoce, y su log indica el nombre de ese servidor.

Notas completas de la versión en GitHub ↗

• ✳Corregido — Actualizar con el comando de instalación ahora reinicia el agente cuando su binario ha cambiado. Antes, seguía ejecutando la versión anterior hasta que el servidor se reiniciaba.

Notas completas de la versión en GitHub ↗

• ✳Vistas previas de pull requests. Cada pull request desde una rama del repositorio recibe su propia copia de los servicios compilados a partir de ella, con bases de datos vacías, en su propia dirección. La vista previa se elimina cuando se cierra el pull request. Los pull requests desde forks nunca reciben vista previa.
• ✳Importación de Docker Compose. Un archivo Compose de un repositorio, o pegado directamente, se convierte en un plan para revisar. Las bases de datos pasan a ser bases de datos gestionadas, los servicios, aplicaciones o workers, y las variables, variables, secretos o referencias.
• ✳Bases de datos MySQL 8.4, con copias de seguridad verificadas y restauraciones que nunca dejan una base de datos a medio cargar.
• ✳Vista de Kubernetes. Con el modo avanzado activado en los ajustes de tu cuenta, las aplicaciones y bases de datos muestran sus recursos, manifiestos y eventos de Kubernetes, en solo lectura y sin secretos.

Notas completas de la versión en GitHub ↗

• ✳Más servidores. Añadir servidor se conecta por SSH, comprueba la máquina y la une al clúster, con el tráfico entre servidores cifrado por WireGuard. Se pueden colocar servicios nuevos en ella. Más servidores añaden capacidad, no alta disponibilidad.
• ✳Corregido — Una consola real ya no muestra el usuario de ejemplo de la demo ni su aviso de “datos simulados”.

Notas completas de la versión en GitHub ↗

• ✳Workers y tareas. Una aplicación puede tener workers, que se ejecutan sin dirección, y tareas programadas, que se ejecutan según un cron en UTC o bajo demanda con Ejecutar ahora. Orbit guarda las cinco últimas ejecuciones correctas y las cinco últimas fallidas de una tarea, con su salida.

Notas completas de la versión en GitHub ↗

• ✳Despliegue con cada push. Un push a la rama de una aplicación despliega ese commit cuando “Desplegar automáticamente” está activado. Las entregas de GitHub están firmadas, y la misma entrega nunca despliega dos veces.

Notas completas de la versión en GitHub ↗

• ✳Espacios de trabajo. Los proyectos, la conexión con GitHub, las credenciales del registry, los almacenamientos de copias de seguridad y la actividad pertenecen a un espacio de trabajo, y la consola permite cambiar de espacio, crearlos y renombrarlos. Los servidores se comparten. Todo lo que existía antes está en un espacio de trabajo llamado “Default”.

Notas completas de la versión en GitHub ↗

• ✳La GitHub App ahora se puede instalar en tu cuenta o en cualquiera de tus organizaciones.
• ✳La App lleva el nombre de su servidor (“Orbit” más el nombre del servidor), y Ajustes > Integraciones ofrece el logo de Orbit para subirlo a GitHub.

Notas completas de la versión en GitHub ↗

• ✳Orbit se instala en Ubuntu 26.04 LTS.

Notas completas de la versión en GitHub ↗

• ✳Instalación. El comando de instalación comprueba la máquina e instala K3s, Traefik, cert-manager, BuildKit y el agente de Orbit. Si se detiene a medias, al volver a ejecutarlo continúa donde se quedó.
• ✳Consola. La consola se publica en su propia dirección HTTPS en el servidor, con un certificado de Let's Encrypt.
• ✳Aplicaciones. Despliega desde una imagen de contenedor, o desde un repositorio de GitHub que Orbit compila en el servidor. Cada una obtiene una dirección HTTPS, dominios personalizados, variables y secretos, comprobaciones de estado, rollbacks y logs sin secretos.
• ✳Bases de datos. Las bases de datos PostgreSQL y Redis se pueden conectar a las aplicaciones mediante referencias. Las credenciales se pueden rotar, el acceso se puede hacer público y las versiones se pueden actualizar.
• ✳Copias de seguridad. Las copias de seguridad van a un almacenamiento compatible con S3 según una programación. Cada una se restaura de forma aislada antes de considerarse verificada, y una restauración puede guardar primero una copia de los datos actuales.
• ✳Tus datos. orbit backup y orbit restore guardan y recuperan los datos propios de Orbit desde el servidor.

Notas completas de la versión en GitHub ↗