FAQ

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

Практичні короткі посібники з налаштування служби, доступу та типових дій клієнтів.

> Створення публічного SSH ключа в терміналі

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

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

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

Кроки в терміналі

  1. Відкрий Terminal, Windows Terminal або PowerShell.
  2. Виконай: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Погодься зі стандартним шляхом або вибери безпечне місце.
  4. Покажи публічний ключ: cat ~/.ssh/id_ed25519.pub.
  5. У Windows PowerShell використай: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Скопіюй увесь рядок ssh-ed25519 у поле SSH public key.

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

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

> Створення SSH ключа у Windows через графічний інтерфейс

Використай PuTTYgen у Windows і скопіюй тільки публічний ключ.
faq/create-ssh-key-windows-gui-uk

Потрібна тільки публічна частина

PuTTYgen створює публічний і приватний ключ. У Cli>_ додай лише публічний ключ, а приватний зберігай локально.

Кроки у Windows

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

Не передавай секретні дані

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

> Pidkliuchennia vlasnoho domena

Перед перемиканням перевірте authoritative DNS, точний hostname, тип запису, apex чи subdomain і конфліктні старі записи.
faq/pidkliuchennia-vlasnoho-domena

Вирішує точний hostname

Спершу визначте, підключаєте apex як example.com чи subdomain як app.example.com. Від цього залежить тип DNS-запису та обмеження провайдера.

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

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

Безпечний rollback

Не вимикайте старий hosting, доки новий hostname не відповідає правильно. Для проблеми надішліть домен, очікувану ціль і публічний DNS-результат, а не login до registrar.

> Peredacha DNS-zony

A/AAAA вказують на адреси, CNAME на alias, MX на пошту, TXT на перевірки, SPF, DKIM або DMARC.
faq/peredacha-dns-zony

Не змішуйте записи навмання

Кожен DNS-тип має окрему роль. A і AAAA ведуть на IP, CNAME створює alias, MX маршрутизує пошту, TXT містить перевірки й mail policies, CAA обмежує certificate authorities.

Копіювання записів

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

Якщо DNS не працює

Надішліть hostname, тип запису, очікуване значення і публічний результат. Не надсилайте DNS login або screenshots з API tokens.

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

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

Один постійний робочий доступ

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

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

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

Доступ без передавання пароля

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

> Як працює передплачений кредит

Кредит показує баланс, прогноз роботи, денну вартість активних сервісів і видимий строк видалення після призупинення.
faq/prepaid-credit-how-it-works

Баланс зменшується під час роботи сервісу

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

Як не довести до призупинення

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

Коли баланс виглядає неочікувано

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

> Місячна оцінка, річна оцінка і реальна денна витрата

Місячні й річні суми потрібні для порівняння; у prepaid-сервісах важлива денна витрата після підтвердженої зміни.
faq/billing-periods-and-credit-burn

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

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

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

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

Спір за конкретний період

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

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

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

Pending не обов’язково означає помилку

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

Дії після платежу

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

Дані, які не потрібні

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

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

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

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

Форми замовлення призначені для назви сервісу, домену, DNS-плану, сховища, CPU, RAM, email адміністратора або публічного SSH-ключа. Паролі, private keys і токени туди не належать.

Підготовка до checkout

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

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

Якщо не впевнені, чи значення є секретом, спершу запитайте без його надсилання. Не надсилайте private keys, паролі, токени, database dumps або повні конфігураційні файли.

> Зміна CPU, RAM, диска або retention після замовлення

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

Це зміна існуючого сервісу

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

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

  1. Перегляньте поточні CPU, RAM, диск, backup і Offsite Archive.
  2. Перевірте нову денну ціну та вплив на кредит.
  3. Прочитайте попередження про рестарт, maintenance або downtime.
  4. Зробіть власний export перед ризиковою зміною.

Якщо зміна не застосувалася

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

> Скасування сервісу і дата видалення даних

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

Скасування не завжди миттєво видаляє дані

Для provisioned-сервісу спочатку застосовується призупинення і показується конфігурований строк видалення. До цього моменту можна планувати export або звернення щодо відновлення.

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

  1. Зробіть власний export потрібних даних.
  2. Прочитайте дату й час запланованого видалення.
  3. Не плутайте backups або Offsite Archive з lifecycle-видаленням.
  4. Зверніться в підтримку до дедлайну, якщо не впевнені.

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

Після видимої дати не варто розраховувати, що дані залишаться доступними. Для питання надішліть номер замовлення і назву сервісу, а не exports чи логіни.

> Backups і запити на restore

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

Backup не є архівом чи export

Retention backup залежить від продукту й опцій. Backup допомагає після помилки, але не замінює власний export, audit archive або Offsite Archive.

Запит restore без зайвого

  1. Вкажіть назву сервісу та номер замовлення.
  2. Опишіть приблизний час, до якого треба повернутися.
  3. Уточніть, чи потрібен весь сервіс або підтримувана частина.
  4. Додайте видиму помилку без паролів, токенів і private keys.

Наслідки перед restore

Якщо сервіс уже приймав нові дані, restore може замінити їх старішим станом. Попередьте команду і експортуйте те, що не хочете втратити.

> Для чого потрібен Offsite Archive

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

Архів поза щоденною роботою

Offsite Archive призначений для віддалених архівних копій і довшого зберігання. Це не live-диск для програми і не те саме, що короткі операційні backups.

Коли вмикати архів

  1. Використовуйте для даних, які треба тримати поза звичайним сервісом.
  2. Оберіть retention у днях за compliance або recovery-ціллю.
  3. Пам’ятайте, що ціна росте від обсягу й часу зберігання.
  4. Для великих даних плануйте також власний export.

Вартість у MB-days

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

> Вибір CPU, RAM і диска для VPS

Розмір VPS обирайте за програмою, базою даних, cache, logs і ростом; OOM або постійний swap означають потребу в більшій RAM.
faq/vps-cpu-ram-and-disk-sizing

Починайте з реального навантаження

Малий статичний сайт має інші потреби, ніж база даних, Java app, пошук або build-контейнер. Враховуйте пам’ять програми, cache, logs, uploads і запас росту.

Ознаки замалого плану

  1. Збільшуйте RAM при OOM, out of memory, process killed або swap.
  2. Збільшуйте CPU при тривалому compute, compression або builds.
  3. Збільшуйте диск до заповнення filesystem, logs або бази.
  4. Після зміни перевірте, чи зник початковий ліміт.

Корисні дані для sizing

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

> Коли VPS потрібна публічна IP

Виділена публічна IP допомагає для allowlist, inbound-доступу, стабільного outbound-джерела або сервісів, прив’язаних до адреси.
faq/vps-public-ip-options

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

Public IP не потрібна кожному сервісу. Найчастіше вона потрібна для вимог партнера, провайдера або firewall щодо allowlist, стабільного outbound або inbound на конкретний порт.

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

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

Тримайте порти закритими за замовчуванням

Публічна IP не означає відкриття всіх портів. Проєктуйте доступ лише для мінімально потрібних сервісів і не надсилайте паролі, private keys або секретні firewall rules.

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

Без придбаної public IP VPS підключається через спільний SSH endpoint з високим портом; з public IP додається прямий SSH на цю адресу.
faq/shared-ssh-access-for-vps

Навіщо потрібен високий порт

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

Як підключатися

  1. Для shared SSH скопіюйте username, public host і високий port зі сторінки сервісу.
  2. Використовуйте ssh -p <port> <username>@<public-host>.
  3. Якщо куплено public IP, може бути другий прямий SSH endpoint на IP або її DNS.
  4. Private key використовуйте тільки локально; підтримці надсилайте host, port, username і видиму помилку.

Коли public IP уже куплена

Public IP не прибирає shared endpoint; вона додає прямий шлях, корисний для allowlist, моніторингу або прямого підключення. Ви можете бачити два SSH-шляхи, і не припускайте port 22, якщо сервіс його не показує.

> Чеклист перед підключенням власного домену

Перед перемиканням перевірте authoritative DNS, точний hostname, тип запису, apex чи subdomain і конфліктні старі записи.
faq/custom-domain-readiness-checklist

Вирішує точний hostname

Спершу визначте, підключаєте apex як example.com чи subdomain як app.example.com. Від цього залежить тип DNS-запису та обмеження провайдера.

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

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

Безпечний rollback

Не вимикайте старий hosting, доки новий hostname не відповідає правильно. Для проблеми надішліть домен, очікувану ціль і публічний DNS-результат, а не login до registrar.

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

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

Не змішуйте записи навмання

Кожен DNS-тип має окрему роль. A і AAAA ведуть на IP, CNAME створює alias, MX маршрутизує пошту, TXT містить перевірки й mail policies, CAA обмежує certificate authorities.

Копіювання записів

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

Якщо DNS не працює

Надішліть hostname, тип запису, очікуване значення і публічний результат. Не надсилайте DNS login або screenshots з API tokens.

> DNS propagation і TTL без обіцянки по хвилинах

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

Propagation — це cache

У DNS немає точного часу в хвилинах. Після зміни authoritative DNS різні resolvers можуть повертати старі й нові відповіді, поки не спливе TTL cache.

Для планової зміни

  1. Знизьте TTL наперед, якщо провайдер дозволяє.
  2. Не робіть випадкові повторні зміни, поки cache спливає.
  3. Тестуйте з кількох resolvers, якщо результати різняться.
  4. Запишіть час, старе значення, нове значення і TTL.

Контекст для діагностики

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

> Планування сховища Nextcloud

Враховуйте файли користувачів, shared folders, versions, trash, previews, sync overhead і ріст команди.
faq/nextcloud-storage-planning

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

Місце займають користувацькі файли, shared folders, deleted files, versions, previews, thumbnails, sync clients і imports. Біля ліміту можуть ламатися uploads або sync.

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

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

Як повідомляти про sync-проблеми

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

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

Плануйте перенесення Git разом із LFS, submodules, правами, deploy keys, webhooks і CI/CD.
faq/gitea-repository-migration

Міграція — це не лише git clone

Окрім історії репозиторію, треба перенести або заново налаштувати owners, teams, protected branches, protected tags, Git LFS, submodules, deploy keys, webhooks і CI/CD.

Перевірка перед cutover

  1. Складіть список репозиторіїв, owners, груп доступу й automation accounts.
  2. Перевірте Git LFS, submodules і branch/tag protections.
  3. Після перенесення протестуйте clone, push, Git LFS, submodules і CI.
  4. Скасуйте або rotate старі tokens без передавання їх значень.

Секрети під час міграції

Не надсилайте tokens, private keys, приватну частину deploy key або CI secrets. Достатньо назв репозиторіїв, типу інтеграції і видимої помилки.

> Домен відправника для Listmonk

Для кампаній підготуйте sender domain або subdomain, From identity, SPF, DKIM, DMARC, bounce і unsubscribe.
faq/listmonk-sender-domain-basics

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

Listmonk потребує чіткої From identity і DNS-записів, які можна перевірити. SPF, DKIM і DMARC мають узгоджуватися з доменом або subdomain кампаній.

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

  1. Оберіть sender domain або subdomain і From name.
  2. Додайте verification records, SPF, DKIM selector і DMARC.
  3. Протестуйте delivery, bounce або Return-Path і посилання.
  4. Перевірте unsubscribe і List-Unsubscribe.

Не додавайте email-секрети в ticket

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

> Runtime-налаштування для Classic Hosting

Classic Hosting може працювати в auto або manual Runtime; CPU, RAM, storage, backups, Offsite Archive, uploads, cache і logs впливають на ціну та стабільність.
faq/classic-hosting-runtime-settings

Auto не є єдиним правильним вибором

Auto Runtime допомагає з розпізнаними проєктами, але manual mode потрібен, коли треба точно вибрати Nginx, Apache, FrankenPHP або конкретний language runtime. PHP selector використовуйте лише там, де runtime його підтримує.

Налаштування перед deploy

  1. Оберіть auto або manual Runtime за framework і build-процесом.
  2. Виберіть PHP 8.2, 8.3 або 8.4 для підтримуваних PHP-сценаріїв.
  3. Налаштуйте CPU, RAM, disk, backup retention і Offsite Archive.
  4. Після deploy протестуйте uploads, cache, logs і видимі помилки.

Якщо програма не стартує

Надішліть runtime mode, мову або PHP version, видиму помилку, що змінилося і час deploy. Не надсилайте .env, паролі, токени або повні logs із секретами.

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

Найбільше допомагають номери замовлень, назви сервісів, домени, час, public hosts, ports, hosting settings, screenshot і видимі помилки без секретів.
faq/support-safe-information-to-share

Контекст корисніший за секрети

Підтримка реагує швидше, коли має номер замовлення, назву сервісу, домен, public host або port, час проблеми, що змінювалося і точний видимий текст помилки.

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

  1. Вкажіть замовлення, сервіс, домен, час і крок, на якому сталася проблема.
  2. Для hosting додайте runtime, PHP або language, CPU, RAM, disk, uploads, cache і logs без секретів.
  3. На screenshots приховуйте passwords, tokens, private keys і персональні дані.
  4. Якщо не впевнені, спершу запитайте без надсилання даних.

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

Не надсилайте passwords, private keys, recovery seeds, API tokens, session cookies, database exports, повний .env, повні logs із секретами або внутрішні деталі інфраструктури.