FAQ

Часті питання

Корисні короткі інструкції для налаштування сервісів, доступу та типових дій користувачів.

> Як працює кредитна система Cli>_?

Один спільний передплачений баланс фінансує всі відповідні сервіси й витрачається лише під час їх активної роботи.
faq/prepaid-credit-how-it-works

Ваш обліковий запис Cli>_ має один спільний передплачений кредитний баланс. Нові клієнти, які відповідають вимогам, можуть отримати Starter Credit лише після завершення обов’язкової перевірки облікового запису та захисту від зловживань. Активні відповідні сервіси поступово витрачають баланс. Місячна оцінка використовує 31 день, а новий сервіс запускається лише якщо баланс покриває щонайменше 7 днів. Червоне попередження з’являється, коли прогнозований час роботи падає нижче 7 днів; інакше помаранчеве з’являється, коли він падає нижче 14 днів.

Після вичерпання балансу сервіс призупиняють через 7 днів, він припиняє витрачати кредит і починається 7-денний строк зберігання та видалення. До показаного терміну його можна перезапустити за достатнього кредиту. Скасування підготовленого сервісу також призупиняє його та запускає той самий строк. Сервіс в очікуванні, який ще не підготовлено, може деактивуватися негайно. Після терміну починаються деактивація та видалення підготовленого сервісу. Force delete негайно деактивує сервіс, пропускає зберігання та запускає видалення з активного runtime; завершення відбувається після обробки deployment і GitOps. Резервні копії та Offsite Archive мають окремі правила зберігання.

Приклад OpenCode за 9,90 EUR: 9,90 / 31 ≈ 0,319 EUR на день. За 10 повних днів витрачається близько 3,19 EUR. Якщо початковий баланс був рівно 9,90 EUR і інших сервісів не було, залишиться близько 6,71 EUR. Після вимкнення подальше списання припиняється.

Приклад наведено для пояснення. Завжди діють поточні ціни, показані в Cli>_.

> Як створити публічний SSH-ключ за допомогою терміналу

Створіть публічний SSH-ключ для безпечного доступу до віртуального сервера. Передавайте лише публічний ключ, а приватний ключ зберігайте на своєму пристрої.
faq/generate-public-ssh-key-uk

Використовуйте лише публічний ключ

Для SSH використовується пара ключів. У налаштуваннях сервісу вставляйте лише публічний ключ, зазвичай файл з розширенням .pub. Приватний ключ залишається на вашому пристрої.

Інструкція

  1. Відкрийте термінал на своєму комп'ютері.
  2. Виконайте команду: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Підтвердіть збереження файлу або виберіть власний шлях. Ніколи не надсилайте свій приватний ключ.
  4. Показати публічний ключ за допомогою команди: cat ~/.ssh/id_ed25519.pub.
  5. Скопіюйте весь рядок, що починається з ssh-ed25519, і вставте його у поле "SSH public key" під час оформлення замовлення або налаштування сервісу.
  6. Скопіюйте увесь рядок, що починається з `ssh-ed25519`, та вставте його у поле "SSH Public Key".

Перевір перед вставленням

  1. Відкрийте PowerShell або Windows Terminal.
  2. Виконайте команду: ssh-keygen -t ed25519 -C "ваш_email@example.com".
  3. Натисніть Enter, щоб зберегти ключ у C:\Users\ваше_ім'я\.ssh\id_ed25519, або вкажіть власний шлях.
  4. Якщо Windows запитує парольну фразу, використовуйте ту, яку ви можете безпечно зберігати, або натисніть Enter, щоб пропустити цей крок для простого налаштування.
  5. Публічний ключ можна переглянути за допомогою команди: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Скопіюйте лише повний рядок, що починається з ssh-ed25519. Не копіюйте та не завантажуйте файл із приватним ключем.
> Як створити SSH-ключ графічним способом у Windows

Графічний посібник у Windows для створення пари SSH-ключів без використання командного рядка.
faq/create-ssh-key-windows-gui-uk

Використовуйте інструмент Windows і вставте лише публічний ключ

Ви можете створити пару SSH-ключів за допомогою графічного інтерфейсу, використовуючи клієнт SSH для Windows, наприклад, PuTTYgen. Cli>_ потрібен лише публічний ключ. Зберігайте файл приватного ключа на своєму комп'ютері та не завантажуйте його у веб-формі.

Інструкція

  1. Встановіть PuTTY або відкрийте PuTTYgen, якщо він вже встановлений.
  2. Виберіть EdDSA/Ed25519, якщо це доступно, або RSA 4096, якщо інструмент Ed25519 не пропонує такий варіант.
  3. Натисніть кнопку Generate і рухайте мишкою по порожній області, поки ключ не буде згенеровано.
  4. Додайте парольну фразу, якщо ви хочете додатковий локальний захист для приватного ключа.
  5. Збережіть приватний ключ на своєму комп'ютері та тримайте його в секреті.
  6. Скопіюйте текст публічного ключа та вставте його у поле SSH public key.

Не передавайте конфіденційні дані

Не надсилайте файли .ppk, приватні ключі, паролі або токени до служби підтримки чи у форми.

> Підключіть власний домен

Дізнайтеся, як направити власний домен або піддомен на сервіс CLIopen перед увімкненням функції "Підключення власного домену".
faq/pidkliuchennia-vlasnoho-domena

Що робить це налаштування

Функція "Використання власного домену" дозволяє вашому сервісу відповідати на запити, використовуючи ваш власний хостнейм, наприклад, app.example.com, замість використання стандартного згенерованого хостнейму *.co.cliopen.cloud. Перед використанням хостнейму в сервісі, необхідно, щоб DNS-сервери були налаштовані для перенаправлення трафіку на CLIopen.

Перед початком

  1. Оберіть точну назву хоста, яку ви хочете використовувати, наприклад, app.example.com. Найпростіше - використовувати піддомен.
  2. Відкрийте панель керування DNS у вашого реєстратора домену або провайдера DNS.
  3. Видаліть будь-які конфліктуючі записи A, AAAA, CNAME, ALIAS або перенаправлення для цієї назви хоста.
  4. Залишайте згенероване CLIopen ім'я хоста активним, поки ваше власне ім'я хоста не буде перевірено та повністю функціонує.

Рекомендовані налаштування DNS для піддомену

Створіть записи DNS для точного імені хоста, яке ви введете в CLIopen. Для app.example.com позначення DNS є app. Направте його на адреси CLIopen ingress, які ви отримаєте від служби підтримки CLIopen або в документації сервісу. Якщо ваш провайдер запитує тип запису, використовуйте запис типу A для IPv4 та запис типу AAAA для IPv6, якщо ці адреси надано.

Приклад:

app.example.com.  A     <CLIopen IPv4 адреса>
app.example.com.  AAAA  <CLIopen IPv6 адреса, якщо вона надана>```

Коли CLIopen надає ціль CNAME

Для деяких сервісів CLIopen може надати згенероване ім'я хоста, наприклад, service.customer.co.cliopen.cloud. Якщо інструкції для вашого сервісу явно вказують використовувати CNAME, створіть запис, такий як app.example.com CNAME service.customer.co.cliopen.cloud. Використовуйте CNAME лише для піддоменів, а не для домену верхнього рівня (apex/root), якщо ваш DNS-провайдер не підтримує ALIAS або ANAME flattening.

Використання кореневої доменної зони

Для кореневої доменної зони, наприклад example.com, більшість провайдерів DNS не дозволяють використовувати стандартний CNAME запис. Використовуйте A/AAAA записи, що вказують на адреси CLIopen ingress, або використовуйте функцію ALIAS/ANAME вашого провайдера, якщо CLIopen надав вам цільове ім'я хоста.

Делегування всієї підзони

Якщо ви хочете, щоб CLIopen керував записами підпіддомену, таким як apps.example.com, створіть NS записи для цього піддомену, що вказують на DNS-сервери CLIopen, які вам надано. Не змінюйте DNS-сервери для цілого домену, якщо ви не хочете, щоб CLIopen (або інша служба DNS) керувала всіма записами.

Перелік необхідних дій

  1. Зачекайте поширення DNS. Невеликі зміни часто стають видимими протягом кількох хвилин, але деякі провайдери можуть мати довший час кешування.
  2. Переконайтеся, що ім'я хоста вказує на цільовий сервер CLIopen, а не на попереднього провайдера.
  3. У поле "Підключити власний домен" введіть точне ім'я хоста без `https://` та будь-яких шляхів.
  4. Після оновлення протестуйте `https://app.example.com` у вашому браузері.
  5. Залишайте старі DNS-записи лише в тому випадку, якщо вони не конфліктують з новим іменем хоста.
> Як перенести зону DNS в CLIopen

Передайте домен на ns1.cliopen.com і ns2.cliopen.com, щоб CLIopen міг публікувати записи для всієї зони.
faq/peredacha-dns-zony

Що означає перенесення зони тут

Для DNS-сервісів клієнтів, перенесення означає зміну авторитетних іменних серверів у вашого реєстратора доменів. Після делегування на CLIopen, записи DNS, додані в CLIopen, публікуються з наших авторитетних іменних серверів.

Перед зміною nameserverів

  1. Скопіюйте існуючі записи DNS, які вам все ще потрібні, наприклад, веб-сайт, пошту, перевірки, SPF, DKIM, DMARC та службові записи.
  2. Додайте зону в CLIopen DNS. Якщо делегування ще не готове, CLIopen збереже її, але не активує для клієнта, поки не буде пройдено валідація.
  3. Якщо можливо, створіть необхідні записи в CLIopen DNS перед перемиканням іменних серверів.
  4. Будь ласка, уважно налаштуйте запис CAA, оскільки неправильні значення можуть завадити отриманню сертифікатів.

Делегуйте зону

  1. Відкрийте налаштування домену у вашого реєстратора, наприклад, example.com.
  2. Знайдіть розділи "Nameservers", "DNS delegation" або "Авторитетні DNS-сервери".
  3. Замініть поточні nameservers значеннями ns1.cliopen.com та ns2.cliopen.com.
  4. Збережіть зміни та зачекайте поширення у реєстрі та резолверах.

Перевірка

Поверніться до CLIopen DNS і натисніть кнопку "Перевірити делегування". Коли публічні записи NS відображають ns1.cliopen.com і ns2.cliopen.com, зона буде додана в чергу на синхронізацію, і записи стануть активними від CLIopen.

> Реєстрація облікового запису та перше вхід

Створіть один робочий обліковий запис, заповніть інформацію для виставлення рахунків і збережіть доступ до електронної пошти, щоб ваша команда не втратила його.
faq/account-registration-and-login

Один обліковий запис для замовлень та управління

Використовуйте цей обліковий запис як довгострокове рішення для замовлень, інформації про оплату, сервісів, доменів і спілкування зі службою підтримки. Найкраще використовувати робочу електронну адресу, до якої команда матиме доступ навіть після змін у складі персоналу.

Перед першим замовленням

  1. Зареєструйтеся, використовуючи свою робочу електронну адресу.
  2. Підтвердьте отримання електронного листа, якщо сайт запросить це.
  3. Вкажіть дані для виставлення рахунку перед оформленням платної замовлення.
  4. Увімкніть двофакторну автентифікацію, коли вона стане доступною, одразу після першого входу в систему.

Доступ для команди

Не надсилайте паролі колегам через чат або електронну пошту. Якщо доступ потрібен кільком особам, використовуйте внутрішній менеджер паролів або дотримуйтесь рекомендованої командної процедури; служба підтримки не потребує вашого пароля чи токену.

> Місячний прогноз, щорічний прогноз і фактичне добове споживання

Місячні та річні ціни використовуються для порівняння; у випадку послуг з попередньою оплатою, щомісячна норма витрати визначається після підтвердження змін.
faq/billing-periods-and-credit-burn

Порівняння не є календарем виставлення рахунків

Використовуйте місячну оцінку як порівняння за 31 день, а річну – як порівняння за 372 дні. Фактичне споживання кредиту для послуг з попередньою оплатою відбувається відповідно до фактичного часу використання сервісу та підтвердженої конфігурації.

Що потрібно перевірити при зміні ціни

  1. Порівняйте денне споживання до і після зміни.
  2. При використанні більшої кількості CPU, RAM або дискового простору, а також при виборі платних опцій, слід очікувати збільшення щоденного споживання.
  3. Зміна набуває чинності лише після підтвердження, можливої оплати та застосування.
  4. Для бухгалтерії збережіть підтвердження замовлення та історію кредиту.

У разі виникнення суперечок враховуйте конкретний період

Номер замовлення, назва сервісу та дати допоможуть службі підтримки перевірити нарахування. Не надсилайте банківські дані або скріншоти з зайвою особистою інформацією.

> Статус замовлення після оплати

Після оплати замовлення може деякий час очікувати підтвердження від постачальника послуг; створюйте дублікати лише тоді, коли перше замовлення явно скасовано або закінчився термін його дії.
faq/order-status-and-payment-confirmation

Статус "В обробці" не завжди означає помилку

Після повернення зі сторінки оплати замовлення може ще чекати на підтвердження від платіжної системи. Поки статус не відображається як невдалий або закінчений, повторне оформлення замовлення може ускладнити обробку платежів.

Як діяти після оплати

  1. Після завершення платежу поверніться до Cli>_.
  2. У вашому обліковому записі перевірте статус замовлення та будь-які повідомлення, які могли бути надіслані під час оплати.
  3. Якщо замовлення все ще обробляється, дайте постачальнику час для його підтвердження.
  4. У разі виникнення проблем, повідомте службу підтримки номер замовлення та референс платежу, якщо він у вас є.

Дані, які не потрібно надсилати

Служба підтримки не потребує даних платіжної картки, паролів або повних банківських підтверджень. Достатньо номера замовлення, часу оплати, видимого статусу та скріншота з прихованими конфіденційними даними, якщо відображається помилка.

> Дані, які пришвидшать налаштування сервісу

Підготуйте назву сервісу, доменне ім'я, обсяг сховища, адресу електронної пошти для доступу та публічний SSH-ключ; секретні дані не вводяться у форми.
faq/service-setup-information-needed

Точні дані економлять час

Використовуйте форми замовлення для публічних або неконфіденційних значень: назва сервісу, домен, план DNS, розмір сховища, CPU, RAM, email адміністратора або публічний SSH-ключ. Паролі, приватні ключі та токени не повинні вводитися у форми.

Підготуйтеся перед оформленням замовлення

  1. Оберіть зрозумілу назву сервісу для вашої команди.
  2. Вирішіть, чи будете використовувати власний домен або тимчасовий системний hostname.
  3. Підготуйте публічний SSH-ключ, якщо це необхідно для сервісу.
  4. Перевірте обсяг сховища та ресурси відповідно до програми, яку ви плануєте запустити.

Не вводьте секрети у форми

Якщо ви не впевнені, чи є дані конфіденційними, краще запитайте, перш ніж надсилати їх. Не надсилайте приватні ключі, паролі, токени, дамп баз даних або повні конфігураційні файли в чат або у замовлення.

> Зміна CPU, RAM, диска або обсягу пам'яті після оформлення замовлення

Змінюйте параметри існуючого сервісу через його сторінку налаштувань, а не створюючи нове замовлення. Зміна ресурсів може вплинути на ціну, щоденне споживання кредитів, необхідність перезавантаження та ризик простою.
faq/change-service-resources-after-order

Ви змінюєте наявний сервіс, а не створюєте новий

Якщо сервіс вже працює, зміну ресурсів слід робити в його деталях. Нове замовлення створить інший сервіс замість редагування існуючого, і може змінити ціну, щоденне споживання кредитів та поведінку після підтвердження, оплати та застосування змін.

Перед підтвердженням змін

  1. Перегляньте поточне використання CPU, RAM, дискового простору, інформацію про резервне копіювання та термін зберігання Offsite Archive.
  2. Перевірте нову щоденну ціну та її вплив на ваш кредитний ліміт.
  3. Ознайомтеся з повідомленнями про перезавантаження, технічне обслуговування або простої.
  4. Перш ніж вносити ризиковані зміни, створіть власний експорт важливих даних.

Що робити, якщо зміна не відбулася

Надішліть назву сервісу, час зміни, видимий статус і текст помилки. Не надсилайте приватні ключі, паролі або токени; для діагностики достатньо публічного контексту та замаскованого скріншота.

> Припинення дії послуги та термін видалення даних

Надана послуга спочатку призупиняється, відображається налаштовуваний видимий термін видалення, після чого може бути виконано остаточне очищення.
faq/cancel-service-and-data-retention

Скасування не завжди призводить до миттєвого видалення даних

Для сервісу, який вже активовано, спочатку застосовується призупинення, і відображається конфігурований період часу, протягом якого можна відновити або експортувати дані. Очікуючі незамовлені замовлення без активних даних можуть мати іншу поведінку, а остаточне видалення відбувається лише після закінчення терміну дії.

Перевірте перед скасуванням

  1. Створіть власний експорт даних, які вам потрібно зберігати протягом тривалого часу.
  2. Ознайомтеся з датою та часом запланованого видалення при призупиненні роботи сервісу.
  3. Не плутайте резервне копіювання та Offsite Archive з видаленням даних відповідно до життєвого циклу.
  4. Якщо ви не впевнені, зверніться до служби підтримки ще до терміну видалення.

Відновлення після закінчення терміну може бути неможливим

Після закінчення зазначеного терміну дані вважаються недоступними. У разі запитань, будь ласка, надайте номер замовлення та назву сервісу, а не експорти з бази даних або конфіденційні облікові дані.

> Резервне копіювання та запити на відновлення

Резервні копії призначені для операційного відновлення, а не заміни експорту; процес відновлення може перезаписати новіші дані.
faq/backups-and-restore-requests

Резервне копіювання - це не архів і не експорт

Термін зберігання резервних копій залежить від обраного продукту та налаштувань. Резервні копії допомагають у відновленні після збою, але не замінюють власний експорт, аудитний архів або Offsite Archive. Відновлення може перезаписати новіші зміни.

Як підготувати запит на відновлення

  1. Вкажіть назву сервісу та номер замовлення.
  2. Опишіть приблизний час, до якого потрібно відновити дані.
  3. Зазначте, чи потрібно відновити весь сервіс або лише певну його частину, якщо це підтримується.
  4. Додайте видиму помилку або контекст без паролів, токенів та приватних ключів.

Оцініть наслідки перед відновленням даних

Якщо сервіс тим часом отримав нові дані, відновлення може замінити їх попереднім станом. Перед підтвердженням відновлення повідомте команду і зробіть резервну копію того, що ви не хочете втратити.

> Для чого призначений Offsite Archive

Offsite Archive зберігає віддалені архівні копії, що знаходяться окремо від звичайних резервних копій та життєвого циклу сервісу.
faq/offsite-archive-purpose

Архів поза межами звичайної роботи

Offsite Archive призначений для віддаленого архівування та тривалого зберігання даних. Це не є диском, який використовується програмою в реальному часі, заміною локального експорту або тим самим, що й короткі резервні копії.

Коли його вмикати

  1. Використовуйте для даних, які потрібно зберігати поза межами звичайного сервісу.
  2. Оберіть кількість днів зберігання відповідно до вимог нормативних документів або цілей відновлення даних.
  3. Врахуйте, що вартість зростає залежно від обсягу збережених даних та тривалості їхнього зберігання.
  4. Для великих обсягів даних плануйте архів разом із власним процесом експорту.

Як оцінювати вартість

Основа розрахунку - MB-days: скільки даних зберігається і скільки днів вони утримуються. Тариф відображається для клієнта як EUR/GB/місяць, а результат округлюється до найближчого цента.

> Вибір процесора, оперативної пам'яті та диска для VPS

Розмір віртуального сервера вибирайте відповідно до ваших потреб: типу застосунку, бази даних, кешу, журналів і очікуваного зростання. Помилки OOM або постійне використання swap вказують на необхідність збільшення обсягу оперативної пам'яті.
faq/vps-cpu-ram-and-disk-sizing

Почніть з реального навантаження, а не з відчуттів

Малий статичний веб-сайт має інші потреби, ніж база даних, Java-додаток, пошук або контейнер для збірок. Під час планування враховуйте пам'ять програми, кеш, логи, завантаження та запас для зростання.

Ознаки недостатнього плану

  1. Збільште обсяг оперативної пам'яті (RAM) у разі виникнення помилок OOM (out of memory), завершення процесів або постійного використання swap-пам'яті.
  2. Збільште продуктивність процесора (CPU) при тривалому високому навантаженні, стисненні даних, компіляції або активній роботі фонових процесів.
  3. Збільште обсяг дискового простору до того, як буде заповнена файлова система, логи або база даних.
  4. Після кожної зміни перевіряйте, чи дійсно додаток більше не досягає початкового ліміту.

Що надіслати, якщо виникли питання щодо ресурсів

Для вирішення проблеми надайте інформацію про назву сервісу, тип програми, видиму помилку, приблизний час виникнення проблеми та поточні значення CPU, RAM і дискового простору. Не надсилайте паролі, приватні ключі або внутрішні конфігураційні файли.

> Коли має сенс використовувати публічну IP-адресу для VPS

Виділена публічна IP-адреса може бути корисною, коли потрібен список дозволених IP-адрес (allowlist), доступ всередину сервера, стабільне джерело для вихідного трафіку або сервіси, прив'язані до певної адреси.
faq/vps-public-ip-options

Спочатку визначте напрямок трафіку

Публічна IP-адреса не завжди потрібна для кожної послуги. Найчастіше вона використовується для задоволення вимог зовнішніх партнерів, провайдерів або брандмауерів щодо списків дозволів (allowlist), стабільного вихідного трафіку або вхідного доступу на певний порт.

Питання перед замовленням IP-адреси

  1. Уточніть у партнера, чи потрібно використовувати allowlist для вхідного трафіку, вихідного трафіку або для обох напрямків.
  2. Використовуйте DNS-імена замість числових IP-адрес, де це можливо.
  3. Відкривайте лише ті порти, які фактично потрібні вашому додатку.
  4. Надішліть запит на додавання до списку дозволених у службу підтримки, перш ніж змінювати параметри доступу до production-середовища.

Що слід залишити закритим

Публічна IP-адреса не означає відкриття всіх портів. Забезпечуйте доступ лише до мінімально необхідних сервісів і не надсилайте паролі, приватні ключі або внутрішні правила брандмауера у вигляді скріншотів із секретною інформацією.

> Спільний SSH-доступ до VPS

Без придбаної публічної IP-адреси, ваш віртуальний сервер підключається через спільний SSH-сервер із високим портом. Якщо у вас є публічна IP-адреса, вам також буде доступне пряме SSH-з'єднання за цією адресою.
faq/shared-ssh-access-for-vps

Навіщо використовується високий порт для спільного SSH-доступу

Кілька сервісів VPS можуть використовувати один загальний публічний SSH-endpoint, тому кожен сервіс отримує власний високий порт. Порт є частиною маршрутизації до вашого сервісу; без нього підключення неможливо однозначно направити на правильну віртуальну машину.

Як підключатися залежно від типу доступу

  1. Для спільного SSH скопіюйте з сервісу ім'я користувача, публічний хост і високий порт.
  2. Використовуйте команду ssh -p <порт> <ім'я_користувача>@<публічний_хост>.
  3. Якщо сервіс має придбану публічну IP-адресу, він може мати інший SSH-endpoint безпосередньо на цій IP-адресі або її DNS-ім'ї, залежно від налаштувань сервісу.
  4. Приватний ключ використовуйте лише локально через ваш SSH-клієнт або агент; у службу підтримки надсилайте лише публічний хост, порт, ім'я користувача та видиму помилку.

Коли у вас є придбана публічна IP-адреса

Публічна IP-адреса не замінює спільний SSH-endpoint; вона додає окремий спосіб доступу, який підходить для списків дозволів, моніторингу або прямого з'єднання. На практиці ви можете бачити два способи SSH-підключення: спільний хост із високим портом і прямий хост або IP-адреса для сервісу з публічною IP-адресою.

> Перевірка перед підключенням вашого домену

Перед перемиканням на інший домен, переконайтеся в правильності налаштувань DNS, точного hostname, типу запису (основний чи піддомен) та відсутності конфліктуючих старих записів.
faq/custom-domain-readiness-checklist

Важливість точного імені хоста

Спочатку визначте, чи ви використовуєте основний домен (наприклад, example.com) або піддомен (наприклад, app.example.com). Кожен варіант може потребувати різних типів DNS-записів, інших обмежень від вашого DNS-провайдера та перевірки у реєстратора.

Перед зміною DNS

  1. Перевірте, де редагуються авторитетні DNS-записи для домену.
  2. Видаліть або змініть конфліктуючі записи A/AAAA, CNAME, ALIAS, ANAME або перенаправлення.
  3. Використовуйте тип запису, рекомендований для конкретної служби та імені хоста.
  4. Після зміни зачекайте на поширення DNS та лише потім перевіряйте остаточне HTTPS.

Безпечний відкат

Не вимикайте старий хостинг, поки новий hostname не відповідає правильно. У разі виникнення проблем надайте домен, очікуваний цільовий адрес і видимий результат DNS, а не облікові дані для реєстратора.

> Типи DNS-записів для сервісів

A/AAAA записи вказують на адреси, CNAME – на псевдонім, MX – на пошту, а TXT – на перевірки, SPF, DKIM або DMARC.
faq/dns-record-types-for-services

Не комбінуйте записи навмання

Кожен тип DNS-запису виконує іншу функцію. Записи A та AAAA вказують на IP-адреси, CNAME створює псевдонім для піддомену, MX перенаправляє пошту, TXT містить перевірки та політики електронної пошти, а CAA обмежує центри сертифікації.

При копіюванні записів

  1. Скопіюйте назву, тип і значення точно відповідно до інструкцій сервісу.
  2. Не використовуйте CNAME для хостів, які вже мають інші записи, якщо це заборонено правилами DNS.
  3. Розміщуйте DKIM під селектором від провайдера, а DMARC зазвичай під _dmarc.
  4. Налаштовуйте CAA обережно, оскільки неправильне значення може заблокувати видачу сертифіката.

Що робити, якщо DNS не працює

Надішліть у службу підтримки hostname, тип запису, очікуване значення та публічний результат. Не надсилайте логін до DNS-адміністрації або скріншоти з API-токенами.

> Поширення DNS і TTL без гарантій щодо часу

TTL визначає, як довго сервери з доступом до DNS можуть зберігати застарілі відповіді; під час переходу старі та нові результати можуть існувати одночасно.
faq/dns-propagation-and-ttl

Поширення DNS – це кешування, а не магія очікування

У системі DNS немає гарантованого часу поширення в хвилинах. Після зміни авторитетних DNS-записів різні сервери можуть повертати старі та нові відповіді, поки не закінчиться термін дії кешу TTL. Тому результат може відрізнятися залежно від мережі, країни або DNS-сервера.

При запланованій зміні

  1. Якщо ваш провайдер дозволяє, зменште TTL перед запланованою зміною.
  2. Зробіть зміни в DNS один раз і уникайте повторних редагувань, поки не закінчиться термін дії кешу.
  3. Перевіряйте з кількох серверів, якщо результати відрізняються.
  4. Запишіть час зміни, старе значення, нове значення та TTL.

Що потрібно надіслати під час діагностики

Вкажіть hostname, очікуваний результат, видиму стару відповідь, видиму нову відповідь, TTL і час зміни. Не надсилайте облікові дані для доступу до DNS або внутрішні примітки провайдера.

> Планування сховища для Workspace Suite

При плануванні обсягу враховуйте файли користувачів, спільні папки, версії, кошик, попередні перегляди, накладні витрати на синхронізацію та прогнозоване зростання.
faq/nextcloud-storage-planning

Workspace Suite росте не лише видимими файлами

Місце займають користувацькі файли, спільні папки, видалені файли, версії, попередні перегляди, мініатюри, клієнти синхронізації та імпорти. Якщо сховище наближається до ліміту, завантаження або синхронізація можуть не працювати.

Перед замовленням ресурсів

  1. Оцініть поточні дані користувачів і спільні папки.
  2. Додайте резерв для версій, кошика, попередніх переглядів та накладних витрат синхронізації.
  3. Врахуйте великі імпорти даних, нові команди та очікуваний ріст.
  4. Збільште обсяг сховища до того, як користувачі досягнуть ліміту.

У разі виникнення проблем із синхронізацією

Надайте інформацію про розмір сервісу, приблизне використання, час виникнення проблеми та видиму помилку клієнта. Не надсилайте особисті файли, паролі або експорти даних користувачів, якщо служба підтримки не запросить їх спеціально безпечним способом.

> Міграція репозиторіїв у Gitea

Перенесення Git-репозиторіїв: плануйте міграцію разом з LFS, submodules, правами доступу, ключами розгортання, вебхуками та CI/CD.
faq/gitea-repository-migration

Міграція - це не просто git clone

Окрім історії репозиторію, необхідно перенести або повторно налаштувати власників, команди, захищені гілки, захищені теги, Git LFS, підмодулі, ключі розгортання, вебхуки та інтеграції CI/CD.

Перевірка перед переходом

  1. Перелічіть репозиторії, власників, групи доступу та облікові записи автоматизації.
  2. Перевірте об'єкти Git LFS, submodules, захищені гілки та теги.
  3. Після міграції протестуйте клонування, відправлення змін, Git LFS, submodules і виконання CI.
  4. Скасуйте або змініть старі токени після завершення міграції, не передаючи їх значення.

Чутливі дані під час міграції

Не надсилайте в службу підтримки токени, приватні ключі, приховану частину ключів розгортання або секрети CI. Достатньо назв репозиторіїв, типу інтеграції, опису видимої помилки та інформації про те, що працювало до міграції.

> Домен для надсилання листів у Listmonk

Для кампаній підготуйте домен або субдомен відправника, ідентифікатор "Від", записи SPF, DKIM, DMARC, обробку повідомлень про помилки та можливість відмовитися від розсилки.
faq/listmonk-sender-domain-basics

Доставка починається з домену

Listmonk потребує чіткої ідентифікації відправника (From identity) та DNS-записів, які можуть бути перевірені поштовими сервісами. SPF, DKIM та DMARC повинні відповідати домену або піддомену, з якого ви плануєте надсилати кампанії.

Перед першою кампанією

  1. Оберіть домен або піддомен для відправки листів та вкажіть ім'я поля "From".
  2. Додайте записи DNS для верифікації, зокрема SPF, DKIM selector і DMARC.
  3. Перевірте доставку, обробку відмов (bounce) або адресу Return-Path, а також посилання в листі.
  4. Перевірте налаштування відписки та List-Unsubscribe перед надсиланням реальної розсилки.

Email-секрети не повинні потрапляти в заявку

Для діагностики, будь ласка, надайте доменне ім'я, тип запису, публічне значення DNS і повідомлення про помилку. Не надсилайте паролі SMTP, API-ключі, приватні ключі DKIM або експорти списків з особистими даними.

> Налаштування середовища виконання для Classic Hosting

Classic Hosting може працювати в автоматичному або ручному режимі. Продуктивність (CPU), обсяг оперативної пам'яті (RAM), дисковий простір, резервне копіювання, зберігання даних Offsite Archive, завантаження, кеш та логи впливають на вартість і стабільність.
faq/classic-hosting-runtime-settings

Автоматичний режим – це не завжди найкращий вибір

Auto Runtime допомагає з проєктами, які він розпізнає, але ручний режим корисний, коли вам потрібно точно вибрати Nginx, Apache, FrankenPHP або конкретне середовище виконання (runtime). Використовуйте PHP selector лише там, де обране вами середовище виконання його підтримує.

Налаштування перед розгортанням

  1. Оберіть автоматичний режим або ручне налаштування Runtime залежно від фреймворку та способу збірки.
  2. Виберіть PHP 8.2, 8.3 або 8.4 лише для сценаріїв, що підтримуються обраним середовищем виконання.
  3. Налаштуйте обчислювальні ресурси (CPU), оперативну пам'ять (RAM), дисковий простір, час збереження резервних копій та архіву Offsite відповідно до обсягу даних і трафіку.
  4. Після розгортання протестуйте завантаження, кеш, журнали та видимі помилки застосунку.

Що робити, якщо додаток не запускається

Надішліть інформацію про режим роботи, мову або версію PHP, видиму помилку, зміни, які були внесені, і приблизний час розгортання. Не надсилайте файли .env, паролі, токени або повні журнали з конфіденційними даними.

> Яку інформацію безпечно надсилати в службу підтримки?

Найбільш корисна інформація для служби підтримки: номери замовлень, назви сервісів, домени, час, публічні хости та порти, налаштування хостингу, знімки екрану та видимі помилки без секретної інформації.
faq/support-safe-information-to-share

Якісний запит містить релевантну інформацію, а не конфіденційні дані.

Служба підтримки може швидше реагувати, якщо отримує номер замовлення, назву сервісу, доменне ім'я, публічний хост або порт, час виникнення проблеми, інформацію про внесені зміни та точне повідомлення про помилку.

Безпечний зміст повідомлення

  1. Вкажіть номер замовлення, назву сервісу, домен, час та етап, на якому виникла проблема.
  2. Для проблем з хостингом вкажіть середовище виконання (runtime), версію PHP або мови програмування, процесор (CPU), оперативну пам'ять (RAM), дисковий простір, завантаження, кеш та логи, не включаючи конфіденційні дані.
  3. Перед відправкою скріншоти обріжте або затемніть конфіденційні області.
  4. Якщо ви не впевнені, чи потрібні ці дані для вирішення вашого запиту, спочатку запитайте без їх надсилання.

Що ніколи не надсилайте

Не надсилайте паролі, приватні ключі, seed-фрази відновлення, API-токены, сесійні кукі, експорти баз даних, повні файли .env, повні логи з конфіденційними даними або внутрішні деталі інфраструктури.