FAQ

Casto kladene otazky

Prakticke kratke navody pre nastavenie sluzieb, pristupov a beznych zakaznickych krokov.

> Ako vygenerovať verejný SSH klúč cez príkazový riadok

Vytvor verejný SSH klúč pre bezpečný prístup k VPS. S Cli>_ zdieľaj iba verejný klúč; súkromný klúč nechaj na svojom zariadení.
faq/ako-vygenerovat-public-ssh-kluc

Verejný klúč sa zdieľa, súkromný zostáva u teba

Do objednávky alebo nastavenia služby vlož iba verejný SSH klúč. Súkromný klúč zostáva na tvojom počítači a neposiela sa podpore ani sa nevkladá do webového formulára.

Postup

  1. Otvor terminál na svojom počítači.
  2. Spusti príkaz: ssh-keygen -t ed25519 -C "tvoj-email@example.com".
  3. Potvrď uloženie súboru alebo vyber vlastnú cestu. Súkromný klúč nikomu neposielaj.
  4. Verejný klúč zobraz príkazom: cat ~/.ssh/id_ed25519.pub.
  5. Skopíruj celý riadok začínajúci ssh-ed25519 a vlož ho do poľa SSH public key pri objednávke alebo nastavení služby.

Windows 10/11 PowerShell

  1. Otvor PowerShell alebo Windows Terminal.
  2. Spusti príkaz: ssh-keygen -t ed25519 -C "tvoj-email@example.com".
  3. Stlač Enter pre uloženie klúča do C:\Users\tvoj-user\.ssh\id_ed25519 alebo zadaj vlastnú cestu.
  4. Ak Windows žiada passphrase, použi takú, ktorú vieš bezpečne uložiť, alebo pri jednoduchom nastavení stlač Enter.
  5. Verejný klúč zobraz príkazom: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Skopíruj iba celý riadok začínajúci ssh-ed25519. Nekopíruj ani nenahrávaj súbor so súkromným klúčom.
> Ako graficky vytvoriť SSH kľúč vo Windows

Grafický postup vo Windows pre vytvorenie SSH key páru bez príkazového riadku.
faq/ako-graficky-vytvorit-ssh-kluc-vo-windows

Použi Windows nástroj a vlož iba public key

SSH key pár vieš vytvoriť aj graficky cez Windows SSH klient ako PuTTYgen. Cli>_ potrebuje iba public key. Private key súbor nechaj na svojom počítači a nenahrávaj ho do webového formulára.

Postup

  1. Nainštaluj PuTTY alebo otvor PuTTYgen, ak ho už máš nainštalovaný.
  2. Vyber EdDSA/Ed25519, ak je dostupné, alebo RSA 4096, ak nástroj Ed25519 neponúka.
  3. Klikni Generate a hýb myšou v prázdnej ploche, kým sa klúč nevytvorí.
  4. Pridaj passphrase, ak chceš lokálnu ochranu private key.
  5. Private key ulož na svoj počítač a nechaj ho tajný.
  6. Skopíruj public key text a vlož ho do poľa SSH public key v Cli>_.
> Prines svoju vlastnu domenu

Ako nasmerovat vlastnu domenu alebo subdomenu na CLIopen sluzbu pred zapnutim Bring your own domain.
faq/prines-si-vlastnu-domenu

Co toto nastavenie robi

Bring your own domain umozni, aby sluzba odpovedala na tvojom vlastnom hostname, napr. app.example.com, namiesto pouzitia iba generovaneho *.co.cliopen.cloud hostname. DNS musi smerovat na CLIopen skor, ako sa hostname bezpecne pouzije v sluzbe.

Pred zaciatkom

  1. Vyber presny hostname, ktory chces pouzit, napr. app.example.com. Najjednoduchsie je pouzit subdomenu.
  2. Otvor DNS administraciu u registratora domeny alebo DNS providera.
  3. Odstran konfliktne A, AAAA, CNAME, ALIAS alebo redirect zaznamy pre rovnaky hostname.
  4. Generovany CLIopen hostname nechaj dostupny, kym vlastny hostname nebude overeny a funkcny.

Odporucane DNS nastavenie pre subdomenu

Vytvor DNS zaznamy pre presny hostname, ktory zadas v CLIopen. Pre app.example.com je DNS nazov app. Nasmeruj ho na CLIopen ingress adresy, ktore dostanes od CLIopen supportu alebo v instrukciach sluzby. Ak DNS provider pyta typ zaznamu, pouzi A pre IPv4 a AAAA pre IPv6, ked su tieto adresy poskytnute.

Priklad:

app.example.com.  A     <CLIopen IPv4 adresa>
app.example.com.  AAAA  <CLIopen IPv6 adresa, ak je poskytnuta>

Ked CLIopen poskytne CNAME ciel

Pri niektorych sluzbach moze CLIopen poskytnut generovany hostname, napr. service.customer.co.cliopen.cloud. Ak instrukcie pre tvoju sluzbu vyslovene hovoria pouzit CNAME, vytvor app.example.com CNAME service.customer.co.cliopen.cloud. CNAME pouzivaj iba pre subdomeny, nie pre apex/root domeny, pokial tvoj DNS provider nepodporuje ALIAS alebo ANAME flattening.

Pouzitie root domeny

Pre example.com bez subdomeny vacsina DNS providerov nepovoli bezny CNAME. Pouzi A/AAAA zaznamy na CLIopen ingress adresy alebo provider-specific ALIAS/ANAME funkciu, ak ti CLIopen poskytol hostname ciel.

Delegovanie celej sub-zony

Ak chces, aby CLIopen spravoval zaznamy pod sub-zonou ako apps.example.com, vytvor NS zaznamy pre tuto sub-zonu na CLIopen nameservery, ktore dostanes. Nemen nameservery celej domeny, ak nechces zamerne presunut spravu vsetkych zaznamov.

Kontrolny zoznam

  1. Pockaj na DNS propagaciu. Male zmeny su casto viditelne do par minut, ale niektori provideri cache-uju dlhsie.
  2. Over, ze hostname smeruje na CLIopen ciel a nie na stareho providera.
  3. Do pola Bring your own domain zadaj presny hostname, bez https:// a bez cesty.
  4. Po aktualizacii sluzby otestuj https://app.example.com v prehliadaci.
  5. Stare DNS zaznamy nechaj len vtedy, ak nekoliduju s novym hostname.
> Ako preniesť DNS zónu do CLIopen

Deleguj doménu na ns1.cliopen.com a ns2.cliopen.com, aby CLIopen publikoval záznamy pre celú zónu.
faq/ako-preniest-dns-zonu-do-cliopen

Čo tu znamená prenos zóny

Pri zákazníckom DNS prenos znamená zmenu autoritatívnych nameserverov u registrátora domény. Po delegovaní na CLIopen sa DNS záznamy pridané v CLIopen publikujú z našich autoritatívnych nameserverov.

Pred zmenou nameserverov

  1. Skopíruj existujúce DNS záznamy, ktoré stále potrebuješ, napríklad web, mail, verifikácie, SPF, DKIM, DMARC a servisné záznamy.
  2. Pridaj zónu v CLIopen DNS. Ak delegácia ešte nie je pripravená, CLIopen ju uloží, ale zákazníkovi ju neaktivuje, kým validácia neprejde.
  3. Ak je to možné, vytvor potrebné záznamy v CLIopen DNS ešte pred prepnutím nameserverov.

Deleguj zónu

  1. Otvor nastavenia domény u registrátora, napríklad example.com.
  2. Nájdi Nameservers, DNS delegation alebo Authoritative DNS nastavenia.
  3. Nahraď aktuálne nameservery hodnotami ns1.cliopen.com a ns2.cliopen.com.
  4. Ulož zmenu a počkaj na propagáciu v registri a resolveroch.

Validácia

Vráť sa do CLIopen DNS a klikni na Znovu overiť delegáciu. Keď verejné NS záznamy ukazujú ns1.cliopen.com a ns2.cliopen.com, zóna sa zaradí na synchronizáciu a záznamy budú živé z CLIopen.

> Registrácia účtu a prvé prihlásenie

Založ jeden pracovný účet, doplň fakturačné údaje a nechaj prístup na e-maili, ktorý tím nestratí.
faq/account-registration-and-login

Jeden účet pre objednávky aj správu

Účet používaj ako dlhodobé miesto pre objednávky, fakturačné údaje, služby, domény a komunikáciu so supportom. Najvhodnejší je pracovný e-mail, ku ktorému bude mať tím prístup aj po personálnych zmenách.

Pred prvou objednávkou

  1. Zaregistruj sa pracovnou e-mailovou adresou.
  2. Dokonči potvrdenie e-mailu, ak ho stránka vyžiada.
  3. Doplň fakturačné údaje skôr, než odošleš platenú objednávku.
  4. Ak bude dostupné dvojfaktorové overenie, zapni ho hneď po prvom prihlásení.

Prístup pre tím

Heslo neposielaj kolegom cez chat ani e-mail. Ak potrebuje prístup viac ľudí, používajte interný password manager alebo požiadajte o odporúčaný tímový postup; podpora nepotrebuje tvoje heslo ani prihlasovací token.

> Ako funguje predplatený kredit

Kredit ukazuje zostatok, odhad výdrže, dennú spotrebu aktívnych služieb a viditeľný termín vymazania pri pozastavení.
faq/prepaid-credit-how-it-works

Kredit sa míňa počas behu služby

Pri predplatených službách sa zostatok znižuje podľa aktívneho času a zvolených parametrov. Denná cena nie je len orientačná tabuľka; pomáha odhadnúť, koľko dní služba vydrží pri aktuálnom kredite a kedy sa môže objaviť viditeľný termín vymazania.

Ako predísť pozastaveniu

  1. Po prihlásení sleduj viditeľný zostatok a odhad výdrže.
  2. Pred potvrdením objednávky alebo zmeny skontroluj novú dennú cenu.
  3. Dobíj kredit s rezervou, nie až v deň vyčerpania.
  4. Pri pozastavenej službe si hneď pozri termín možného vymazania dát.

Keď zostatok nesedí s očakávaním

Pri otázke na kredit pošli číslo objednávky, názov služby a obdobie, ktoré chceš skontrolovať. Neposielaj platobné karty, heslá, súkromné kľúče ani celé výpisy s citlivými údajmi.

> Mesačný odhad, ročný odhad a reálna denná spotreba

Mesačné a ročné ceny slúžia na porovnanie; pri predplatených službách rozhoduje denná spotreba po potvrdení zmeny.
faq/billing-periods-and-credit-burn

Porovnanie nie je fakturačný kalendár

Mesačný odhad používaj ako porovnanie za 31 dní a ročný ako porovnanie za 372 dní. Skutočné čerpanie kreditu sa pri predplatených službách deje podľa aktívneho času služby a podľa potvrdenej konfigurácie.

Čo si overiť pri zmene ceny

  1. Porovnaj dennú spotrebu pred zmenou a po zmene.
  2. Pri vyššom CPU, RAM, disku alebo platených voľbách počítaj s vyšším denným čerpaním.
  3. Zmenu považuj za účinnú až po potvrdení, prípadnej platbe a aplikovaní.
  4. Pre účtovníctvo si ulož potvrdenie objednávky a históriu kreditu.

Pri spore rieš konkrétne obdobie

Supportu pomôže číslo objednávky, názov služby a dátumy, za ktoré chceš čerpanie skontrolovať. Neposielaj bankové údaje, celé platobné výpisy ani screenshoty s nechcenými osobnými údajmi.

> Stav objednávky po platbe

Objednávka môže po zaplatení chvíľu čakať na potvrdenie poskytovateľa; duplicitu vytváraj až keď je prvá jasne zrušená alebo expirovaná.
faq/order-status-and-payment-confirmation

Pending nemusí znamenať zlyhanie

Po návrate z platobnej stránky môže objednávka ešte čakať na potvrdenie od platobného poskytovateľa. Kým stav nie je jasne neúspešný alebo expirovaný, nová duplicitná objednávka môže zbytočne skomplikovať párovanie.

Ako postupovať po platbe

  1. Po dokončení platby sa vráť späť do Cli>_.
  2. V účte skontroluj stav objednávky a prípadnú správu pri platbe.
  3. Ak objednávka stále čaká, daj poskytovateľovi čas na potvrdenie.
  4. Pri probléme pošli supportu číslo objednávky a referenciu platby, ak ju vidíš.

Čo neposielať

Support nepotrebuje údaje z platobnej karty, prihlasovacie heslo ani celé bankové potvrdenie. Stačí číslo objednávky, čas platby, viditeľný stav a maskovaný screenshot, ak sa zobrazuje chyba.

> Údaje, ktoré urýchlia nastavenie služby

Priprav názov služby, doménu, veľkosť úložiska, prístupový e-mail a verejný SSH kľúč; tajné údaje do formulárov nepatria.
faq/service-setup-information-needed

Presné vstupy šetria čas

Objednávkové formuláre používaj na verejné alebo netajné hodnoty: názov služby, doménu, plán DNS, veľkosť úložiska, CPU, RAM, admin e-mail alebo verejný SSH kľúč. Heslá, private keys a tokeny patria mimo formulár.

Priprav si pred kliknutím na objednávku

  1. Vyber rozpoznateľný názov služby pre svoj tím.
  2. Rozhodni, či použiješ vlastnú doménu alebo dočasný systémový hostname.
  3. Priprav verejný SSH kľúč, ak ho služba vyžaduje.
  4. Skontroluj veľkosť úložiska a zdroje podľa aplikácie, ktorú ideš prevádzkovať.

Tajomstvá neposielaj

Ak si nie si istý, či je údaj tajný, radšej sa spýtaj bez jeho odoslania. Súkromné kľúče, heslá, tokeny, databázové dumpy a celé konfiguračné súbory neposielaj do chatu ani do objednávky.

> Zmena CPU, RAM, disku alebo retencie po objednávke

Existujúcu službu upravuj cez jej detail, nie novou duplicitnou objednávkou; pri zmene zdroje menia cenu, cena služby, denná spotreba kreditu, reštart a riziko výpadku.
faq/change-service-resources-after-order

Meníš existujúcu službu, nie zakladáš novú

Ak už služba beží, zmenu zdrojov rob z jej detailu. Nová objednávka by vytvorila ďalšiu službu namiesto úpravy existujúcej a môže zmeniť cenu, dennú spotrebu kreditu aj prevádzkové správanie po potvrdení, zaplatení a uplatnení zmeny.

Pred potvrdením zmeny

  1. Pozri aktuálne CPU, RAM, disk, zálohy a Offsite Archive retenciu.
  2. Skontroluj novú dennú cenu a vplyv na kredit.
  3. Prečítaj si upozornenie na reštart, údržbu alebo výpadok.
  4. Pred rizikovou zmenou si sprav vlastný export dôležitých dát.

Keď zmena neprebehne podľa očakávania

Pošli názov služby, čas zmeny, viditeľný stav a chybové hlásenie. Neposielaj private keys, heslá ani tokeny; na diagnostiku stačí verejný kontext a maskovaný screenshot.

> Zrušenie služby a termín vymazania dát

Provisioned služba sa najprv pozastaví, ukáže konfigurovateľný viditeľný termín vymazania a až neskôr môže nasledovať trvalé vyčistenie.
faq/cancel-service-and-data-retention

Zrušenie nie je okamžité vymazanie každej služby

Pri už provisioned službe sa služba najprv pozastaví a zobrazí konfigurovateľný viditeľný termín vymazania, dokedy sa dá riešiť obnovenie alebo export. Čakajúce nezaplatené objednávky bez bežiacich dát môžu mať iné správanie a trvalé vyčistenie prichádza až po uplynutí lifecycle lehoty.

Pred zrušením si skontroluj

  1. Sprav vlastný export dát, ktoré potrebuješ dlhodobo uchovať.
  2. Prečítaj si dátum a čas plánovaného vymazania pri pozastavenej službe.
  3. Zálohy a Offsite Archive nezamieňaj s lifecycle vymazaním služby.
  4. Ak si nie si istý, kontaktuj support ešte pred termínom vymazania.

Obnova po termíne nemusí byť možná

Po uplynutí viditeľného termínu sa s dátami nemá počítať ako s dostupnými. Pri otázke pošli číslo objednávky a názov služby, nie databázové exporty ani tajné prihlasovacie údaje.

> Zálohy a žiadosti o obnovu

Zálohy slúžia na operačnú obnovu, nie ako náhrada exportu; restore môže prepísať novšie dáta.
faq/backups-and-restore-requests

Backup nie je archív ani export

Retencia záloh závisí od produktu a zvolených možností. Záloha pomáha pri operačnej obnove po chybe, ale nenahrádza vlastný export, auditný archív ani Offsite Archive. Restore môže prepísať novšie zmeny.

Ako pripraviť restore request

  1. Uveď názov služby a číslo objednávky.
  2. Popíš približný čas, ku ktorému sa chceš vrátiť.
  3. Napíš, či sa má obnoviť celá služba alebo konkrétna časť, ak je to podporované.
  4. Prilož viditeľnú chybu alebo kontext bez hesiel, tokenov a súkromných kľúčov.

Pred obnovou rátaj s dopadom

Ak služba medzičasom prijala nové dáta, restore ich môže nahradiť starším stavom. Pred potvrdením obnovy informuj tím a sprav export toho, čo nechceš stratiť.

> Na čo slúži Offsite Archive

Offsite Archive drží vzdialené archívne kópie oddelene od krátkych prevádzkových záloh a od životného cyklu služby.
faq/offsite-archive-purpose

Archív mimo bežnej prevádzky

Offsite Archive je určený na vzdialené archívne kópie a dlhšie uchovanie dát. Nie je to live disk pre aplikáciu, náhrada lokálneho exportu ani rovnaká vec ako krátke operačné backupy.

Kedy ho zapnúť

  1. Použi ho pre dáta, ktoré chceš držať aj mimo bežnej prevádzky služby.
  2. Vyber retenčné dni podľa compliance, obchodnej potreby alebo recovery cieľa.
  3. Sleduj, že cena rastie podľa uloženého objemu a času uchovania.
  4. Pri veľkých dátach plánuj archív spolu s vlastným exportným procesom.

Ako rozmýšľať nad cenou

Základ je MB-days: koľko dát je uložených a koľko dní sa držia. Sadzba sa zákazníkovi zobrazuje ako EUR/GB/mesiac a výsledok sa zaokrúhľuje na celé centy.

> Výber CPU, RAM a disku pre VPS

Veľkosť VPS vyber podľa aplikácie, databázy, cache, logov a rastu; OOM alebo swapovanie sú signál na viac RAM.
faq/vps-cpu-ram-and-disk-sizing

Začni podľa reálnej záťaže, nie podľa pocitu

Malý statický web má iné potreby než databáza, Java aplikácia, vyhľadávanie alebo kontajner s buildmi. Pri plánovaní počítaj s aplikačnou pamäťou, cache, databázou, logmi, uploadmi a rezervou pre rast.

Signály, že plán je malý

  1. RAM zvýš pri OOM, out of memory, process killed alebo trvalom swapovaní.
  2. CPU zvýš pri dlhodobo vysokej výpočtovej záťaži, kompresii, buildoch alebo busy workeroch.
  3. Disk zväčši skôr, než sa zaplní súborový systém, logy alebo databáza.
  4. Po každej zmene sleduj, či aplikácia naozaj prestala narážať na pôvodný limit.

Čo poslať pri sizing otázke

Pomôže názov služby, typ aplikácie, viditeľná chyba, približný čas problému a aktuálne zvolené CPU, RAM a disk. Neposielaj heslá, súkromné kľúče ani interné konfiguračné súbory.

> Kedy dáva zmysel verejná IP pre VPS

Dedikovaná verejná IP pomáha pri allowlistoch, inbound prístupe, stabilnom outbound zdroji alebo službách viazaných na adresu.
faq/vps-public-ip-options

Najprv zisti smer komunikácie

Verejná IP nie je automaticky potrebná pre každú službu. Najčastejšie rieši požiadavky externých partnerov, poskytovateľov alebo firewallov na allowlist, stabilný outbound zdroj alebo inbound prístup na konkrétny port.

Otázky pred objednaním IP

  1. Spýtaj sa partnera, či allowlistuje inbound, outbound alebo oba smery.
  2. Použi DNS názvy namiesto číselných IP všade, kde to externý systém dovolí.
  3. Otváraj iba porty, ktoré aplikácia reálne potrebuje.
  4. Požiadavku na allowlist pošli supportu skôr, než zmeníš produkčný prístup.

Čo nechať zatvorené

Verejná IP nemá znamenať otvorenie všetkých portov. Prístup navrhuj po minimálnych potrebných službách a neposielaj heslá, private keys ani interné firewall pravidlá ako screenshoty s tajnými hodnotami.

> Zdieľaný SSH prístup k VPS

Bez dokúpenej verejnej IP sa VPS pripája cez zdieľaný SSH endpoint s vysokým portom; pri verejnej IP pribudne aj priame SSH na tejto adrese.
faq/shared-ssh-access-for-vps

Prečo zdieľaný SSH používa vysoký port

Viac VPS služieb môže zdieľať rovnaký verejný SSH endpoint, preto každá služba dostane vlastný vysoký port. Port je súčasť smerovania k tvojej službe; bez neho by sa pripojenie nedalo jednoznačne doručiť na správnu VPS.

Ako sa pripájať podľa typu prístupu

  1. Pri zdieľanom SSH skopíruj zo služby SSH username, verejný host a vysoký port.
  2. Použi formát ssh -p <port> <username>@<public-host>.
  3. Ak má služba dokúpenú verejnú IP, môže mať aj druhý SSH endpoint priamo na tejto IP alebo jej DNS mene podľa nastavenia služby.
  4. Súkromný kľúč používaj iba lokálne cez svoj SSH klient alebo agent; do supportu patrí len verejný host, port, username a viditeľná chyba.

Keď máš dokúpenú verejnú IP

Verejná IP nemení späť zdieľaný SSH endpoint; pridáva samostatný spôsob prístupu vhodný pre allowlisty, monitoring alebo priame napojenie. V praxi teda môžeš vidieť dva SSH prístupy: zdieľaný host s vysokým portom a priamy host alebo IP pre službu s verejnou IP.

> Kontrola pred pripojením vlastnej domény

Pred prepnutím domény over autoritatívne DNS, presný hostname, typ záznamu, či je to doména alebo subdoména, a konfliktné staré záznamy.
faq/custom-domain-readiness-checklist

Rozhoduje presný hostname

Najprv si ujasni, či pripájaš apex doménu ako example.com alebo subdoménu ako app.example.com. Každý variant môže vyžadovať iný typ DNS záznamu, iné obmedzenia DNS poskytovateľa a kontrolu u registrátora.

Pred zmenou DNS

  1. Over, kde sa upravujú autoritatívne DNS záznamy pre doménu.
  2. Odstráň alebo uprav konfliktné A/AAAA, CNAME, ALIAS, ANAME alebo redirect záznamy.
  3. Použi typ záznamu odporúčaný pre danú službu a hostname.
  4. Po zmene počkaj na DNS propagáciu a až potom testuj finálne HTTPS.

Bezpečný rollback

Pôvodný hosting nevypínaj skôr, než nový hostname odpovedá správne. Pri riešení problému pošli doménu, očakávaný cieľ a viditeľný DNS výsledok, nie prístupy do registrátora.

> Typy DNS záznamov pre služby

A/AAAA smerujú na adresy, CNAME na alias, MX na poštu a TXT na overenia, SPF, DKIM alebo DMARC.
faq/dns-record-types-for-services

Nekombinuj záznamy naslepo

Každý DNS typ rieši inú úlohu. A a AAAA ukazujú na IP adresy, CNAME vytvára alias pre subdoménu, MX smeruje poštu, TXT nesie overenia a mailové politiky, CAA obmedzuje certifikačné autority.

Pri kopírovaní záznamov

  1. Skopíruj názov, typ a hodnotu presne podľa inštrukcií služby.
  2. CNAME nedávaj na hostname, ktorý už má iné záznamy, ak to DNS pravidlá zakazujú.
  3. DKIM vlož pod selector od poskytovateľa a DMARC typicky pod _dmarc.
  4. CAA nastav opatrne, lebo nesprávna hodnota môže blokovať vystavenie certifikátu.

Keď DNS nefunguje

Supportu pošli hostname, typ záznamu, očakávanú hodnotu a verejne viditeľný výsledok. Neposielaj login do DNS administrácie ani screenshoty s API tokenmi.

> DNS propagácia a TTL bez sľubov na minútu

TTL určuje, ako dlho môžu resolvery držať starú odpoveď; počas prechodu môžu vedľa seba existovať staré aj nové výsledky.
faq/dns-propagation-and-ttl

Propagácia je cache, nie magické čakanie

Pri DNS neexistuje pevný sľub na minútu. Po zmene autoritatívneho DNS môžu rôzne resolvery ešte vracať staré a nové odpovede, kým im nevyprší cache podľa TTL. Preto sa výsledok môže líšiť medzi sieťami, krajinami alebo DNS resolvermi.

Pri plánovanej zmene

  1. Ak to poskytovateľ dovolí, zníž TTL ešte pred plánovaným prepnutím.
  2. Po úprave DNS nerob opakované náhodné zmeny, kým expirujú cache.
  3. Testuj z viacerých resolverov, ak sa výsledky rozchádzajú.
  4. Zapíš si čas zmeny, starú hodnotu, novú hodnotu a TTL.

Čo poslať pri diagnostike

Uveď hostname, očakávaný cieľ, viditeľnú starú odpoveď, viditeľnú novú odpoveď, TTL a čas zmeny. Prístupy do DNS účtu ani interné poznámky poskytovateľa neposielaj.

> Plánovanie úložiska pre Nextcloud

Do kapacity započítaj súbory používateľov, zdieľané priečinky, verzie, koš, náhľady, sync overhead a rast tímu.
faq/nextcloud-storage-planning

Nextcloud rastie aj mimo viditeľných súborov

Kapacitu míňajú používateľské súbory, zdieľané priečinky, odstránené súbory, verzovanie, previews, thumbnails, náhľady, sync klienti a importy. Ak sa úložisko blíži k limitu, môžu zlyhávať uploady alebo synchronizácia.

Pred objednaním kapacity

  1. Spočítaj aktuálne dáta používateľov a spoločné priečinky.
  2. Pridaj rezervu na verzie, koš, náhľady a sync overhead.
  3. Zohľadni veľké importy, nové tímy a očakávaný rast.
  4. Kapacitu zvýš skôr, než používatelia začnú narážať na limit.

Pri problémoch so sync

Pošli veľkosť služby, približné využitie, čas problému a viditeľnú chybu klienta. Neposielaj osobné súbory, heslá ani exporty používateľských dát, ak si ich support výslovne nevyžiada bezpečným spôsobom.

> Migrácia repozitárov do Gitea

Presun Git repozitárov naplánuj spolu s LFS, submodules, právami, deploy keys, webhookmi a CI/CD.
faq/gitea-repository-migration

Migrácia nie je len git clone

Okrem histórie repozitára treba preniesť alebo znovu nastaviť vlastníkov, tímy, protected branches, protected tags, Git LFS, submodules, deploy keys, webhooky a CI/CD napojenia.

Kontrola pred cutoverom

  1. Spíš repozitáre, vlastníkov, prístupové skupiny a automation účty.
  2. Over Git LFS objekty, submodules, branch protections a tag protections.
  3. Po prenose otestuj clone, push, Git LFS, submodules a CI beh.
  4. Staré tokeny po migrácii zruš alebo otoč bez zdieľania ich hodnôt.

Citlivé údaje pri migrácii

Do supportu neposielaj tokeny, private keys, deploy key private časť ani CI secrets. Stačia názvy repozitárov, typ integrácie, viditeľná chyba a informácia, čo bolo pred migráciou funkčné.

> Odosielacia doména pre Listmonk

Pre kampane priprav sender doménu alebo subdoménu, From identitu, SPF, DKIM, DMARC, bounce a odhlásenie.
faq/listmonk-sender-domain-basics

Doručiteľnosť začína pri doméne

Listmonk potrebuje jasnú From identitu a DNS záznamy, ktoré poštový svet vie overiť. SPF, DKIM a DMARC musia sedieť s doménou alebo subdoménou, z ktorej chceš posielať kampane.

Pred prvou kampaňou

  1. Vyber sender doménu alebo subdoménu a From názov.
  2. Pridaj verifikačné DNS záznamy, SPF, DKIM selector a DMARC.
  3. Otestuj doručenie, bounce alebo Return-Path a odkazy v správe.
  4. Skontroluj odhlásenie a List-Unsubscribe pred ostrým odoslaním.

Mailové tajomstvá nepatria do ticketu

Pri diagnostike pošli doménu, typ záznamu, verejne viditeľnú DNS hodnotu a chybové hlásenie. Neposielaj SMTP heslá, API tokeny, private DKIM key ani export adresáta s osobnými údajmi.

> Runtime nastavenia pre Classic Hosting

Classic Hosting vie bežať v auto alebo manuálnom Runtime; CPU, RAM, pamäť, úložisko, retencia záloh, retencia Offsite Archive, uploady, cache a logy ovplyvňujú cenu aj stabilitu.
faq/classic-hosting-runtime-settings

Auto režim nie je jediná správna voľba

Auto Runtime pomáha pri rozpoznaných projektoch, no manuálny režim je vhodný, keď chceš presne zvoliť Nginx, Apache, FrankenPHP alebo konkrétny jazykový runtime. PHP selector používaj iba tam, kde ho zvolený runtime podporuje.

Nastavenia pred nasadením

  1. Vyber auto alebo manuálny Runtime podľa frameworku a spôsobu buildovania.
  2. Zvoľ PHP 8.2, 8.3 alebo 8.4 iba pre podporované PHP scenáre.
  3. Nastav CPU, RAM, disk, backup retenciu a Offsite Archive podľa dát a návštevnosti.
  4. Po deployi otestuj uploady, cache, logy a viditeľné aplikačné chyby.

Keď aplikácia neštartuje

Pošli runtime režim, jazyk alebo PHP verziu, viditeľnú chybu, čo sa menilo a približný čas nasadenia. Neposielaj .env súbory, heslá, tokeny ani celé logy s citlivými hodnotami.

> Aké informácie bezpečne poslať podpore

Najviac pomôžu čísla objednávok, názvy služieb, domény, časy, verejné hosty, porty, retencia záloh, retencia Offsite Archive, uploady, cache, logy, screenshot a viditeľné chyby bez tajomstiev.
faq/support-safe-information-to-share

Dobrý ticket má kontext, nie tajomstvá

Support vie reagovať rýchlejšie, keď dostane číslo objednávky, názov služby, doménu, verejný host alebo port, čas problému, čo sa menilo a presné viditeľné chybové hlásenie.

Bezpečný obsah správy

  1. Uveď objednávku, službu, doménu, čas a krok, pri ktorom problém nastal.
  2. Pri hostingu doplň runtime, PHP alebo jazyk, CPU, RAM, disk, uploady, cache a logy bez tajných hodnôt.
  3. Screenshoty pred odoslaním orež alebo začierni na citlivých miestach.
  4. Ak si nie si istý, či údaj patrí do ticketu, najprv sa opýtaj bez jeho odoslania.

Čo nikdy neposielať

Neposielaj heslá, private keys, recovery seedy, API tokeny, session cookies, databázové exporty, celé .env súbory, plné logy s citlivými hodnotami ani interné infraštruktúrne detaily.