FAQ

Często zadawane pytania

Praktyczne krótkie przewodniki dotyczące konfiguracji usług, dostępu i typowych działań klientów.

> Jak wygenerowac publiczny klucz SSH w terminalu

Utworz publiczny klucz SSH do dostepu i udostepniaj tylko public key.
faq/jak-wygenerowac-publiczny-klucz-ssh

Uzyj tylko klucza publicznego

SSH uzywa pary kluczy. W ustawieniach uslugi wklej tylko klucz publiczny, zwykle plik .pub. Klucz prywatny zostaje na twoim urzadzeniu.

Kroki w terminalu

  1. Otworz Terminal, Windows Terminal albo PowerShell.
  2. Uruchom: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Zaakceptuj domyslna lokalizacje albo wybierz bezpieczna sciezke.
  4. Pokaz klucz publiczny: cat ~/.ssh/id_ed25519.pub.
  5. W Windows PowerShell uzyj: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Skopiuj cala linie ssh-ed25519 do pola SSH public key.

Sprawdz przed wklejeniem

Nie kopiuj klucza prywatnego. Jesli ustawisz passphrase, przechowuj ja bezpiecznie.

> Jak utworzyc klucz SSH graficznie w Windows

Graficzny sposob w Windows z PuTTYgen do utworzenia klucza SSH.
faq/jak-utworzyc-klucz-ssh-graficznie-w-windows

Wystarczy czesc publiczna

PuTTYgen tworzy klucz publiczny i prywatny. Do Cli>_ dodaj tylko klucz publiczny, a prywatny trzymaj lokalnie.

Kroki w Windows

  1. Otworz PuTTYgen.
  2. Wybierz EdDSA / Ed25519, jesli jest dostepne.
  3. RSA 4096 traktuj tylko jako opcje awaryjna.
  4. Kliknij Generate i poruszaj mysza, az klucz zostanie utworzony.
  5. Zapisz klucz prywatny na swoim komputerze.
  6. Skopiuj tekst klucza publicznego do pola SSH public key.

Nie udostepniaj tajnych danych

Nie wysylaj plikow .ppk, kluczy prywatnych, passphrase, hasel ani tokenow do wsparcia lub formularzy.

> Podlaczenie wlasnej domeny

Przed przełączeniem domeny sprawdź autorytatywne DNS, dokładny hostname, typ rekordu, apex lub subdomenę i stare konflikty.
faq/podlaczenie-wlasnej-domeny

Liczy się dokładny hostname

Najpierw ustal, czy podłączasz apex domain jak example.com, czy subdomenę jak app.example.com. Każdy wariant może wymagać innego typu rekordu DNS i ma inne ograniczenia dostawcy.

Przed zmianą DNS

  1. Sprawdź, gdzie edytuje się autorytatywne rekordy DNS domeny.
  2. Usuń lub zmień kolidujące A/AAAA, CNAME, ALIAS, ANAME albo przekierowania.
  3. Użyj typu rekordu zalecanego dla danej usługi i hostname.
  4. Po zmianie poczekaj na propagację DNS i dopiero testuj finalne HTTPS.

Bezpieczny rollback

Nie wyłączaj starego hostingu, zanim nowy hostname odpowiada poprawnie. Przy problemie wyślij domenę, oczekiwany cel i publicznie widoczny wynik DNS, nie dostęp do rejestratora.

> Przekazanie strefy DNS

A/AAAA wskazują adresy, CNAME alias, MX pocztę, a TXT weryfikację, SPF, DKIM lub DMARC.
faq/przekazanie-strefy-dns

Nie mieszaj rekordów na ślepo

Każdy typ DNS ma inną rolę. A i AAAA wskazują adresy IP, CNAME tworzy alias dla subdomeny, MX kieruje pocztę, TXT niesie weryfikacje i polityki pocztowe, CAA ogranicza urzędy certyfikacji.

Przy kopiowaniu rekordów

  1. Skopiuj nazwę, typ i wartość dokładnie według instrukcji usługi.
  2. Nie ustawiaj CNAME na hostname, który według reguł DNS ma już inne rekordy.
  3. DKIM umieść pod selectorem dostawcy, a DMARC zwykle pod _dmarc.
  4. CAA zmieniaj ostrożnie, bo błędna wartość może blokować certyfikat.

Gdy DNS nie działa

Wyślij hostname, typ rekordu, oczekiwaną wartość i publicznie widoczny wynik. Nie wysyłaj loginu do panelu DNS ani screenshotów z wrażliwymi danymi dostępowymi.

> Rejestracja konta i pierwsze logowanie

Załóż jedno konto robocze, uzupełnij dane rozliczeniowe i użyj adresu e-mail, do którego zespół zachowa dostęp.
faq/account-registration-and-login

Jedno konto do zamówień i zarządzania

Konto jest stałym miejscem dla zamówień, danych rozliczeniowych, usług, domen i kontaktu ze wsparciem. Najlepszy jest służbowy adres e-mail, do którego zespół będzie miał dostęp także po zmianach personalnych.

Przed pierwszym zamówieniem

  1. Zarejestruj się służbowym adresem e-mail.
  2. Potwierdź e-mail, jeśli strona tego wymaga.
  3. Uzupełnij dane rozliczeniowe przed płatnym zamówieniem.
  4. Włącz logowanie dwuskładnikowe, gdy będzie dostępne dla konta.

Dostęp dla zespołu

Nie wysyłaj hasła współpracownikom przez czat ani e-mail. Używajcie wewnętrznego menedżera haseł albo poproście o rekomendowany proces zespołowy; wsparcie nie potrzebuje twojego hasła.

> Jak działa przedpłacony kredyt

Kredyt pokazuje saldo, szacowany czas działania, dzienne zużycie aktywnych usług i widoczny termin usunięcia przy wstrzymaniu.
faq/prepaid-credit-how-it-works

Kredyt zużywa się podczas działania usługi

W usługach przedpłaconych saldo maleje według aktywnego czasu i wybranych parametrów. Dzienna cena pomaga oszacować, ile dni usługa będzie działać przy obecnym kredycie i kiedy może pojawić się termin usunięcia.

Jak uniknąć wstrzymania

  1. Po zalogowaniu sprawdzaj saldo i szacowany czas działania.
  2. Przed zatwierdzeniem zamówienia lub zmiany sprawdź nową dzienną cenę.
  3. Doładuj kredyt z wyprzedzeniem, nie ostatniego dnia.
  4. Przy wstrzymanej usłudze od razu sprawdź możliwy termin usunięcia danych.

Gdy saldo wygląda inaczej niż oczekujesz

Wyślij numer zamówienia, nazwę usługi i okres do sprawdzenia. Nie wysyłaj danych kart, haseł, kluczy prywatnych ani pełnych wyciągów z wrażliwymi danymi.

> Szacunek miesięczny, roczny i realne dzienne zużycie

Ceny miesięczne i roczne służą do porównania; w usługach przedpłaconych liczy się dzienne zużycie po zatwierdzeniu zmiany.
faq/billing-periods-and-credit-burn

Porównanie to nie kalendarz fakturowania

Szacunek miesięczny traktuj jako porównanie dla 31 dni, a roczny dla 372 dni. Rzeczywiste zużycie kredytu wynika z aktywnego czasu usługi i zatwierdzonej konfiguracji.

Kontrola przy zmianie ceny

  1. Porównaj dzienne zużycie przed i po zmianie.
  2. Większe CPU, RAM, dysk lub płatne opcje zwiększą dzienne zużycie.
  3. Zmiana obowiązuje po zatwierdzeniu, ewentualnej płatności i zastosowaniu.
  4. Do księgowości zachowaj potwierdzenie zamówienia i historię kredytu.

Sporny okres opisuj konkretnie

Wsparciu pomogą numer zamówienia, nazwa usługi i daty do sprawdzenia. Nie wysyłaj danych bankowych ani zrzutów z niepotrzebnymi danymi osobowymi.

> Status zamówienia po płatności

Po zapłacie zamówienie może czekać na potwierdzenie operatora; duplikat twórz dopiero po jasnym anulowaniu lub wygaśnięciu.
faq/order-status-and-payment-confirmation

Pending nie musi oznaczać błędu

Po powrocie ze strony płatności zamówienie może jeszcze czekać na potwierdzenie dostawcy płatności. Dopóki status nie jest jednoznacznie nieudany lub wygasły, duplikat może utrudnić dopasowanie płatności.

Po płatności

  1. Po zakończeniu płatności wróć do Cli>_.
  2. Sprawdź w koncie status zamówienia i komunikat przy płatności.
  3. Jeśli zamówienie nadal czeka, daj dostawcy czas na potwierdzenie.
  4. W razie problemu wyślij wsparciu numer zamówienia i widoczną referencję płatności.

Czego nie wysyłać

Wsparcie nie potrzebuje danych karty, hasła logowania ani pełnego potwierdzenia bankowego. Wystarczy numer zamówienia, czas płatności, widoczny status i zamazany zrzut ekranu.

> Dane przyspieszające konfigurację usługi

Przygotuj nazwę usługi, domenę, wielkość przestrzeni, e-mail dostępu i publiczny klucz SSH; dane wrażliwe nie należą do formularzy.
faq/service-setup-information-needed

Precyzyjne dane oszczędzają czas

Formularze zamówień są na wartości publiczne lub niewrażliwe: nazwę usługi, domenę, plan DNS, rozmiar przestrzeni, CPU, RAM, e-mail administratora lub publiczny klucz SSH. Hasła i klucze prywatne nie powinny tam trafiać.

Przygotuj przed zamówieniem

  1. Wybierz nazwę usługi rozpoznawalną dla zespołu.
  2. Zdecyduj, czy użyjesz własnej domeny czy tymczasowego hostname.
  3. Przygotuj publiczny klucz SSH, jeśli usługa go wymaga.
  4. Sprawdź przestrzeń i zasoby według aplikacji, którą chcesz uruchomić.

Nie wysyłaj wrażliwych wartości

Jeśli nie masz pewności, czy dana wartość jest wrażliwa, zapytaj bez jej przesyłania. Klucze prywatne, hasła, eksporty baz danych i pełne pliki konfiguracyjne nie należą do czatu ani zamówienia.

> Zmiana CPU, RAM, dysku lub retencji po zamówieniu

Istniejącą usługę zmieniaj z jej szczegółów, nie nowym zamówieniem; zmiana może wpłynąć na cenę, dzienne zużycie, restart i przerwę.
faq/change-service-resources-after-order

Zmieniasz istniejącą usługę

Jeśli usługa już działa, zasoby zmieniaj z jej szczegółów. Nowe zamówienie utworzyłoby kolejną usługę zamiast zmienić obecną i może zmienić cenę, dzienne zużycie oraz zachowanie operacyjne.

Przed zatwierdzeniem zmiany

  1. Sprawdź aktualne CPU, RAM, dysk, kopie zapasowe i retencję Offsite Archive.
  2. Zweryfikuj nową dzienną cenę i wpływ na kredyt.
  3. Przeczytaj ostrzeżenie o restarcie, pracach utrzymaniowych lub przerwie.
  4. Przed ryzykowną zmianą wykonaj własny eksport ważnych danych.

Gdy zmiana nie poszła zgodnie z oczekiwaniami

Wyślij nazwę usługi, czas zmiany, widoczny status i komunikat błędu. Nie wysyłaj kluczy prywatnych ani haseł; wystarczy publiczny kontekst i zamazany screenshot.

> Anulowanie usługi i termin usunięcia danych

Już uruchomiona usługa najpierw zostaje wstrzymana, pokazuje konfigurowalny termin usunięcia, a później może zostać trwale wyczyszczona.
faq/cancel-service-and-data-retention

Anulowanie nie zawsze oznacza natychmiastowe usunięcie

Dla już uruchomionej usługi najpierw następuje wstrzymanie i widoczny konfigurowalny termin usunięcia, przed którym można rozważyć przywrócenie lub eksport. Oczekujące nieopłacone zamówienia bez działających danych mogą zachować się inaczej.

Przed anulowaniem sprawdź

  1. Wykonaj własny eksport danych potrzebnych długoterminowo.
  2. Przeczytaj datę i godzinę planowanego usunięcia przy wstrzymanej usłudze.
  3. Nie myl kopii zapasowych i Offsite Archive z usunięciem w cyklu życia usługi.
  4. Jeśli nie masz pewności, skontaktuj się ze wsparciem przed terminem usunięcia.

Po terminie przywrócenie może nie być możliwe

Po upływie widocznego terminu nie zakładaj dostępności danych. Przy pytaniu wyślij numer zamówienia i nazwę usługi, nie eksporty baz danych ani dane dostępowe.

> Kopie zapasowe i prośby o przywrócenie

Kopie zapasowe służą do odtworzenia operacyjnego, nie zastępują eksportu; przywrócenie może nadpisać nowsze dane.
faq/backups-and-restore-requests

Kopia zapasowa to nie archiwum ani eksport

Retencja kopii zapasowych zależy od produktu i wybranych opcji. Kopia zapasowa pomaga przy operacyjnym odtworzeniu po błędzie, ale nie zastępuje własnego eksportu, archiwum audytowego ani Offsite Archive. Przywrócenie może nadpisać nowsze zmiany.

Przygotowanie prośby o przywrócenie

  1. Podaj nazwę usługi i numer zamówienia.
  2. Opisz przybliżony moment, do którego chcesz wrócić.
  3. Napisz, czy odtworzyć całą usługę czy konkretną część, jeśli jest obsługiwana.
  4. Dołącz widoczny błąd lub kontekst bez haseł i kluczy prywatnych.

Uwzględnij skutki przywrócenia

Jeśli usługa przyjęła w międzyczasie nowe dane, przywrócenie może zastąpić je starszym stanem. Przed potwierdzeniem poinformuj zespół i wyeksportuj to, czego nie chcesz stracić.

> Do czego służy Offsite Archive

Offsite Archive przechowuje zdalne kopie archiwalne oddzielnie od krótkich kopii operacyjnych i cyklu życia usługi.
faq/offsite-archive-purpose

Archiwum poza zwykłą pracą

Offsite Archive jest przeznaczony na zdalne kopie archiwalne i dłuższe przechowywanie danych. Nie jest żywym dyskiem aplikacji, zamiennikiem lokalnego eksportu ani tym samym co krótkie backupy operacyjne.

Kiedy włączyć

  1. Użyj go dla danych, które chcesz trzymać poza zwykłą pracą usługi.
  2. Wybierz dni retencji według compliance, potrzeby biznesowej lub celu recovery.
  3. Pamiętaj, że koszt rośnie wraz z objętością i czasem przechowywania.
  4. Przy dużych danych planuj archiwum razem z własnym procesem eksportu.

Jak rozumieć cenę

Podstawą są MB-days: ilość przechowanych danych pomnożona przez liczbę dni. Stawka jest pokazywana jako EUR/GB/miesiąc, a wynik zaokrąglany do pełnych centów.

> Wybór CPU, RAM i dysku dla VPS

Rozmiar VPS dobieraj do aplikacji, bazy danych, cache, logów i wzrostu; OOM lub swapowanie to sygnał na więcej RAM.
faq/vps-cpu-ram-and-disk-sizing

Zacznij od realnego obciążenia

Mała statyczna strona ma inne potrzeby niż baza danych, aplikacja Java, wyszukiwarka czy kontener z buildami. Planuj pamięć aplikacji, cache, bazę, logi, uploady i zapas na wzrost.

Sygnały, że plan jest za mały

  1. Zwiększ RAM przy OOM, out of memory, process killed lub stałym swapowaniu.
  2. Zwiększ CPU przy długiej wysokiej pracy obliczeniowej, kompresji, buildach lub zajętych workerach.
  3. Zwiększ dysk zanim zapełni się system plików, logi lub baza.
  4. Po każdej zmianie sprawdź, czy aplikacja przestała trafiać w poprzedni limit.

Co wysłać przy pytaniu o sizing

Pomaga nazwa usługi, typ aplikacji, widoczny błąd, przybliżony czas problemu i obecne CPU, RAM oraz dysk. Nie wysyłaj haseł, kluczy prywatnych ani wewnętrznych plików konfiguracyjnych.

> Kiedy publiczna IP dla VPS ma sens

Dedykowana publiczna IP pomaga przy allowlistach, dostępie inbound, stałym źródle outbound lub usługach związanych z adresem.
faq/vps-public-ip-options

Najpierw ustal kierunek komunikacji

Publiczna IP nie jest automatycznie potrzebna dla każdej usługi. Najczęściej rozwiązuje wymagania partnerów, dostawców lub firewalli dotyczące allowlisty, stabilnego źródła outbound albo dostępu inbound na konkretny port.

Pytania przed zamówieniem IP

  1. Zapytaj partnera, czy allowlista dotyczy inbound, outbound czy obu kierunków.
  2. Używaj nazw DNS zamiast numerycznych IP tam, gdzie system zewnętrzny na to pozwala.
  3. Otwieraj tylko porty faktycznie potrzebne aplikacji.
  4. Przekaż wymaganie allowlisty wsparciu zanim zmienisz dostęp produkcyjny.

Co zostawić zamknięte

Publiczna IP nie oznacza otwarcia wszystkich portów. Projektuj dostęp po minimalnych potrzebnych usługach i nie wysyłaj haseł, kluczy prywatnych ani wrażliwych notatek firewall.

> Współdzielony dostęp SSH do VPS

Bez dokupionej publicznej IP VPS łączy się przez współdzielony endpoint SSH z wysokim portem; z publiczną IP pojawia się też druga bezpośrednia ścieżka SSH.
faq/shared-ssh-access-for-vps

Dlaczego współdzielony SSH używa wysokiego portu

Wiele usług VPS może współdzielić ten sam publiczny endpoint SSH, dlatego każda usługa dostaje własny wysoki port. Port jest częścią kierowania do twojej usługi; bez niego połączenia nie dałoby się jednoznacznie dostarczyć do właściwego VPS.

Łączenie według typu dostępu

  1. Dla współdzielonego SSH skopiuj z usługi nazwę użytkownika SSH, publiczny host i wysoki port.
  2. Użyj formatu ssh -p <port> <username>@<public-host>.
  3. Jeśli usługa ma dokupioną publiczną IP, może mieć drugi endpoint SSH bezpośrednio na tej IP lub jej nazwie DNS.
  4. Klucz prywatny używaj tylko lokalnie w kliencie SSH lub agencie; do wsparcia podaj publiczny host, port, nazwę użytkownika i widoczny błąd.

Druga ścieżka z publiczną IP

Publiczna IP nie usuwa współdzielonego endpointu SSH; dodaje oddzielny sposób dostępu przydatny dla allowlist, monitoringu lub bezpośredniego połączenia. Możesz więc widzieć host współdzielony z wysokim portem oraz bezpośredni host lub IP.

> Lista kontrolna przed podłączeniem własnej domeny

Przed przełączeniem domeny sprawdź autorytatywne DNS, dokładny hostname, typ rekordu, apex lub subdomenę i stare konflikty.
faq/custom-domain-readiness-checklist

Liczy się dokładny hostname

Najpierw ustal, czy podłączasz apex domain jak example.com, czy subdomenę jak app.example.com. Każdy wariant może wymagać innego typu rekordu DNS i ma inne ograniczenia dostawcy.

Przed zmianą DNS

  1. Sprawdź, gdzie edytuje się autorytatywne rekordy DNS domeny.
  2. Usuń lub zmień kolidujące A/AAAA, CNAME, ALIAS, ANAME albo przekierowania.
  3. Użyj typu rekordu zalecanego dla danej usługi i hostname.
  4. Po zmianie poczekaj na propagację DNS i dopiero testuj finalne HTTPS.

Bezpieczny rollback

Nie wyłączaj starego hostingu, zanim nowy hostname odpowiada poprawnie. Przy problemie wyślij domenę, oczekiwany cel i publicznie widoczny wynik DNS, nie dostęp do rejestratora.

> Typy rekordów DNS dla usług

A/AAAA wskazują adresy, CNAME alias, MX pocztę, a TXT weryfikację, SPF, DKIM lub DMARC.
faq/dns-record-types-for-services

Nie mieszaj rekordów na ślepo

Każdy typ DNS ma inną rolę. A i AAAA wskazują adresy IP, CNAME tworzy alias dla subdomeny, MX kieruje pocztę, TXT niesie weryfikacje i polityki pocztowe, CAA ogranicza urzędy certyfikacji.

Przy kopiowaniu rekordów

  1. Skopiuj nazwę, typ i wartość dokładnie według instrukcji usługi.
  2. Nie ustawiaj CNAME na hostname, który według reguł DNS ma już inne rekordy.
  3. DKIM umieść pod selectorem dostawcy, a DMARC zwykle pod _dmarc.
  4. CAA zmieniaj ostrożnie, bo błędna wartość może blokować certyfikat.

Gdy DNS nie działa

Wyślij hostname, typ rekordu, oczekiwaną wartość i publicznie widoczny wynik. Nie wysyłaj loginu do panelu DNS ani screenshotów z wrażliwymi danymi dostępowymi.

> Propagacja DNS i TTL bez obietnicy co do minuty

TTL określa, jak długo resolvery mogą trzymać starą odpowiedź; w przejściu stare i nowe wyniki mogą istnieć równolegle.
faq/dns-propagation-and-ttl

Propagacja to cache, nie magia

W DNS nie ma stałej obietnicy co do minuty. Po zmianie autorytatywnego DNS różne resolvery mogą zwracać stare i nowe odpowiedzi, dopóki nie wygaśnie cache według TTL.

Przy planowanej zmianie

  1. Jeśli dostawca pozwala, obniż TTL przed planowanym przełączeniem.
  2. Po edycji DNS nie rób losowych kolejnych zmian, gdy cache wygasa.
  3. Testuj z kilku resolverów, jeśli wyniki się różnią.
  4. Zapisz czas zmiany, starą wartość, nową wartość i TTL.

Co wysłać do diagnostyki

Podaj hostname, oczekiwany cel, widoczną starą odpowiedź, widoczną nową odpowiedź, TTL i czas zmiany. Dostęp do konta DNS nie jest potrzebny.

> Planowanie przestrzeni dla Nextcloud

Do pojemności wlicz pliki użytkowników, foldery wspólne, wersje, kosz, podglądy, narzut synchronizacji i wzrost zespołu.
faq/nextcloud-storage-planning

Nextcloud rośnie także poza widocznymi plikami

Pojemność zużywają pliki użytkowników, foldery wspólne, usunięte pliki, wersjonowanie, podglądy, miniatury, klienci synchronizacji i importy. Blisko limitu mogą zawodzić uploady lub synchronizacja.

Przed zamówieniem pojemności

  1. Policz aktualne dane użytkowników i foldery wspólne.
  2. Dodaj zapas na wersje, kosz, podglądy i narzut synchronizacji.
  3. Uwzględnij duże importy, nowe zespoły i oczekiwany wzrost.
  4. Zwiększ pojemność zanim użytkownicy trafią na limit.

Przy problemach z synchronizacją

Wyślij rozmiar usługi, przybliżone użycie, czas problemu i widoczny błąd klienta. Nie wysyłaj prywatnych plików, haseł ani eksportów danych użytkowników, chyba że wsparcie poprosi bezpiecznym sposobem.

> Migracja repozytoriów do Gitea

Przeniesienie repozytoriów Git zaplanuj z LFS, submodules, uprawnieniami, deploy keys, webhookami i CI/CD.
faq/gitea-repository-migration

Migracja to nie tylko git clone

Poza historią repozytorium trzeba przenieść lub odtworzyć właścicieli, zespoły, protected branches, protected tags, Git LFS, submodules, deploy keys, webhooki i integracje CI/CD.

Kontrola przed cutoverem

  1. Spisz repozytoria, właścicieli, grupy dostępu i konta automatyzacji.
  2. Sprawdź obiekty Git LFS, submodules, branch protections i tag protections.
  3. Po przeniesieniu przetestuj clone, push, Git LFS, submodules i przebieg CI.
  4. Stare dane dostępowe po migracji usuń lub bezpiecznie obróć.

Wrażliwe dane przy migracji

Nie wysyłaj prywatnych kluczy, prywatnej części deploy key ani poufnych wartości CI. Wystarczą nazwy repozytoriów, typ integracji, widoczny błąd i informacja, co działało przed migracją.

> Domena nadawcza dla Listmonk

Do kampanii przygotuj domenę lub subdomenę sender, tożsamość From, SPF, DKIM, DMARC, bounce i wypisanie.
faq/listmonk-sender-domain-basics

Dostarczalność zaczyna się od domeny

Listmonk potrzebuje jasnej tożsamości From i rekordów DNS, które poczta potrafi zweryfikować. SPF, DKIM i DMARC muszą pasować do domeny lub subdomeny, z której wysyłasz kampanie.

Przed pierwszą kampanią

  1. Wybierz domenę lub subdomenę sender i nazwę From.
  2. Dodaj weryfikacyjne DNS, SPF, DKIM selector i DMARC.
  3. Przetestuj dostarczenie, bounce lub Return-Path oraz linki w wiadomości.
  4. Sprawdź wypisanie i List-Unsubscribe przed prawdziwą wysyłką.

Dostępy mailowe nie należą do ticketu

Do diagnostyki wyślij domenę, typ rekordu, publicznie widoczną wartość DNS i komunikat błędu. Nie wysyłaj haseł SMTP, prywatnego DKIM key ani eksportu odbiorców z danymi osobowymi.

> Ustawienia Runtime dla Classic Hosting

Classic Hosting może działać w auto lub manualnym Runtime; CPU, RAM, przestrzeń, retencja backupów, Offsite Archive, uploady, cache i logi wpływają na cenę i stabilność.
faq/classic-hosting-runtime-settings

Tryb auto nie jest jedyną dobrą opcją

Auto Runtime pomaga przy rozpoznanych projektach, ale tryb manualny jest właściwy, gdy chcesz dokładnie wybrać Nginx, Apache, FrankenPHP albo konkretny runtime językowy. PHP selector stosuj tylko tam, gdzie wspiera go wybrany runtime.

Ustawienia przed wdrożeniem

  1. Wybierz auto lub manualny Runtime według frameworka i sposobu buildowania.
  2. Wybierz PHP 8.2, 8.3 lub 8.4 tylko dla obsługiwanych scenariuszy PHP.
  3. Ustaw CPU, RAM, dysk, retencję backupów i Offsite Archive według danych i ruchu.
  4. Po deployu przetestuj uploady, cache, logi i widoczne błędy aplikacji.

Gdy aplikacja nie startuje

Wyślij tryb runtime, język lub wersję PHP, widoczny błąd, co się zmieniło i przybliżony czas wdrożenia. Nie wysyłaj plików .env, haseł ani pełnych logów z wrażliwymi wartościami.

> Jakie informacje bezpiecznie wysłać do wsparcia

Najbardziej pomagają numery zamówień, nazwy usług, domeny, czasy, publiczne hosty, porty, ustawienia hostingu i widoczne błędy bez wrażliwych danych.
faq/support-safe-information-to-share

Dobry ticket ma kontekst, nie wrażliwe dane

Wsparcie reaguje szybciej, gdy otrzyma numer zamówienia, nazwę usługi, domenę, publiczny host lub port, czas problemu, zmiany i dokładny widoczny błąd.

Bezpieczna treść wiadomości

  1. Podaj zamówienie, usługę, domenę, czas i krok, przy którym wystąpił problem.
  2. Dla hostingu dodaj runtime, PHP lub język, CPU, RAM, dysk, uploady, cache i logi bez wrażliwych wartości.
  3. Zrzuty ekranu przed wysłaniem przytnij lub zamazuj wrażliwe miejsca.
  4. Jeśli nie wiesz, czy dana informacja pasuje do ticketu, najpierw zapytaj bez jej wysyłania.

Czego nigdy nie wysyłać

Nie wysyłaj haseł, kluczy prywatnych, recovery seedów, session cookies, eksportów baz danych, pełnych plików .env, pełnych logów z wrażliwymi wartościami ani wewnętrznych szczegółów infrastruktury.