FAQ

Často kladené otázky

Praktické krátké průvodce nastavením služby, přístupem a běžnými akcemi zákazníků.

> Jak vygenerovat verejny SSH klic v terminalu

Vytvor verejny SSH klic pro pristup ke sluzbe a sdilej pouze public key.
faq/jak-vygenerovat-verejny-ssh-klic

Pouzij pouze verejny klic

SSH pouziva par klicu. Do nastaveni sluzby vloz pouze verejny klic, obvykle soubor .pub. Soukromy klic zustava na tvem zarizeni.

Postup v terminalu

  1. Otevri Terminal, Windows Terminal nebo PowerShell.
  2. Spust: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Potvrd vychozi umisteni nebo zvol bezpecnou cestu.
  4. Zobraz verejny klic prikazem: cat ~/.ssh/id_ed25519.pub.
  5. Ve Windows PowerShell pouzij: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Zkopiruj cely radek ssh-ed25519 do pole SSH public key.

Zkontroluj pred vlozenim

Nekopiruj soukromy klic. Pokud nastavis passphrase, uloz ji bezpecne pro pozdejsi pouziti.

> Jak vytvorit SSH klic graficky ve Windows

Windows GUI postup s PuTTYgen pro vytvoreni SSH klice a sdileni jen public key.
faq/jak-vytvorit-ssh-klic-graficky-ve-windows

Staci verejna cast

PuTTYgen vytvori verejny i soukromy klic. Do Cli>_ pridej pouze verejny klic a soukromy ponech lokalne.

Postup ve Windows

  1. Otevri PuTTYgen.
  2. Vyber EdDSA / Ed25519, pokud je dostupne.
  3. RSA 4096 pouzij jen jako zalozni moznost.
  4. Klikni na Generate a hybej mysi, dokud se klic nevytvori.
  5. Uloz soukromy klic do sveho pocitace.
  6. Zkopiruj text verejneho klice do pole SSH public key.

Nesdilej tajne udaje

Neposilej .ppk soubory, soukrome klice, passphrase, hesla ani tokeny podpora nebo do formularu.

> Pripojeni vlastni domeny

Před přepnutím domény ověř autoritativní DNS, přesný hostname, typ záznamu, zda jde o doménu nebo subdoménu, a staré konfliktní záznamy.
faq/pripojeni-vlastni-domeny

Rozhoduje přesný hostname

Nejdřív si ujasni, zda připojuješ apex doménu jako example.com nebo subdoménu jako app.example.com. Každá varianta může vyžadovat jiný typ DNS záznamu a jiná omezení poskytovatele DNS.

Před změnou DNS

  1. Ověř, kde se upravují autoritativní DNS záznamy domény.
  2. Odstraň nebo uprav konfliktní A/AAAA, CNAME, ALIAS, ANAME nebo redirect záznamy.
  3. Použij typ záznamu doporučený pro danou službu a hostname.
  4. Po změně počkej na DNS propagaci a až potom testuj finální HTTPS.

Bezpečný rollback

Původní hosting nevypínej dřív, než nový hostname odpovídá správně. Při řešení problému pošli doménu, očekávaný cíl a veřejně viditelný DNS výsledek, ne přístupy k registrátorovi.

> Predani DNS zony

A/AAAA směřují na adresy, CNAME na alias, MX na poštu a TXT na ověření, SPF, DKIM nebo DMARC.
faq/predani-dns-zony

Nekombinuj záznamy naslepo

Každý DNS typ řeší jiný úkol. A a AAAA ukazují na IP adresy, CNAME vytváří alias pro subdoménu, MX směruje poštu, TXT nese ověření a mailové politiky, CAA omezuje certifikační autority.

Při kopírování záznamů

  1. Zkopíruj název, typ a hodnotu přesně podle instrukcí služby.
  2. CNAME nedávej na hostname, který už má jiné záznamy, pokud to DNS pravidla zakazují.
  3. DKIM vlož pod selector poskytovatele a DMARC typicky pod _dmarc.
  4. CAA nastavuj opatrně, protože špatná hodnota může blokovat vydání certifikátu.

Když DNS nefunguje

Podpoře pošli hostname, typ záznamu, očekávanou hodnotu a veřejně viditelný výsledek. Neposílej login do DNS administrace ani screenshoty s citlivými přístupovými údaji.

> Registrace účtu a první přihlášení

Založ jeden pracovní účet, doplň fakturační údaje a používej e-mail, který tým dlouhodobě neztratí.
faq/account-registration-and-login

Jeden účet pro objednávky i správu

Účet používej jako dlouhodobé místo pro objednávky, fakturační údaje, služby, domény a komunikaci s podporou. Nejlepší je pracovní e-mail, ke kterému bude mít tým přístup i při personálních změnách.

Před první objednávkou

  1. Zaregistruj se pracovní e-mailovou adresou.
  2. Dokonči ověření e-mailu, pokud ho stránka vyžádá.
  3. Doplň fakturační údaje před odesláním placené objednávky.
  4. Pokud bude dostupné dvoufaktorové ověření, zapni ho hned po prvním přihlášení.

Přístup pro tým

Heslo neposílej kolegům přes chat ani e-mail. Pokud potřebuje přístup více lidí, používejte interní správce hesel nebo si vyžádejte doporučený týmový postup; podpora nepotřebuje tvoje heslo.

> Jak funguje předplacený kredit

Kredit ukazuje zůstatek, odhad výdrže, denní spotřebu aktivních služeb a viditelný termín smazání při pozastavení.
faq/prepaid-credit-how-it-works

Kredit se čerpá při běhu služby

U předplacených služeb se zůstatek snižuje podle aktivního času a zvolených parametrů. Denní cena pomáhá odhadnout, kolik dní služba vydrží při aktuálním kreditu a kdy se může objevit termín smazání.

Jak předejít pozastavení

  1. Po přihlášení sleduj viditelný zůstatek a odhad výdrže.
  2. Před potvrzením objednávky nebo změny zkontroluj novou denní cenu.
  3. Dobíjej kredit s rezervou, ne až v den vyčerpání.
  4. U pozastavené služby si hned přečti termín možného smazání dat.

Když zůstatek nesedí

Při dotazu na kredit pošli číslo objednávky, název služby a období ke kontrole. Neposílej platební karty, hesla, soukromé klíče ani celé výpisy s citlivými údaji.

> Měsíční odhad, roční odhad a reálná denní spotřeba

Měsíční a roční ceny slouží k porovnání; u předplacených služeb rozhoduje denní spotřeba po potvrzení změny.
faq/billing-periods-and-credit-burn

Porovnání není fakturační kalendář

Měsíční odhad používej jako srovnání za 31 dní a roční jako srovnání za 372 dní. Skutečné čerpání kreditu probíhá podle aktivního času služby a potvrzené konfigurace.

Kontrola při změně ceny

  1. Porovnej denní spotřebu před změnou a po změně.
  2. Vyšší CPU, RAM, disk nebo placené volby znamenají vyšší denní čerpání.
  3. Změnu považuj za účinnou až po potvrzení, případné platbě a aplikování.
  4. Pro účetnictví si ulož potvrzení objednávky a historii kreditu.

Sporné období řeš přesně

Podpoře pomůže číslo objednávky, název služby a data, za která chceš čerpání prověřit. Neposílej bankovní údaje ani screenshoty s nechtěnými osobními údaji.

> Stav objednávky po platbě

Objednávka může po zaplacení chvíli čekat na potvrzení poskytovatele; duplicitu vytvářej až po jasném zrušení nebo expiraci první objednávky.
faq/order-status-and-payment-confirmation

Pending nemusí znamenat selhání

Po návratu z platební stránky může objednávka čekat na potvrzení od platebního poskytovatele. Dokud stav není jasně neúspěšný nebo expirovaný, duplicitní objednávka může zkomplikovat párování.

Postup po platbě

  1. Po dokončení platby se vrať zpět do Cli>_.
  2. V účtu zkontroluj stav objednávky a případnou zprávu u platby.
  3. Pokud objednávka stále čeká, dej poskytovateli čas na potvrzení.
  4. Při problému pošli podpoře číslo objednávky a referenci platby, pokud ji vidíš.

Údaje, které nejsou potřeba

Podpora nepotřebuje údaje z platební karty, přihlašovací heslo ani celé bankovní potvrzení. Stačí číslo objednávky, čas platby, viditelný stav a začerněný screenshot chyby.

> Údaje, které urychlí nastavení služby

Připrav název služby, doménu, velikost úložiště, přístupový e-mail a veřejný SSH klíč; citlivé údaje do formulářů nepatří.
faq/service-setup-information-needed

Přesné vstupy šetří čas

Objednávkové formuláře používej pro veřejné nebo necitlivé hodnoty: název služby, doménu, plán DNS, velikost úložiště, CPU, RAM, admin e-mail nebo veřejný SSH klíč. Hesla a soukromé klíče do formuláře nepatří.

Připrav si před objednávkou

  1. Vyber rozpoznatelný název služby pro svůj tým.
  2. Rozhodni, zda použiješ vlastní doménu nebo dočasný systémový hostname.
  3. Připrav veřejný SSH klíč, pokud ho služba vyžaduje.
  4. Zkontroluj úložiště a zdroje podle aplikace, kterou budeš provozovat.

Citlivé hodnoty neposílej

Pokud si nejsi jistý, zda je údaj citlivý, raději se zeptej bez jeho odeslání. Soukromé klíče, hesla, databázové exporty a celé konfigurační soubory neposílej do chatu ani do objednávky.

> Změna CPU, RAM, disku nebo retence po objednávce

Existující službu upravuj přes její detail, ne novou duplicitní objednávkou; změna může ovlivnit cenu, denní spotřebu, restart i výpadek.
faq/change-service-resources-after-order

Upravuješ existující službu

Pokud služba už běží, změnu zdrojů dělej z jejího detailu. Nová objednávka by vytvořila další službu místo úpravy stávající a může změnit cenu, denní spotřebu kreditu i provozní chování.

Před potvrzením změny

  1. Zkontroluj aktuální CPU, RAM, disk, zálohy a Offsite Archive retenci.
  2. Ověř novou denní cenu a dopad na kredit.
  3. Přečti si upozornění na restart, údržbu nebo výpadek.
  4. Před rizikovou změnou proveď vlastní export důležitých dat.

Když změna nedopadne podle očekávání

Pošli název služby, čas změny, viditelný stav a chybovou zprávu. Neposílej soukromé klíče ani hesla; pro diagnostiku stačí veřejný kontext a začerněný screenshot.

> Zrušení služby a termín smazání dat

Provisioned služba se nejprve pozastaví, ukáže nastavitelný termín smazání a až později může následovat trvalé vyčištění.
faq/cancel-service-and-data-retention

Zrušení není vždy okamžité smazání

U už zřízené služby se služba nejprve pozastaví a zobrazí nastavitelný termín smazání, do kterého lze řešit obnovení nebo export. Nezaplacené čekající objednávky bez běžících dat se mohou chovat jinak.

Před zrušením zkontroluj

  1. Vytvoř vlastní export dat, která potřebuješ dlouhodobě uchovat.
  2. Přečti si datum a čas plánovaného smazání u pozastavené služby.
  3. Zálohy a Offsite Archive nezaměňuj se smazáním v životním cyklu služby.
  4. Pokud si nejsi jistý, kontaktuj podporu ještě před termínem smazání.

Obnova po termínu nemusí být možná

Po uplynutí viditelného termínu se s daty nemá počítat jako s dostupnými. Při dotazu pošli číslo objednávky a název služby, ne databázové exporty ani přístupové údaje.

> Zálohy a žádosti o obnovu

Zálohy slouží k operační obnově, ne jako náhrada exportu; obnova může přepsat novější data.
faq/backups-and-restore-requests

Záloha není archiv ani export

Retence záloh závisí na produktu a zvolených možnostech. Záloha pomáhá při operační obnově po chybě, ale nenahrazuje vlastní export, auditní archiv ani Offsite Archive. Obnova může přepsat novější změny.

Příprava žádosti o obnovu

  1. Uveď název služby a číslo objednávky.
  2. Popiš přibližný čas, ke kterému se chceš vrátit.
  3. Napiš, zda se má obnovit celá služba nebo konkrétní část, pokud je to podporováno.
  4. Přilož viditelnou chybu nebo kontext bez hesel a soukromých klíčů.

Před obnovou počítej s dopadem

Pokud služba mezitím přijala nová data, obnova je může nahradit starším stavem. Před potvrzením obnovy informuj tým a exportuj vše, co nechceš ztratit.

> K čemu slouží Offsite Archive

Offsite Archive drží vzdálené archivní kopie odděleně od krátkých provozních záloh i od životního cyklu služby.
faq/offsite-archive-purpose

Archiv mimo běžný provoz

Offsite Archive je určený pro vzdálené archivní kopie a delší uchování dat. Není to živý disk pro aplikaci, náhrada lokálního exportu ani totéž co krátké operační zálohy.

Kdy ho zapnout

  1. Použij ho pro data, která chceš držet i mimo běžný provoz služby.
  2. Vyber retenční dny podle compliance, obchodní potřeby nebo recovery cíle.
  3. Sleduj, že cena roste podle uloženého objemu a doby uchování.
  4. U velkých dat plánuj archiv spolu s vlastním exportním procesem.

Jak přemýšlet o ceně

Základem jsou MB-days: kolik dat je uložených a kolik dní se drží. Sazba se zákazníkovi zobrazuje jako EUR/GB/měsíc a výsledek se zaokrouhluje na celé centy.

> Výběr CPU, RAM a disku pro VPS

Velikost VPS vybírej podle aplikace, databáze, cache, logů a růstu; OOM nebo swapování jsou signál pro více RAM.
faq/vps-cpu-ram-and-disk-sizing

Začni podle reálné zátěže

Malý statický web má jiné potřeby než databáze, Java aplikace, vyhledávání nebo kontejner s buildy. Při plánování počítej s aplikační pamětí, cache, databází, logy, uploady a rezervou pro růst.

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

  1. RAM navyš při OOM, out of memory, process killed nebo trvalém swapování.
  2. CPU navyš při dlouhodobě vysoké výpočetní zátěži, kompresi, buildech nebo vytížených workerech.
  3. Disk zvětši dřív, než se zaplní souborový systém, logy nebo databáze.
  4. Po každé změně sleduj, zda aplikace přestala narážet na původní limit.

Co poslat při sizing dotazu

Pomůže název služby, typ aplikace, viditelná chyba, přibližný čas problému a aktuálně zvolené CPU, RAM a disk. Neposílej hesla, soukromé klíče ani interní konfigurační soubory.

> Kdy dává smysl veřejná IP pro VPS

Dedikovaná veřejná IP pomáhá u allowlistů, inbound přístupu, stabilního outbound zdroje nebo služeb vázaných na adresu.
faq/vps-public-ip-options

Nejdřív zjisti směr komunikace

Veřejná IP není automaticky nutná pro každou službu. Nejčastěji řeší požadavky externích partnerů, poskytovatelů nebo firewallů na allowlist, stabilní outbound zdroj nebo inbound přístup na konkrétní port.

Otázky před objednáním IP

  1. Zeptej se partnera, zda allowlistuje inbound, outbound nebo oba směry.
  2. Používej DNS názvy místo číselných IP všude, kde to externí systém dovolí.
  3. Otevírej jen porty, které aplikace skutečně potřebuje.
  4. Požadavek na allowlist pošli podpoře dřív, než změníš produkční přístup.

Co nechat zavřené

Veřejná IP nemá znamenat otevření všech portů. Přístup navrhuj podle minimálních potřebných služeb a neposílej hesla, soukromé klíče ani citlivé firewallové poznámky.

> Sdílený SSH přístup k VPS

Bez dokoupené veřejné IP se VPS připojuje přes sdílený SSH endpoint s vysokým portem; při veřejné IP přibude i přímá SSH cesta.
faq/shared-ssh-access-for-vps

Proč sdílený SSH používá vysoký port

Více VPS služeb může sdílet stejný veřejný SSH endpoint, proto každá služba dostane vlastní vysoký port. Port je součástí směrování k tvé službě; bez něj by se spojení nedalo jednoznačně doručit na správnou VPS.

Připojení podle typu přístupu

  1. U sdíleného SSH zkopíruj ze služby SSH uživatelské jméno, veřejný host a vysoký port.
  2. Použij formát ssh -p <port> <username>@<public-host>.
  3. Pokud má služba dokoupenou veřejnou IP, může mít i druhou SSH adresu přímo na této IP nebo jejím DNS jméně.
  4. Soukromý klíč používej jen lokálně přes svůj SSH klient nebo agent; do podpory patří veřejný host, port, uživatelské jméno a viditelná chyba.

Druhá cesta s veřejnou IP

Veřejná IP nenahrazuje zpětně sdílený SSH endpoint; přidává samostatný způsob přístupu vhodný pro allowlisty, monitoring nebo přímé napojení. Můžeš tedy vidět sdílený host s vysokým portem i přímý host nebo IP pro službu s veřejnou IP.

> Kontrola před připojením vlastní domény

Před přepnutím domény ověř autoritativní DNS, přesný hostname, typ záznamu, zda jde o doménu nebo subdoménu, a staré konfliktní záznamy.
faq/custom-domain-readiness-checklist

Rozhoduje přesný hostname

Nejdřív si ujasni, zda připojuješ apex doménu jako example.com nebo subdoménu jako app.example.com. Každá varianta může vyžadovat jiný typ DNS záznamu a jiná omezení poskytovatele DNS.

Před změnou DNS

  1. Ověř, kde se upravují autoritativní DNS záznamy domény.
  2. Odstraň nebo uprav konfliktní A/AAAA, CNAME, ALIAS, ANAME nebo redirect záznamy.
  3. Použij typ záznamu doporučený pro danou službu a hostname.
  4. Po změně počkej na DNS propagaci a až potom testuj finální HTTPS.

Bezpečný rollback

Původní hosting nevypínej dřív, než nový hostname odpovídá správně. Při řešení problému pošli doménu, očekávaný cíl a veřejně viditelný DNS výsledek, ne přístupy k registrátorovi.

> Typy DNS záznamů pro služby

A/AAAA směřují na adresy, CNAME na alias, MX na poštu a TXT na ověření, SPF, DKIM nebo DMARC.
faq/dns-record-types-for-services

Nekombinuj záznamy naslepo

Každý DNS typ řeší jiný úkol. A a AAAA ukazují na IP adresy, CNAME vytváří alias pro subdoménu, MX směruje poštu, TXT nese ověření a mailové politiky, CAA omezuje certifikační autority.

Při kopírování záznamů

  1. Zkopíruj název, typ a hodnotu přesně podle instrukcí služby.
  2. CNAME nedávej na hostname, který už má jiné záznamy, pokud to DNS pravidla zakazují.
  3. DKIM vlož pod selector poskytovatele a DMARC typicky pod _dmarc.
  4. CAA nastavuj opatrně, protože špatná hodnota může blokovat vydání certifikátu.

Když DNS nefunguje

Podpoře pošli hostname, typ záznamu, očekávanou hodnotu a veřejně viditelný výsledek. Neposílej login do DNS administrace ani screenshoty s citlivými přístupovými údaji.

> DNS propagace a TTL bez slibu na minutu

TTL určuje, jak dlouho mohou resolvery držet starou odpověď; během přechodu mohou existovat staré i nové výsledky.
faq/dns-propagation-and-ttl

Propagace je cache, ne magie

U DNS neexistuje pevný slib na minutu. Po změně autoritativního DNS mohou různé resolvery vracet staré i nové odpovědi, dokud jim nevyprší cache podle TTL.

Při plánované změně

  1. Pokud to poskytovatel dovolí, sniž TTL ještě před plánovaným přepnutím.
  2. Po úpravě DNS nedělej opakované náhodné změny, dokud expirují cache.
  3. Testuj z více resolverů, pokud se výsledky liší.
  4. Zapiš si čas změny, starou hodnotu, novou hodnotu a TTL.

Co poslat k diagnostice

Uveď hostname, očekávaný cíl, viditelnou starou odpověď, viditelnou novou odpověď, TTL a čas změny. Přístupy do DNS účtu neposílej.

> Plánování úložiště pro Nextcloud

Do kapacity započítej soubory uživatelů, sdílené složky, verze, koš, náhledy, režii synchronizace a růst týmu.
faq/nextcloud-storage-planning

Nextcloud roste i mimo viditelné soubory

Kapacitu spotřebují uživatelské soubory, sdílené složky, smazané soubory, verzování, náhledy, miniatury, synchronizační klienti a importy. Pokud se úložiště blíží limitu, mohou selhávat uploady nebo synchronizace.

Před objednáním kapacity

  1. Sečti aktuální data uživatelů a společné složky.
  2. Přidej rezervu na verze, koš, náhledy a režii synchronizace.
  3. Zohledni velké importy, nové týmy a očekávaný růst.
  4. Kapacitu navyš dřív, než uživatelé narazí na limit.

Při problémech se synchronizací

Pošli velikost služby, přibližné využití, čas problému a viditelnou chybu klienta. Neposílej osobní soubory, hesla ani exporty uživatelských dat, pokud si je podpora výslovně nevyžádá bezpečným způsobem.

> Migrace repozitářů do Gitea

Přesun Git repozitářů naplánuj spolu s LFS, submodules, právy, deploy keys, webhooky a CI/CD.
faq/gitea-repository-migration

Migrace není jen git clone

Kromě historie repozitáře je potřeba přenést nebo znovu nastavit vlastníky, týmy, protected branches, protected tags, Git LFS, submodules, deploy keys, webhooky a CI/CD napojení.

Kontrola před cutoverem

  1. Sepiš repozitáře, vlastníky, přístupové skupiny a automation účty.
  2. Ověř Git LFS objekty, submodules, branch protections a tag protections.
  3. Po přenosu otestuj clone, push, Git LFS, submodules a CI běh.
  4. Staré přístupové údaje po migraci zruš nebo bezpečně otoč.

Citlivé údaje při migraci

Do podpory neposílej soukromé klíče, privátní část deploy key ani CI citlivé hodnoty. Stačí názvy repozitářů, typ integrace, viditelná chyba a informace, co před migrací fungovalo.

> Odesílací doména pro Listmonk

Pro kampaně připrav sender doménu nebo subdoménu, From identitu, SPF, DKIM, DMARC, bounce a odhlášení.
faq/listmonk-sender-domain-basics

Doručitelnost začíná u domény

Listmonk potřebuje jasnou From identitu a DNS záznamy, které poštovní svět umí ověřit. SPF, DKIM a DMARC musí sedět s doménou nebo subdoménou, ze které chceš posílat kampaně.

Před první kampaní

  1. Vyber sender doménu nebo subdoménu a From název.
  2. Přidej ověřovací DNS záznamy, SPF, DKIM selector a DMARC.
  3. Otestuj doručení, bounce nebo Return-Path a odkazy ve zprávě.
  4. Zkontroluj odhlášení a List-Unsubscribe před ostrým odesláním.

Mailové citlivé údaje nepatří do ticketu

Při diagnostice pošli doménu, typ záznamu, veřejně viditelnou DNS hodnotu a chybové hlášení. Neposílej SMTP hesla, soukromý DKIM key ani export adresátů s osobními údaji.

> Runtime nastavení pro Classic Hosting

Classic Hosting může běžet v auto nebo manuálním Runtime; CPU, RAM, úložiště, retence záloh, Offsite Archive, uploady, cache a logy ovlivňují cenu i stabilitu.
faq/classic-hosting-runtime-settings

Auto režim není jediná správná volba

Auto Runtime pomáhá u rozpoznaných projektů, ale manuální režim je vhodný, když chceš přesně zvolit Nginx, Apache, FrankenPHP nebo konkrétní jazykový runtime. PHP selector používej jen tam, kde ho zvolený runtime podporuje.

Nastavení před nasazením

  1. Vyber auto nebo manuální Runtime podle frameworku a způsobu sestavení.
  2. Zvol PHP 8.2, 8.3 nebo 8.4 jen pro podporované PHP scénáře.
  3. Nastav CPU, RAM, disk, retenci záloh a Offsite Archive podle dat a návštěvnosti.
  4. Po nasazení otestuj uploady, cache, logy a viditelné aplikační chyby.

Když aplikace nestartuje

Pošli runtime režim, jazyk nebo PHP verzi, viditelnou chybu, co se měnilo a přibližný čas nasazení. Neposílej .env soubory, hesla ani celé logy s citlivými hodnotami.

> Jaké informace bezpečně poslat podpoře

Nejvíc pomohou čísla objednávek, názvy služeb, domény, časy, veřejné hosty, porty, nastavení hostingu a viditelné chyby bez citlivých údajů.
faq/support-safe-information-to-share

Dobrý ticket má kontext, ne citlivé údaje

Podpora reaguje rychleji, když dostane číslo objednávky, název služby, doménu, veřejný host nebo port, čas problému, co se měnilo a přesné viditelné chybové hlášení.

Bezpečný obsah zprávy

  1. Uveď objednávku, službu, doménu, čas a krok, při kterém problém nastal.
  2. U hostingu doplň runtime, PHP nebo jazyk, CPU, RAM, disk, uploady, cache a logy bez citlivých hodnot.
  3. Screenshoty před odesláním ořízni nebo začerni na citlivých místech.
  4. Pokud si nejsi jistý, zda údaj patří do ticketu, nejdřív se zeptej bez jeho odeslání.

Co nikdy neposílat

Neposílej hesla, soukromé klíče, recovery seedy, session cookies, databázové exporty, celé .env soubory, plné logy s citlivými hodnotami ani interní infrastrukturní detaily.