> ## Documentation Index > Fetch the complete documentation index at: https://help.teable.ai/llms.txt > Use this file to discover all available pages before exploring further. # Оновлення версії У цьому документі описано, як оновити самостійно розміщене розгортання Teable. ## Канали випусків і теги версій Застосунок Teable публікує **теги випусків на основі дати** у форматі `release..` (наприклад, `release.2026-07-14T12-24-39Z.2228`), а також два рухомі канали: | Тег | Значення | | ----------------------------- | -------------------------------------------------------------------- | | `latest` | **Стабільний** канал — завжди вказує на найновіший стабільний випуск | | `beta` | Рухомий канал — найновіша збірка, що випереджає стабільну | | `release..` | Незмінний конкретний випуск | Випуски виходять часто (нерідко кілька разів на тиждень); ви самі вирішуєте, коли оновлюватися. Усі теги наведено в [GitHub Packages](https://github.com/teableio/teable/pkgs/container/teable). Перед будь-яким оновленням наполегливо рекомендуємо спочатку створити резервну копію даних. ## Регулярні оновлення: стежте за журналом змін Про нові функції та виправлення повідомляється в [Журналі змін](/uk/changelog), а кожен тег випуску Teable містить дату збірки — тож відповідь на запитання «чи є це вже в моїй версії?» зводиться до порівняння дат. Щоб отримати функцію, про яку ви прочитали, переведіть образ Teable на будь-який випуск із датою цієї публікації або пізнішою: * **Розгортання Docker** можуть просто використовувати канал `latest`: ```bash theme={null} cd teable # каталог вашого розгортання docker compose pull docker compose up -d ``` Контейнери буде повторно створено на основі нового образу; ваші дані зберігаються в томах Docker (або в зовнішній базі даних) і не змінюються. * У **розгортаннях Kubernetes** не слід використовувати рухомий тег: зафіксуйте образ Teable і **свідомо оновлюйте зафіксований тег під час кожного оновлення**. Сценарій `pin-image.sh` у репозиторії розгортання визначає, на який конкретний випуск зараз указує `latest`. ## Рекомендований підхід: оновлюйте всю платформу разом Повнофункціональне розгортання має дві лінії версій — застосунку Teable і самої платформи (див. [Архітектура](/uk/deploy/architecture)). Найнадійніша процедура пов’язує їх між собою, використовуючи [`VERSIONS.md`](https://github.com/teableio/teable-deployment/blob/main/VERSIONS.md) як таблицю оновлень. Під час кожного оновлення: 1. Оновіть середовище виконання до **найновішого випуску платформи** (`v..`): кожен тег git — це перевірений знімок усіх компонентів середовища виконання, а відповідний запис у [`CHANGELOG.md`](https://github.com/teableio/teable-deployment/blob/main/CHANGELOG.md) пояснює, що змінилося і які дії потрібно виконати, якщо такі є (більшість випусків можна замінити без зупинки). Працюйте з репозиторієм, у якому вибрано цей тег. 2. Переведіть застосунок Teable на **конкретний тег випуску, якому зараз відповідає `latest`** (його визначає `pin-image.sh`) — так ви отримаєте зафіксовану перевірену комбінацію замість рухомого каналу. 3. Запустіть вбудований засіб **doctor** — він перевіряє працездатність і порівнює фактичну конфігурацію з маніфестом випуску платформи (сумісна / потрібно оновити застосунок Teable / невідома комбінація). ## Обов’язкові секрети Teable більше не використовує вбудовані стандартні секрети як резервні значення. Якщо ваше розгортання покладалося на ці стандартні значення, перший запуск після оновлення зупиниться й покаже список потрібних змінних середовища та готовий для копіювання блок, який збереже ваші наявні сеанси, токени й зашифровані дані. Додайте блок, перезапустіть систему, а потім заплануйте ротацію. Див. [Секрети та ротація](/uk/deploy/env#secrets-and-rotation). ## Міграція бази даних Teable автоматично виконує міграції бази даних під час запуску; вручну нічого робити не потрібно. Якщо після оновлення щось працює неправильно, перевірте журнали: ```bash theme={null} docker compose logs teable | grep -i migration ``` ## Відкат Якщо після оновлення виникли проблеми: 1. Поверніть тег образу у файлі `docker-compose.yaml` до попереднього тегу випуску (саме тому фіксований тег кращий за `latest`: попередню версію записано явно). 2. `docker compose up -d` Відкат **після** випуску, який змінив схему бази даних, може бути небезпечним — у такому разі відновіть дані з резервної копії, створеної перед оновленням. Це головна причина наведеної вище рекомендації щодо резервного копіювання. ## Поширені запитання Ні. Ваші дані зберігаються в томах Docker або зовнішніх базах даних, і оновлення контейнерів не вплине на них. Проте ми все одно рекомендуємо створити резервну копію перед оновленням. Ні. Ідентифікатор екземпляра не змінюється під час оновлень застосунку. Це постійний ідентифікатор вашого самостійно розміщеного встановлення. Завантаження нових образів зазвичай триває кілька хвилин (залежно від швидкості мережі), а перезапуск контейнера — лише кілька секунд. Увесь процес зазвичай завершується протягом 5–10 хвилин. Під час використання `docker compose up -d` станеться коротка перерва в роботі сервісу (зазвичай від кількох до кількох десятків секунд). Перевірити поточну версію можна так: * Перегляньте номер версії в нижньому лівому куті інтерфейсу Teable * Скористайтеся обліковим записом адміністратора, щоб відкрити панель адміністратора * Виконайте `docker inspect --format='{{.Config.Image}}'`, щоб перевірити версію образу. Якщо ви використовуєте канал `latest`, повнофункціональне розгортання містить допоміжний сценарій `pin-image.sh`, який визначає, якому випуску зараз відповідає `latest`. 1. Спочатку перевірте журнали контейнера для діагностики: `docker compose logs teable` 2. Якщо проблема пов’язана з міграцією бази даних, спробуйте відновити дані з резервної копії 3. Якщо проблема не зникає, виконайте відкат до попередньої версії 4. Зверніться до служби підтримки за адресою [support@teable.ai](mailto:support@teable.ai)