FAQ

Najczęściej zadawane pytania

Praktyczne, krótkie poradniki dotyczące konfiguracji usług, dostępu oraz typowych czynności dla użytkowników.

> Jak działa system kredytowy Cli>_?

Jedno wspólne saldo przedpłacone finansuje wszystkie kwalifikujące się usługi i maleje tylko podczas ich aktywnego działania.
faq/prepaid-credit-how-it-works

Konto Cli>_ ma jedno wspólne saldo przedpłacone. Uprawnieni nowi klienci mogą odebrać Starter Credit dopiero po ukończeniu wymaganego procesu weryfikacji konta i zabezpieczeń przed nadużyciami. Aktywne kwalifikujące się usługi zużywają saldo z czasem. Szacunek miesięczny obejmuje 31 dni, a nowa usługa może ruszyć tylko wtedy, gdy saldo wystarczy na co najmniej 7 dni. Czerwone ostrzeżenie pojawia się, gdy szacowany czas działania spadnie poniżej 7 dni; w przeciwnym razie pomarańczowe pojawia się poniżej 14 dni.

Po wyczerpaniu salda usługa zostaje zawieszona po 7 dniach, przestaje zużywać kredyt i rozpoczyna się 7-dniowy okres retencji i usunięcia. Przed wyświetlonym terminem można ją uruchomić ponownie po zapewnieniu wystarczającego salda. Anulowanie wdrożonej usługi również ją zawiesza i rozpoczyna ten sam okres. Oczekująca, niewdrożona usługa może zostać dezaktywowana natychmiast. Po terminie rozpoczyna się dezaktywacja i usuwanie wdrożonej usługi. Force delete natychmiast dezaktywuje usługę, pomija retencję i rozpoczyna usuwanie z aktywnego runtime; zakończenie następuje po przetworzeniu deploymentu i GitOps. Kopie zapasowe i Offsite Archive mają osobne zasady retencji.

Przykład OpenCode za 9,90 EUR: 9,90 / 31 ≈ 0,319 EUR dziennie. Po 10 pełnych dniach zużycie wynosi około 3,19 EUR. Jeśli saldo początkowe wynosiło dokładnie 9,90 EUR i nie korzystały z niego inne usługi, pozostaje około 6,71 EUR. Po wyłączeniu dalsze zużycie ustaje.

Przykład ma charakter ilustracyjny. Zawsze obowiązują aktualne ceny wyświetlane w Cli>_.

> Jak wygenerować klucz SSH przy użyciu linii komend

Utwórz klucz publiczny SSH, aby bezpiecznie uzyskać dostęp do wirtualnego serwera (VPS). Udostępnij tylko klucz publiczny; klucz prywatny pozostaw na swoim urządzeniu.
faq/jak-wygenerowac-publiczny-klucz-ssh

Klucz publiczny udostępniany jest, a klucz prywatny pozostaje w Twojej posiadłości

Podczas składania zamówienia lub konfiguracji usługi, wklej tylko klucz publiczny. Klucz prywatny pozostaje na Twoim komputerze i nie jest wysyłany do działu pomocy technicznej ani wpisywany do formularza internetowego.

Instrukcje

  1. Otwórz terminal na swoim komputerze.
  2. Uruchom polecenie: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Potwierdź lokalizację pliku lub wybierz własną ścieżkę. Nigdy nie udostępniaj swojego klucza prywatnego.
  4. Wyświetl klucz publiczny za pomocą polecenia: cat ~/.ssh/id_ed25519.pub.
  5. Skopiuj całą linię rozpoczynającą się od ssh-ed25519 i wklej ją do pola "Klucz publiczny SSH" podczas składania zamówienia lub konfiguracji usługi.
  6. Skopiuj całą linię z ssh-ed25519 i wklej ją do pola "Klucz publiczny SSH".

PowerShell w systemie Windows 10/11

  1. Otwórz program PowerShell lub Windows Terminal.
  2. Uruchom polecenie: ssh-keygen -t ed25519 -C "twój-email@example.com".
  3. Naciśnij Enter, aby zapisać klucz w lokalizacji C:\Users\twój-użytkownik\.ssh\id_ed25519 lub wprowadź własną ścieżkę.
  4. Jeśli system Windows poprosi o hasło, użyj takiego, który możesz bezpiecznie zapamiętać, lub naciśnij Enter, aby pominąć ten krok podczas prostego konfigurowania usługi.
  5. Wyświetl klucz publiczny za pomocą polecenia: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Skopiuj tylko całą linię rozpoczynającą się od ssh-ed25519. Nie kopiuj ani nie przesyłaj pliku z kluczem prywatnym.
> Jak utworzyć klucz SSH graficznie w systemie Windows

Graficzny poradnik dla systemu Windows, który pokazuje jak utworzyć parę kluczy SSH bez użycia wiersza poleceń.
faq/jak-utworzyc-klucz-ssh-graficznie-w-windows

Użyj narzędzia Windows i wklej tylko klucz publiczny

Parę kluczy SSH można utworzyć graficznie za pomocą klienta SSH dla systemu Windows, takiego jak PuTTYgen. Cli>_ potrzebuje tylko klucza publicznego. Plik z kluczem prywatnym pozostaw na swoim komputerze i nie przesyłaj go do formularza internetowego.

Instrukcja

  1. Zainstaluj PuTTY lub otwórz PuTTYgen, jeśli jest już zainstalowany.
  2. Wybierz EdDSA/Ed25519, jeśli jest dostępne, w przeciwnym razie wybierz RSA 4096.
  3. Kliknij przycisk Generate i porusz myszą po pustej przestrzeni, aż klucz zostanie wygenerowany.
  4. Dodaj frazę hasła, jeśli chcesz zapewnić dodatkową lokalną ochronę dla klucza prywatnego.
  5. Zapisz klucz prywatny na swoim urządzeniu i traktuj go jako poufny.
  6. Skopiuj tekst klucza publicznego i wklej go do pola SSH public key w Cli>_.

Nie udostępniaj poufnych danych

Nie przesyłaj plików .ppk, kluczy prywatnych, haseł ani tokenów do działu pomocy technicznej lub w formularzach.

> Przenieś swoją własną domenę

Dowiedz się, jak skierować własną domenę lub subdomenę do usługi CLIopen przed aktywacją opcji 'Przenieś swoją własną domenę'.
faq/podlaczenie-wlasnej-domeny

Co robi to ustawienie?

Funkcja "Użyj własnej domeny" umożliwia Twojej usłudze odpowiadanie na własnym hostname, np. app.example.com, zamiast korzystania z domyślnego wygenerowanego hostname *.co.cliopen.cloud. DNS musi wskazywać na CLIopen, zanim nazwę hosta będzie można bezpiecznie używać w usłudze.

Przed rozpoczęciem

  1. Wybierz dokładną nazwę hosta, którą chcesz użyć, np. app.example.com. Najprostszym rozwiązaniem jest użycie poddomeny.
  2. Otwórz panel zarządzania DNS u rejestratora domeny lub dostawcy usług DNS.
  3. Usuń wszelkie konfliktowe rekordy A, AAAA, CNAME, ALIAS lub przekierowania dla tej nazwy hosta.
  4. Zachowaj aktywny automatycznie generowany hostname CLIopen, dopóki Twój własny hostname nie zostanie zweryfikowany i będzie w pełni funkcjonalny.

Rekomendowane ustawienia DNS dla poddomeny

Utwórz rekordy DNS dla dokładnego hostnama, który wprowadzasz do CLIopen. Dla app.example.com etykieta DNS to app. Skieruj go na adresy ingress CLIopen, które otrzymasz od działu wsparcia CLIopen lub w dokumentacji usługi. Jeśli Twój dostawca wymaga typu rekordu, użyj rekordu A dla IPv4 i rekordu AAAA dla IPv6, jeśli te adresy są dostępne.

Pamiętaj:

app.example.com.  A     <adres IPv4 CLIopen>
app.example.com.  AAAA  <adres IPv6 CLIopen, jeśli jest dostępny>

Gdy CLIopen udostępnia cel CNAME

Niektóre usługi mogą udostępnić wygenerowaną nazwę hosta, np. service.customer.co.cliopen.cloud. Jeśli instrukcje dotyczące Twojej usługi wyraźnie wymagają użycia rekordu CNAME, utwórz rekord taki jak app.example.com CNAME service.customer.co.cliopen.cloud. Używaj rekordów CNAME tylko dla poddomen, a nie dla domeny głównej (root), chyba że Twój dostawca DNS obsługuje funkcję ALIAS lub ANAME flattening.

Używanie domeny głównej

Dla domeny głównej, takiej jak example.com, większość dostawców DNS nie zezwala na użycie standardowego rekordu CNAME. Użyj rekordów A/AAAA wskazujących na adresy wejściowe CLIopen lub funkcji ALIAS/ANAME oferowanej przez Twojego dostawcę, jeśli CLIopen udostępnił Ci nazwę hosta docelową.

Delegowanie całej poddomeny

Jeśli chcesz, aby CLIopen zarządzał rekordami w poddomenie, takim jak apps.example.com, utwórz rekordy NS dla tej poddomeny wskazujące na serwery DNS CLIopen, które otrzymasz. Nie zmieniaj serwerów nazw dla całej domeny, chyba że celowo chcesz, aby CLIopen (lub inny serwis DNS) zarządzał wszystkimi rekordami.

Lista kontrolna

  1. Poczekaj na propagację DNS. Małe zmiany często stają się widoczne w ciągu kilku minut, ale niektóre firmy mogą dłużej przechowywać dane w pamięci podręcznej.
  2. Sprawdź, czy nazwa hosta wskazuje na serwer CLIopen, a nie na poprzedniego dostawcę.
  3. W polu "Bring your own domain" wprowadź dokładną nazwę hosta, bez `https://` i ścieżki.
  4. Po aktualizacji usługi przetestuj adres `https://app.example.com` w przeglądarce.
  5. Zachowaj stare rekordy DNS tylko wtedy, gdy nie kolidują z nową nazwą hosta.
> Jak przenieść strefę DNS do CLIopen

Zdeleguj domenę na serwery ns1.cliopen.com i ns2.cliopen.com, aby firma CLIopen mogła publikować rekordy dla całej strefy.
faq/przekazanie-strefy-dns

Co oznacza tutaj transfer strefy?

W przypadku klienta korzystającego z usług DNS, transfer oznacza zmianę serwerów nazw autorytatywnych u rejestratora domeny. Po przekierowaniu do CLIopen, rekordy DNS dodane w CLIopen są publikowane przez nasze serwery nazw autorytatywne.

Przed zmianą serwerów nazw

  1. Skopiuj istniejące rekordy DNS, które nadal są potrzebne, takie jak rekordy dla strony internetowej, poczty elektronicznej, weryfikacji, SPF, DKIM, DMARC oraz rekordy serwisowe.
  2. Dodaj strefę w CLIopen DNS. Jeśli delegacja nie jest jeszcze gotowa, CLIopen zapisuje ją, ale nie aktywuje dla klienta, dopóki walidacja się nie powiedzie.
  3. Jeśli to możliwe, utwórz wymagane rekordy w CLIopen DNS przed przełączeniem serwerów nazw.
  4. Upewnij się, że ustawienia CAA są poprawne, ponieważ nieprawidłowe wartości mogą uniemożliwić wystawienie certyfikatów.

Delegowanie strefy

  1. Otwórz ustawienia domeny u rejestratora, na przykład example.com.
  2. Znajdź serwery nazw (Nameservers), delegację DNS lub ustawienia autorytatywnego DNS.
  3. Zastąp aktualne serwery nazw wartościami ns1.cliopen.com i ns2.cliopen.com.
  4. Zapisz zmiany i poczekaj na propagację w rejestrze oraz resolverach.

Weryfikacja

Wróć do CLIopen DNS i kliknij przycisk Ponowne sprawdzenie delegacji. Gdy publiczne rekordy NS wskazują ns1.cliopen.com i ns2.cliopen.com, strefa zostanie dodana do kolejki synchronizacji, a rekordy staną się aktywne w CLIopen.

> Rejestracja konta i pierwsze logowanie

Załóż jedno konto firmowe, uzupełnij dane do faktur oraz użyj adresu e-mail, do którego Twój zespół będzie miał dostęp.
faq/account-registration-and-login

Jedno konto do składania zamówień i zarządzania

Wykorzystaj swoje konto jako stałe miejsce do przechowywania informacji o zamówieniach, danych rozliczeniowych, usługach, domenach oraz do komunikacji z działem wsparcia. Najlepiej używać służbowego adresu e-mail, do którego zespół będzie miał dostęp nawet po zmianach w składzie zespołu.

Przed pierwszym zamówieniem

  1. Zarejestruj się przy użyciu swojego służbowego adresu e-mail.
  2. Potwierdź wiadomość e-mail, jeśli strona o to poprosi.
  3. Uzupełnij dane do faktury przed złożeniem płatnej zamówienia.
  4. Jeśli będzie dostępne uwierzytelnianie dwuskładnikowe, włącz je od razu po pierwszym zalogowaniu.

Dostęp dla zespołu

Nie przesyłaj haseł współpracownikom przez czat ani e-mail. Jeśli dostęp potrzebuje więcej osób, korzystaj z wewnętrznego menedżera haseł lub poproś o zalecany proces zespołowy; wsparcie techniczne nie wymaga Twojego hasła ani tokenu uwierzytelniającego.

> Szacunkowe zużycie: miesięczne, roczne oraz rzeczywiste dzienne

Ceny podane za miesiąc i rok służą do porównania; w przypadku usług płatnych z góry, liczy się rzeczywiste dzienne zużycie po zatwierdzeniu zmiany.
faq/billing-periods-and-credit-burn

Porównanie nie jest kalendarzem fakturowania

Szacunkowe wartości miesięczne należy traktować jako porównanie dla 31 dni, a roczne jako porównanie dla 372 dni. Rzeczywiste zużycie kredytu w przypadku usług płatnych z góry odbywa się zgodnie z czasem aktywności usługi oraz zatwierdzoną konfiguracją.

Co należy sprawdzić przy zmianie ceny

  1. Porównaj dzienne zużycie przed i po zmianie.
  2. Większa ilość CPU, RAM lub dysku, a także płatne opcje, mogą zwiększyć dzienne zużycie.
  3. Zmiana wchodzi w życie dopiero po potwierdzeniu, ewentualnej płatności i jej zastosowaniu.
  4. W celach księgowych, zapisz potwierdzenie zamówienia i historię kredytu.

W przypadku sporu należy określić konkretny okres.

Obsługa klienta będzie potrzebować numeru zamówienia, nazwy usługi oraz dat, za które chcesz sprawdzić zużycie. Nie przesyłaj danych bankowych ani zrzutów ekranu zawierających niechciane dane osobowe.

> Status zamówienia po dokonaniu płatności

Zamówienie może czekać na potwierdzenie przez dostawcę przed rozpoczęciem realizacji; duplikuj je tylko wtedy, gdy pierwsze zamówienie zostało wyraźnie anulowane lub wygasło.
faq/order-status-and-payment-confirmation

"W oczekiwaniu" nie zawsze oznacza błąd

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

Co zrobić po zapłacie

  1. Po zakończeniu płatności wróć do Cli>_.
  2. Sprawdź w swoim koncie status zamówienia i ewentualny komunikat dotyczący płatności.
  3. Jeśli zamówienie nadal jest przetwarzane, daj dostawcy czas na potwierdzenie.
  4. W razie problemów prosimy o kontakt z działem pomocy technicznej, podając numer zamówienia oraz referencję płatności, jeśli jest dostępna.

Czego nie należy wysyłać

Dział obsługi klienta nie wymaga danych karty kredytowej, hasła do logowania ani pełnego potwierdzenia transakcji bankowej. Wystarczy numer zamówienia, czas dokonania płatności, widoczny status oraz zamazany zrzut ekranu w przypadku wyświetlenia błędu.

> Dane, które przyspieszą konfigurację usługi

Przygotuj nazwę usługi, domenę, rozmiar pamięci, adres e-mail do logowania oraz klucz SSH. Nie umieszczaj danych poufnych w formularzach.
faq/service-setup-information-needed

Dokładne dane pozwalają zaoszczędzić czas

W formularzach zamówień należy podawać tylko publiczne lub niewrażliwe informacje, takie jak nazwa usługi, domena, konfiguracja DNS, rozmiar przestrzeni dyskowej, procesor (CPU), pamięć RAM, adres e-mail administratora lub klucz SSH. Hasła, klucze prywatne i tokeny nie powinny być wpisywane w formularzach.

Przygotuj się przed złożeniem zamówienia

  1. Wybierz zrozumiałą nazwę usługi dla swojego zespołu.
  2. Zdecyduj, czy chcesz użyć własnej domeny, czy tymczasowego hostname'u.
  3. Przygotuj klucz SSH, jeśli usługa go wymaga.
  4. Sprawdź wymagane zasoby, takie jak przestrzeń dyskowa, w zależności od aplikacji, którą zamierzasz uruchomić.

Nie wysyłaj poufnych informacji

Jeśli nie jesteś pewien, czy dana informacja jest poufna, zapytaj o to, zanim ją przekażesz. Nie udostępniaj kluczy prywatnych, haseł, tokenów, kopii baz danych ani pełnych plików konfiguracyjnych w czacie ani w zamówieniu.

> Zmiana procesora, pamięci RAM, dysku lub okresu przechowywania po złożeniu zamówienia

Modyfikuj istniejącą usługę za pomocą jej szczegółów, a nie poprzez tworzenie nowego, duplikatowego zamówienia. Zmiana zasobów może wpłynąć na cenę usługi, dzienne zużycie kredytów, konieczność ponownego uruchomienia oraz ryzyko przestoju.
faq/change-service-resources-after-order

Czy modyfikujesz istniejącą usługę, czy tworzysz nową?

Jeśli usługa już działa, zmiany zasobów należy wprowadzać z poziomu szczegółów usługi. Nowe zamówienie utworzy kolejną usługę zamiast zmodyfikować istniejącą i może zmienić cenę, dzienne zużycie oraz zachowanie systemu po zatwierdzeniu, opłaceniu i zastosowaniu zmian.

Przed zatwierdzeniem zmiany

  1. Sprawdź aktualne zużycie procesora (CPU), pamięci RAM, dysku oraz ustawienia kopii zapasowych i retencji Offsite Archive.
  2. Sprawdź nową dzienną cenę i jej wpływ na dostępny kredyt.
  3. Przeczytaj powiadomienie o planowanym restarcie, pracach konserwacyjnych lub awarii.
  4. Przed wprowadzeniem ryzykownych zmian, wykonaj własny eksport ważnych danych.

Co zrobić, gdy zmiana nie przebiega zgodnie z oczekiwaniami

Podaj nazwę usługi, czas zmiany, widoczny status oraz komunikat o błędzie. Nie przesyłaj kluczy prywatnych, haseł ani tokenów; do diagnostyki wystarczy publiczny kontekst i zamazany zrzut ekranu.

> Anulowanie usługi i okres usuwania danych

Usługa została aktywowana. Najpierw zostaje ona wstrzymana, wyświetlany jest konfigurowalny termin usunięcia danych, a następnie następuje trwałe usunięcie.
faq/cancel-service-and-data-retention

Anulowanie usługi nie zawsze oznacza jej natychmiastowe usunięcie

W przypadku już aktywnej usługi, najpierw następuje jej wstrzymanie i wyświetlany jest konfigurowalny okres czasu, po którym można rozważyć przywrócenie lub eksport danych. Oczekujące zamówienia, które nie zostały jeszcze opłacone i nie generują żadnych danych, mogą mieć inne zachowanie, a ostateczne usunięcie następuje dopiero po upływie określonego czasu trwania.

Sprawdź przed anulowaniem

  1. Wyeksportuj dane, które chcesz zachować na dłużej.
  2. Zapoznaj się z datą i godziną planowanego usunięcia danych w przypadku zawieszenia usługi.
  3. Pamiętaj, że kopie zapasowe i archiwizacja zewnętrzna różnią się od usuwania danych zgodnie z cyklem życia usługi.
  4. Jeśli masz wątpliwości, skontaktuj się z działem pomocy technicznej przed terminem usunięcia.

Odzyskanie danych po upływie terminu może nie być możliwe

Po upływie widocznego terminu nie traktuj danych jako dostępnych. W przypadku pytań podaj numer zamówienia i nazwę usługi, a nie eksporty baz danych ani dane uwierzytelniające.

> Kopie zapasowe i wnioski o przywrócenie

Kopie zapasowe służą do odzyskiwania danych w przypadku awarii, a nie zastępują eksportu; proces przywracania może nadpisać nowsze dane.
faq/backups-and-restore-requests

Kopia zapasowa nie jest archiwum ani eksportem

Okres przechowywania kopii zapasowych zależy od wybranego produktu i opcji. Kopia zapasowa służy do przywrócenia działania po awarii, ale nie zastępuje własnego eksportu danych, archiwizacji audytowej ani zewnętrznego archiwum (Offsite Archive). Przywracanie może nadpisać nowsze zmiany.

Jak przygotować żądanie przywrócenia

  1. Podaj nazwę usługi i numer zamówienia.
  2. Opisz przybliżony moment, do którego chcesz powrócić.
  3. Wpisz, czy ma zostać odtworzona cała usługa, czy tylko jej część, jeśli jest to możliwe.
  4. Dołącz widoczny błąd lub kontekst, ale unikaj przesyłania haseł, tokenów i kluczy prywatnych.

Przed rozpoczęciem procesu odzyskiwania uwzględnij potencjalne skutki

Jeśli usługa w międzyczasie przyjęła nowe dane, proces przywracania może zastąpić je starszym stanem. Przed potwierdzeniem prosimy o kontakt z zespołem oraz wykonanie eksportu danych, których nie chcesz utracić.

> Czym jest Offsite Archive?

Offsite Archive przechowuje zdalne kopie archiwne, oddzielone od krótkich kopii zapasowych i cyklu życia usługi.
faq/offsite-archive-purpose

Archiwum działające w tle

Offsite Archive służy do tworzenia zdalnych kopii zapasowych i długoterminowego przechowywania danych. Nie jest to dysk aktywny dla aplikacji, zamiennik lokalnego eksportu ani takie samo rozwiązanie jak krótkie kopie zapasowe.

Kiedy go włączyć

  1. Użyj tej funkcji do przechowywania danych, które mają być dostępne również poza normalnym działaniem usługi.
  2. Wybierz okres retencji w zależności od wymagań prawnych, potrzeb biznesowych lub celu odzyskiwania danych.
  3. Pamiętaj, że koszt rośnie wraz z objętością przechowywanych danych i czasem ich przechowywania.
  4. W przypadku dużych ilości danych należy zaplanować archiwum wraz z własnym procesem eksportu.

Jak interpretować cenę

Podstawą jest MB-days: ilość przechowywanych danych pomnożona przez liczbę dni. Cena wyświetlana jest dla klienta jako EUR/GB/miesiąc, a wynik zaokrąglany do pełnych centów.

> Wybór procesora (CPU), pamięci RAM i dysku dla VPS

Wybierz rozmiar VPS w zależności od aplikacji, bazy danych, pamięci podręcznej, logów oraz przewidywanego wzrostu. OOM lub używanie przestrzeni wymiany wskazują na potrzebę zwiększenia ilości pamięci RAM.
faq/vps-cpu-ram-and-disk-sizing

Zacznij od rzeczywistego obciążenia

Mała strona internetowa ma inne wymagania niż baza danych, aplikacja Java, wyszukiwarka lub kontener z procesami budowania. Podczas planowania uwzględnij pamięć aplikacji, pamięć podręczną, bazę danych, logi, przesyłanie plików i rezerwę na przyszły wzrost.

Sygnały wskazujące na zbyt małą przestrzeń

  1. Zwiększ ilość pamięci RAM w przypadku wystąpienia błędów OOM (Out Of Memory), zatrzymywania procesów lub ciągłego używania pliku wymiany.
  2. Zwiększ moc obliczeniową CPU, gdy występują długotrwałe obciążenia, kompresja danych, procesy budowania lub intensywne działanie aplikacji.
  3. Zwiększ pojemność dysku przed zapełnieniem systemu plików, logów lub bazy danych.
  4. Po każdej zmianie sprawdź, czy aplikacja rzeczywiście przestała osiągać pierwotny limit.

Co należy przesłać, gdy masz pytanie o konfigurację zasobów

Podaj nazwę usługi, typ aplikacji, widoczny błąd, przybliżony czas wystąpienia problemu oraz aktualnie używane zasoby CPU, RAM i dysku. Nie udostępniaj haseł, kluczy prywatnych ani wewnętrznych plików konfiguracyjnych.

> Kiedy publiczny adres IP ma sens dla VPS

Dedykowany publiczny adres IP pomaga w tworzeniu list dozwolonych, zapewnia dostęp od strony klienta (inbound), stabilne źródło połączeń wychodzących (outbound) oraz umożliwia korzystanie z usług związanych z konkretnym adresem.
faq/vps-public-ip-options

Najpierw ustal kierunek komunikacji

Adres IP publiczny nie jest automatycznie wymagany dla każdej usługi. Najczęściej służy do spełnienia wymagań partnerów, dostawców lub firewalli dotyczących listy dozwolonych adresów (allowlist), stabilnego źródła wychodzącego ruchu lub dostępu przychodzącego na określony port.

Pytania przed zamówieniem adresu IP

  1. Zapytaj partnera, czy lista dozwolonych obejmuje połączenia przychodzące, wychodzące lub oba kierunki.
  2. Tam, gdzie to możliwe, używaj nazw DNS zamiast adresów IP.
  3. Otwieraj tylko te porty, które są faktycznie potrzebne aplikacji.
  4. Należy przekazać wymagania dotyczące listy dozwolonych (allowlist) działowi wsparcia przed zmianą konfiguracji dostępu produkcyjnego.

Co pozostawić wyłączone

Publiczny adres IP nie oznacza otwarcia wszystkich portów. Konfiguruj dostęp tylko dla niezbędnych usług i nie udostępniaj haseł, kluczy prywatnych ani wewnętrznych reguł zapory ogniowej w postaci zrzutów ekranu zawierających poufne dane.

> Wspólny dostęp SSH do serwera VPS

Bez zakupu publicznego adresu IP, serwer VPS łączy się za pośrednictwem współdzielonego punktu dostępu SSH z wysokim portem; w przypadku posiadania publicznego adresu IP, dostęp bezpośredni przez SSH jest również możliwy pod tym adresem.
faq/shared-ssh-access-for-vps

Dlaczego współdzielony SSH używa wysokiego portu

Wiele usług VPS może korzystać z tego samego publicznego punktu końcowego SSH, dlatego każda usługa otrzymuje własny wysoki port. Port jest częścią procesu kierowania ruchu do Twojej usługi; bez niego połączenie nie mogłoby być jednoznacznie dostarczone do właściwego serwera VPS.

Jak łączyć w zależności od typu dostępu

  1. W przypadku współdzielonego SSH skopiuj z usługi nazwę użytkownika SSH, adres hosta i port.
  2. Połącz się za pomocą polecenia ssh -p <port> <username>@<public-host> w terminalu lokalnym.
  3. Jeśli usługa posiada dodatkowo publiczny adres IP, może mieć drugi punkt końcowy SSH bezpośrednio pod tym adresem IP lub jego nazwą DNS, w zależności od konfiguracji usługi.
  4. Klucz prywatny używaj tylko lokalnie za pomocą klienta SSH lub agenta; do działu pomocy przekaż publiczny adres, port, nazwę użytkownika oraz widoczny błąd.

Kiedy masz wykupioną publiczną IP

Publiczny adres IP nie zastępuje współdzielonego punktu końcowego SSH; dodaje oddzielny sposób dostępu, który jest przydatny do list dopuszczalnych, monitoringu lub bezpośredniego połączenia. W praktyce możesz zobaczyć dwa sposoby łączenia się przez SSH: współdzielony host z wysokim portem oraz dedykowany host lub adres IP dla usługi z publicznym adresem IP.

> Sprawdzenie przed podłączeniem własnej domeny

Przed zmianą domeny sprawdź autoryzacyjne serwery DNS, dokładny host, typ rekordu (czy jest to domena główna czy subdomena) oraz brak konfliktujących starych rekordów.
faq/custom-domain-readiness-checklist

Liczy się dokładna nazwa hosta

Najpierw upewnij się, czy podłączasz domenę główną (np. example.com) czy subdomenę (np. app.example.com). Każdy wariant może wymagać innego typu rekordu DNS oraz mieć inne ograniczenia po stronie dostawcy.

Przed zmianą DNS

  1. Sprawdź, gdzie edytowane są autorytatywne rekordy DNS domeny.
  2. Usuń lub zmień kolidujące rekordy A/AAAA, CNAME, ALIAS, ANAME lub przekierowania.
  3. Użyj typu rekordu zalecanego dla danej usługi i nazwy hosta.
  4. Po zmianie poczekaj na propagację DNS i dopiero wtedy przetestuj działanie HTTPS.

Bezpieczne przywrócenie poprzedniej wersji

Nie wyłączaj starego hostingu, dopóki nowy adres nie będzie działał poprawnie. W przypadku problemów podaj domenę, oczekiwany cel oraz publicznie widoczny wynik DNS, a nie dane do logowania do rejestratora.

> Rodzaje rekordów DNS dla usług

Rekordy A/AAAA wskazują na adresy IP, CNAME tworzy alias, MX służy do konfiguracji poczty, a TXT jest używany do weryfikacji, SPF, DKIM lub DMARC.
faq/dns-record-types-for-services

Nie mieszaj rekordów DNS bez zastanowienia

Każdy typ rekordu DNS pełni inną funkcję. Rekordy A i AAAA wskazują na adresy IP, CNAME tworzy alias dla subdomeny, MX kieruje pocztę, TXT zawiera weryfikacje i polityki związane z pocztą elektroniczną, a CAA ogranicza uprawnienia do wystawiania certyfikatów.

Przy kopiowaniu rekordów

  1. Skopiuj nazwę, typ i wartość dokładnie zgodnie z instrukcjami usługi.
  2. Używaj rekordów A/AAAA dla adresów, CNAME dla dozwolonych aliasów poddomen, MX dla poczty oraz TXT dla SPF, DKIM, DMARC lub weryfikacji.
  3. Umieść DKIM pod selektorem dostawcy, a DMARC zwykle pod _dmarc.
  4. Ustawienia CAA należy wprowadzać ostrożnie, ponieważ nieprawidłowa wartość może uniemożliwić wystawienie certyfikatu.

Co zrobić, gdy DNS nie działa

Przekaż do działu wsparcia nazwę hosta, typ rekordu, oczekiwaną wartość i publicznie widoczny wynik. Nie przesyłaj loginu do panelu DNS ani zrzutów ekranu zawierających klucze API.

> Propagacja DNS i TTL - brak gwarancji czasu działania

TTL (Time To Live) określa, jak długo serwery DNS mogą przechowywać starą odpowiedź. Podczas procesu propagacji, stare i nowe wyniki mogą istnieć równocześnie w różnych serwerach DNS aż do wygaśnięcia pamięci podręcznej.
faq/dns-propagation-and-ttl

Propagacja to kwestia pamięci podręcznej, a nie magii

W systemie DNS nie ma gwarancji co do czasu propagacji. Po zmianie autorytatywnego serwera DNS różne resolvery mogą nadal zwracać stare i nowe odpowiedzi, dopóki ich pamięć podręczna nie zostanie zaktualizowana zgodnie z wartością TTL. Dlatego też wynik może się różnić w zależności od sieci, kraju lub używanego resolvera.

W przypadku planowanych zmian

  1. Jeśli dostawca na to pozwala, zmniejsz TTL przed planowaną zmianą.
  2. Po wprowadzeniu zmiany w DNS unikaj powtarzania losowych modyfikacji, dopóki pamięć podręczna nie zostanie zaktualizowana.
  3. Sprawdzaj wyniki z różnych serwerów DNS, jeśli występują rozbieżności.
  4. Zapisz czas zmiany, poprzednią wartość, nową wartość oraz TTL.

Co należy przesłać podczas diagnostyki

Podaj nazwę hosta, oczekiwany cel, widoczną starą odpowiedź, widoczną nową odpowiedź, TTL oraz czas zmiany. Nie udostępniaj danych logowania do konta DNS ani wewnętrznych notatek dostawcy.

> Planowanie przestrzeni dyskowej dla Workspace Suite

Przy planowaniu pojemności należy uwzględnić pliki użytkowników, udostępnione foldery, wersje plików, kosz, podglądy oraz narzut synchronizacji i przewidywany wzrost zespołu.
faq/nextcloud-storage-planning

Przestrzeń dyskowa Workspace Suite rośnie również poza widocznymi plikami

Pojemność jest wykorzystywana przez pliki użytkowników, udostępnione foldery, usunięte pliki, wersjonowanie, podglądy, miniaturki, klientów synchronizacji oraz importy. Jeśli przestrzeń dyskowa zbliża się do limitu, mogą występować problemy z przesyłaniem plików lub synchronizacją.

Przed zamówieniem zasobów

  1. Policz aktualne dane użytkowników i udostępnione foldery.
  2. Dodaj zapas miejsca na wersje, kosz, podglądy i narzut synchronizacji.
  3. Uwzględnij duże importy danych, nowe zespoły oraz przewidywany wzrost.
  4. Zwiększ pojemność przed osiągnięciem limitu przez użytkowników.

W przypadku problemów z synchronizacją

Podaj informacje o rozmiarze usługi, przybliżonym zużyciu, czasie wystąpienia problemu oraz widocznym błędzie klienta. Nie przesyłaj prywatnych plików, haseł ani eksportów danych użytkowników, chyba że dział wsparcia wyraźnie poprosi o nie w bezpieczny sposób.

> Migracja repozytoriów do Gitea

Planowanie migracji repozytoriów Git powinno uwzględniać LFS, submodule, uprawnienia, klucze wdrożeniowe, webhooki oraz CI/CD.
faq/gitea-repository-migration

Migracja to coś więcej niż tylko `git clone`

Oprócz historii repozytorium, należy przenieść lub ponownie skonfigurować właścicieli, zespoły, chronione gałęzie, chronione tagi, Git LFS, moduły podrzędne, klucze wdrożeniowe, webhooki oraz połączenia CI/CD.

Kontrola przed przejściem na nową wersję

  1. Wymień repozytoria, właścicieli, grupy dostępu i konta automatyzacji.
  2. Sprawdź obiekty Git LFS, moduły podrzędne, zabezpieczenia gałęzi oraz tagów.
  3. Po przeniesieniu przetestuj klonowanie, wypychanie zmian, Git LFS, moduły podrzędne i działanie CI.
  4. Po migracji usuń lub zresetuj stare tokeny, unikając udostępniania ich wartości.

Wrażliwe dane podczas migracji

Nie przesyłaj do działu wsparcia tokenów, kluczy prywatnych, poufnej części klucza wdrożeniowego ani tajnych danych CI. Podawaj nazwy repozytoriów, typ integracji, opis widocznego błędu oraz informację o tym, co działało poprawnie przed migracją.

> Domena nadawcza dla Listmonk

Aby przygotować się do kampanii, skonfiguruj domenę lub subdomenę nadawcy, identyfikator From, rekordy SPF, DKIM, DMARC, obsługę odbić oraz możliwość wypisania z listy.
faq/listmonk-sender-domain-basics

Dostarczalność zaczyna się od domeny

Listmonk wymaga jasnej tożsamości nadawcy (From) oraz rekordów DNS, które system pocztowy może zweryfikować. SPF, DKIM i DMARC muszą być skonfigurowane dla domeny lub subdomeny, z której chcesz wysyłać kampanie.

Przed pierwszą kampanią

  1. Wybierz domenę nadawcy lub subdomenę oraz nazwę "From".
  2. Dodaj rekordy DNS do weryfikacji, takie jak SPF, DKIM (wybierz selektor) i DMARC.
  3. Przetestuj dostarczanie wiadomości, obsługę błędów (bounce) oraz adres Return-Path i linki zawarte w wiadomości.
  4. Sprawdź opcję rezygnacji i List-Unsubscribe przed wysłaniem wiadomości do odbiorców.

Dane logowania do poczty elektronicznej nie powinny być umieszczane w zgłoszeniu

Podczas diagnozowania, przekaż domenę, typ rekordu, publicznie widoczną wartość DNS oraz komunikat o błędzie. Nie udostępniaj haseł SMTP, kluczy API, prywatnych kluczy DKIM ani eksportu adresatów zawierającego dane osobowe.

> Ustawienia środowiska uruchomieniowego dla Classic Hosting

Classic Hosting może działać w trybie automatycznym lub ręcznym. Parametry takie jak CPU, RAM, pamięć, przestrzeń dyskowa, okres przechowywania kopii zapasowych, archiwum zewnętrznego, przesyłanie danych, pamięć podręczna i logi wpływają na koszt oraz stabilność działania.
faq/classic-hosting-runtime-settings

Tryb automatyczny nie zawsze jest najlepszym rozwiązaniem

Auto Runtime pomaga w rozpoznawaniu typów projektów, ale tryb ręczny jest odpowiedni, gdy chcesz precyzyjnie wybrać Nginx, Apache, FrankenPHP lub konkretne środowisko uruchomieniowe języka. Wybieraj selektor PHP tylko wtedy, gdy wybrane środowisko uruchomieniowe go obsługuje.

Ustawienia przed wdrożeniem

  1. Wybierz automatyczny lub ręczny tryb działania w zależności od frameworka i sposobu budowania.
  2. Wybierz wersję PHP 8.2, 8.3 lub 8.4 tylko wtedy, gdy wybrane środowisko uruchomieniowe to obsługuje.
  3. Skonfiguruj zasoby takie jak CPU, RAM, przestrzeń dyskowa, retencję kopii zapasowych oraz archiwum zewnętrznego w zależności od ilości danych i ruchu.
  4. Po wdrożeniu przetestuj przesyłanie plików, pamięć podręczną, logi i widoczne błędy aplikacji.

Kiedy aplikacja się nie uruchamia

Podaj informacje o trybie działania, języku lub wersji PHP, widocznych błędach, wprowadzonych zmianach oraz przybliżonym czasie wdrożenia. Nie udostępniaj plików .env, haseł, tokenów ani pełnych logów zawierających poufne dane.

> Jakie informacje bezpiecznie przekazać do działu pomocy technicznej

Najbardziej przydatne są numery zamówień, nazwy usług, domeny, czasy, publiczne serwery i porty, ustawienia kopii zapasowych, przechowywanie w archiwum zewnętrznym, pliki przesyłane przez użytkownika, pamięć podręczna, logi, zrzuty ekranu oraz widoczne błędy (bez poufnych danych).
faq/support-safe-information-to-share

Dobry wniosek powinien zawierać istotne informacje, a nie poufne dane.

Dział wsparcia może szybciej reagować, jeśli otrzyma numer zamówienia, nazwę usługi, domenę, publiczny host lub port, czas wystąpienia problemu, informacje o wprowadzonych zmianach oraz dokładny komunikat błędu.

Bezpieczna treść wiadomości

  1. Podaj numer zamówienia, nazwę usługi, domenę, przybliżony czas oraz serwer lub port, jeśli to istotne.
  2. W przypadku problemów z hostingiem podaj informacje o środowisku uruchomieniowym, języku lub wersji PHP, procesorze, pamięci RAM, dysku, kopiach zapasowych, archiwizacji zewnętrznej, przesyłanych plikach, pamięci podręcznej oraz logach, pomijając wrażliwe dane.
  3. Przed dołączeniem zrzutów ekranu usuń lub zamaskuj hasła, tokeny, klucze prywatne, sesje i dane osobowe.
  4. Jeśli nie jesteś pewien, czy dana informacja jest odpowiednia do zgłoszenia, najpierw zapytaj bez jej wysyłania.

Czego nigdy nie wysyłaj

Nie przesyłaj haseł, kluczy prywatnych, fraz odzyskiwania, tokenów API, plików cookie sesji, eksportów baz danych, pełnych plików .env, pełnych logów zawierających poufne dane ani szczegółowych informacji o wewnętrznej infrastrukturze.