# Dokumentacja API (/pl/docs/api) API hostd pozwala zarządzać kontem programowo. Adres bazowy: `https://hostd.cloud`. ## Uwierzytelnianie [#uwierzytelnianie] Większość endpointów wymaga klucza API. Utwórz klucz w portalu w [Ustawienia → Klucze API](https://hostd.cloud/app/settings/api-keys) i przesyłaj go jako token Bearer: ```http Authorization: Bearer ``` ```bash curl -H "Authorization: Bearer " https://hostd.cloud/api/network/ips/ ``` Lista klastrów jest publiczna i nie wymaga uwierzytelnienia. ## Endpointy [#endpointy] * [Public cloud](/pl/docs/api/public-cloud/list-clusters) — klastry, projekty, zużycie, zadania i ceny godzinowe. * [IP addresses](/pl/docs/api/ip-addresses/list-ip-addresses) — przypisane adresy IP i ich rekordy reverse DNS (PTR). # Możliwości platformy (/pl/docs/cloud/capabilities) Chmura publiczna hostd to niezawodna, skalowalna i bezpieczna infrastruktura (IaaS) zbudowana w oparciu o wiodące technologie klasy enterprise. ## Stos technologiczny i sprzęt [#stos-technologiczny-i-sprzęt] Używamy wyłącznie sprawdzonego i niezawodnego sprzętu od światowych liderów, aby zapewnić maksymalną wydajność i stabilność Twoich systemów. **Proxmox VE** — stabilna gałąź enterprise oparta na KVM/QEMU Wyłącznie **Dell PowerEdge** z procesorami **AMD EPYC** Przełączniki i routery **Dell PowerSwitch** oraz **Juniper** **Proxmox Backup Server (PBS)** — izolowany datastore z deduplikacją dla każdego projektu Rozproszony all-flash NVMe (SDS) z **RoCEv2** i asynchronicznym `io_uring` ### Wydajność dysków [#wydajność-dysków] Dzięki all-flash NVMe oraz nowoczesnym protokołom, typowe opóźnienie (latency) dla operacji **4k randwrite** w trybie **t1q1** (1 wątek, `iodepth=1`) z użyciem **fsync** wynosi zaledwie około **0.11 ms** (mierzone bezpośrednio na poziomie hiperwizora). *Uwaga: Jest to wskaźnik infrastrukturalny, a nie gwarancja (SLA) dla Twojej aplikacji wewnątrz VM, ponieważ system operacyjny gościa i emulacja dodają własne narzuty.* Każdy dysk wirtualny VM ma limit **20 000 IOPS** odczytu i zapisu oraz **1000 MB/s** przepustowości odczytu i zapisu. Szczegóły: [Storage](/pl/docs/cloud/storage). ### Dostępne strefy [#dostępne-strefy] * **WAW-AMD1** — Warszawa, Polska. Infrastruktura znajduje się w certyfikowanych centrach danych **Atman WAW-2** oraz **Equinix WA2** (zgodność ze standardem Tier III+). Twoje dane i kopie zapasowe fizycznie pozostają w Polsce. ## Zasoby obliczeniowe (Compute) [#zasoby-obliczeniowe-compute] * **Nowoczesne systemy Linux:** Natychmiastowe wdrażanie czystych i stabilnych obrazów Ubuntu, Debian, Rocky Linux i AlmaLinux. * **Elastyczne tryby procesora (CPU modes):** * **Performance:** Dedykowane vCPU o maksymalnej wydajności do 100% czasu procesora dla systemów o dużym obciążeniu. * **Eco:** Zrównoważone zużycie do 50% czasu procesora dla standardowych aplikacji internetowych i usług. * **Slim:** Optymalny tryb do 25% czasu procesora do testowania, programowania i lekkich zadań w tle. * **Natychmiastowe skalowanie (Resize):** Zwiększanie vCPU, RAM i dysku systemowego w locie, bez przerywania pracy systemu. * **Gwarantowana wysoka dostępność (High Availability):** Bezpłatna, automatyczna ochrona przed awariami sprzętowymi. W przypadku awarii serwera fizycznego Twoja VM zostanie automatycznie zrestartowana na innym węźle w czasie krótszym niż minuta. * **Snapshoty:** Tworzenie natychmiastowych zrzutów stanu dysku w celu szybkiego i bezpiecznego przywrócenia systemu podczas aktualizacji lub testów. ## Sieć i bezpieczeństwo (Networking) [#sieć-i-bezpieczeństwo-networking] * **Publiczny WAN (IPv4 / IPv6):** Przypisz publiczny adres w trybie **IPv4**, **IPv6** lub **IPv4 + IPv6** (albo zostaw WAN wyłączony). Adresy są przypisywane bezpośrednio do interfejsu maszyny bez overlay NAT. Opłata godzinowa za public IP dotyczy **tylko IPv4**. * **Sieci prywatne (VLAN):** Tworzenie w pełni izolowanych lokalnych segmentów sieci Layer 2 dla bezpiecznej komunikacji między serwerami, z wbudowanym automatycznym zarządzaniem adresami (IPAM). * **Odwrotny DNS (PTR):** Wygodne zarządzanie rekordami PTR dla publicznych adresów IPv4 i IPv6 bezpośrednio w portalu. * **Firewall:** Konfiguracja reguł filtrowania ruchu na publicznych interfejsach WAN. * **Grupy bezpieczeństwa (Security Groups):** Szablony reguł zapory sieciowej do szybkiego i wielokrotnego stosowania na różnych maszynach wirtualnych. * **Mapa sieci:** Interaktywna wizualizacja całej Twojej infrastruktury, pokazująca połączenia między maszynami, sieciami prywatnymi i bramami. * **External VLAN:** Integracja chmury z Twoim fizycznym sprzętem (bare metal lub on-premises) za pomocą dedykowanego kanału Layer 2. ## Cloud Gateway [#cloud-gateway] Wyspecjalizowany, w pełni zarządzany router infrastrukturalny dla Twoich sieci prywatnych. * **Pełna automatyzacja:** Konfiguracja NAT, port forwarding, VPN i proxy bez konieczności ręcznego administrowania systemem operacyjnym routera. * **WireGuard VPN:** Szybki i bezpieczny dostęp dla administratorów i programistów do lokalnych zasobów chmury przez zaszyfrowany tunel. * **Reverse Proxy:** Wydajne proxy oparte na Caddy z automatycznym generowaniem certyfikatów Let's Encrypt przy pierwszym zapytaniu do domeny. ## Kopie zapasowe (Backup) [#kopie-zapasowe-backup] Zintegrowany, w pełni automatyczny system kopii zapasowych oparty na technologii klasy enterprise Proxmox Backup Server (PBS). * **Automatyczne harmonogramy (Backup jobs):** Elastyczne harmonogramy kopii zapasowych dla grup maszyn wirtualnych. * **Inkrementalność i deduplikacja:** Backupy kopiują tylko zmodyfikowane bloki dysku i podlegają deduplikacji na poziomie pamięci masowej, co zapewnia ogromną oszczędność miejsca na dysku (on-disk size) i zmniejsza koszty przechowywania. * **Przywracanie na poziomie plików (File restore):** Przeglądanie drzewa plików kopii zapasowej i pobieranie pojedynczych plików lub folderów bezpośrednio z backupu, bez pełnego przywracania systemu. * **Ochrona kopii (Protection):** Ochrona ważnych kopii zapasowych przed przypadkowym lub automatycznym usunięciem przez polityki retencji. ## Zarządzanie i rozliczenia (Account & Billing) [#zarządzanie-i-rozliczenia-account--billing] * **Dostęp zespołowy:** Dodawanie członków zespołu przez e-mail i przypisywanie ról (Superadmin, Admin, Auditor) w celu bezpiecznego wspólnego zarządzania zasobami. * **Rozliczenia godzinowe:** Naliczanie opłat wyłącznie za faktycznie przydzielone zasoby z dokładnością do godziny. * **Dwa modele płatności:** Płatność z góry (Prepaid z funkcją automatycznego doładowania) lub z dołu (Postpaid z fakturami na początku miesiąca). # Szybki start (/pl/docs/cloud/getting-started) Ten przewodnik pomoże Ci stworzyć pierwszy projekt, bezpiecznie skonfigurować reguły dostępu, uruchomić Twoją pierwszą maszynę wirtualną, zabezpieczyć ją zaporą sieciową (Firewall), włączyć tryb wysokiej dostępności (HA) i skonfigurować automatyczne kopie zapasowe. ## Harmonogram kroków [#harmonogram-kroków] 1. [Utworzenie projektu](#step-1-project) 2. [Uruchomienie maszyny wirtualnej (VM)](#step-2-vm) 3. [Konfiguracja grupy bezpieczeństwa (Security Group)](#step-3-security-group) 4. [Konfiguracja Firewalla na VM](#step-4-firewall) 5. [Włączenie trybu High Availability (HA)](#step-5-ha) 6. [Konfiguracja Backup Job](#step-6-backup-job) ## Przed rozpoczęciem [#przed-rozpoczęciem] * Zapoznaj się ze stroną [Zasoby i limity](/pl/docs/cloud/public-cloud-overview), aby zrozumieć, jak działa platforma i jakie limity obowiązują. * Przygotuj klucz SSH na swoim komputerze (będziesz potrzebować publicznej części klucza do wklejenia w formularzu). * Zainstaluj klienta SSH. W razie potrzeby możesz również skorzystać z konsoli webowej (`VM → Console`). * Jeśli posiadasz konto typu prepaid, upewnij się, że masz wystarczające środki na saldzie. ## Kroki [#kroki] ### 1. Utwórz projekt [#step-1-project] 1. Otwórz panel zarządzania: `Console → Public Cloud`. 2. Kliknij **Create project** (Utwórz projekt), wybierz dogodną dla siebie strefę, wprowadź **Project name** (Nazwę projektu) i potwierdź utworzenie. Tworzenie projektu — Public Cloud ### 2. Utwórz maszynę wirtualną (VM) [#step-2-vm] 1. Na stronie głównej (overview) nowego projektu kliknij **Create VM** (Utwórz VM). 2. Wybierz obraz systemu operacyjnego, podaj `hostname`, `username` oraz hasło. 3. Dodaj swój **publiczny klucz SSH** w odpowiednim polu. 4. Skonfiguruj potrzebne zasoby (vCPU, RAM, rozmiar dysku i `CPU mode`). 5. Włącz opcję **publicznego interfejsu WAN** (Public WAN), aby maszyna otrzymała dostęp do internetu. 6. Kliknij **Create** (Utwórz). Proces tworzenia maszyny i początkowej inicjalizacji przez `cloud-init` trwa do jednej minuty. Tworzenie VM — formularz z obrazem, kluczem SSH i WAN ### 3. Utwórz grupę bezpieczeństwa (Security Group) [#step-3-security-group] Aby wygodnie zarządzać tymi samymi regułami (na przykład dostępem przez SSH) dla wielu serwerów, warto korzystać z Security Groups. 1. Przejdź do sekcji `Datacenter → Security groups`. 2. Utwórz nową grupę bezpieczeństwa (Security Group). Użyj krótkiej nazwy łacińskiej (do **15** znaków). 3. Dodaj regułę **IN** zezwalającą na połączenia: wybierz protokół **TCP**, port **22** (SSH). W polu **Source** wskaż swoje adresy IP w formacie `x.x.x.x/32`. Security groups w Datacenter ### 4. Skonfiguruj Firewall na VM [#step-4-firewall] Teraz należy zabezpieczyć maszynę wirtualną przed niechcianym ruchem. W tym celu otwórz `VM → Firewall` (reguły dotyczą wyłącznie publicznego interfejsu WAN). 1. Przełącz suwak **Global Status** w pozycję **On**. 2. Zmień **Policy In** na **DROP** — zablokuje to cały ruch przychodzący, oprócz tego, który wyraźnie zezwolisz. 3. Kliknij **Apply**, aby zastosować politykę. 4. Dodaj zezwolenie na SSH: kliknij **Insert Security Group** i wybierz grupę utworzoną w kroku 3, lub kliknij **Add Rule** i stwórz standardową regułę tylko dla tej maszyny. 5. Teraz możesz bezpiecznie połączyć się z maszyną przez SSH. Firewall VM — Global Status, Policy In i reguły ### 5. Włącz High Availability (HA) [#step-5-ha] Tryb HA automatycznie uruchamia maszynę wirtualną na innym serwerze fizycznym, jeśli bieżący węzeł ulegnie awarii. Ta funkcja jest świadczona całkowicie **bezpłatnie** — płacisz jedynie standardową stawkę godzinową za vCPU i RAM swojej maszyny VM. 1. Przejdź do sekcji `Datacenter → High Availability`. 2. Włącz przełącznik **HA** dla wybranej maszyny wirtualnej. 3. W razie potrzeby utwórz **regułę rozmieszczenia (affinity rule)**, aby określić, czy wybrane maszyny VM powinny działać na tym samym serwerze fizycznym, czy muszą działać na różnych. 4. Bieżący status HA możesz zawsze sprawdzić w zakładce `Summary` w ustawieniach maszyny VM. High Availability w Datacenter ### 6. Utwórz Backup Job [#step-6-backup-job] Automatyczne harmonogramy (backup jobs) są głównym narzędziem do regularnego zapisywania stanu wybranych maszyn wirtualnych w Twoim projekcie według określonego grafiku. Domyślnie w projekcie można utworzyć tylko **1** harmonogram, ale można do niego dodać wiele maszyn wirtualnych. 1. Otwórz sekcję `Backup → Jobs`. 2. Kliknij przycisk **Create backup job**. 3. Skonfiguruj **Job name** (np. `Production VMs`) i upewnij się, że przełącznik **Enabled** jest aktywny. 4. Wybierz dni tygodnia, w których ma być wykonywany backup (wymagany jest co najmniej jeden dzień). Tworzenie kopii zapasowej rozpoczyna się w dozwolonym oknie czasowym **00:00–06:00**. 5. Skonfiguruj **Retention**: dla typowej maszyny VM wystarczy **Keep daily = 7**. 6. Na liście **Virtual machines** zaznacz swoją maszynę VM i kliknij przycisk **Save**. Create backup job — modal ## Uwaga [#uwaga] * Dopóki nie aktywujesz Firewalla (krok 4), Twoja VM z publicznym IP będzie całkowicie otwarta dla internetu na wszystkich portach. Skonfiguruj zaporę sieciową od razu, zanim umieścisz na maszynie ważne dane lub usługi. * Jeśli zatrzymasz VM, opłaty za CPU i RAM nie będą naliczane. Nadal jednak będziesz płacić za zarezerwowany dysk, przypisany Floating IP, backupy oraz Cloud Gateway. * HA chroni przed awariami sprzętowymi (ponowne uruchomienie zajmuje zazwyczaj do minuty), ale nie chroni przed awariami wewnątrz systemu operacyjnego. Do ochrony danych niezbędne są kopie zapasowe (krok 6). * Za kopie zapasowe płacisz tylko za rzeczywiste miejsce w pamięci masowej (on-disk) po kompresji i deduplikacji — patrz [Datastore](/pl/docs/cloud/backup/datastore). # Wprowadzenie (/pl/docs/cloud) Ta sekcja zawiera wszystkie niezbędne informacje do pracy z chmurą publiczną hostd — od tworzenia pierwszej maszyny wirtualnej po konfigurację sieci i kopii zapasowych. Szczegółowy przegląd stosu technologicznego, architektury i sprzętu. Krok po kroku do uruchomienia bezpiecznej VM. Organizacja zasobów na poziomie konta i projektów, tryby procesora oraz domyślne limity. Zarządzanie zespołem, monitorowanie kosztów i limity. Tworzenie, podłączanie, zmiana rozmiaru, reinstalacja, snapshoty, backupy i usuwanie. Publiczne adresy IP, rekordy PTR, sieci prywatne i zewnętrzne VLANy. Konfiguracja NAT, port forwarding, WireGuard i reverse proxy. Harmonogramy kopii zapasowych, zarządzanie datastore i przywracanie plików. Zadania, grupy bezpieczeństwa, High Availability (HA) i uprawnienia. Modele prepaid i postpaid, faktury oraz koszty zasobów. ## Uwaga [#uwaga] * Chmura publiczna to usługa typu IaaS (Infrastruktura jako Usługa). Zapewniamy działanie sprzętu fizycznego, wirtualizacji i sieci, podczas gdy zarządzanie systemem operacyjnym i aplikacjami leży po Twojej stronie. # Zasoby i limity (/pl/docs/cloud/public-cloud-overview) Na tej stronie znajdziesz szczegółowe informacje na temat organizacji konta i projektów, specyfiki trybów vCPU oraz domyślnych limitów systemowych. ## Organizacja zasobów [#organizacja-zasobów] Zarządzanie infrastrukturą w chmurze dzieli się na dwa poziomy logiczne: **konto** oraz **projekty**. | Poziom zarządzania | Co zawiera | | ------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Konto** | Ogólne ustawienia profilu, saldo finansowe oraz łączny limit vCPU (dzielony na wszystkie projekty). | | **Projekt** | Maszyny wirtualne, sieci prywatne (VLAN), zarezerwowane publiczne adresy IP, bramy Cloud Gateway, przestrzeń na backupy (PBS datastore), uprawnienia zespołu i godzinową szczegółowość wydatków. | Usługi chmury publicznej są rozliczane **godzinowo w złotówkach (PLN)**. Oferujemy dwie modele płatności: * **Prepaid** (przedpłata) — środki są pobierane co godzinę z Twojego salda. Dostępne jest automatyczne doładowanie salda z karty (auto-reload). * **Postpaid** (płatność z dołu) — płatność za faktycznie zużyte zasoby. Otrzymujesz jedną zbiorczą fakturę na początku każdego miesiąca za poprzedni okres (wymaga osobnego zatwierdzenia). Więcej szczegółów na temat modeli płatności znajdziesz w sekcji [Modele billing](/pl/docs/cloud/billing/models). ## Tryby CPU [#tryby-cpu] Podczas tworzenia maszyny wirtualnej lub zmiany jej rozmiaru wybierasz **tryb CPU** (CPU mode) oraz liczbę **vCPU**. Liczba vCPU określa, ile wirtualnych rdzeni "widzi" system operacyjny gościa. Z kolei tryb CPU definiuje **łączny maksymalny limit** czasu procesora, jaki VM może zużyć łącznie na fizycznym hoście. Jedno w pełni obciążone vCPU odpowiada **100%** czasu rdzenia fizycznego. | Tryb procesora | Łączny limit CPU dla VM | | --------------- | ------------------------------------------------------------------------------ | | **Performance** | Do **100%** na każde vCPU (np. 4 vCPU = do **400%** czasu procesora) | | **Eco** | Do **50%** na każde vCPU (np. 4 vCPU = do **200%** czasu procesora) | | **Slim** | Do **25%** na każde vCPU (np. 4 vCPU = do **100%** czasu procesora) | *Przykład pracy w trybie Eco z 4 vCPU (limit 200%):* Maszyna wirtualna może korzystać z dowolnej kombinacji obciążenia w granicach limitu — na przykład obciążyć wszystkie cztery wirtualne rdzenie po 50% każdy, lub dwa wirtualne rdzenie na pełne 100% (podczas gdy pozostałe dwa rdzenie są bezczynne). Całkowite zużycie fizycznego procesora nigdy nie przekroczy 200%. Wybrany tryb CPU określa również, ile zasobów VM zużywa z globalnego limitu Twojego konta. ## Limity (domyślne) [#limity-domyślne] Aby chronić nowe konta przed niekontrolowanymi wydatkami, obowiązują domyślne limity startowe. Jeśli Twoja firma potrzebuje więcej zasobów, wyślij zgłoszenie do naszego zespołu wsparcia. ### Limity konta [#limity-konta] | Zasób | Domyślny limit | | ----------------------------------------- | ------------------------------------- | | Projekty w obrębie jednej strefy | **5** | | Łączny budżet vCPU na koncie | **16** (ekwiwalent trybu Performance) | | Maksymalna liczba vCPU dla pojedynczej VM | **16** | Nie ma osobnego limitu na liczbę maszyn wirtualnych — obowiązuje budżet vCPU oraz wynikające z niego limity RAM i dysku. Budżet vCPU jest wspólny dla wszystkich projektów konta i jest obliczany z uwzględnieniem wag trybów: | CPU mode | Waga jednego vCPU | | ----------- | ----------------- | | Performance | **1** | | Eco | **0.5** | | Slim | **0.25** | *Przykład użycia budżetu 16 vCPU:* Możesz utworzyć 16 vCPU w trybie Performance, 32 vCPU w trybie Eco, 64 vCPU w trybie Slim lub dowolną inną kombinację mieszczącą się w limicie. Absolutna liczba rdzeni na pojedynczej VM jest przy tym ograniczona do 16. ### Limity projektu [#limity-projektu] | Zasób | Domyślny limit | | ---------------------------------------------- | -------------------------------------------------------- | | Sieci prywatne (VLAN) | **1** | | Automatyczne zadania backupu (Backup jobs) | **1** | | Łączna pamięć RAM dla wszystkich VM | Budżet vCPU konta × **6** GiB (domyślnie **96** GiB) | | Łączny dysk systemowy (NVMe) dla wszystkich VM | Budżet vCPU konta × **100** GiB (domyślnie **1600** GiB) | ### Limity wirtualnej maszyny (VM) [#limity-wirtualnej-maszyny-vm] | Zasób | Limity i kroki | | ---------------------------------------- | -------------------------------------------------------------- | | Liczba vCPU | Od **2** do limitu (zwiększana z krokiem o **2**) | | Pamięć operacyjna (RAM) | Od **vCPU × 1** do **vCPU × 6** GiB | | Dysk systemowy | Od **vCPU × 10** do **vCPU × 100** GiB (z krokiem ×10) | | Snapshoty użytkownika (Snapshots) | **1** naraz na VM | | Liczba interfejsów sieci prywatnej (LAN) | Do **8** interfejsów (każdy wymaga utworzonej sieci prywatnej) | | Klucze SSH przy tworzeniu | Do **5** kluczy | *Uwaga: zmniejszanie konfiguracji VM (vCPU, RAM lub przechodzenie na niższy CPU mode) jest dozwolone nie częściej niż raz dziennie dla każdej maszyny. Obniżenie vCPU oraz RAM wymaga obowiązkowego zatrzymania serwera. Więcej szczegółów znajdziesz w sekcji [Resize VM](/pl/docs/cloud/virtual-machines/resize).* ### Limity i reguły sieciowe [#limity-i-reguły-sieciowe] | Charakterystyka | Limit lub reguła | | ----------------- | ------------------------------------------------------------------------------------------------------- | | Publiczny IPv4 | Odwrotny DNS (rekord PTR) można łatwo zmienić bezpośrednio w portalu. | | IPv6 | Planowane do wdrożenia. | | Sieci prywatne | Domyślnie **1** na projekt (obsługiwane jest tylko adresowanie IPv4). | | External VLAN | Interfejs połączenia jest dostępny w UI, ale do konfiguracji wymagany jest kontakt ze wsparciem. | | Przepustowość WAN | 100 / 200 / 300 / 400 Mbps dla VM z odpowiednio 2–7 / 8–15 / 16–23 / 24+ vCPU. | | Przepustowość LAN | 2 / 3 / 4 / 5 Gbps dla tych samych poziomów vCPU (dokładne wartości podano w formularzu tworzenia VM). | | Firewall VM | Filtruje tylko publiczny interfejs WAN. W regułach dozwolone są podsieci (CIDR) maksymalnie do **/26**. | # Storage (/pl/docs/cloud/storage) W sekcji **Storage** możesz kontrolować użycie przestrzeni dyskowej przydzielonej dla dysków systemowych Twoich maszyn wirtualnych. Poniżej opisane są też limity wydajności każdego dysku wirtualnego. ## Specyfika korzystania z pamięci masowej [#specyfika-korzystania-z-pamięci-masowej] * Obecnie w portalu wyświetlana jest szczegółowa statystyka dotycząca rozmiarów dysków wirtualnych w trybie podglądu (read-only). * W dowolnym momencie możesz zwiększyć przestrzeń dyskową dla dysku systemowego dowolnej maszyny wirtualnej w zakładce [Resize VM](/pl/docs/cloud/virtual-machines/resize) (działa to bez wyłączania i restartowania maszyny). * Dyski systemowe VM działają na rozproszonym all-flash NVMe — szczegóły architektury w [Możliwości platformy](/pl/docs/cloud/capabilities). ## Limity wydajności dysku [#limity-wydajności-dysku] Każdy dysk wirtualny ma na poziomie hiperwizora stałe limity IOPS i przepustowości. Wartości są jednakowe dla wszystkich VM i nie da się ich zmienić w portalu. | Limit | Wartość | | --------------------- | ------------- | | IOPS odczytu | **20 000** | | IOPS zapisu | **20 000** | | Przepustowość odczytu | **1000 MB/s** | | Przepustowość zapisu | **1000 MB/s** | ## Uwaga [#uwaga] Możliwość tworzenia i podłączania dodatkowych dysków wirtualnych do jednej maszyny jest obecnie w fazie rozwoju. Jeśli potrzebujesz rozszerzyć przestrzeń do przechowywania danych już teraz, zwiększ rozmiar swojego głównego dysku systemowego za pomocą formularza zmiany zasobów. # Get an IP address (/pl/docs/api/ip-addresses/get-ip-address) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # List IP addresses (/pl/docs/api/ip-addresses/list-ip-addresses) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # Update PTR record (/pl/docs/api/ip-addresses/update-ptr-record) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # Get account usage (/pl/docs/api/public-cloud/get-account-usage) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # Get a cluster (/pl/docs/api/public-cloud/get-cluster) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # Get a project (/pl/docs/api/public-cloud/get-project) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # List clusters (/pl/docs/api/public-cloud/list-clusters) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # List project resource usage (/pl/docs/api/public-cloud/list-project-resource-usage) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # List project tasks (/pl/docs/api/public-cloud/list-project-tasks) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # List projects (/pl/docs/api/public-cloud/list-projects) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # Datastore (/pl/docs/cloud/backup/datastore) W sekcji **Datastore** możesz przeglądać istniejące kopie zapasowe, sprawdzać, ile miejsca zajmują, ustawiać ochronę dla krytycznych kopii lub ręcznie usuwać niepotrzebne wolumeny. Backup Datastore — statystyki i lista wolumenów ## Kroki [#kroki] 1. Otwórz sekcję `Backup → Datastore`. 2. Znajdź odpowiednią maszynę wirtualną na liście. 3. Rozwiń ją, aby zobaczyć konkretne kopie zapasowe (volumes). Możesz sprawdzić rozmiar logiczny (logical), rzeczywisty rozmiar na dysku (on-disk) oraz datę utworzenia. 4. Jeśli dana kopia jest krytycznie ważna, włącz dla niej opcję **protection** (ochronę). Zabezpieczy to ją przed automatycznym lub przypadkowym usunięciem. 5. Usuwaj kopie ręcznie tylko wtedy, gdy masz całkowitą pewność, że dane te nie będą już potrzebne. Z menu wiersza grupy VM możesz też **Delete all backups** (usunąć wszystkie kopie tej maszyny). 6. **File restore** na wybranej kopii pozwala przeglądać i pobierać pojedyncze pliki (bez pełnego restore VM). ## Uwaga [#uwaga] Aby usunąć chroniony (protected) backup, należy najpierw zdjąć z niego ochronę. Pamiętaj, że jeśli usuniesz maszynę wirtualną, ale pozostawisz jej kopie zapasowe, przestrzeń dyskowa używana do ich przechowywania będzie nadal taryfikowana. Pełny restore VM jest w `VM → Backups`; ta strona służy do zarządzania kopiami i file restore. # File restore (/pl/docs/cloud/backup/file-restore) Jeśli przypadkowo usunąłeś kilka plików i nie chcesz cofać stanu całego systemu, możesz pobrać pojedyncze pliki lub foldery bezpośrednio z kopii zapasowej. File restore — drzewo plików ## Kroki [#kroki] 1. Otwórz sekcję `Backup → Datastore`. 2. Znajdź interesujący Cię backup i kliknij przycisk **File restore**. 3. Otworzy się drzewo plików Twojego systemu — możesz rozwijać foldery i wyszukiwać potrzebne dane. 4. Po znalezieniu pliku lub folderu kliknij odpowiedni przycisk, aby go pobrać (foldery zostaną pobrane jako archiwum zip). ## Uwaga [#uwaga] To narzędzie jest przeznaczone głównie do pobierania plików konfiguracyjnych lub mniejszych katalogów (orientacyjnie do około **200 MB**). Jeśli potrzebujesz odzyskać ogromną bazę danych lub pełny obraz maszyny, zalecamy skorzystanie z pełnego przywracania maszyny VM lub skontaktowanie się z [supportem](https://hostd.cloud/contact). # Backup (/pl/docs/cloud/backup) Tutaj zebrano wszystkie instrukcje dotyczące tworzenia kopii zapasowych Twoich maszyn wirtualnych: od konfiguracji regularnych harmonogramów po przywracanie pojedynczych plików. Konfiguracja harmonogramów (dni tygodnia, okno czasowe) oraz polityki retencji (retention policy). Przeglądanie istniejących kopii zapasowych, ochrona przed przypadkowym usunięciem oraz statystyki. Pobieranie pojedynczych plików lub folderów bez konieczności pełnego przywracania całej maszyny wirtualnej. Pełne przywracanie maszyny wirtualnej z zapisanej kopii. ## Uwaga [#uwaga] Infrastruktura platformy zapewnia bezpieczne i niezawodne przechowywanie kopii zapasowych, ale konfiguracja harmonogramów oraz regularne testowanie przywracania danych leżą po Twojej stronie. Zalecamy okresowe sprawdzanie, czy dane przywracają się prawidłowo. # Backup jobs (/pl/docs/cloud/backup/jobs) Automatyczne harmonogramy (backup jobs) są głównym narzędziem do regularnego i nieprzerwanego zapisywania stanu wybranych maszyn wirtualnych w Twoim projekcie według określonego grafiku. Create backup job — modal ## Kroki [#kroki] 1. Otwórz sekcję `Backup → Jobs`. 2. Kliknij przycisk **Create backup job** (lub edytuj już istniejący). 3. Skonfiguruj ustawienia harmonogramu oraz polityki retencji (szczegóły poniżej). 4. Wybierz odpowiednie maszyny wirtualne w tabeli **Virtual machines** i kliknij **Create**. 5. Na liście maszyn mogą wyświetlać się ostrzeżenia dla those VM, które nie są jeszcze chronione żadnym backupem — zalecamy dodanie ich do harmonogramu. ## Konfiguracja w oknie Create backup job [#konfiguracja-w-oknie-create-backup-job] **General** * **Enabled** — pozwala tymczasowo wyłączyć wykonywanie harmonogramu bez usuwania samych ustawień. * **Job name** — przyjazna dla Ciebie nazwa (na przykład `Production VMs`). * **Backup time window** — przedział czasu, w którym system ma prawo rozpocząć tworzenie kopii zapasowej (obecnie jest to **00:00–06:00**). **Schedule** * Wybierz dni tygodnia, w które ma być wykonywany backup (wymagany jest przynajmniej jeden dzień). **Retention** Ten blok zarządza liczbą kopii przechowywanych w datastore. Po przekroczeniu limitu najstarsze kopie są usuwane automatycznie. Pozostawienie pola pustego lub wpisanie **0** wyłącza dany poziom przechowywania. * **Keep daily** — ile ostatnich codziennych kopii zachować (na przykład **7** oznacza historię z ostatniego tygodnia). * **Keep weekly** — ile tygodniowych zrzutów zachować (na przykład **4** oznacza historię z około miesiąca). * **Keep monthly** / **Keep yearly** — długoterminowe przechowywanie. Używaj tylko wtedy, gdy jest to naprawdę konieczne, ponieważ zwiększa to koszty przestrzeni dyskowej. **Jak najlepiej skonfigurować:** Dla typowej maszyny wystarczą standardowe ustawienia: **7** daily i **4** weekly. Dla środowisk testowych wystarczy **3** daily i **0** weekly. Maksymalne limity w formularzu to: daily do 90, weekly do 26, monthly do 12, yearly do 2. ## Koszt backup storage [#koszt-backup-storage] Kopie zapasowe są tworzone **przyrostowo** i podlegają **deduplikacji**. Z tego powodu w sekcji `Backup → Datastore` zobaczysz dwie wartości: * **Logical** — całkowity rozmiar logiczny wszystkich kopii. * **On-disk** — rzeczywisty rozmiar na dysku po skompresowaniu i deduplikacji. Płacisz **wyłącznie za rzeczywisty (on-disk) rozmiar** w gigabajtach (GiB). **Przykład ilustracyjny:** Posiadasz maszynę wirtualną z dyskiem o rozmiarze **100 GiB**, na którym faktycznie zajęte jest tylko **50 GiB**, a codzienne zmiany na dysku wynoszą około **5 GiB** danych. Jeśli skonfigurujesz codzienny backup z parametrem **Keep daily = 7**, wówczas pierwszy pełny backup zajmie tylko faktycznie używane miejsce — około **50 GiB** (a nie pełny rozmiar dysku 100 GiB). Każdy kolejny dzień będzie dodawał tylko około \~5 GiB zmienionych danych. Oznacza to, że po tygodniu będziesz posiadać 7 kopii zapasowych, ale na dysku zajmą one około **80 GiB** (50 + 6×5), a nie 700 GiB. Jeśli zwiększysz retencję do 30 dni, rozmiar ten wzrośnie do około **195 GiB** (50 + 29×5). Zawsze sprawdzaj wskaźnik **on-disk** przed znaczącym zwiększeniem parametrów retencji. ## Uwaga [#uwaga] Domyślnie w projekcie można utworzyć tylko **1** harmonogram (backup job), ale można do niego dodać wiele maszyn wirtualnych. Pamiętaj również, że posiadanie kopii zapasowej nie zwalnia z obowiązku testowania, czy jesteś w stanie pomyślnie przywrócić z niej dane. # Billing (/pl/docs/cloud/billing) Infrastruktura chmury publicznej jest taryfikowana **godzinowo w złotych polskich (PLN)**. Płacisz za przydzielone zasoby: vCPU, pamięć operacyjną, przestrzeń dyskową, publiczne adresy IPv4, bramy Cloud Gateway oraz miejsce na kopie zapasowe (backupy). Zarządzać swoim saldem możesz w panelu [`Billing`](https://hostd.cloud/app/settings/billing), a faktury przeglądać i opłacać w [`Invoices`](https://hostd.cloud/app/settings/invoices). Jak działają modele Prepaid i Postpaid oraz czym się różnią. Kiedy wystawiamy faktury i co dokładnie wchodzi w ich skład. Za jakie zasoby nadal płacisz, nawet jeśli wyłączyłeś serwer. # Faktury (/pl/docs/cloud/billing/invoices) Wszystkie swoje faktury możesz przeglądać lub pobierać w formacie PDF w panelu [`Invoices`](https://hostd.cloud/app/settings/invoices). Tam również możesz opłacić je online. Harmonogram wystawiania faktur zależy od Twojego modelu płatności. ## Prepaid (przedpłata) [#prepaid-przedpłata] W tym modelu doładowujesz saldo z góry, a koszt usług jest z niego potrącany co godzinę. Faktura VAT jest generowana **w momencie każdego doładowania salda** (na fakturze widnieje to jako *Doładowanie salda rozliczeniowego*). Bieżące dzienne zużycie zasobów nie generuje nowych faktur. ## Postpaid (płatność z dołu) [#postpaid-płatność-z-dołu] W tym modelu płacisz za faktyczne zużycie za ubiegły okres. Jedna zbiorcza faktura VAT jest wystawiana **na początku każdego miesiąca**. * Każdy Twój projekt jest wyświetlany na fakturze jako osobna pozycja: `Public Cloud {uuid} | {project name}` wraz ze zbiorczym podsumowaniem zużycia zasobów (godziny vCPU, RAM, dysk itp.). * Jeśli kwota do zapłaty wynosi mniej niż **1 PLN netto**, faktura nie jest generowana. * Jeśli posiadasz kredyt kompensacyjny lub rabat, są one widoczne jako osobna pozycja **Rabat** wraz z podaniem przyczyny. ### Jak opłacić fakturę [#jak-opłacić-fakturę] Faktury możesz opłacić przelewem bankowym (dane do przelewu znajdują się w samym pliku PDF) lub online bezpośrednio w portalu za pomocą karty, Apple Pay lub Google Pay. Dla własnej wygody możesz włączyć funkcję **auto-pay**, aby system automatycznie pobierał środki z zapisanej karty w dniu wystawienia faktury. # Modele rozliczeń (/pl/docs/cloud/billing/models) Platforma nalicza opłaty **godzinowo** za wszystkie zasoby przydzielone do Twojego projektu (nawet jeśli nie są obciążone w 100%). Twoje konto może działać w jednym z dwóch modeli płatności, a dany model ma zastosowanie do wszystkich Twoich projektów jednocześnie. | | **Prepaid** (domyślny) | **Postpaid** | | ------------- | --------------------------------------- | ----------------------------------------- | | Płatność | Z góry — z salda konta | Z dołu — miesięczna faktura | | Rozliczanie | Godzinowe potrącanie środków z salda | Godzinowe rejestrowanie użycia zasobów | | Faktura | Natychmiast po każdym doładowaniu salda | Na początku miesiąca za poprzedni miesiąc | | Automatyzacja | Auto-reload (automatyczne doładowanie) | Auto-pay (automatyczne opłacanie faktur) | ## Prepaid (przedpłata) [#prepaid-przedpłata] Ten model jest włączany automatycznie po rejestracji konta. Doładowujesz saldo w panelu Billing, a koszt użytych zasobów jest co godzinę potrącany z tej kwoty. * **Doładowanie** — minimalna kwota wynosi **50 PLN netto** (maksymalna — 2000 PLN). Opłaty można dokonać kartą, Apple Pay lub Google Pay. Podatek VAT jest doliczany w momencie płatności. * **Auto-reload** — bardzo wygodna funkcja, która pozwala na automatyczne doładowanie salda z zapisanej karty płatniczej, gdy spadnie ono poniżej określonego progu. * Jeśli na Twoim koncie znajdują się środki bonusowe lub promocyjne, system zawsze będzie w pierwszej kolejności pobierał opłaty z tych środków, a dopiero potem z Twoich realnych pieniędzy. ## Postpaid (płatność z dołu) [#postpaid-płatność-z-dołu] Ten model pozwala na korzystanie z usług bez przedpłaty i otrzymywanie faktury po zakończeniu okresu rozliczeniowego. Aby na niego przejść, należy złożyć wniosek do wsparcia technicznego za pomocą przycisku **Request contract billing** w panelu Billing. * Na początku każdego miesiąca otrzymujesz jedną fakturę za wszystkie zasoby zużyte w poprzednim miesiącu. * Jeśli dla Twojego konta uzgodniono **indywidualny rabat**, jest on automatycznie uwzględniany w naliczeniach godzinowych. * **Auto-pay** — pozwala na automatyczne opłacanie wystawionych faktur z zapisanej karty płatniczej. * W tym modelu bieżące zadłużenie jest widoczne w czasie rzeczywistym, natomiast funkcja bezpośredniego doładowania salda zostaje wyłączona, jako że po prostu opłacasz wystawiane faktury. ### Kredyt kompensacyjny [#kredyt-kompensacyjny] W przypadku awarii lub w ramach gestu lojalności hostd może przyznać Ci jednorazowy kredyt kompensacyjny. Obniży on automatycznie kwotę Twoich przyszłych faktur (wyświetla się jako pozycja **Rabat**). Taki kredyt może pokryć do **75%** kwoty pojedynczej faktury, a niewykorzystany fragment przechodzi na kolejne miesiące. # Koszty zatrzymanej VM (/pl/docs/cloud/billing/stopped-vm-costs) Zatrzymanie (Stop) maszyny wirtualnej kończy naliczanie opłat za zasoby obliczeniowe (**vCPU** oraz **RAM**). Wszystkie inne zarezerwowane zasoby są jednak nadal taryfikowane godzinowo, ponieważ platforma w dalszym ciągu rezerwuje je dla Ciebie. | Zasób | Taryfikowany dla zatrzymanej VM? | | ---------------------------- | -------------------------------- | | vCPU i RAM | Nie | | Dysk systemowy (storage) | Tak | | Floating IP (publiczny IPv4) | Tak | | PBS backup storage | Tak | Z tego powodu zatrzymanie maszyny wirtualnej **nie oznacza zerowego kosztu**. Jeśli chcesz całkowicie zatrzymać naliczanie opłat, na przykład za dysk lub publiczny IP, musisz bezpowrotnie usunąć maszynę wirtualną (wraz z dyskiem) lub zwolnić adres IP ze swojego projektu. Godzinowe zestawienie kosztów możesz zawsze sprawdzić w sekcji `Datacenter → Resource usage` (dostępne wyłącznie dla właściciela konta). # Cloud Gateway (/pl/docs/cloud/cloud-gateway) Cloud Gateway to zarządzany router, który hostd automatycznie wdraża dla Twojej sieci prywatnej. Pozwala on na konfigurację NAT, port forwardingu, VPN WireGuard oraz reverse proxy. ## Co to jest? [#co-to-jest] Jest to całkowicie odizolowana maszyna wirtualna pełniąca funkcję routera. Jej główną różnicą w stosunku do zwykłych maszyn VM jest to, że **nie masz do niej dostępu przez SSH ani konsolę**. Wszystkie ustawienia konfiguruje się wyłącznie za pomocą interfejsu portalu hostd, a infrastruktura stosuje je automatycznie pod maską. W celu zapewnienia niezawodności Cloud Gateway działa z włączoną funkcją **High Availability (HA)** od razu po utworzeniu. Jeśli serwer fizyczny, na którym działa router, ulegnie awarii, system automatycznie uruchomi go ponownie na innym węźle (zwykle trwa to do minuty). Nie musisz konfigurować HA dla niego samodzielnie. ## Kiedy tego potrzebujesz [#kiedy-tego-potrzebujesz] Cloud Gateway przyda się, gdy maszyny w prywatnej sieci **nie mają własnych publicznych IP**, a Ty potrzebujesz: * wyjścia do internetu (NAT) z adresem WAN bramy; * dostępu z internetu do konkretnych usług na VM (port forwarding); * bezpiecznego dostępu administratorów do sieci prywatnej (WireGuard); * publikacji HTTP/HTTPS z certyfikatem Let's Encrypt (reverse proxy). Jeśli wystarczy Ci izolowana sieć VLAN bez routingu do internetu — Cloud Gateway możesz wyłączyć lub usunąć w dowolnym momencie. ## Jak włączyć Cloud Gateway [#jak-włączyć-cloud-gateway] Możesz go aktywować podczas tworzenia nowej sieci prywatnej (`Network → Private networks → New` → **Enable Cloud Gateway**) lub dodać go później do już istniejącej sieci VLAN (za pomocą przycisku **Enable Cloud Gateway** w menu sieci). Dla sieci typu Internal VLAN brama jest domyślnie włączona przy tworzeniu. Router automatycznie zajmie adres IP **`.1`** w Twojej podsieci i będzie działał jako brama domyślna (default gateway) dla wszystkich podłączonych do niej maszyn VM. Dlatego upewnij się, że ten adres jest wolny. Publiczny adres IPv4 bramy możesz nadać automatycznie (pierwszy wolny z puli) albo wybrać spośród adresów już zarezerwowanych w projekcie. Publiczny IP rozliczany jest osobno od samej usługi Cloud Gateway. Tworzenie sieci prywatnej z Cloud Gateway ## Usługi [#usługi] Po uruchomieniu bramy konfigurujesz w portalu: Przekierowanie portów z publicznego adresu IP routera na wewnętrzne adresy IP maszyn VM. Bezpieczny dostęp VPN do sieci prywatnej dla Twoich administratorów lub programistów. Konfiguracja serwera proxy HTTP/HTTPS z automatycznym uzyskiwaniem certyfikatów Let's Encrypt. ## Uwaga [#uwaga] Możesz całkowicie usunąć Cloud Gateway w dowolnym momencie, aby zatrzymać jego taryfikację. Sama sieć prywatna (VLAN) nie zostanie przy tym usunięta, a Twoje maszyny VM będą nadal widzieć się nawzajem w sieci lokalnej. # Port forwarding (/pl/docs/cloud/cloud-gateway/port-forwarding) Port forwarding (DNAT) pozwala na odbieranie ruchu na publicznym adresie IP bramy Cloud Gateway i automatyczne przekierowywanie go do konkretnej maszyny wirtualnej w sieci prywatnej. Port forwarding — reguła DNAT ## Kroki [#kroki] 1. Otwórz swoją sieć prywatną i przejdź do sekcji **Port forwards**. 2. Kliknij przycisk **Add** i podaj parametry: protokół, port publiczny na routerze, a także wewnętrzny adres IP i port (backend) docelowej maszyny VM. 3. Kliknij **Save**, aby zapisać regułę. 4. Przetestuj połączenie z zewnątrz. ## Uwaga [#uwaga] Jeśli planujesz korzystać z usługi [Reverse proxy](/pl/docs/cloud/cloud-gateway/reverse-proxy), pamiętaj, że porty TCP **80** i **443** zostaną dla niej zarezerwowane i nie będą mogły być użyte do standardowego port forwardingu. W takim przypadku użyj innych portów publicznych lub skonfiguruj serwer proxy dla ruchu. # Reverse proxy (/pl/docs/cloud/cloud-gateway/reverse-proxy) Możesz używać Cloud Gateway jako reverse proxy (opartego na Caddy), który będzie przyjmował ruch HTTP i HTTPS i kierował go do Twoich serwerów backendowych. Automatycznie uzyskuje on i odnawia darmowe certyfikaty SSL od Let's Encrypt dla Twoich domen. Reverse proxy — vhost i backend ## Kroki [#kroki] 1. W panelu swojego dostawcy DNS utwórz **rekord A** (A record), który skieruje Twoją domenę na publiczny adres IP bramy Cloud Gateway. 2. W portalu hostd otwórz zakładkę **Reverse proxy** w ustawieniach sieci prywatnej i **włącz** tę usługę. 3. Dodaj swoją domenę (hostname) oraz podaj prywatny adres IP i port docelowej maszyny VM (backend). 4. Kliknij **Save**, aby zapisać konfigurację. 5. Spróbuj otworzyć swoją domenę w przeglądarce za pomocą protokołu HTTPS. Jeśli rekord A został poprawnie skonfigurowany, system automatycznie wygeneruje certyfikat SSL podczas pierwszej wizyty na stronie. ## Uwaga [#uwaga] Zarządzanie bezpośrednimi rekordami DNS (rekordami A) Twojej domeny odbywa się po stronie Twojego dostawcy usług DNS. Pamiętaj: włączenie usługi Reverse proxy całkowicie rezerwuje porty TCP **80** i **443**, a także port UDP **443** na bramie Cloud Gateway, co wyklucza ich użycie do standardowego port forwardingu. # WireGuard (/pl/docs/cloud/cloud-gateway/wireguard) WireGuard pozwala na stworzenie bezpiecznego kanału VPN pomiędzy Twoim komputerem a siecią prywatną w chmurze. Jest to idealne rozwiązanie do dostępu administracyjnego do baz danych lub wewnętrznych usług bez konieczności udostępniania ich w internecie. WireGuard — widok strony ## Kroki [#kroki] 1. In ustawieniach swojej sieci prywatnej przejdź do zakładki **WireGuard**. 2. Jeśli serwer nie został jeszcze skonfigurowany, kliknij przycisk **Set up WireGuard server** (lub **Enable**, jeśli był wyłączony). 3. Kliknij **Add peer** i wprowadź jasną nazwę dla swojego urządzenia (na przykład "Laptop admina"). 4. Na liście urządzeń (peers) otwórz menu **Peer config**. Możesz zeskanować kod QR za pomocą aplikacji mobilnej WireGuard lub kliknąć **Download**, aby pobrać plik konfiguracyjny (`.conf`) dla klienta stacjonarnego. 5. Zaimportuj plik do klienta WireGuard, połącz się i przetestuj dostęp (na przykład pingując prywatny adres IP dowolnej maszyny wirtualnej). Peer config — QR i pobranie konfiguracji ## Uwaga [#uwaga] Pobrana konfiguracja jest ustawiona tak, że przez VPN kierowany jest **wyłącznie ruch do Twojej sieci prywatnej** (split tunneling). Cały Twój normalny ruch internetowy (przeglądanie stron, YouTube) będzie przesyłany tak jak dotychczas, nie obciążając bramy Cloud Gateway. # High Availability (HA) (/pl/docs/cloud/datacenter/high-availability) Tryb High Availability (HA) automatycznie chroni Twoje maszyny wirtualne przed awariami sprzętowymi. Jeśli serwer fizyczny, na którym działa maszyna, ulegnie awarii, platforma samodzielnie uruchomi ją ponownie na innym działającym serwerze. ## Kroki [#kroki] 1. Przejdź do sekcji `Datacenter → High Availability`. 2. Włącz przełącznik **HA** dla wybranej maszyny wirtualnej. 3. W razie potrzeby utwórz **regułę affinity** (regułę wzajemnego rozmieszczenia), aby określić, czy konkretne maszyny VM powinny działać na tym samym serwerze fizycznym, czy obowiązkowo na różnych. 4. Bieżący status HA możesz zawsze sprawdzić w zakładce Summary w ustawieniach konkretnej maszyny VM. ## Uwaga [#uwaga] * Restart maszyny wirtualnej na innym serwerze w przypadku awarii trwa zazwyczaj **do jednej minuty**. Pamiętaj, że jest to restart sprzętowy (analogicznie do włączenia po nagłej utracie zasilania), dlatego nie chroni przed wewnętrznymi błędami samego systemu operacyjnego. * Funkcja High Availability jest świadczona całkowicie **bezpłatnie** — płacisz jedynie standardowy koszt godzinowy vCPU oraz RAM swojej maszyny. * Każda reguła affinity może łączyć od **2 do 3 maszyn VM**. Jedna maszyna wirtualna może należeć tylko do jednej reguły rozmieszczenia. # Datacenter (/pl/docs/cloud/datacenter) Sekcja **Datacenter** łączy w sobie narzędzia do kontroli i konfiguracji Twojej chmury na poziomie całego projektu. Przegląd historii operacji, statusów wykonania oraz błędów. Tworzenie i konfiguracja szablonów reguł zapory sieciowej (firewalla). Aktywacja wysokiej dostępności dla maszyn wirtualnych oraz konfiguracja reguł wzajemnego rozmieszczenia (affinity rules). Zarządzanie członkami projektu i ich rolami (poprzez zakładkę `Datacenter → Permissions`). Szczegółowy raport godzinowy o zużyciu zasobów i kosztach finansowych za bieżący miesiąc. ## Uwaga [#uwaga] Większość konfiguracji w sekcji Datacenter wymaga uprawnień **Admin** lub **Superadmin**. Szczegółowe statystyki finansowe oraz sekcja rozliczeń są dostępne wyłącznie dla właściciela konta (**Superadmin**). # IP sets (/pl/docs/cloud/datacenter/ip-sets) IP sets to nazwane listy adresów IPv4/IPv6 i sieci CIDR. Tworzysz listę raz, a potem odwołujesz się do niej w regułach firewalla jako **source** lub **destination**, zamiast powtarzać te same adresy w każdej regule. ## Kroki [#kroki] 1. Otwórz `Datacenter → IP sets`. 2. Kliknij **Add** i podaj krótką nazwę łacińską (do **15** znaków). 3. Wybierz IP set i kliknij **Add address**, aby dodać hosty lub CIDR (IPv4 do **/24**, IPv6 do **/64**). 4. Otwórz `VM → Firewall` (albo reguły security group) i utwórz albo edytuj regułę. 5. W polu **Source Address** lub **Destination Address** wybierz IP set z **Use IP set…** albo wpisz ręcznie `+name`. 6. Późniejsze zmiany członków IP set obowiązują wszędzie, gdzie ten set jest użyty. ## Uwaga [#uwaga] * IP set wpływa na ruch dopiero wtedy, gdy reguła firewalla go używa, a firewall VM jest włączony (**Global Status** = **On** w `VM → Firewall`). * Bezpośredni CIDR w regule jest nadal ograniczony do **/26**; członkowie IP set mogą być IPv4 do **/24** lub IPv6 do **/64**. * Usunięcie IP set czyści odwołania do niego w regułach, które go używały. # Resource usage (/pl/docs/cloud/datacenter/resource-usage) Zakładka **Resource usage** pozwala właścicielowi projektu (Superadmin) na szczegółowe śledzenie godzinowych kosztów w złotych polskich (PLN) dla każdego typu wykorzystywanych zasobów. Resource usage — koszty godzinowe ## Kroki [#kroki] 1. Otwórz sekcję `Datacenter → Resource usage` (sekcja ta jest widoczna wyłącznie dla właściciela projektu). 2. Zapoznaj się z godzinowym zestawieniem kosztów według głównych kategorii: procesory (compute), pamięć operacyjna (RAM), dyski (storage), **publiczne IPv4**, backupy oraz Cloud Gateway. 3. Porównaj te dane z aktywnymi usługami w Twoim projekcie, aby zrozumieć strukturę kosztów. 4. W celu dokonania płatności i przejrzenia dokumentów księgowych przejdź do sekcji `Billing`. ## Uwaga [#uwaga] * Kolumna **Public IPv4** liczy i wycenia **tylko adresy IPv4**. Publiczne IPv6 nie jest rozliczane jako osobna pozycja IP. * Dane na tej stronie służą wyłącznie do wewnętrznego monitorowania i planowania budżetu. Są one aktualizowane co godzinę, ale nie stanowią dokumentu finansowego ani księgowego (oficjalne rachunki i faktury są generowane wyłącznie w sekcji `Billing`). # Security groups (/pl/docs/cloud/datacenter/security-groups) Grupy bezpieczeństwa (Security Groups) to szablony reguł filtrowania ruchu. Pozwalają one na jednorazowe skonfigurowanie reguł dostępu (na przykład otwarcie portów dla serwera WWW lub ograniczenie dostępu do bazy danych) i szybkie zastosowanie ich do wielu maszyn wirtualnych. ## Kroki [#kroki] 1. Otwórz sekcję `Datacenter → Security groups`. 2. Kliknij **Create group** i wprowadź krótką nazwę łacińską grupy (do **15** znaków). 3. Dodaj potrzebne reguły dla ruchu przychodzącego (**IN**) lub wychodzącego (**OUT**) wewnątrz utworzonej grupy. 4. Przejdź do ustawień odpowiedniej maszyny wirtualnej do zakładki `VM → Firewall` i kliknij przycisk **Insert Security Group**, aby podłączyć utworzony szablon reguł. 5. W przyszłości wszelkie zmiany wprowadzone przez Ciebie w grupie bezpieczeństwa w sekcji Datacenter zostaną automatycznie zastosowane do wszystkich podłączonych maszyn wirtualnych. ## Uwaga [#uwaga] Grupa bezpieczeństwa zacznie filtrować ruch maszyny wirtualnej dopiero wtedy, gdy podłączysz ją do tej maszyny VM i upewnisz się, że zapora sieciowa jest włączona (przełącznik **Global Status** jest ustawiony w pozycji **On** w ustawieniach `VM → Firewall`). # Zadania (/pl/docs/cloud/datacenter/tasks) Dziennik zadań (Tasks) wyświetla historię wszystkich operacji infrastrukturalnych w Twoim projekcie (takich jak tworzenie maszyn wirtualnych, zmiana ich rozmiaru, włączanie i wyłączanie itp.). Pomaga to zobaczyć, który z członków zespołu uruchomił dane działanie i w jakim statusie się ono znajduje. Tasks — historia zadań projektu Aby przejrzeć dziennik, otwórz sekcję `Datacenter → Tasks`. Każdy uczestnik projektu, niezależnie od swojej roli, może zobaczyć szczegółową tabelę: * **Start Time / End Time** — dokładny czas rozpoczęcia i zakończenia zadania. * **Opis operacji** — jakie konkretnie działanie było wykonywane. * **Status** — bieżący status wykonania (`OK`, `running` lub błąd, jeśli coś poszło nie tak). * **Użytkownik** — adres e-mail członka zespołu, który uruchomił zadanie. ## Uwaga [#uwaga] * Ten dziennik rejestruje wyłącznie operacje związane z zarządzaniem chmurą na poziomie portalu hostd. Nie wyświetla on zdarzeń systemowych ani logów wewnątrz samego systemu operacyjnego maszyny wirtualnej. * Zadania automatycznych kopii zapasowych według harmonogramu, a także operacje automatycznego restartu w przypadku awarii (HA) są częścią wewnętrznej logiki systemowej platformy i nie są wyświetlane w tej tabeli działań użytkowników. # External VLAN (/pl/docs/cloud/networking/external-vlan) **External VLAN** to usługa, która pozwala stworzyć wspólne środowisko sieciowe Layer 2 w Twojej strefie (klastrze). Dzięki temu możesz połączyć maszyny wirtualne w chmurze z dowolną zewnętrzną infrastrukturą znajdującą się poza naszą platformą. Umożliwia to podłączenie: * Fizycznych serwerów dedykowanych (bare metal); * Własnych routerów lub przełączników; * Infrastruktury lokalnej (on-premises) za pośrednictwem kanałów transmisji danych Twojego operatora lub dostawcy. W przeciwieństwie do standardowych sieci prywatnych, które możesz samodzielnie tworzyć i konfigurować w portalu, uruchomienie usługi **External VLAN** wymaga koordynacji technicznej oraz konfiguracji przełączników sieciowych z naszej strony. Aby skonfigurować takie połączenie, skontaktuj się z naszym zespołem wsparcia technicznego. # Floating IP (/pl/docs/cloud/networking/floating-ip) Funkcja Floating IP pozwala na przypisywanie i przenoszenie publicznych adresów IPv4 między różnymi zasobami (maszynami wirtualnymi lub bramami Cloud Gateway) w obrębie Twojego projektu. ## Jak to działa [#jak-to-działa] W chmurze publicznej hostd Floating IP to **rzeczywisty publiczny adres IPv4**, który jest konfigurowany bezpośrednio na interfejsie sieciowym Twojej maszyny VM (na przykład `net0`) lub bramy Cloud Gateway. Jest to istotna różnica w porównaniu do wielu innych platform chmurowych, które stosują wirtualny NAT 1:1 na poziomie sieci nakładkowej (overlay). U nas cały ruch przychodzący dociera bezpośrednio do Twojego systemu operacyjnego gościa, bez zbędnych translacji adresów czy pośrednich węzłów proxy (proxy hops). Słowo **Floating** ("pływający") oznacza, że adres nie jest powiązany z cyklem życia konkretnej maszyny wirtualnej. Możesz zachować go w projekcie podczas usuwania serwera i przypisać go później do nowej maszyny lub bramy sieciowej. ## Kroki do zachowania i ponownego przypisania [#kroki-do-zachowania-i-ponownego-przypisania] 1. Otwórz sekcję `Network → Public IPs`, aby wyświetlić listę swoich adresów IP. 2. Podczas usuwania maszyny wirtualnej lub bramy, koniecznie **odznacz pole wyboru** przy opcji **Release public IP address**. Wtedy ten adres IP pozostanie zarezerwowany w Twoim projekcie. 3. Podczas tworzenia nowego serwera lub bramy Cloud Gateway, w formularzu konfiguracji sieci wybierz swój zarezerwowany adres z listy zamiast opcji **Auto**. 4. Jeśli chcesz zmienić adres IP na już działającej maszynie VM: przejdź do sekcji `VM → Resize`, wyłącz interfejs publiczny (`net0`), zapisz ustawienia, a następnie włącz go ponownie, wybierając opcję **Auto** lub konkretny zarezerwowany adres IP. Restart systemu nie jest do tego wymagany. ## Uwaga [#uwaga] * Aby zmienić adres IP, należy najpierw tymczasowo wyłączyć interfejs sieciowy WAN. * Zarezerwowane adresy IP, które pozostają wolne (nie są podłączone do żadnej maszyny VM ani bramy Cloud Gateway), są nadal taryfikowane według standardowej stawki godzinowej, ponieważ pozostają przypisane do Twojego projektu. # Sieć (/pl/docs/cloud/networking) Ten rozdział zawiera instrukcje dotyczące konfiguracji publicznych adresów IP, tworzenia sieci prywatnych (VLAN) oraz zarządzania topologią sieciową Twojego projektu. Wizualny podgląd topologii Twojego projektu, aktywnych połączeń oraz statusów maszyn wirtualnych. Rzeczywiste publiczne adresy IPv4 dla Twoich maszyn i bram sieciowych z możliwością zachowania i ponownego użycia. Konfiguracja wstecznych rekordów DNS (PTR) dla Twoich publicznych adresów IP. Tworzenie izolowanych lokalnych sieci (VLAN) oraz konfiguracja wewnętrznego zarządzania adresacją (IPAM). Podłączanie dedykowanego kanału Layer 2 do Twojej infrastruktury fizycznej lub zewnętrznej (poza chmurą). Konfiguracja NAT, VPN WireGuard, port forwardingu oraz reverse proxy na wirtualnym routerze. ## Uwaga [#uwaga] Jeśli chcesz przypisać istniejący publiczny adres IP do innej maszyny wirtualnej, najpierw wyłącz publiczny interfejs (WAN) w sekcji `VM → Resize`, zapisz ustawienia, a następnie włącz interfejs ponownie, wybierając odpowiedni zarezerwowany adres. Działa to bez konieczności restartowania systemu operacyjnego. # Mapa sieci (/pl/docs/cloud/networking/network-map) Zakładka **Mapa sieci** (Network Map) udostępnia przejrzysty schemat logiczny całej infrastruktury Twojego projektu, pokazując powiązania między publicznym internetem, bramami Cloud Gateway, sieciami prywatnymi oraz maszynami wirtualnymi. Mapa sieci w portalu ## Co wyświetla schemat [#co-wyświetla-schemat] 1. **Węzeł WAN** (po lewej stronie) — pokazuje stan Twojej puli publicznych adresów IPv4: łączną liczbę adresów w projekcie, ile z nich jest używanych, a ile pozostaje wolnych. 2. **Maszyny wirtualne** (karty) — pokazują nazwę maszyny, jej adresy publiczne i prywatne, bieżący status zasilania, konfigurację vCPU/RAM oraz wykres obciążenia. Klikając na nazwę maszyny VM, możesz szybko przejść do jej szczegółowych ustawień. 3. **Sieci prywatne** (okręgi z nazwą **vnet** i podsiecią CIDR) — wizualizują Twoje wewnętrzne sieci VLAN. Wszystkie maszyny podłączone do sieci lokalnej są połączone liniami z odpowiednim okręgiem podsieci. 4. **Cloud Gateway** — jest wyświetlana na styku publicznego internetu i Twojej sieci prywatnej. Klikając na nazwę bramy, możesz otworzyć ustawienia WireGuard, reverse proxy lub port forwardingu. 5. **Zarządzanie zasilaniem i konsola** — na karcie każdej uruchomionej maszyny VM znajduje się ikona konsoli (**Open Console in New Window**), a za pomocą menu trzech kropek `⋯` możesz szybko wykonać restart lub zatrzymanie maszyny. ## Uwaga [#uwaga] * Ta strona służy wyłącznie do wizualnego monitorowania i szybkiej nawigacji. Zmiany parametrów sieci lub interfejsów należy dokonywać w odpowiednich sekcjach (na przykład w `VM → Resize` lub w ustawieniach konkretnej sieci prywatnej). * Animowane linie prowadzące do maszyn wirtualnych wskazują, że serwer jest uruchomiony (status **running**). Linie bramy Cloud Gateway są animowane zawsze. Jest to wizualny wskaźnik aktywności statusu, a no wykres ruchu sieciowego w czasie rzeczywistym. * Maszyny wirtualne, które nie są podłączone do żadnej sieci, są grupowane i wyświetlane osobno w prawej części ekranu. # Sieć prywatna (/pl/docs/cloud/networking/private-network) Sieć prywatna (lokalny VLAN) pozwala połączyć Twoje maszyny wirtualne w izolowany segment sieciowy Layer 2. Ruch w takiej sieci jest całkowicie zabezpieczony przed dostępem z zewnątrz i nie jest taryfikowany. Sieć prywatna — lista i layout VLAN ## Kroki [#kroki] 1. Otwórz sekcję `Network → Private networks`. 2. Kliknij przycisk **New** i utwórz wewnętrzną sieć VLAN, podając żądany zakres podsieci IPv4 (CIDR). 3. Jeśli maszyny wirtualne w tej sieci lokalnej potrzebują bezpiecznego dostępu do internetu (NAT) lub innych usług sieciowych, włącz opcję **Enable Cloud Gateway** (Włącz Cloud Gateway). 4. Podłącz swoje maszyny wirtualne do utworzonej sieci (można to zrobić zarówno na etapie tworzenia nowej maszyny VM, jak i na działającej maszynie w sekcji `VM → Resize`). 5. Listę przydzielonych adresów oraz zarządzanie nimi znajdziesz w zakładce **IPAM** w ustawieniach swojej sieci prywatnej. # PTR / reverse DNS (/pl/docs/cloud/networking/ptr) Wsteczny rekord DNS (rekord PTR) służy do weryfikacji zgodności Twojego publicznego adresu IP z nazwą domenową. Najczęściej poprawny rekord PTR jest niezbędny do stabilnego działania serwerów pocztowych (aby Twoje wiadomości e-mail nie trafiały do spamu) lub dla systemów monitorowania i autoryzacji dostępu. Edycja PTR w Network → IP Addresses ## Kroki [#kroki] 1. Przejdź do sekcji `Network → Public IPs`. 2. Wybierz odpowiedni publiczny adres IP i kliknij pole edycji **PTR**. 3. Wprowadź swoją nazwę domenową (FQDN), którą chcesz powiązać z tym adresem. 4. Kliknij **Save**, aby zapisać zmiany. ## Uwaga [#uwaga] Zarządzanie głównymi rekordami DNS Twojej domeny (takimi jak A, MX, CNAME, TXT) odbywa się po stronie Twojego dostawcy usług DNS (na przykład Cloudflare lub rejestratora domeny). Konfiguracja rekordu PTR w naszym portalu działa wyłącznie na potrzeby wstecznego wyszukiwania (reverse DNS) publicznych adresów IPv4 przydzielonych przez naszą platformę. # Projekty (/pl/docs/cloud/projects) Projekt w naszym systemie jest głównym narzędziem do grupowania oraz izolowania Twoich zasobów chmurowych. Project overview — lista VM i limity zasobów ## Co łączy projekt [#co-łączy-projekt] * Maszyny wirtualne oraz operacje na nich (uruchamianie, zatrzymywanie, restart, zmiana konfiguracji); * Infrastrukturę sieciową (sieci prywatne VLAN, wydzielone publiczne adresy IP, bramy Cloud Gateway); * System kopii zapasowych (personalny harmonogram kopii oraz dedykowaną przestrzeń PBS datastore); * Uprawnienia dostępu, grupy bezpieczeństwa (Security Groups), High Availability oraz dziennik zdarzeń; * Statystyki finansowe i koszty projektu (dostępne wyłącznie dla właściciela konta). ## Uwaga [#uwaga] Możesz usunąć projekt dopiero wtedy, gdy zostaną z niego całkowicie usunięte wszystkie maszyny wirtualne oraz sieci prywatne. Usunięcie projektu jest nieodwracalne: automatycznie zwalnia wszystkie publiczne adresy IP, całkowicie czyści przestrzeń kopii zapasowych (PBS datastore) i trwale kasuje wszystkie backupy. # Koszty projektu (/pl/docs/cloud/projects/resource-usage) Wszystkie bieżące naliczenia oraz analityka finansowa Twojego projektu są obliczane godzinowo w złotych polskich (PLN). Statystyki te są dostępne wyłącznie dla właściciela projektu (**Superadmin**) na stronie `Datacenter → Resource usage`. Pozostali członkowie zespołu posiadający role Admin lub Auditor nie widzą informacji finansowych. Szczegółowe informacje o tym, jak prawidłowo czytać raport o zużyciu zasobów i porównywać go z aktywnymi usługami, znajdziesz w sekcji [Resource usage](/pl/docs/cloud/datacenter/resource-usage). # Dostęp zespołu (/pl/docs/cloud/projects/team-access) Możesz pracować nad projektem wspólnie ze swoimi współpracownikami lub partnerami. Zarządzać dostępem i rolami uczestników może wyłącznie właściciel projektu — użytkownik o roli **Superadmin**. Dodanie użytkownika i rola ## Kroki do przyznania dostępu [#kroki-do-przyznania-dostępu] 1. Przejdź do sekcji `Datacenter → Permissions`. 2. Kliknij przycisk **Add permission**. 3. Wpisz e-mail użytkownika, który posiada zarejestrowane konto w systemie hostd, i wybierz jego rolę (**Admin** lub **Auditor**). 4. W razie potrzeby możesz zawsze odebrać dostęp lub zmienić rolę użytkownika na tej samej liście. ## Dostępne role w systemie [#dostępne-role-w-systemie] | Rola | Uprawnienia | | -------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Superadmin** | Właściciel projektu. Posiada pełne uprawnienia: zarządzanie uczestnikami, przegląd bilingu i wydatków finansowych, tworzenie, modyfikowanie i usuwanie dowolnych maszyn VM oraz sieci. | | **Admin** | Administrator techniczny. Posiada pełny dostęp do zarządzania infrastrukturą (tworzenie, zmiana rozmiaru, usuwanie maszyn VM, konfiguracja sieci), ale nie widzi informacji finansowych ani sekcji zarządzania dostępem zespołu. | | **Auditor** | Obserwator. Posiada dostęp do podglądu parametrów maszyn VM oraz sieci w trybie tylko do odczytu (read-only), bez prawa do wprowadzania jakichkolwiek zmian. | ## Uwaga [#uwaga] Aby pomyślnie dodać członka zespołu, musi on posiadać zarejestrowane konto w systemie hostd. Natychmiast po wprowadzeniu jego adresu e-mail projekt pojawi się w jego osobistym panelu zarządzania. # Backupy VM i restore (/pl/docs/cloud/virtual-machines/backups-restore) Jeśli Twój system uległ poważnej awarii lub dane zostały uszkodzone, możesz całkowicie przywrócić maszynę wirtualną (w tym stan jej dysku systemowego) z wcześniej utworzonej kopii zapasowej (backupu). ## Przed przywróceniem sprawdź [#przed-przywróceniem-sprawdź] * Maszyna wirtualna musi być całkowicie wyłączona (status **stopped**). * Żądany backup znajduje się na liście dostępnych w zakładce `VM → Backups`. ## Kroki do przywrócenia [#kroki-do-przywrócenia] 1. Wyłącz maszynę wirtualną. 2. Przejdź do sekcji `VM → Backups`. 3. Wybierz odpowiednią kopię na podstawie daty jej utworzenia i kliknij przycisk **Restore** (Przywróć). 4. W razie potrzeby zaznacz opcję automatycznego uruchomienia maszyny po przywróceniu. 5. Poczekaj na zakończenie procesu przywracania i sprawdź poprawność działania swoich usług. ## Uwaga [#uwaga] * Procedura przywracania wymaga obowiązkowego zatrzymania maszyny wirtualnej. * Jeśli dla Twojej maszyny VM aktywowana jest funkcja automatycznego restartu w przypadku awarii (HA), przed rozpoczęciem przywracania należy **tymczasowo wyłączyć HA (autostart)** w sekcji `Datacenter → High Availability`. W przeciwnym razie system HA będzie próbował automatycznie uruchomić serwer podczas procedury przywracania, co doprowadzi do błędu. Po pomyślnym przywróceniu będziesz mógł ponownie włączyć HA. * Ochrona, usuwanie kopii oraz pobieranie pojedynczych plików — w **Backup → Datastore**. Strona `VM → Backups` służy tylko do pełnego restore. # SSH i konsola (/pl/docs/cloud/virtual-machines/connect-console) Do zarządzania maszyną wirtualną możesz połączyć się z nią przez sieć za pomocą SSH (metoda podstawowa) lub skorzystać z wbudowanej w portal konsoli webowej noVNC (metoda awaryjna, jeśli sieć jest niedostępna). Konsola noVNC ## Przed połączeniem sprawdź [#przed-połączeniem-sprawdź] * Maszyna wirtualna znajduje się w statusie **running**. * Pamiętasz nazwę użytkownika (username), którą podałeś podczas tworzenia lub reinstalacji VM. * Jeśli łączysz się przez SSH przez internet (WAN): maszyna ma publiczny adres IP, a na Twoim komputerze skonfigurowano odpowiedni prywatny klucz SSH. ## Metody połączenia [#metody-połączenia] ### 1. Połączenie przez SSH (Zalecane) [#1-połączenie-przez-ssh-zalecane] Otwórz terminal na swoim komputerze i wykonaj polecenie połączenia (jeśli klucz prywatny jest zapisany w domyślnej ścieżce `~/.ssh/id_rsa` lub `~/.ssh/id_ed25519`, parametr `-i` nie jest wymagany): ```bash ssh username@public_ip ``` Jeśli używasz klucza o niestandardowej nazwie lub ścieżce: ```bash ssh -i ~/.ssh/id_rsa username@public_ip ``` ### 2. Połączenie przez konsolę webową noVNC [#2-połączenie-przez-konsolę-webową-novnc] Jeśli na maszynie wyłączono sieć, zablokowano porty lub wystąpiły problemy z konfiguracją kluczy SSH: 1. Przejdź do ustawień swojej maszyny VM i otwórz zakładkę `VM → Console` (lub kliknij przycisk **Open Console in New Window**). 2. Zaloguj się do systemu, wprowadzając nazwę użytkownika (username) oraz hasło podane podczas tworzenia lub reinstalacji systemu. ## Uwaga [#uwaga] Na wszystkich naszych standardowych obrazach Linux autoryzacja SSH za pomocą hasła jest domyślnie zablokowana. Jeśli spróbujesz połączyć się przez SSH przy użyciu hasła, otrzymasz błąd dostępu (Permission denied). Aby włączyć logowanie hasłem, skorzystaj z [osobnego poradnika](/pl/docs/cloud/virtual-machines/ssh-password-login). # Tworzenie VM (/pl/docs/cloud/virtual-machines/create) Tworzenie nowej maszyny wirtualnej (VM) odbywa się za pomocą wygodnego formularza w portalu. Pozwala to na elastyczne dostosowanie parametrów serwera do Twoich zadań. Tworzenie VM — formularz z obrazem, kluczem SSH i WAN ## Kroki [#kroki] 1. Otwórz swój projekt i kliknij przycisk **Create VM** (Utwórz VM). 2. **System operacyjny i użytkownik:** Wybierz żądany obraz systemu operacyjnego (dostępne są stabilne dystrybucje systemu Linux, takie jak Ubuntu, Debian, Rocky Linux oraz AlmaLinux). Podaj hostname, nazwę użytkownika (username) oraz hasło. 3. **Konfiguracja zasobów:** Dostosuj potrzebne zasoby (vCPU, RAM, rozmiar dysku oraz **CPU mode**). 4. **Autoryzacja:** Dodaj swój publiczny klucz SSH. Gorąco zalecamy używanie kluczy SSH do uzyskiwania dostępu. 5. **Sieć:** Wybierz tryb publicznego WAN (**Off**, **IPv4**, **IPv6** lub **IPv4 + IPv6**), prywatną sieć LAN albo oba interfejsy jednocześnie (w zależności od architektury Twojego projektu). 6. Kliknij **Create** (Utwórz). Proces tworzenia maszyny i początkowej inicjalizacji przez `cloud-init` trwa do jednej minuty. ## Uwaga [#uwaga] * Na wszystkich standardowych obrazach Linux logowanie przez SSH hasłem jest **domyślnie wyłączone** ze względów bezpieczeństwa — połączenie jest możliwe wyłącznie za pomocą kluczy SSH. Jeśli koniecznie potrzebujesz logowania hasłem, możesz włączyć je ręcznie po uruchomieniu maszyny zgodnie z [tą instrukciem](/pl/docs/cloud/virtual-machines/ssh-password-login). * Nie przechowujemy Twoich haseł, dlatego po utworzeniu maszyny wirtualnej wyświetlenie podanego hasła w portalu będzie niemożliwe. Zapisz je w bezpiecznym miejscu. * Minimalna konfiguracja dowolnej maszyny wirtualnej wynosi **2 vCPU**, a liczba rdzeni procesora rośnie z krokiem co **2**. Pamięć RAM oraz rozmiar dysku są oferowane w postaci proporcjonalnych poziomów taryfowych (tiers) na podstawie wybranej liczby vCPU. * Dysk systemowy ma limit **20 000 IOPS** oraz **1000 MB/s** (odczyt i zapis). Szczegóły: [Storage](/pl/docs/cloud/storage). * Tryby publicznego WAN: **Off** (bez adresu publicznego), **IPv4**, **IPv6** lub **IPv4 + IPv6**. Na podłączonej VM możesz przełączać tylko **Off ↔ ten sam tryb**; żeby zmienić IPv4 / IPv6 / dual-stack, najpierw wyłącz WAN. * Opłata godzinowa za **public IP** dotyczy **tylko IPv4**. Publiczne IPv6 nie ma osobnej opłaty za adres. * Tryb wysokiej dostępności (HA) nie aktywuje się automatycznie podczas tworzenia. Jeśli potrzebujesz sprzętowej ochrony przed awariami, włącz go po utworzeniu w sekcji `Datacenter → High Availability`. # Usunięcie VM (/pl/docs/cloud/virtual-machines/destroy) Usunięcie maszyny wirtualnej (VM) jest operacją nieodwracalną, która całkowicie czyści zasoby przydzielone dla niej na serwerze fizycznym. Usunięcie VM — opcje backupów i publicznego IP ## Kroki [#kroki] 1. Wyłącz maszynę wirtualną (musi mieć status **stopped**). 2. Przejdź do sekcji `VM → Destroy`. 3. **Opcja kopii zapasowych:** Wybierz, czy chcesz automatycznie usunąć wszystkie zgromadzone backupy tej maszyny, czy chcesz zachować je w swoim PBS datastore do przyszłego użytku lub przywracania pojedynczych plików. 4. **Opcja adresu IP:** Wybierz, czy chcesz zwolnić publiczny adres IP maszyny (release), czy zachować go w projekcie jako Floating IP do podłączenia do innych serwerów w przyszłości. 5. Potwierdź usunięcie. ## Uwaga [#uwaga] Zachowane w projekcie publiczne adresy IP (Floating IPs) oraz kopie zapasowe (jeśli zdecydowałeś się je zachować) są nadal naliczane zgodnie ze standardowymi stawkami godzinowymi, ponieważ zajmują zasoby platformy. Jeśli nie są Ci już potrzebne, usuń je ręcznie w odpowiednich sekcjach sieci lub backupów. # Firewall i security groups (/pl/docs/cloud/virtual-machines/firewall-security-groups) Możesz skonfigurować zaporę sieciową (Firewall) bezpośrednio dla każdej maszyny wirtualnej. W tym celu możesz tworzyć unikalne, indywidualne reguły dostępu lub podłączać wcześniej przygotowane szablony — grupy bezpieczeństwa (Security Groups). Create firewall rule — modal ## Kroki do konfiguracji reguł [#kroki-do-konfiguracji-reguł] 1. Przejdź do sekcji `VM → Firewall`. 2. Jeśli zapora sieciowa jest wyłączona, przełącz suwak **Global Status** w pozycję **On**, zmień ogólną politykę wejściową **Policy In** na **DROP** (zablokuje to cały nieznany ruch przychodzący) i kliknij **Apply**. 3. Aby utworzyć nową regułę, kliknij przycisk **Add rule**. 4. Wypełnij parametry reguły (szczegóły poniżej) i kliknij **Add**. 5. Zwróć uwagę na kolejność reguł w tabeli — są one stosowane po kolei od góry do dołu w ramach każdego kierunku (przychodzącego lub wychodzącego). ### Konfiguracja reguł w oknie dialogowym [#konfiguracja-reguł-w-oknie-dialogowym] * **Type** — wybierz kierunek ruchu: **IN** (ruch przychodzący do Twojej VM) lub **OUT** (ruch wychodzący z Twojej VM). * **Action** — wybierz działanie: **ACCEPT** (zezwól na ruch) lub **DROP** (zablokuj ruch). * **Protocol** — wybierz protokół połączenia: **TCP**, **UDP** lub **ICMP**. * **Source Address / Destination Address** — podaj adres IP lub zakres (CIDR) nadawcy (dla IN) lub odbiorcy (dla OUT). * **Source Port / Destination Port** — podaj konkretne porty lub zakresy portów (na przykład `22` dla SSH lub `80,443` dla ruchu WWW). * **Comment** — opcjonalnie dodaj krótki opis reguły (na przykład "Dostęp do bazy danych"). * **Enabled** — pozwala tymczasowo wyłączyć regułę bez usuwania jej z listy. ## Używanie grup bezpieczeństwa (Security Groups) [#używanie-grup-bezpieczeństwa-security-groups] Insert Security Group na VM Firewall Jeśli masz wiele maszyn wirtualnych, które wymagają tych samych reguł dostępu, utwórz szablon w sekcji [Security groups](/pl/docs/cloud/datacenter/security-groups). Następnie na stronie `VM → Firewall` kliknij przycisk **Insert Security Group** i wybierz odpowiedni szablon z listy. ## Uwaga [#uwaga] * Zapora sieciowa w portalu hostd filtruje ruch **wyłącznie na publicznym interfejsie WAN (`net0`)**. Ruch lokalny w sieciach prywatnych (LAN) pozostaje całkowicie otwarty wewnątrz Twojej sieci. * Aby zwiększyć bezpieczeństwo i stabilność działania sieci, zakres podsieci (CIDR) w pojedynczej regule jest ograniczony do maksymalnej wartości **/26**. * Wychodzący SMTP (porty 25 / 465 / 587) jest domyślnie zablokowany na brzegu sieci, niezależnie od tych reguł — zobacz [Wychodząca poczta (SMTP)](/pl/docs/cloud/virtual-machines/outbound-email). # Maszyny wirtualne (/pl/docs/cloud/virtual-machines) W tej sekcji zebrano wszystkie niezbędne poradniki dotyczące zarządzania Twoimi maszynami wirtualnymi (VM) w chmurze publicznej. Szczegółowy opis formularza tworzenia (wybór obrazu, wielkości zasobów, kluczy SSH i sieci). Jak połączyć się z Twoją maszyną przez SSH lub awaryjną konsolę webową noVNC. Instrukcja włączenia dostępu za pomocą hasła (który jest domyślnie wyłączony ze względów bezpieczeństwa). Zmiana trybu procesora, liczby vCPU, pamięci RAM oraz zwiększanie dysku systemowego. Pełna reinstalacja systemu operacyjnego na Twoim serwerze z wyczyszczeniem dysku. Tworzenie natychmiastowego zrzutu systemu (punktu przywracania) w celu bezpiecznego przeprowadzania eksperymentów. Pełne przywracanie maszyny wirtualnej z zapisanej kopii zapasowej. Prawidłowe usuwanie serwera z możliwością zachowania jego adresu IP oraz kopii zapasowych. Konfiguracja zapory sieciowej w celu ochrony Twojej VM przed zewnętrznymi zagrożeniami. ## Uwaga [#uwaga] Jeśli wyłączysz maszynę wirtualną (Stop), system przestanie naliczać opłaty za vCPU oraz RAM. Opłaty za dysk, zarezerwowany adres IP, backupy oraz Cloud Gateway będą jednak nadal naliczane, ponieważ te zasoby pozostają przypisane do Twojego projektu. # Wychodząca poczta (SMTP) (/pl/docs/cloud/virtual-machines/outbound-email) Wychodząca poczta z instancji (SMTP na portach **25**, **465** i **587**) jest **domyślnie zablokowana** na brzegu sieci hostd. Obowiązuje to nawet wtedy, gdy reguły zapory na VM zezwalają na ten ruch. Chronimy w ten sposób reputację naszych zakresów adresów IP. ## Status w panelu [#status-w-panelu] Na stronie **VM → Firewall** widać, czy wychodząca poczta dla tej instancji jest **Blocked** (zablokowana) czy **Allowed** (dozwolona). ## Wniosek o odblokowanie [#wniosek-o-odblokowanie] 1. Otwórz **VM → Firewall**. 2. Użyj **Request unlock**. 3. Podaj cel, domenę (domeny) nadawcy i oczekiwany wolumen. 4. Wyślij — powstanie ticket w **Support**, gdzie możesz śledzić sprawę. Sprawdzamy wniosek (m.in. uzasadnienie, domeny, historię konta). Po akceptacji wychodząca poczta dla instancji zostaje odblokowana. ## Uwaga [#uwaga] * Odblokowanie dotyczy instancji / jej publicznych IP. Po zmianie publicznego IP skontaktuj się z supportem, żeby zaktualizować allowlistę. * Same reguły zapory w gościu lub w Proxmox nie otworzą wychodzącego SMTP, dopóki działa blokada na brzegu. * Skonfiguruj SPF, DKIM i DMARC dla domen, z których wysyłasz. # Reinstall VM (/pl/docs/cloud/virtual-machines/reinstall) Funkcja Reinstall pozwala na całkowite wyczyszczenie dysku systemowego Twojej maszyny wirtualnej i wdrożenie czystego systemu operacyjnego z wybranego obrazu. Podczas tej operacji wszystkie parametry sprzętowe Twojego serwera (liczba vCPU, pamięć RAM, rozmiar dysku oraz adresy MAC interfejsów sieciowych) pozostają bez zmian. Reinstall VM — obraz OS, dane logowania i klucze SSH ## Kroki do reinstalacji [#kroki-do-reinstalacji] 1. Zatrzymaj swoją maszynę wirtualną (musi mieć status **stopped**). 2. Przejdź do sekcji `VM → Reinstall`. 3. Wybierz system operacyjny, podaj hostname, nazwę użytkownika (username) oraz nowe hasło. 4. Dodaj swój publiczny klucz SSH. 5. Kliknij przycisk **Reinstall** (Reinstaluj). Proces ponownej instalacji trwa do jednej minuty. ## Uwaga [#uwaga] * Operacja Reinstall jest operacją destrukcyjną. Platforma całkowicie usuwa obecny dysk systemowy i tworzy na jego miejscu nowy z czystym systemem operacyjnym. Jeśli na starym dysku pozostały ważne konfiguracje lub pliki, upewnij się, że je zapisałeś lub wcześniej utworzyłeś kopię zapasową w sekcji `VM → Backups`. * Reinstalacja systemu operacyjnego automatycznie **usuwa aktualny snapshot użytkownika** maszyny wirtualnej, jeśli taki był utworzony. # Resize VM (/pl/docs/cloud/virtual-machines/resize) Możesz elastycznie zmieniać charakterystykę swojej maszyny wirtualnej (liczbę vCPU, RAM, rozmiar dysku oraz tryb procesora CPU mode) w zależności od bieżącego obciążenia. VM Resize — CPU mode, vCPU, RAM i sieć ## Co można zmienić na gorąco (gdy VM działa) [#co-można-zmienić-na-gorąco-gdy-vm-działa] Gdy Twoja maszyna wirtualna jest uruchomiona (status **running**), możesz wykonać następujące działania bez zatrzymywania systemu: * **Zwiększyć** liczbę vCPU, pamięć RAM oraz rozmiar dysku systemowego. * Zmienić tryb pracy procesora **CPU mode** (na przykład przejść z Eco na Performance). * Dodawać, odłączać lub konfigurować interfejsy sieciowe (WAN/LAN). ## Co wymaga zatrzymania maszyny wirtualnej [#co-wymaga-zatrzymania-maszyny-wirtualnej] Każde **zmniejszenie zasobów** (zmniejszenie liczby vCPU lub pamięci operacyjnej RAM) wymaga obowiązkowego zatrzymania maszyny wirtualnej. Przed zapisaniem takich zmian wyłącz serwer. ## Kroki do zmiany rozmiaru [#kroki-do-zmiany-rozmiaru] 1. Przejdź do sekcji `VM → Resize`. 2. Wybierz nowy tryb **CPU mode**, liczbę vCPU oraz pamięć RAM w dostępnej siatce taryf (tiers). 3. Jeśli potrzebujesz więcej miejsca na pliki, podaj nowy (większy) rozmiar dysku systemowego. 4. Jeśli chcesz zmienić publiczny adres IP: wyłącz publiczny interfejs WAN, kliknij **Save**, a następnie ponownie włącz WAN i wybierz istniejący Floating IP lub opcję **Auto** w celu otrzymania nowego adresu. Działa to bez restartu systemu operacyjnego. 5. Kliknij **Save**, aby zastosować zmiany. ## Uwaga [#uwaga] * Zmniejszać zasoby (vCPU, RAM) lub przechodzić na niższy tryb pracy procesora (np. z Performance na Eco) można nie częściej niż **raz dziennie** dla każdej maszyny wirtualnej. * Zmiana rozmiaru dysku systemowego jest możliwa **wyłącznie w stronę zwiększania**. Zmniejszanie przestrzeni dyskowej jest zablokowane na poziomie systemów plików, aby zapobiec utracie danych. * Tryb pracy procesora (**CPU mode**) można zmieniać "w locie" na działającej maszynie wirtualnej. # Snapshoty (/pl/docs/cloud/virtual-machines/snapshots) Snapshot (migawka / natychmiastowy zrzut stanu) to szybki zapis stanu dysku Twojej maszyny wirtualnej. Jest to niezwykle przydatne narzędzie, gdy musisz dokonać potencjalnie niebezpiecznej zmiany w konfiguracji lub zaktualizować oprogramowanie i chcesz mieć możliwość natychmiastowego powrotu do działającego stanu w przypadku błędu. ## Kroki [#kroki] 1. Przejdź do sekcji `VM → Snapshots`. 2. Kliknij przycisk **Create snapshot** bezpośrednio przed rozpoczęciem prac technicznych w systemie. 3. Przeprowadź zaplanowane konfiguracje lub aktualizacje na serwerze. 4. Jeśli wszystko przebiegło pomyślnie — usuń utworzony snapshot, aby zwolnić zasoby. Jeśli coś poszło nie tak — kliknij przycisk **Rollback**, aby natychmiast cofnąć stan maszyny do momentu utworzenia snapshotu. ## Uwaga [#uwaga] * **Snapshot to nie backup!** Jest on przechowywany na tym samym macierzy dyskowej, co sama maszyna wirtualna, i służy wyłącznie do krótkoterminowej ochrony podczas prac technicznych. Do niezawodnej, długoterminowej ochrony danych używaj automatycznych zadań [Backup jobs](/pl/docs/cloud/backup/jobs). * Dla każdej maszyny wirtualnej można utworzyć **tylko jeden snapshot naraz**. Przed utworzeniem nowego snapshotu należy koniecznie usunąć lub cofnąć poprzedni. # Włączenie SSH hasłem (/pl/docs/cloud/virtual-machines/ssh-password-login) Ze względów bezpieczeństwa na wszystkich standardowych obrazach Linux na platformie hostd logowanie przez SSH za pomocą hasła jest **domyślnie zablokowane**. Gorąco zalecamy korzystanie wyłącznie z kluczy SSH. Jeśli jednak Twoje skrypty lub aplikacje wymagają dostępu za pomocą hasła, możesz aktywować tę opcję ręcznie wewnątrz systemu operacyjnego gościa. ## Kroki do włączenia [#kroki-do-włączenia] 1. Połącz się ze swoją maszyną wirtualną za pomocą klucza SSH lub wbudowanej konsoli webowej `VM → Console`. 2. Utwórz nowy plik konfiguracyjny demona SSH, wykonując polecenie: ```bash sudo nano /etc/ssh/sshd_config.d/99-password-auth.conf ``` 3. Dodaj do tego pliku następującą linię: ```text PasswordAuthentication yes ``` Zapisz plik (w edytorze nano: `Ctrl+O`, `Enter`, a następnie wyjdź — `Ctrl+X`). 4. Zrestartuj usługę SSH wewnątrz systemu operacyjnego, aby zastosować nową konfigurację: * Dla **Debian / Ubuntu**: ```bash sudo systemctl restart ssh ``` * Dla **AlmaLinux / Rocky Linux**: ```bash sudo systemctl restart sshd ``` 5. Teraz możesz łączyć się z serwerem przez SSH, wprowadzając nazwę użytkownika oraz hasło. ## Uwaga [#uwaga] * Autoryzacja za pomocą hasła jest znacznie mniej bezpieczna niż korzystanie z kluczy SSH, ponieważ Twój serwer staje się podatny na ataki typu brute-force (próby złamania hasła przez roboty z internetu). Gorąco zalecamy ograniczanie dostępu do portu SSH za pomocą [Firewall VM](/pl/docs/cloud/virtual-machines/firewall-security-groups). * Jeśli wykonasz pełną reinstalację systemu ([Reinstall](/pl/docs/cloud/virtual-machines/reinstall)), systemowa usługa `cloud-init` ponownie zablokuje logowanie hasłem. W takim przypadku powyższe kroki trzeba będzie powtórzyć. # Документація API (/uk/docs/api) API hostd дозволяє керувати акаунтом програмно. Базова URL-адреса: `https://hostd.cloud`. ## Автентифікація [#автентифікація] Більшість ендпоінтів потребують ключ API. Створіть ключ у порталі в [Налаштування → Ключі API](https://hostd.cloud/app/settings/api-keys) і надсилайте його як Bearer-токен: ```http Authorization: Bearer ``` ```bash curl -H "Authorization: Bearer " https://hostd.cloud/api/network/ips/ ``` Список кластерів публічний і не потребує автентифікації. ## Ендпоінти [#ендпоінти] * [Public cloud](/uk/docs/api/public-cloud/list-clusters) — кластери, проєкти, використання, задачі та погодинні ціни. * [IP addresses](/uk/docs/api/ip-addresses/list-ip-addresses) — призначені IP-адреси та їхні записи reverse DNS (PTR). # Можливості платформи (/uk/docs/cloud/capabilities) Публічна хмара від hostd — це надійна, масштабована та безпечна інфраструктура (IaaS), побудована на базі провідних технологій корпоративного рівня. ## Технологічний стек та залізо [#технологічний-стек-та-залізо] Ми використовуємо лише перевірене та надійне обладнання від світових лідерів для забезпечення максимальної продуктивності та стабільності вашого бізнесу. **Proxmox VE** — стабільна гілка enterprise-репозиторію на базі KVM/QEMU Лише **Dell PowerEdge** з процесорами **AMD EPYC** Комутатори та маршрутизатори **Dell PowerSwitch** та **Juniper** **Proxmox Backup Server (PBS)** — ізольований дедуплікований datastore для кожного проєкту Розподілене all-flash NVMe (SDS) з **RoCEv2** та асинхронним `io_uring` ### Продуктивність дискової підсистеми [#продуктивність-дискової-підсистеми] Завдяки all-flash NVMe сховищу та сучасним протоколам передачі даних, типова затримка (latency) для операцій **4k randwrite** у режимі **t1q1** (1 потік, `iodepth=1`) із використанням **fsync** складає всього близько **0.11 ms** (вимірюється безпосередньо на рівні гіпервізора). *Зверніть увагу: це показник інфраструктури, а не гарантія (SLA) для вашого застосунку всередині VM, оскільки файлова система гостьової ОС та емуляція додають свої накладні витрати.* Кожен віртуальний диск VM обмежено **20 000 IOPS** читання і запису та **1000 MB/s** пропускної здатності читання і запису. Деталі: [Storage](/uk/docs/cloud/storage). ### Доступні зони [#доступні-зони] * **WAW-AMD1** — Варшава, Польща. Інфраструктура розміщується у сертифікованих дата-центрах **Atman WAW-2** та **Equinix WA2** (відповідність стандарту Tier III+). Ваші дані та бекапи фізично залишаються на території Польщі. ## Обчислювальні ресурси (Compute) [#обчислювальні-ресурси-compute] * **Сучасні ОС Linux:** Миттєве розгортання чистих та стабільних образів Ubuntu, Debian, Rocky Linux та AlmaLinux. * **Гнучкі режими роботи процесора (CPU modes):** * **Performance:** Виділені vCPU з максимальною продуктивністю до 100% процесорного часу для високонавантажених систем. * **Eco:** Збалансоване використання до 50% процесорного часу для стандартних веб-застосунків та сервісів. * **Slim:** Оптимальний режим до 25% процесорного часу для тестування, розробки та легких фонових задач. * **Миттєве масштабування (Resize):** Збільшення vCPU, RAM та об'єму системного диска "на льоту" без зупинки роботи системи. * **Гарантована висока доступність (High Availability):** Автоматичний захист від апаратних збоїв. У разі виходу сервера з ладу ваша VM буде автоматично перезапущена на іншому робочому вузлі менш ніж за хвилину. * **Снапшоти (Snapshots):** Створення миттєвого знімка стану диска для швидкого та безпечного відкату змін у разі оновлень чи експериментів. ## Мережа та безпека (Networking) [#мережа-та-безпека-networking] * **Публічний WAN (IPv4 / IPv6):** Підключіть публічну адресу в режимі **IPv4**, **IPv6** або **IPv4 + IPv6** (або залиште WAN вимкненим). Адреси призначаються безпосередньо на інтерфейс машини без overlay NAT. Погодинна плата за public IP стосується **лише IPv4**. * **Приватні мережі (VLAN):** Створення повністю ізольованих локальних мережевих сегментів Layer 2 для безпечної комунікації між серверами з вбудованим автоматичним керуванням адресами (IPAM). * **Зворотний DNS (PTR):** Зручне керування PTR-записами для публічних адрес IPv4 та IPv6 безпосередньо через портал. * **Мережевий екран (Firewall):** Налаштування правил фільтрації трафіку на публічних інтерфейсах. * **Групи безпеки (Security Groups):** Шаблони правил міжмережевого екрана для швидкого та багаторазового застосування до різних віртуальних машин. * **Мапа мережі:** Інтерактивна та наочна візуалізація всієї вашої інфраструктури, зв'язків між серверами, приватними мережами та шлюзами. * **External VLAN:** Можливість інтеграції хмари з вашим фізичним обладнанням (bare metal або on-premises) через виділений канал Layer 2. ## Cloud Gateway (Керований шлюз) [#cloud-gateway-керований-шлюз] Спеціалізований та повністю керований інфраструктурний маршрутизатор для ваших приватних мереж. * **Повна автоматизація:** Налаштування NAT, port forwarding, VPN та проксіювання без необхідності ручного адміністрування операційної системи маршрутизатора. * **WireGuard VPN:** Швидкий та безпечний доступ адміністраторів та розробників до локальних ресурсів хмари по захищеному каналу. * **Reverse Proxy:** Зворотний проксі-сервер на базі високопродуктивного Caddy з автоматичним отриманням та оновленням безкоштовних SSL-сертифікатів від Let's Encrypt під час першого відвідування домену. ## Резервне копіювання (Backup) [#резервне-копіювання-backup] Інтегрована та повністю автоматизована система бекапів на базі технологій корпоративного рівня Proxmox Backup Server (PBS). * **Регулярні розклади (Backup jobs):** Налаштування гнучких автоматичних графіків резервного копіювання для груп віртуальних машин. * **Інкрементальність та дедуплікація:** Бекапи копіюють лише фактично змінені блоки диска та проходять дедуплікацію на рівні сховища, що забезпечує колосальну економію дискового простору (on-disk size) і зменшує вартість зберігання. * **Відновлення на рівні файлів (File restore):** Зручний перегляд файлового дерева копії та завантаження окремих файлів або папок прямо з бекапу без повного відкату всієї системи. * **Захист копій (Protection):** Можливість захистити важливі копії від випадкового чи автоматичного видалення за політикою зберігання. ## Керування та білінг (Account & Billing) [#керування-та-білінг-account--billing] * **Командний доступ:** Додавання учасників за email та призначення ролей (Superadmin, Admin, Auditor) для безпечного спільного керування інфраструктурними ресурсами. * **Погодинна тарифікація:** Нарахування витрат виключно за фактично задіяні ресурси з точністю до години. * **Дві моделі оплати:** Оплата за передоплатою (Prepaid з функцією автопоповнення) або за фактом використання (Postpaid із виставленням рахунку на початку місяця). # Швидкий старт (/uk/docs/cloud/getting-started) Цей посібник допоможе вам створити перший проєкт, безпечно налаштувати правила доступу, запустити вашу першу віртуальну машину, захистити її мережевим екраном (Firewall), увімкнути режим високої доступності (HA) та налаштувати автоматичні бекапи. ## Порядок кроків [#порядок-кроків] 1. [Створення проєкту](#step-1-project) 2. [Запуск віртуальної машини (VM)](#step-2-vm) 3. [Налаштування групи безпеки (Security Group)](#step-3-security-group) 4. [Налаштування Firewall на VM](#step-4-firewall) 5. [Увімкнення High Availability (HA)](#step-5-ha) 6. [Налаштування Backup Job](#step-6-backup-job) ## Перед початком [#перед-початком] * Ознайомтеся зі сторінкою [Огляд та ліміти](/uk/docs/cloud/public-cloud-overview), щоб розібратися з принципами роботи платформи та діючими лімітами. * Підготуйте SSH-ключ на вашому комп'ютері (вам знадобиться публічна частина ключа для вставки у форму). * Встановіть SSH-клієнт. За потреби ви також зможете скористатися вебконсоллю (`VM → Console`). * Якщо у вас prepaid-акаунт, перевірте, чи достатньо коштів на балансі. ## Кроки [#кроки] ### 1. Створіть проєкт [#step-1-project] 1. Відкрийте панель керування: `Console → Public Cloud`. 2. Натисніть **Create project**, виберіть зручну для вас зону, вкажіть **Project name** та підтвердіть створення. Створення проєкту — Public Cloud ### 2. Створіть віртуальну машину (VM) [#step-2-vm] 1. На головній сторінці (overview) вашого нового проєкту натисніть **Create VM**. 2. Виберіть образ операційної системи, вкажіть `hostname`, `username` та пароль. 3. Додайте ваш **публічний SSH-ключ** у відповідне поле. 4. Налаштуйте потрібні ресурси (vCPU, RAM, розмір диска та `CPU mode`). 5. Увімкніть опцію **публічного WAN** (Public WAN), щоб машина отримала доступ до інтернету. 6. Натисніть **Create**. Процес створення машини та початкової ініціалізації через `cloud-init` займає до однієї хвилини. Створення VM — форма з образом, SSH-ключем і WAN ### 3. Створіть групу безпеки (Security Group) [#step-3-security-group] Для зручного керування однаковими правилами (наприклад, доступом через SSH) для багатьох серверів варто використовувати Security Groups. 1. Перейдіть до розділу `Datacenter → Security groups`. 2. Створіть нову групу безпеки (Security Group). Використовуйте коротку латинську назву (до **15** символів). 3. Додайте правило **IN** для дозволу підключень: оберіть протокол **TCP**, порт **22** (SSH). У полі **Source** вкажіть ваші IP-адреси у форматі `x.x.x.x/32`. Security groups у Datacenter ### 4. Налаштуйте Firewall на VM [#step-4-firewall] Тепер необхідно захистити віртуальну машину від небажаного трафіку. Для цього відкрийте `VM → Firewall` (правила застосовуються лише до публічного WAN-інтерфейсу). 1. Переведіть перемикач **Global Status** у положення **On**. 2. Змініть **Policy In** на **DROP** — це заблокує весь вхідний трафік, окрім того, який ви явно дозволите. 3. Натисніть **Apply**, щоб застосувати політику. 4. Додайте дозвіл для SSH: натисніть **Insert Security Group** і виберіть групу з кроку 3, або натисніть **Add Rule** і створіть звичайне правило тільки для цієї машини. 5. Тепер ви можете безпечно підключитися до машини через SSH. Firewall VM — Global Status, Policy In і правила ### 5. Увімкніть High Availability (HA) [#step-5-ha] Режим HA автоматично перезапускає віртуальну машину на іншому фізичному сервері, якщо поточний вузол вийде з ладу. Функція надається **безкоштовно** — ви платите лише стандартну вартість vCPU та RAM. 1. Перейдіть до розділу `Datacenter → High Availability`. 2. Увімкніть перемикач **HA** для вашої віртуальної машини. 3. За потреби створіть **правило взаємного розміщення (affinity rule)**, щоб визначити, чи повинні певні VM працювати на одному сервері чи обов'язково на різних. 4. Поточний статус HA можна перевірити на вкладці `Summary` у налаштуваннях VM. High Availability у Datacenter ### 6. Створіть Backup Job [#step-6-backup-job] Автоматичні розклади (backup jobs) — основний інструмент для регулярного збереження стану ваших VM. За замовчуванням у проєкті можна створити **1** розклад, до якого можна додати кілька машин. 1. Відкрийте `Backup → Jobs`. 2. Натисніть **Create backup job**. 3. Вкажіть **Job name** (наприклад, `Production VMs`) і переконайтеся, що перемикач **Enabled** активовано. 4. Оберіть дні тижня для бекапу (потрібен хоча б один день). Резервне копіювання запускається в дозволеному часовому вікні **00:00–06:00**. 5. Налаштуйте **Retention**: для типової VM достатньо **Keep daily = 7**. 6. У таблиці **Virtual machines** виберіть вашу VM і натисніть **Save**. Create backup job — діалог ## Зверніть увагу [#зверніть-увагу] * Поки ви не активуєте Firewall (крок 4), ваша VM з публічним IP буде повністю відкрита для інтернету на всіх портах. Налаштуйте мережевий екран одразу, перш ніж розміщувати на машині важливі дані або сервіси. * Якщо ви зупините VM, кошти за CPU та RAM більше не зніматимуться. Проте ви продовжуєте платити за зарезервований диск, закріплений Floating IP, бекапи та Cloud Gateway. * HA захищає від апаратних збоїв (перезапуск зазвичай займає до хвилини), але не від збоїв всередині ОС. Для захисту даних потрібні бекапи (крок 6). * За бекапи ви платите лише за реальний об'єм у сховищі (on-disk) після стиснення та дедуплікації — див. [Datastore](/uk/docs/cloud/backup/datastore). ## Наступні кроки [#наступні-кроки] Детальний опис усіх параметрів форми створення. Як користуватися SSH та emergency-консоллю noVNC. Налаштування автоматичних бекапів для вашої VM. Забезпечення високої доступності та налаштування правил affinity. # Вступ (/uk/docs/cloud) Цей розділ містить всю необхідну інформацію для роботи з публічною хмарою hostd — від створення першої віртуальної машини до налаштування мережі та бекапів. Детальний огляд технологічного стеку, архітектури та заліза платформи. Покроковий гайд зі створення безпечної VM. Організація ресурсів на рівні акаунта та проєктів, режими процесора та ліміти за замовчуванням. Управління командою, моніторинг витрат та ліміти. Створення, підключення, зміна розміру, перевстановлення, snapshot, backup та видалення. Публічні IP-адреси, PTR-записи, приватні мережі та external VLAN. Налаштування NAT, port forwarding, WireGuard та reverse proxy. Розклади резервного копіювання, datastore та відновлення файлів. Керування задачами, security groups, High Availability (HA) та доступом. Prepaid і postpaid моделі, виставлення рахунків та вартість ресурсів. ## Зверніть увагу [#зверніть-увагу] * Публічна хмара — це IaaS (інфраструктура як послуга). Ми забезпечуємо роботу фізичного обладнання, віртуалізації та мережі, а керування операційною системою та застосунками здійснюється на вашому боці. # Ресурси та ліміти (/uk/docs/cloud/public-cloud-overview) На цій сторінці наведено детальну інформацію про організацію акаунта та проєктів, особливості та вагу режимів vCPU, а також діючі ліміти за замовчуванням. ## Організація ресурсів [#організація-ресурсів] Управління інфраструктурою у хмарі поділяється на два логічні рівні: **акаунт** та **проєкти**. | Рівень управління | Що містить | | ----------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Акаунт** | Загальні налаштування профілю, фінансовий баланс та загальний ліміт vCPU (розподіляється між усіма проєктами). | | **Проєкт** | Віртуальні машини, локальні мережі (VLAN), зарезервовані публічні IP, шлюзи Cloud Gateway, сховище бекапів (PBS datastore), правила доступу команди та погодинна деталізація витрат. | Послуги публічної хмари тарифікуються **погодинно в польських злотих (PLN)**. Ми пропонуємо дві моделі оплати: * **Prepaid** (передоплата) — кошти списуються щогодини з вашого балансу. Доступне налаштування автопоповнення балансу з картки (auto-reload). * **Postpaid** (післяплата) — оплата за фактично спожиті ресурси. Ви отримуєте один загальний рахунок на початку кожного місяця за попередній період (вимагає окремого погодження). Детальніше про моделі оплати дивіться у розділі [Моделі billing](/uk/docs/cloud/billing/models). ## Режими CPU [#режими-cpu] Створюючи віртуальну машину або змінюючи її розмір, ви обираєте **CPU mode** та кількість **vCPU**. Кількість vCPU визначає, скільки віртуальних ядер "бачить" операційна система гостя. Натомість режим CPU визначає **загальний максимальний ліміт** процесорного часу, який VM сумарно може використовувати на фізичному хості. Одне повністю завантажене vCPU відповідає **100%** часу одного фізичного ядра. | Режим процесора | Сумарний ліміт CPU для VM | | --------------- | --------------------------------------------------------------------------------------- | | **Performance** | До **100%** на кожне vCPU (наприклад, 4 vCPU = до **400%** процесорного часу) | | **Eco** | До **50%** на кожне vCPU (наприклад, 4 vCPU = до **200%** процесорного часу) | | **Slim** | До **25%** на кожне vCPU (наприклад, 4 vCPU = до **100%** процесорного часу) | *Приклад роботи в Eco з 4 vCPU (ліміт 200%):* Віртуальна машина може використовувати будь-яку комбінацію навантаження в межах ліміту — наприклад, завантажити всі чотири віртуальні ядра на 50% кожне, або два віртуальні ядра на повні 100% (поки інші два ядра простоюють). Сумарне споживання фізичного процесора при цьому ніколи не перевищить 200%. Обраний режим CPU також визначає, скільки ресурсів VM споживає з глобального ліміту вашого акаунта. ## Ліміти (за замовчуванням) [#ліміти-за-замовчуванням] Для захисту від неконтрольованих витрат на нових акаунтах діють базові стартові ліміти. Якщо вашому бізнесу потрібно більше ресурсів, будь ласка, надішліть запит до нашої служби підтримки. ### Ліміти акаунта [#ліміти-акаунта] | Ресурс | Ліміт за замовчуванням | | ---------------------------------------- | ----------------------------------------- | | Проєктів у межах однієї зони | **5** | | Загальний бюджет vCPU на акаунті | **16** (в еквіваленті режиму Performance) | | Максимальна кількість vCPU для однієї VM | **16** | Окремого ліміту на кількість віртуальних машин немає — діє бюджет vCPU та похідні квоти RAM і диска. Бюджет vCPU є спільним для всіх проєктів акаунта та розраховується з урахуванням ваги режимів: | CPU mode | Вага одного vCPU | | ----------- | ---------------- | | Performance | **1** | | Eco | **0.5** | | Slim | **0.25** | *Приклад використання бюджету 16 vCPU:* Ви можете створити 16 vCPU у режимі Performance, або 32 vCPU у режимі Eco, або 64 vCPU у режимі Slim (чи будь-яку іншу комбінацію в межах ліміту). Абсолютна кількість ядер на одній VM при цьому обмежена значенням 16. ### Ліміти проєкту [#ліміти-проєкту] | Ресурс | Ліміт за замовчуванням | | --------------------------------------------- | ----------------------------------------------------------------- | | Приватні мережі (VLAN) | **1** | | Завдання автоматичних бекапів (Backup jobs) | **1** | | Загальна оперативна пам'ять (RAM) для всіх VM | Бюджет vCPU акаунта × **6** GiB (за замовчуванням **96** GiB) | | Загальний об'єм дисків (NVMe) для всіх VM | Бюджет vCPU акаунта × **100** GiB (за замовчуванням **1600** GiB) | ### Ліміти віртуальної машини (VM) [#ліміти-віртуальної-машини-vm] | Ресурс | Межі та кроки | | ----------------------------------------------- | -------------------------------------------------------------------- | | Кількість vCPU | Від **2** до ліміту (збільшується з кроком у **2**) | | Оперативна пам'ять (RAM) | Від **vCPU × 1** до **vCPU × 6** GiB | | Системний диск | Від **vCPU × 10** до **vCPU × 100** GiB (з кроком ×10) | | Користувацькі снапшоти (Snapshots) | **1** одночасно на кожну VM | | Кількість приватних мережевих інтерфейсів (LAN) | До **8** інтерфейсів (для кожного потрібна створена приватна мережа) | | SSH-ключі при створенні | До **5** ключів | *Зверніть увагу: зменшувати конфігурацію VM (vCPU, RAM або переходити на нижчий CPU mode) можна не частіше ніж один раз на день для кожної машини. Зниження vCPU та RAM потребує обов'язкової зупинки сервера. Детальніше дивіться у розділі [Resize VM](/uk/docs/cloud/virtual-machines/resize).* ### Мережеві ліміти та правила [#мережеві-ліміти-та-правила] | Характеристика | Ліміт або правило | | ----------------------- | ------------------------------------------------------------------------------------------------------------------- | | Публічний IPv4 | Зворотний DNS (PTR-запис) можна легко змінити безпосередньо в порталі. | | IPv6 | Заплановано до впровадження. | | Приватні мережі | За замовчуванням **1** на проєкт (підтримується лише адресація IPv4). | | External VLAN | Інтерфейс підключення є в UI, але для конфігурації необхідно звернутися до підтримки. | | Пропускна здатність WAN | 100 / 200 / 300 / 400 Mbps для VM із 2–7 / 8–15 / 16–23 / 24+ vCPU відповідно. | | Пропускна здатність LAN | 2 / 3 / 4 / 5 Gbps для тих самих рівнів vCPU (точні показники вказані у формі створення VM). | | Firewall VM | Фільтрує тільки публічний інтерфейс WAN. У правилах дозволено використовувати підмережі (CIDR) максимум до **/26**. | ## Наступні кроки [#наступні-кроки] Детальний огляд архітектури та заліза хмари. Покроковий запуск вашої першої VM. Ізоляція локального трафіку. # Storage (/uk/docs/cloud/storage) У розділі **Storage** ви можете контролювати використання дискового простору, виділеного під системні диски ваших віртуальних машин. Нижче також описані ліміти продуктивності кожного віртуального диска. ## Особливості використання сховища [#особливості-використання-сховища] * Наразі в порталі відображається детальна статистика щодо об'ємів віртуальних дисків у режимі перегляду (read-only). * Збільшити дисковий простір для системного диска будь-якої віртуальної машини ви можете у будь-який момент на вкладці [Resize VM](/uk/docs/cloud/virtual-machines/resize) (це працює без вимкнення та перезавантаження машини). * Системні диски VM працюють на розподіленому all-flash NVMe — деталі архітектури в [Можливості платформи](/uk/docs/cloud/capabilities). ## Ліміти продуктивності диска [#ліміти-продуктивності-диска] Кожен віртуальний диск має на рівні гіпервізора фіксовані ліміти IOPS і пропускної здатності. Значення однакові для всіх VM і їх не можна змінити в порталі. | Ліміт | Значення | | --------------------------- | ------------- | | IOPS читання | **20 000** | | IOPS запису | **20 000** | | Пропускна здатність читання | **1000 MB/s** | | Пропускна здатність запису | **1000 MB/s** | ## Зверніть увагу [#зверніть-увагу] Можливість створювати та підключати додаткові віртуальні диски до однієї машини наразі перебуває у розробці. Якщо вам потрібно розширити простір для збереження даних прямо зараз, збільште розмір вашого основного системного диска через форму зміни ресурсів. # Get an IP address (/uk/docs/api/ip-addresses/get-ip-address) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # List IP addresses (/uk/docs/api/ip-addresses/list-ip-addresses) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # Update PTR record (/uk/docs/api/ip-addresses/update-ptr-record) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # Get account usage (/uk/docs/api/public-cloud/get-account-usage) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # Get a cluster (/uk/docs/api/public-cloud/get-cluster) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # Get a project (/uk/docs/api/public-cloud/get-project) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # List clusters (/uk/docs/api/public-cloud/list-clusters) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # List project resource usage (/uk/docs/api/public-cloud/list-project-resource-usage) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # List project tasks (/uk/docs/api/public-cloud/list-project-tasks) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # List projects (/uk/docs/api/public-cloud/list-projects) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # Datastore (/uk/docs/cloud/backup/datastore) Тут ви можете переглядати наявні бекапи, перевіряти скільки місця вони займають, встановлювати захист на важливі копії або видаляти непотрібні. Backup Datastore — статистика та список volumes ## Кроки [#кроки] 1. Відкрийте `Backup → Datastore`. 2. Знайдіть у списку потрібну віртуальну машину. 3. Розгорніть її, щоб побачити конкретні копії (volumes). Ви зможете перевірити номінальний (logical) та фактичний (on-disk) розмір, а також дату створення. 4. Якщо якась копія є критично важливою, увімкніть для неї **protection**. Це захистить її від автоматичного або випадкового видалення. 5. Видаляйте копії вручну лише тоді, коли ви абсолютно впевнені, що ці дані більше не потрібні. З меню рядка групи VM можна також **Delete all backups** (видалити всі копії цієї машини). 6. **File restore** на вибраній копії дозволяє переглядати й завантажувати окремі файли (без повного restore VM). ## Зверніть увагу [#зверніть-увагу] Для видалення захищеного (protected) бекапу спочатку зніміть із нього захист. Пам'ятайте, що якщо ви видаляєте віртуальну машину, але залишаєте її бекапи, простір для їхнього зберігання продовжуватиме тарифікуватися. Повний restore VM — у `VM → Backups`; ця сторінка — для керування копіями та file restore. ## Наступні кроки [#наступні-кроки] налаштування розкладів. завантаження окремих файлів. як видалити машину разом з бекапами. # Відновлення файлів (/uk/docs/cloud/backup/file-restore) Якщо ви випадково видалили кілька файлів і не хочете відкочувати стан усієї системи, ви можете завантажити окремі файли чи папки прямо з бекапу. Відновлення файлів — дерево файлів ## Кроки [#кроки] 1. Відкрийте `Backup → Datastore`. 2. Знайдіть потрібну копію бекапу і натисніть **File restore**. 3. Відкриється файлове дерево вашої системи — ви можете розгортати папки і шукати потрібні дані. 4. Знайшовши файл або папку, натисніть на відповідну кнопку, щоб завантажити їх (папки завантажаться як архів). ## Зверніть увагу [#зверніть-увагу] Цей інструмент чудово підходить для завантаження конфігураційних файлів чи невеликих директорій (приблизно до **200 MB**). Якщо вам потрібно дістати величезну базу даних або повний архів машини, краще скористатися повноцінним відновленням VM або звернутися до [support](https://hostd.cloud/contact). ## Наступні кроки [#наступні-кроки] відновлення всієї системи. перегляд наявних бекапів. налаштування автоматичних розкладів. # Backup (/uk/docs/cloud/backup) Тут зібрані інструкції щодо резервного копіювання ваших віртуальних машин: від налаштування регулярних розкладів до відновлення окремих файлів. Налаштування розкладів (дні тижня, часове вікно) та політики зберігання (retention). Перегляд наявних бекапів, захист від випадкового видалення та статистика. Завантаження окремих файлів або папок без повного відкату віртуальної машини. Повне відновлення віртуальної машини зі збереженої копії. ## Зверніть увагу [#зверніть-увагу] Інфраструктура платформи забезпечує надійне зберігання бекапів, але налаштування розкладів та регулярне тестування відновлення залишаються вашою відповідальністю. Радимо періодично перевіряти, чи коректно відновлюються ваші дані. # Backup jobs (/uk/docs/cloud/backup/jobs) Автоматичні розклади (backup jobs) є основним інструментом для регулярного та безперервного збереження стану обраних віртуальних машин у вашому проєкті за заданим графіком. Create backup job — діалог ## Кроки [#кроки] 1. Відкрийте `Backup → Jobs`. 2. Натисніть **Create backup job** (або відредагуйте вже існуючий). 3. Заповніть налаштування розкладу та політики зберігання (деталі нижче). 4. Виберіть потрібні віртуальні машини у таблиці **Virtual machines** та натисніть **Create**. 5. У списку машин можуть бути попередження для тих VM, які ще не захищені бекапами — радимо їх також додати. ## Налаштування в Create backup job [#налаштування-в-create-backup-job] **General** * **Enabled** — дозволяє тимчасово вимкнути виконання розкладу без видалення самих налаштувань. * **Job name** — зручна для вас назва (наприклад, `Production VMs`). * **Backup time window** — проміжок часу, коли системі дозволено починати бекап (наразі це **00:00–06:00**). **Schedule** * Оберіть дні тижня, у які має виконуватися бекап (потрібен хоча б один день). **Retention** Цей блок керує тим, скільки копій зберігатиметься у сховищі. Коли ліміт перевищується, найстаріші копії видаляються автоматично. Якщо залишити поле порожнім або вписати **0**, цей рівень зберігання вимикається. * **Keep daily** — скільки останніх щоденних копій зберігати (наприклад, **7** — це історія за останній тиждень). * **Keep weekly** — скільки тижневих зрізів залишати (наприклад, **4** — це історія приблизно за місяць). * **Keep monthly** / **Keep yearly** — довгострокове зберігання. Використовуйте лише якщо це дійсно потрібно, оскільки це збільшує витрати на дисковий простір. **Як краще налаштувати:** Для типової машини достатньо стандартних **7** daily і **4** weekly. Для тестових середовищ вистачить **3** daily і **0** weekly. ## Вартість backup storage [#вартість-backup-storage] Бекапи створюються **інкрементально** та проходять **дедуплікацію**. Тому в розділі `Backup → Datastore` ви побачите два значення: * **Logical** — повний номінальний розмір усіх копій. * **On-disk** — реальний розмір на диску після стиснення та дедуплікації. Ви платите **тільки за реальний (on-disk) об'єм** у гігабайтах (GiB). **Ілюстративний приклад:** У вас є віртуальна машина з диском на **100 GiB**, на якій реально зайнято лише **50 GiB**, а щоденні зміни складають близько **5 GiB** даних. Якщо ви налаштуєте щоденний бекап із **Keep daily = 7**, то перший повний бекап займе лише фактично використане місце — близько **50 GiB** (а не весь номінальний розмір диска 100 GiB). Усі наступні дні додаватимуть лише по \~5 GiB змінених даних. Тобто за тиждень у вас зберігатиметься 7 копій, але на диску вони займатимуть близько **80 GiB** (50 + 6×5), а не 700 GiB. Якщо ви збільшите ліміт до 30 днів, об'єм зросте приблизно до **195 GiB** (50 + 29×5). Завжди перевіряйте показник **on-disk** перед суттєвим збільшенням політики Retention. ## Зверніть увагу [#зверніть-увагу] За замовчуванням у проєкті можна створити лише **1** розклад (backup job), але в нього можна додати безліч машин. Також пам'ятайте, що наявність бекапу не звільняє від необхідності перевіряти, чи можете ви з нього успішно відновитися. ## Наступні кроки [#наступні-кроки] керування створеними бекапами. як відновити VM. де подивитися витрати. # Billing (/uk/docs/cloud/billing) Інфраструктура публічної хмари тарифікується **погодинно в польських злотих (PLN)**. Ви платите за виділені ресурси: vCPU, оперативну пам'ять, дисковий простір, публічні IPv4, Cloud Gateway та місце для бекапів. Керувати балансом можна в панелі [`Billing`](https://hostd.cloud/app/settings/billing), а рахунки переглядати й оплачувати в [`Invoices`](https://hostd.cloud/app/settings/invoices). Як працюють моделі Prepaid та Postpaid і чим вони відрізняються. Коли ми виставляємо рахунки та що саме в них входить. За які ресурси ви продовжуєте платити, навіть якщо вимкнули сервер. # Рахунки (/uk/docs/cloud/billing/invoices) Усі ваші рахунки можна переглянути або завантажити у форматі PDF в панелі [`Invoices`](https://hostd.cloud/app/settings/invoices). Там само їх можна оплатити онлайн. Графік виставлення рахунків залежить від вашої моделі оплати. ## Prepaid (передоплата) [#prepaid-передоплата] У цій моделі ви поповнюєте баланс наперед, а вартість послуг списується з нього щогодини. Рахунок з урахуванням ПДВ (VAT) генерується **в момент кожного поповнення балансу** (у рахунку це вказано як *Doładowanie salda rozliczeniowego*). Поточне щоденне споживання ресурсів нових рахунків не створює. ## Postpaid (післяплата) [#postpaid-післяплата] У цій моделі ви платите за фактичне споживання за минулий період. Один загальний рахунок з урахуванням ПДВ виставляється **на початку кожного місяця**. * Кожен ваш проєкт відображається в рахунку окремим рядком: `Public Cloud {uuid} | {project name}` зі зведеним обсягом споживання ресурсів (години vCPU, RAM, диску тощо). * Якщо сума до сплати становить менше ніж **1 PLN net**, рахунок не генерується. * Якщо у вас є компенсаційний кредит або знижка, вони відображаються як окремий рядок **Rabat** з вказанням причини. ### Як оплатити рахунок [#як-оплатити-рахунок] Ви можете оплатити рахунки банківським переказом (реквізити вказані у самому PDF-файлі) або онлайн прямо в порталі за допомогою картки, Apple Pay чи Google Pay. Для зручності можна увімкнути функцію **auto-pay**, щоб система автоматично списувала кошти зі збереженої картки в день виставлення рахунка. ## Наступні кроки [#наступні-кроки] детальніше про логіку оплати. перевірка детальної статистики витрат. # Моделі billing (/uk/docs/cloud/billing/models) Платформа нараховує витрати **погодинно** за всі виділені вашому проєкту ресурси (навіть якщо вони не завантажені на 100%). Ваш акаунт може працювати за однією з двох моделей оплати, і ця модель застосовується до всіх ваших проєктів одночасно. | | **Prepaid** (за замовчуванням) | **Postpaid** | | ------------- | --------------------------------------- | ---------------------------------------- | | Оплата | Наперед — з балансу акаунта | Після факту — щомісячний рахунок | | Облік | Погодинне списання коштів з балансу | Погодинна фіксація використаних ресурсів | | Рахунок | Одразу після кожного поповнення балансу | На початку місяця за попередній місяць | | Автоматизація | Auto-reload (автоматичне поповнення) | Auto-pay (автоматична оплата рахунків) | ## Prepaid (передоплата) [#prepaid-передоплата] Ця модель вмикається автоматично після реєстрації. Ви поповнюєте баланс у панелі Billing, і вартість використаних ресурсів щогодини віднімається від цієї суми. * **Поповнення** — мінімальна сума складає **50 PLN net** (максимальна — 2000 PLN). Оплатити можна карткою, Apple Pay або Google Pay. ПДВ (VAT) додається в момент оплати. * **Auto-reload** — дуже зручна функція, яка дозволяє автоматично поповнювати баланс зі збереженої картки, коли він опускається нижче визначеного порогу. * Якщо на вашому балансі є бонусні або промо-кошти, система завжди списуватиме ресурси спочатку з них, а вже потім із ваших реальних грошей. ## Postpaid (післяплата) [#postpaid-післяплата] Ця модель дозволяє користуватися послугами без передоплати та отримувати рахунок за фактом використання. Щоб перейти на неї, потрібно відправити запит до підтримки через кнопку **Request contract billing** у панелі Billing. * На початку кожного місяця ви отримуєте один рахунок за всі ресурси, спожиті у попередньому місяці. * Якщо для вашого акаунта погоджена **індивідуальна знижка**, вона автоматично враховується у погодинних нарахуваннях. * **Auto-pay** — дозволяє автоматично оплачувати виставлені рахунки зі збереженої картки. * У цій моделі поточну заборгованість видно в режимі реального часу, але функція прямого поповнення балансу відключається, оскільки ви просто оплачуєте виставлені рахунки. ### Компенсаційний кредит [#компенсаційний-кредит] У випадках збоїв або як жест лояльності hostd може надати вам одноразовий кредит. Він автоматично зменшить ваші майбутні рахунки (відображається як позиція **Rabat**). Такий кредит може покрити до **75%** суми одного рахунка, а невикористаний залишок переноситься на наступні місяці. ## Наступні кроки [#наступні-кроки] деталі про виставлення рахунків. за що ви платите, коли машина вимкнена. поточна статистика споживання. # Вартість зупиненої VM (/uk/docs/cloud/billing/stopped-vm-costs) Зупинка (Stop) віртуальної машини припиняє тарифікацію обчислювальних ресурсів (**vCPU** та **RAM**). Проте всі інші зарезервовані ресурси продовжують тарифікуватися погодинно, оскільки платформа продовжує зберігати їх за вами. | Ресурс | Тарифікується для зупиненої VM? | | ---------------------------- | ------------------------------- | | vCPU і RAM | Ні | | Системний диск (storage) | Так | | Floating IP (публічний IPv4) | Так | | PBS backup storage | Так | Тому зупинена віртуальна машина **не дорівнює нульовій вартості**. Якщо ви хочете повністю припинити тарифікацію, наприклад, диска чи публічного IP, вам необхідно безповоротно видалити віртуальну машину (разом з диском) або звільнити IP-адресу з проєкту. Ви завжди можете перевірити погодинну розбивку витрат на сторінці `Datacenter → Resource usage` (доступно лише власнику акаунта). ## Наступні кроки [#наступні-кроки] як видалити машину та перестати платити. керування публічними адресами. логіка списання коштів. # Cloud Gateway (/uk/docs/cloud/cloud-gateway) Cloud Gateway — це керований маршрутизатор, який hostd автоматично розгортає для вашої приватної мережі. Він дозволяє налаштовувати NAT, port forwarding, WireGuard VPN та reverse proxy. ## Що це таке? [#що-це-таке] Це повністю ізольована віртуальна машина-маршрутизатор. Її головна відмінність від ваших звичайних VM — **ви не маєте до неї доступу по SSH або через консоль**. Усі налаштування виконуються виключно через інтерфейс порталу hostd, а інфраструктура застосовує їх автоматично під капотом. Для забезпечення надійності Cloud Gateway працює з увімкненим **High Availability (HA)** одразу після створення. Якщо фізичний сервер, на якому він працює, виходить з ладу, система автоматично перезапустить маршрутизатор на іншому вузлі (зазвичай це займає до хвилини). Вам не потрібно налаштовувати HA для нього вручну. ## Коли це потрібно [#коли-це-потрібно] Cloud Gateway знадобиться, коли машини в приватній мережі **не мають власних публічних IP**, а вам потрібно: * вихід в інтернет (NAT) через WAN-адресу шлюзу; * доступ з інтернету до окремих сервісів на VM (port forwarding); * безпечний доступ адміністраторів до приватної мережі (WireGuard); * публікація HTTP/HTTPS з сертифікатом Let's Encrypt (reverse proxy). Якщо достатньо ізольованого VLAN без маршрутизації в інтернет — Cloud Gateway можна вимкнути або видалити в будь-який момент. ## Як увімкнути Cloud Gateway [#як-увімкнути-cloud-gateway] Ви можете активувати його під час створення нової приватної мережі (`Network → Private networks → New` → **Enable Cloud Gateway**) або додати пізніше до вже існуючого VLAN (за допомогою кнопки **Enable Cloud Gateway** у меню мережі). Для мереж типу Internal VLAN шлюз увімкнено за замовчуванням під час створення. Маршрутизатор автоматично займе IP-адресу **`.1`** у вашій підмережі і працюватиме як шлюз за замовчуванням (default gateway) для всіх підключених до неї VM. Тому переконайтеся, що ця адреса вільна. Публічну IPv4-адресу шлюзу можна призначити автоматично (перша вільна з пулу) або вибрати серед уже зарезервованих у проєкті. Публічний IP тарифікується окремо від самої послуги Cloud Gateway. Створення приватної мережі з Cloud Gateway ## Сервіси [#сервіси] Після запуску шлюзу в порталі налаштовуєте: Прокидання портів з публічної адреси маршрутизатора на внутрішні адреси ваших VM. Безпечний VPN-доступ до приватної мережі для ваших адміністраторів чи розробників. Налаштування HTTP/HTTPS проксі з автоматичним отриманням сертифікатів Let's Encrypt. ## Зверніть увагу [#зверніть-увагу] Ви можете повністю видалити Cloud Gateway у будь-який момент, щоб припинити його тарифікацію. Сама приватна мережа (VLAN) при цьому не видалиться, а ваші VM продовжуватимуть бачити одна одну в локальній мережі. # Port forwarding (/uk/docs/cloud/cloud-gateway/port-forwarding) Port forwarding (DNAT) дозволяє приймати трафік на публічному IP-адресі вашого Cloud Gateway і автоматично перенаправляти його на конкретну віртуальну машину всередині приватної мережі. Port forwarding — правило DNAT ## Кроки [#кроки] 1. Відкрийте вашу приватну мережу та перейдіть до розділу **Port forwards**. 2. Натисніть **Add** і вкажіть параметри: протокол, публічний порт на маршрутизаторі, а також внутрішню IP-адресу та порт (backend) цільової VM. 3. Натисніть **Save**, щоб зберегти правило. 4. Перевірте підключення ззовні. ## Зверніть увагу [#зверніть-увагу] Якщо ви плануєте використовувати [Reverse proxy](/uk/docs/cloud/cloud-gateway/reverse-proxy), пам'ятайте, що TCP-порти **80** та **443** будуть зарезервовані для нього і не зможуть використовуватися для звичайного port forwarding. У такому разі використовуйте інші публічні порти або налаштовуйте проксіювання трафіку. ## Наступні кроки [#наступні-кроки] маршрутизація HTTP-трафіку. налаштування VPN. керування локальною мережею. # Reverse proxy (/uk/docs/cloud/cloud-gateway/reverse-proxy) Ви можете використовувати Cloud Gateway як reverse proxy (на базі Caddy), який прийматиме HTTP та HTTPS трафік і направлятиме його на ваші бекенд-сервери. Він автоматично отримує та оновлює безкоштовні SSL-сертифікати від Let's Encrypt для ваших доменів. Reverse proxy — vhost і backend ## Кроки [#кроки] 1. У панелі вашого DNS-провайдера створіть **A-запис** (A record), який направить ваш домен на публічну IP-адресу Cloud Gateway. 2. У порталі hostd відкрийте вкладку **Reverse proxy** в налаштуваннях вашої приватної мережі та **увімкніть** цей сервіс. 3. Додайте ваш домен (hostname) та вкажіть приватну IP-адресу й порт вашої цільової VM (backend). 4. Натисніть **Save** для збереження конфігурації. 5. Спробуйте відкрити ваш домен у браузері через HTTPS. Якщо А-запис налаштовано правильно, система автоматично згенерує SSL-сертифікат під час першого відвідування сайту. ## Зверніть увагу [#зверніть-увагу] Керування прямими DNS-записами (A-записами) вашого домену здійснюється на стороні вашого DNS-провайдера. Зверніть увагу: увімкнення сервісу Reverse proxy повністю резервує за собою TCP-порти **80** і **443**, а також UDP-порт **443** на Cloud Gateway, що виключає їхнє використання для прямого port forwarding. ## Наступні кроки [#наступні-кроки] налаштування PTR-записів. прямий проброс портів. # WireGuard (/uk/docs/cloud/cloud-gateway/wireguard) WireGuard дозволяє створити безпечний VPN-канал між вашим комп'ютером та приватною мережею в хмарі. Це ідеально підходить для адміністративного доступу до баз даних або внутрішніх сервісів без виставлення їх в інтернет. WireGuard — огляд сторінки ## Кроки [#кроки] 1. У налаштуваннях вашої приватної мережі перейдіть на вкладку **WireGuard**. 2. Якщо сервер ще не налаштовано, натисніть **Set up WireGuard server** (або **Enable**, якщо він був вимкнений). 3. Натисніть **Add peer** і введіть зрозумілу назву для вашого пристрою (наприклад, "Ноутбук адміна"). 4. У списку пірів (peers) відкрийте меню **Peer config**. Ви можете відсканувати QR-код за допомогою мобільного додатка WireGuard або натиснути **Download**, щоб зберегти файл конфігурації (`.conf`) для десктопного клієнта. 5. Імпортуйте файл у клієнт WireGuard, підключіться та перевірте доступ (наприклад, пінгом приватної IP-адреси будь-якої вашої VM). Peer config — QR-код і завантаження ## Зверніть увагу [#зверніть-увагу] Завантажена конфігурація налаштована так, що через VPN маршрутизується **лише трафік до вашої приватної мережі** (split tunneling). Увесь ваш звичайний інтернет-трафік (веб-серфінг, YouTube) ітиме як завжди, не навантажуючи Cloud Gateway. ## Наступні кроки [#наступні-кроки] налаштування VLAN. проброс портів. проксіювання HTTP(S). # High Availability (HA) (/uk/docs/cloud/datacenter/high-availability) Режим High Availability (HA) автоматично захищає ваші віртуальні машини від апаратних збоїв. Якщо фізичний сервер, на якому працює машина, вийде з ладу, платформа самостійно перезапустить її на іншому робочому сервері. ## Кроки [#кроки] 1. Перейдіть до розділу `Datacenter → High Availability`. 2. Увімкніть перемикач **HA** для потрібної віртуальної машини. 3. За потреби створіть **affinity rule** (правило взаємного розміщення), щоб визначити, чи повинні певні VM працювати на одному фізичному сервері чи обов'яково на різних. 4. Перевірити поточний статус HA завжди можна на вкладці Summary у налаштуваннях конкретної VM. ## Зверніть увагу [#зверніть-увагу] * Перезапуск віртуальної машини на іншому сервері у разі збою зазвичай займає **до однієї хвилини**. Зверніть увагу, що це апаратний перезапуск (аналогічно увімкненню після збою живлення), тому він не захищає від внутрішніх збоїв самої операційної системи. * Функція High Availability надається повністю **безкоштовно** — ви платите лише стандартну погодинну вартість vCPU та RAM вашої машини. * Кожне правило affinity може об'єднувати від **2 до 3 VM**. Одна віртуальна машина може належати лише до одного правила розміщення. # Datacenter (/uk/docs/cloud/datacenter) Розділ **Datacenter** об'єднує інструменти для контролю та налаштування вашої хмари на рівні всього проєкту. Перегляд історії операцій, статусів виконання та помилок. Створення та налаштування шаблонів правил міжмережевого екрана (firewall). Активація високої доступності для віртуальних машин та налаштування правил взаємного розміщення (affinity rules). Управління учасниками проєкту та їхніми ролями (через вкладку `Datacenter → Permissions`). Детальний погодинний звіт про споживання ресурсів та фінансові витрати за поточний місяць. ## Зверніть увагу [#зверніть-увагу] Більшість конфігурацій у розділі Datacenter вимагають прав доступу **Admin** або **Superadmin**. Детальна фінансова статистика та розділ білінгу доступні виключно власнику акаунта (**Superadmin**). # IP sets (/uk/docs/cloud/datacenter/ip-sets) IP sets — це іменовані списки адрес IPv4/IPv6 і мереж CIDR. Створіть список один раз, а потім посилайтеся на нього в правилах firewall як **source** або **destination**, замість того щоб повторювати ті самі адреси в кожному правилі. ## Кроки [#кроки] 1. Відкрийте `Datacenter → IP sets`. 2. Натисніть **Add** і введіть коротку латинську назву (до **15** символів). 3. Виберіть IP set і натисніть **Add address**, щоб додати хости або CIDR (IPv4 до **/24**, IPv6 до **/64**). 4. Відкрийте `VM → Firewall` (або правила security group) і створіть чи змініть правило. 5. У полі **Source Address** або **Destination Address** виберіть IP set у **Use IP set…** або введіть вручну `+name`. 6. Надалі зміни членів IP set застосуються скрізь, де цей set використано. ## Зверніть увагу [#зверніть-увагу] * IP set впливає на трафік лише тоді, коли правило firewall його використовує, а firewall VM увімкнено (**Global Status** = **On** у `VM → Firewall`). * Прямий CIDR у правилі як і раніше обмежений **/26**; члени IP set можуть бути IPv4 до **/24** або IPv6 до **/64**. * Видалення IP set очищає посилання на нього в правилах, які його використовували. # Resource usage (/uk/docs/cloud/datacenter/resource-usage) Вкладка **Resource usage** дозволяє власнику проєкту (Superadmin) детально відстежувати погодинні витрати у польських злотих (PLN) за кожним типом задіяних ресурсів. Resource usage — погодинні витрати ## Кроки [#кроки] 1. Відкрийте `Datacenter → Resource usage` (цей розділ бачить лише власник проєкту). 2. Ознайомтеся з погодинною розбивкою витрат за основними категоріями: процесори (compute), оперативна пам'ять (RAM), диски (storage), **публічні IPv4**, бекапи та Cloud Gateway. 3. Порівняйте ці дані з активними сервісами у вашому проєкті, щоб розуміти структуру витрат. 4. Для оплати та перегляду закриваючих документів перейдіть до розділу `Billing`. ## Зверніть увагу [#зверніть-увагу] * Колонка **Public IPv4** рахує та тарифікує **лише адреси IPv4**. Публічний IPv6 не тарифікується окремим рядком IP. * Дані на цій сторінці призначені для внутрішнього моніторингу та планування бюджету. Вони оновлюються щогодини, але не є фінансовим чи бухгалтерським документом (офіційні рахунки формуються виключно в розділі `Billing`). # Security groups (/uk/docs/cloud/datacenter/security-groups) Групи безпеки (Security Groups) — це шаблони правил фільтрації трафіку. Вони дозволяють налаштувати правила доступу (наприклад, відкрити порти для веб-сервера чи обмежити доступ до бази даних) один раз і швидко застосовувати їх до багатьох віртуальних машин. ## Кроки [#кроки] 1. Відкрийте розділ `Datacenter → Security groups`. 2. Натисніть **Create group** та введіть коротку латинську назву групи (до **15** символів). 3. Додайте потрібні правила для вхідного (**IN**) або вихідного (**OUT**) трафіку всередині створеної групи. 4. Перейдіть до налаштувань потрібної віртуальної машини на вкладку `VM → Firewall` та натисніть кнопку **Insert Security Group**, щоб підключити створений шаблон правил. 5. Надалі будь-які зміни, внесені вами в групу безпеки в розділі Datacenter, автоматично застосуються до всіх підключених віртуальних машин. ## Зверніть увагу [#зверніть-увагу] Група безпеки почне фільтрувати трафік віртуальної машини лише тоді, коли ви підключите її до цієї VM і переконаєтеся, що мережевий екран увімкнений (перемикач **Global Status** встановлено в положення **On** у налаштуваннях `VM → Firewall`). # Задачі (/uk/docs/cloud/datacenter/tasks) Журнал задач відображає історію всіх інфраструктурних операцій у вашому проєкті (таких як створення віртуальних машин, зміна їхніх розмірів, увімкнення та вимкнення тощо). Це допомагає бачити, хто з учасників команди запустив певну дію та в якому статусі вона перебуває. Задачі — історія задач проєкту Для перегляду журналу відкрийте розділ `Datacenter → Tasks`. Будь-який учасник проєкту, незалежно від його ролі, може бачити детальну таблицю: * **Start Time / End Time** — точний час початку та завершення задачі. * **Опис операції** — яка саме дія виконувалася. * **Status** — поточний статус виконання (`OK`, `running` або опис помилки, якщо щось пішло не так). * **Користувач** — email учасника команди, який запустив задачу. ## Зверніть увагу [#зверніть-увагу] * Цей журнал фіксує лише операції, пов'язані з управлінням хмарою на рівні порталу hostd. Він не відображає системні події чи логи всередині самої операційної системи віртуальної машини. * Завдання автоматичних бекапів за розкладом, а також операції автоматичного перезапуску у разі збоїв (HA) є частиною внутрішньої системної логіки платформи і не відображаються у цій таблиці дій користувачів. # External VLAN (/uk/docs/cloud/networking/external-vlan) **External VLAN** — це послуга, яка дозволяє створити спільне мережеве середовище Layer 2 у вашій зоні (кластері). Завдяки цьому ви можете об'єднати віртуальні машини в хмарі з будь-якою зовнішньою інфраструктурою поза межами нашої платформи. Це дозволяє підключити: * Фізичні виділені сервери (bare metal); * Власні маршрутизатори чи комутатори; * Локальну інфраструктуру (on-premises) через канали зв'язку вашого оператора чи провайдера. На відміну від звичайних приватних мереж, які ви можете створювати та налаштовувати самостійно в порталі, підключення **External VLAN** потребує технічної координації та конфігурації комутаторів з нашого боку. Щоб налаштувати таке з'єднання, зверніться до нашої служби підтримки. # Floating IP (/uk/docs/cloud/networking/floating-ip) Функція Floating IP дозволяє закріплювати та переносити публічні IPv4-адреси між різними ресурсами (віртуальними машинами чи шлюзами Cloud Gateway) всередині вашого проєкту. ## Як це працює [#як-це-працює] У публічній хмарі hostd Floating IP — це **реальна публічна адреса IPv4**, яка прописується безпосередньо на мережевому інтерфейсі вашої VM (наприклад, `net0`) або Cloud Gateway. Це суттєва відмінність від багатьох інших хмарних платформ, де використовується віртуальний 1:1 NAT на рівні мережевого оверлею. У нас весь вхідний трафік доходить до вашої ОС гостя безпосередньо, без зайвих трансляцій чи проміжних проксі-вузлів (proxy hops). Слово **Floating** ("плаваючий") означає, що адреса не прив'язана до життєвого циклу конкретної віртуальної машини. Ви можете зберегти її у проєкті під час видалення сервера і пізніше призначити новій машині чи шлюзу. ## Кроки для збереження та перепризначення [#кроки-для-збереження-та-перепризначення] 1. Відкрийте розділ `Network → Public IPs`, щоб переглянути список ваших адрес. 2. Колі ви видаляєте віртуальну машину чи шлюз, обов'язково **зніміть прапорець** біля пункту **Release public IP address**. Тоді ця IP-адреса залишиться зарезервованою у вашому проєкті. 3. Під час створення нового сервера чи Cloud Gateway у формі налаштувань мережі виберіть вашу зарезервовану адресу зі списку замість опції **Auto**. 4. Якщо ви хочете змінити IP-адресу на вже працюючій VM: перейдіть у `VM → Resize`, вимкніть публічний інтерфейс (`net0`), збережіть налаштування, а потім увімкніть його знову, обравши **Auto** або конкретний зарезервований IP. Перезавантаження системи для цього не потрібне. ## Зверніть увагу [#зверніть-увагу] * Для зміни IP-адреси спочатку тимчасово вимкніть мережевий інтерфейс WAN. * Зарезервовані адреси, що залишаються вільними (без підключення до VM чи Cloud Gateway), продовжують тарифікуватися за стандартною погодинною ставкою, оскільки вони закріплені за вашим проєктом. ## Наступні кроки [#наступні-кроки] огляд мережевих налаштувань. як безпечно видалити машину та зберегти ресурси. # Мережа (/uk/docs/cloud/networking) Цей розділ містить інструкції з налаштування публічних IP-адрес, створення приватних мереж (VLAN) та керування топологією вашого проєкту. Візуальний перегляд топології вашого проєкту, активних підключень та статусів VM. Реальні публічні IPv4-адреси для ваших машин та шлюзів із можливістю збереження та повторного використання. Налаштування зворотних DNS-записів (PTR) для публічних IP-адрес. Створення ізольованих локальних мереж (VLAN) та налаштування внутрішньої IPAM. Підключення виділеного каналу Layer 2 до вашої фізичної або зовнішньої інфраструктури (поза хмарою). Налаштування NAT, WireGuard VPN, port forwarding та reverse proxy на віртуальному маршрутизаторі. ## Зверніть увагу [#зверніть-увагу] Якщо ви хочете перепризначити публічний IP-адрес на іншу віртуальну машину, спочатку вимкніть публічний інтерфейс (WAN) у розділі `VM → Resize`, збережіть налаштування, а потім підключіть інтерфейс знову, вибравши потрібну зарезервовану адресу. Це працює без перезавантаження операційної системи. # Мапа мережі (/uk/docs/cloud/networking/network-map) Вкладка **Мапа мережі** надає наочну логічну схему всієї інфраструктури вашого проєкту, відображаючи зв'язки між публічним інтернетом, Cloud Gateway, приватними мережами та віртуальними машинами. Мапа мережі в порталі ## Що відображається на схемі [#що-відображається-на-схемі] 1. **Вузол WAN** (ліворуч) — показує стан вашого пулу публічних IPv4-адрес: загальну кількість адрес у проєкті, скільки з них використано та скільки залишилося вільними. 2. **Віртуальні машини** (картки) — відображають назву машини, її публічні та приватні IP-адреси, поточний статус живлення, конфігурацію vCPU/RAM та графік навантаження. Клікнувши на назву VM, ви можете швидко перейти до її детальних налаштувань. 3. **Приватні мережі** (кола з назвою **vnet** та CIDR-підмережею) — візуалізують ваші внутрішні VLAN. Усі машини, підключені до локальної мережі, пов'язані лініями з відповідним колом підмережі. 4. **Cloud Gateway** — відображається на стику публічного інтернету та вашої приватної мережі. Клікнувши на назву шлюзу, можна відкрити налаштування WireGuard, reverse proxy чи port forwarding. 5. **Керування живленням та консоль** — на картці кожної запущеної VM є іконка консолі (**Open Console in New Window**), а через меню трьох крапок `⋯` можна швидко виконати перезапуск або зупинку машини. ## Зверніть увагу [#зверніть-увагу] * Ця сторінка призначена виключно для візуального моніторингу та швидкої навігації. Змінювати параметри мереж чи інтерфейсів потрібно у відповідних розділах (наприклад, у `VM → Resize` або в налаштуваннях конкретної приватної мережі). * Анімовані лінії, що йдуть до віртуальних машин, вказують на те, що сервер запущено (статус **running**). Лінії Cloud Gateway анімовані завжди. Це візуальний індикатор активності статусу, а не графік живого трафіку. * Віртуальні машини, які не підключені до жодної мережі, групуються та відображаються окремо у правій частині екрана. ## Наступні кроки [#наступні-кроки] перенесення публічних IP. створення локальних мереж. налаштування послуг шлюзу. # Приватна мережа (/uk/docs/cloud/networking/private-network) Приватна мережа (локальний VLAN) дозволяє об'єднати ваші віртуальні машини в ізольований мережевий сегмент Layer 2. Трафік у такій мережі повністю захищений від стороннього доступу і не тарифікується. Приватна мережа — список і схема VLAN ## Кроки [#кроки] 1. Відкрийте розділ `Network → Private networks`. 2. Натисніть **New** та створіть внутрішній VLAN, вказавши бажаний діапазон IPv4-підмережі (CIDR). 3. Якщо віртуальним машинам у цій локальній мережі потрібен безпечний доступ до інтернету (NAT) або додаткові сервіси, увімкніть опцію **Enable Cloud Gateway**. 4. Підключіть ваші машини до створеної мережі (це можна зробити як на етапі створення нової VM, так і на працюючій машині через розділ `VM → Resize`). 5. Переглянути список розподілених адрес та керувати ними можна на вкладці **IPAM** у налаштуваннях вашої мережі. ## Наступні кроки [#наступні-кроки] відкриття доступу до внутрішніх VM. де перевірити вартість Cloud Gateway. # PTR / reverse DNS (/uk/docs/cloud/networking/ptr) Зворотний DNS-запис (PTR-запис) використовується для перевірки відповідності вашої публічної IP-адреси доменному імені. Найчастіше правильний PTR-запис потрібен для стабільної роботи поштових серверів (щоб ваші листи не потрапляли у спам) або для систем моніторингу доступу. Редагування PTR у Network → IP Addresses ## Кроки [#кроки] 1. Перейдіть до розділу `Network → Public IPs`. 2. Виберіть потрібну публічну IP-адресу та натисніть на поле редагування **PTR**. 3. Введіть ваше доменне ім'я (FQDN), яке ви хочете асоціювати з цією адресою. 4. Натисніть **Save**, щоб зберегти зміни. ## Зверніть увагу [#зверніть-увагу] Керування прямими DNS-записами вашого домену (такими як A, MX, CNAME, TXT) здійснюється на стороні вашого DNS-провайдера (наприклад, Cloudflare чи реєстратора домену). Налаштування PTR у нашому порталі працює виключно для зворотного пошуку (reverse DNS) публічних IPv4-адрес, виділених нашою платформою. ## Наступні кроки [#наступні-кроки] збереження IP при видаленні VM. маршрутизація HTTPS-запитів. # Проєкти (/uk/docs/cloud/projects) Проєкт у нашій системі є основним інструментом для групування та ізоляції ваших хмарних ресурсів. Project overview — список VM і ліміти ресурсів ## Що об'єднує проєкт [#що-обєднує-проєкт] * Віртуальні машини та операції з ними (запуск, зупинка, перезапуск, зміна конфігурації); * Мережеву інфраструктуру (приватні мережі VLAN, виділені публічні IP-адреси, Cloud Gateway); * Систему бекапів (персональний розклад копіювання та окреме сховище PBS datastore); * Права доступу, групи безпеки (Security Groups), High Availability та журнал подій; * Фінансову статистику витрат проєкту (доступна лише власнику акаунта). ## Зверніть увагу [#зверніть-увагу] Ви можете видалити проєкт лише після того, як з нього будуть повністю видалені всі віртуальні машини та приватні мережі. Видалення проєкту є безповоротним: воно автоматично звільняє всі ваші публічні IP-адреси, повністю очищує сховище резервних копій (PBS datastore) та назавжди стирає всі бекапи. ## Наступні кроки [#наступні-кроки] створення проєкту та запуск першої VM. налаштування ролей та прав для колег. моніторинг погодинного споживання ресурсів. # Витрати проєкту (/uk/docs/cloud/projects/resource-usage) Усі поточні нарахування та фінансова аналітика вашого проєкту розраховуються погодинно у польських злотих (PLN). Ця статистика доступна виключно власнику проєкту (**Superadmin**) на сторінці `Datacenter → Resource usage`. Інші учасники команди з ролями Admin чи Auditor фінансову інформацію не бачать. Детальну інформацію про те, як правильно читати звіт про споживання та порівнювати його з активними послугами, ви можете знайти у розділі [Resource usage](/uk/docs/cloud/datacenter/resource-usage). ## Наступні кроки [#наступні-кроки] робота з балансом та оплата рахунків. нарахування за вимкнені сервери. # Доступ команди (/uk/docs/cloud/projects/team-access) Ви можете працювати над проєктом разом із колегами чи партнерами. Керувати доступом та ролями учасників може лише власник проєкту — користувач із роллю **Superadmin**. Додавання користувача та ролі ## Кроки для надання доступу [#кроки-для-надання-доступу] 1. Перейдіть до розділу `Datacenter → Permissions`. 2. Натисніть кнопку **Add permission**. 3. Введіть email користувача, який має зареєстрований обліковий запис hostd, та оберіть його роль (**Admin** або **Auditor**). 4. За потреби ви завжди можете відкликати доступ або змінити роль у цьому ж списку. ## Доступні ролі в системі [#доступні-ролі-в-системі] | Роль | Права доступу | | -------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Superadmin** | Власник проєкту. Має повні права: керування учасниками, перегляд білінгу та фінансових витрат, створення, зміна та видалення будь-яких VM і мереж. | | **Admin** | Технічний адміністратор. Має повний доступ до управління інфраструктурою (створення, зміна розміру, видалення VM, налаштування мережі), але не бачить фінансової інформації та розділу прав доступу. | | **Auditor** | Спостерігач. Має доступ до перегляду параметрів VM та мереж у режимі read-only без права внесення змін. | ## Зверніть увагу [#зверніть-увагу] Для успішного додавання учасника команди він повинен мати зареєстрований акаунт у системі hostd. Одразу після введення його email-адреси проєкт миттєво з'явиться в його особистій панелі керування. ## Наступні кроки [#наступні-кроки] загальний огляд структури проєктів. інформація про доступ до бюджету. # Backup і restore VM (/uk/docs/cloud/virtual-machines/backups-restore) Якщо ваша система зазнала серйозного збою або дані були пошкоджені, ви можете повністю відновити віртуальну машину (включаючи стан системного диска) з раніше створеного бекапу. ## Перед відновленням перевірте [#перед-відновленням-перевірте] * Віртуальна машина має бути повністю вимкнена (статус **stopped**). * Бажана резервна копія відображається у списку доступних на вкладці `VM → Backups`. ## Кроки для відновлення [#кроки-для-відновлення] 1. Вимкніть вашу віртуальну машину. 2. Перейдіть до розділу `VM → Backups`. 3. Оберіть потрібну копію за датою створення та натисніть кнопку **Restore**. 4. За потреби встановіть прапорець автоматичного запуску машини після відновлення. 5. Зачекайте завершення процесу відновлення та перевірте працездатність ваших сервісів. ## Зверніть увагу [#зверніть-увагу] * Процедура відновлення вимагає обов'язкової зупинки віртуальної машини. * Якщо для вашої VM активована функція автоматичного перезапуску при збоях (HA), перед початком відновлення необхідно **тимчасово вимкнути HA (autostart)** у розділі `Datacenter → High Availability`. В іншому випадку система HA намагатиметься автоматично запустити сервер під час процедури відновлення, що призведе до помилки. Після успішного відновлення ви зможете увімкнути HA знову. * Захист, видалення копій і завантаження окремих файлів — у **Backup → Datastore**. Сторінка `VM → Backups` лише для повного restore. ## Наступні кроки [#наступні-кроки] налаштування регулярного розкладу бекапів. завантаження окремих файлів без повного відкату VM. # SSH і консоль (/uk/docs/cloud/virtual-machines/connect-console) Для керування віртуальною машиною ви можете підключитися до неї по мережі через SSH (основний метод) або скористатися вбудованою в портал веб-консоллю noVNC (аварійний метод, якщо мережа недоступна). Консоль noVNC ## Перед підключенням перевірте [#перед-підключенням-перевірте] * Віртуальна машина перебуває у статусі **running**. * Ви пам'ятаєте ім'я користувача (username), яке вказали при створенні або перевстановленні VM. * Якщо ви підключаєтеся по SSH через інтернет (WAN): машина має публічну IP-адресу, а на вашому комп'ютері налаштовано відповідний приватний SSH-ключ. ## Методи підключення [#методи-підключення] ### 1. Підключення через SSH (Рекомендовано) [#1-підключення-через-ssh-рекомендовано] Відкрийте термінал на вашому комп'ютері та виконайте команду підключення (якщо приватний ключ збережено у стандартному шляху `~/.ssh/id_rsa` або `~/.ssh/id_ed25519`, параметр `-i` можна не вказувати): ```bash ssh username@public_ip ``` Якщо ви використовуєте ключ із нетиповим ім'ям або шляхом: ```bash ssh -i ~/.ssh/id_rsa username@public_ip ``` ### 2. Підключення через веб-консоль noVNC [#2-підключення-через-веб-консоль-novnc] Якщо на машині вимкнено мережу, заблоковано порти або виникли проблеми з налаштуванням SSH-ключів: 1. Перейдіть у налаштування вашої VM та відкрийте вкладку `VM → Console` (або натисніть кнопку **Open Console in New Window**). 2. Увійдіть у систему, ввівши ім'я вашого користувача (username) та пароль, який ви вказали під час створення або перевстановлення системи. ## Зверніть увагу [#зверніть-увагу] На всіх наших стандартних образах Linux авторизація в SSH за паролем за замовчуванням заблокована. Якщо ви спробуєте підключитися по SSH за паролем, ви отримаєте помилку доступу (Permission denied). Для увімкнення входу за паролем скористайтеся [окремим посібником](/uk/docs/cloud/virtual-machines/ssh-password-login). ## Наступні кроки [#наступні-кроки] як дозволити вхід за паролем по SSH. налаштування дозволів для мережевого екрана. # Створення VM (/uk/docs/cloud/virtual-machines/create) Створення нової віртуальної машини (VM) виконується через зручну форму в порталі. Це дозволяє гнучко налаштувати характеристики сервера під ваші завдання. Створення VM — форма з образом, SSH-ключем і WAN ## Кроки [#кроки] 1. Відкрийте ваш проєкт та натисніть кнопку **Create VM**. 2. **Операційна система та користувач:** Оберіть бажаний образ операційної системи (доступні стабільні дистрибутиви Linux, такі як Ubuntu, Debian, Rocky Linux та AlmaLinux). Вкажіть hostname, ім'я користувача (username) та пароль. 3. **Налаштування ресурсів:** Налаштуйте потрібні ресурси (vCPU, RAM, розмір диска та **CPU mode**). 4. **Авторизація:** Додайте ваш публічний SSH-ключ. Ми наполегливо радимо використовувати саме SSH-ключі для доступу. 5. **Мережа:** Оберіть режим публічного WAN (**Off**, **IPv4**, **IPv6** або **IPv4 + IPv6**), приватну мережу LAN або обидва інтерфейси одночасно (залежно від архітектури вашого проєкту). 6. Натисніть **Create**. Процес створення машини та початкової ініціалізації через `cloud-init` займає до однієї хвилини. ## Зверніть увагу [#зверніть-увагу] * На всіх стандартних образах Linux вхід по SSH за паролем **вимкнено за замовчуванням** з міркувань безпеки — підключення можливе лише за допомогою SSH-ключів. Якщо вам обов'язково потрібен вхід за паролем, ви можете увімкнути його вручну після запуску за [цією інструкцією](/uk/docs/cloud/virtual-machines/ssh-password-login). * Ми не зберігаємо ваші паролі, тому після створення віртуальної машини переглянути вказаний пароль у порталі буде неможливо. Будь ласка, збережіть його в надійному місці. * Мінімальна конфігурація будь-якої VM складає **2 vCPU**, а збільшення процесорних ядер відбувається з кроком у **2**. Обсяг RAM та диска пропонуються у вигляді пропорційних тарифних рівнів (tiers) на базі обраної кількості vCPU. * Системний диск обмежено **20 000 IOPS** та **1000 MB/s** (читання і запис). Деталі: [Storage](/uk/docs/cloud/storage). * Режими публічного WAN: **Off** (без публічної адреси), **IPv4**, **IPv6** або **IPv4 + IPv6**. На підключеній VM можна перемикати лише **Off ↔ той самий режим**; щоб змінити IPv4 / IPv6 / dual-stack, спочатку вимкніть WAN. * Погодинна плата за **public IP** стосується **лише IPv4**. Публічний IPv6 не має окремої плати за адресу. * Режим високої доступності (HA) не активується автоматично під час створення. Якщо вам потрібен апаратний захист від збоїв, увімкніть його після створення у розділі `Datacenter → High Availability`. ## Наступні кроки [#наступні-кроки] як вперше підключитися до створеної VM. створення ізольованого локального VLAN. # Видалення VM (/uk/docs/cloud/virtual-machines/destroy) Видалення віртуальної машини (VM) є незворотною операцією, яка повністю очищує виділені під неї ресурси на сервері. Destroy VM — опції backup і публічного IP ## Кроки [#кроки] 1. Вимкніть віртуальну машину (вона має бути у статусі **stopped**). 2. Перейдіть до розділу `VM → Destroy`. 3. **Опція бекапів:** Оберіть, чи потрібно автоматично видалити всі накопичені бекапи цієї машини, чи ви бажаєте зберегти їх у вашому PBS datastore для подальшого використання або відновлення файлів. 4. **Опція IP-адреси:** Оберіть, чи хочете ви звільнити публічну IP-адресу машини (release), чи бажаєте зберегти її у вашому проєкті як Floating IP для підключення до інших серверів у майбутньому. 5. Підтвердіть видалення. ## Зверніть увагу [#зверніть-увагу] Збережені у проєкті публічні IP-адреси (Floating IPs) та резервні копії (якщо ви вирішили їх зберегти) продовжують тарифікуватися за стандартними погодинними тарифами, оскільки вони займають ресурси платформи. Якщо вони вам більше не потрібні, видаліть їх вручну у відповідних розділах мережі чи бекапів. ## Наступні кроки [#наступні-кроки] перенесення зарезервованих адрес на нові ресурси. як нараховуються витрати за збережені ресурси. # Firewall і security groups (/uk/docs/cloud/virtual-machines/firewall-security-groups) Ви можете налаштувати мережевий екран (Firewall) безпосередньо для кожної віртуальної машини. Для цього можна створювати унікальні індивідуальні правила доступу або підключати заздалегідь підготовлені шаблони — групи безпеки (Security Groups). Create firewall rule — діалог ## Кроки для налаштування правил [#кроки-для-налаштування-правил] 1. Перейдіть до розділу `VM → Firewall`. 2. Якщо мережевий екран вимкнено, переведіть перемикач **Global Status** у положення **On**, змініть загальну вхідну політику **Policy In** на **DROP** (це заблокує весь невідомий вхідний трафік) та натисніть **Apply**. 3. Щоб створити нове правило, натисніть кнопку **Add rule**. 4. Заповніть параметри правила (деталі нижче) та натисніть **Add**. 5. Зверніть увагу на порядок правил у таблиці — вони застосовуються послідовно зверху вниз у межах кожного напрямку (вхідного чи вихідного). ### Налаштування правил у діалозі [#налаштування-правил-у-діалозі] * **Type** — оберіть напрямок трафіку: **IN** (вхідний до вашої VM) або **OUT** (вихідний від вашої VM). * **Action** — оберіть дію: **ACCEPT** (дозволити трафік) або **DROP** (заблокувати трафік). * **Protocol** — оберіть протокол зв'язку: **TCP**, **UDP** або **ICMP**. * **Source Address / Destination Address** — вкажіть IP-адресу або діапазон (CIDR) відправника (для IN) чи отримувача (для OUT). * **Source Port / Destination Port** — вкажіть конкретні порти чи діапазони портів (наприклад, `22` для SSH або `80,443` для веб-трафіку). * **Comment** — за бажанням додайте короткий опис правила (наприклад, "Доступ до бази даних"). * **Enabled** — дозволяє тимчасово вимкнути правило, не видаляючи його зі списку. ## Використання груп безпеки (Security Groups) [#використання-груп-безпеки-security-groups] Insert Security Group на firewall VM Якщо у вас є багато віртуальних машин, які вимагають однакових правил доступу, створіть шаблон у розділі [Security groups](/uk/docs/cloud/datacenter/security-groups). Після цього на сторінці `VM → Firewall` натисніть кнопку **Insert Security Group** та оберіть потрібний шаблон зі списку. ## Зверніть увагу [#зверніть-увагу] * Мережевий екран у порталі hostd фільтрує трафік **виключно на публічному інтерфейсі WAN (`net0`)**. Локальний трафік у приватних мережах (LAN) залишається повністю відкритим всередині вашої мережі. * Для підвищення безпеки та стабільності роботи мережі діапазон підмереж (CIDR) в одному правилі обмежений максимальним значенням **/26**. * Вихідний SMTP (порти 25 / 465 / 587) за замовчуванням заблоковано на мережевому edge, незалежно від цих правил — див. [Вихідна пошта (SMTP)](/uk/docs/cloud/virtual-machines/outbound-email). ## Наступні кроки [#наступні-кроки] створення шаблонів правил. перевірка підключення до сервера. # Віртуальні машини (/uk/docs/cloud/virtual-machines) У цьому розділі зібрані всі необхідні посібники для керування вашими віртуальними машинами (VM) у публічній хмарі. Детальний опис форми створення (вибір образу, обсягу ресурсів, SSH-ключів та мереж). Як підключитися до вашої машини по SSH або через аварійну веб-консоль noVNC. Інструкція з увімкнення доступу по паролю (який за замовчуванням вимкнений з міркувань безпеки). Зміна процесорного режиму, обсягу vCPU, RAM та збільшення системного диска. Повне перевстановлення операційної системи на вашому сервері з очищенням диска. Створення миттєвого знімка системи (точки відновлення) для безпечного проведення експериментів. Повне відновлення віртуальної машини зі збереженого бекапу. Правильне видалення сервера з можливістю збереження його IP-адреси та бекапів. Налаштування мережевого екрана для захисту вашої VM від зовнішніх загроз. ## Зверніть увагу [#зверніть-увагу] Якщо ви вимкнете віртуальну машину (Stop), система перестане нараховувати плату за vCPU та RAM. Проте плата за диск, зарезервовану IP-адресу, бекапи та Cloud Gateway продовжуватиме нараховуватися, оскільки ці ресурси залишаються закріпленими за вами. # Вихідна пошта (SMTP) (/uk/docs/cloud/virtual-machines/outbound-email) Вихідна пошта з інстансів (SMTP на портах **25**, **465** і **587**) **за замовчуванням заблокована** на мережевому edge hostd. Це діє навіть тоді, коли правила firewall Proxmox на VM дозволяють такий трафік. Так ми захищаємо репутацію наших діапазонів IP-адрес. ## Статус у панелі [#статус-у-панелі] На сторінці **VM → Firewall** видно, чи вихідна пошта для цього інстансу **Blocked** (заблокована) чи **Allowed** (дозволена). ## Запит на розблокування [#запит-на-розблокування] 1. Відкрийте **VM → Firewall**. 2. Скористайтеся **Request unlock**. 3. Вкажіть призначення, домен(и) відправника та очікуваний обсяг. 4. Надішліть — буде створено ticket у **Support**, де можна стежити за заявкою. Ми перевіряємо запит (зокрема обґрунтування, домени, історію акаунта). Після схвалення вихідну пошту для інстансу буде розблоковано. ## Зверніть увагу [#зверніть-увагу] * Розблокування стосується інстансу / його публічних IP. Після зміни публічного IP зверніться в support, щоб оновити allowlist. * Лише правила firewall у гостьовій ОС або в Proxmox не відкриють вихідний SMTP, поки діє блокування на edge. * Налаштуйте SPF, DKIM і DMARC для доменів, з яких надсилаєте пошту. # Reinstall VM (/uk/docs/cloud/virtual-machines/reinstall) Функція Reinstall дозволяє повністю очистити системний диск вашої віртуальної машини та розгорнути чисту операційну систему з обраного образу. При цьому всі апаратні характеристики вашого сервера (кількість vCPU, обсяг RAM, розмір диска та MAC-адреси мережевих інтерфейсів) залишаються незмінними. VM Reinstall — образ ОС, облікові дані та SSH-ключі ## Кроки для перевстановлення [#кроки-для-перевстановлення] 1. Зупиніть вашу віртуальну машину (вона має бути у статусі **stopped**). 2. Перейдіть до розділу `VM → Reinstall`. 3. Оберіть операційну систему, вкажіть hostname, ім'я користувача (username) та новий пароль. 4. Додайте ваш публічний SSH-ключ. 5. Натисніть кнопку **Reinstall**. Процес перевстановлення триває до однієї хвилини. ## Зверніть увагу [#зверніть-увагу] * Операція Reinstall є деструктивною. Платформа повністю видаляє поточний системний диск і створює на його місці новий із чистою операційною системою. Якщо на старому диску залишилися важливі конфігурації чи файли, обов'язково переконайтеся, що ви зберегли їх або заздалегідь створили резервну копію в розділі `VM → Backups`. * Перевстановлення ОС автоматично **видаляє поточний користувацький snapshot** віртуальної машини, якщо він був створений. ## Наступні кроки [#наступні-кроки] відновлення системи з бекапів. робота з миттєвими знімками системи. # Resize VM (/uk/docs/cloud/virtual-machines/resize) Ви можете гнучко змінювати характеристики вашої віртуальної машини (обсяг vCPU, RAM, розмір диска та режим процесора CPU mode) залежно від навантаження. VM Resize — CPU mode, vCPU, RAM і мережа ## Що можна змінити в гарячому режимі (VM працює) [#що-можна-змінити-в-гарячому-режимі-vm-працює] Поки ваша віртуальна машина запущена (статус **running**), ви можете виконати такі дії без зупинки системи: * **Збільшити** кількість vCPU, обсяг RAM та розмір системного диска. * Змінити режим роботи процесора **CPU mode** (наприклад, перейти з Eco на Performance). * Додавати, відключати або налаштовувати мережеві інтерфейси (WAN/LAN). ## Що вимагає зупинки віртуальної машини [#що-вимагає-зупинки-віртуальної-машини] Будь-яке **зниження ресурсів** (зменшення кількості vCPU або обсягу оперативної пам'яті RAM) потребує обов'язкової зупинки віртуальної машини. Перед збереженням таких змін вимкніть сервер. ## Кроки для зміни розміру [#кроки-для-зміни-розміру] 1. Перейдіть до розділу `VM → Resize`. 2. Оберіть новий режим **CPU mode**, обсяг vCPU та оперативної пам'яті у доступній сітці тарифів (tiers). 3. Якщо вам потрібно більше місця для файлів, вкажіть новий (більший) розмір системного диска. 4. Якщо потрібно змінити публічний IP-адрес: вимкніть публічний інтерфейс WAN, натисніть **Save**, потім знову увімкніть WAN та оберіть існуючий Floating IP або виберіть **Auto** для отримання нової адреси. Це працює без перезавантаження ОС. 5. Натисніть **Save**, щоб застосувати зміни. ## Зверніть увагу [#зверніть-увагу] * Знижувати ресурси (vCPU, RAM) або переходити на нижчий режим роботи процесора (наприклад, з Performance на Eco) можна не частіше ніж **один раз на день** для кожної VM. * Зміна розміру системного диска можлива **тільки у бік збільшення**. Зменшення дискового простору обмежене на рівні файлових систем для запобігання втраті даних. * Режим роботи процесора (**CPU mode**) можна змінювати "на льоту" на працюючій машині. ## Наступні кроки [#наступні-кроки] як тарифікуються ресурси після зміни конфігурації. перенесення та збереження IP-адрес. # Snapshot (/uk/docs/cloud/virtual-machines/snapshots) Снапшот (snapshot) — це миттєвий знімок стану диска вашої віртуальної машини. Це надзвичайно зручний інструмент, коли вам потрібно зробити потенційно небезпечне налаштування або оновити ПЗ і мати можливість миттєво повернутися до робочого стану у разі помилки. ## Кроки [#кроки] 1. Перейдіть до розділу `VM → Snapshots`. 2. Натисніть кнопку **Create snapshot** безпосередньо перед початком проведення робіт у системі. 3. Проведіть заплановані налаштування чи оновлення на сервері. 4. Якщо все пройшло успішно — видаліть створений снапшот, щоб звільнити ресурси. Якщо щось пішло не так — натисніть кнопку **Rollback**, щоб миттєво повернути машину до моменту створення снапшота. ## Зверніть увагу [#зверніть-увагу] * **Снапшот не є бекапом!** Він зберігається на тому ж дисковому масиві, що й сама віртуальна машина, і призначений лише для короткострокового захисту під час проведення технічних робіт. Для надійного довгострокового захисту даних використовуйте автоматичні [Backup jobs](/uk/docs/cloud/backup/jobs). * Для кожної віртуальної машини можна створити **лише один снапшот одночасно**. Перед створенням нового снапшота обов'язково видаліть або відкотіть попередній. ## Наступні кроки [#наступні-кроки] налаштування регулярного резервного копіювання. повне перевстановлення системи. # Увімкнення SSH за паролем (/uk/docs/cloud/virtual-machines/ssh-password-login) З міркувань безпеки на всіх стандартних образах Linux платформи hostd вхід по SSH за паролем **заблокований за замовчуванням**. Ми наполегливо радимо використовувати саме SSH-ключі. Проте, якщо для роботи ваших скриптів чи застосунків обов'язково потрібен доступ за паролем, ви можете активувати його вручную всередині операційної системи. ## Кроки для увімкнення [#кроки-для-увімкнення] 1. Підключіться до вашої віртуальної машини за допомогою SSH-ключа або вбудованої веб-консолі `VM → Console`. 2. Створіть новий файл конфігурації SSH-демона, виконавши команду: ```bash sudo nano /etc/ssh/sshd_config.d/99-password-auth.conf ``` 3. Додайте у цей файл наступний рядок: ```text PasswordAuthentication yes ``` Збережіть файл (у редакторі nano: `Ctrl+O`, `Enter`, потім вихід — `Ctrl+X`). 4. Перезапустіть службу SSH всередині ОС, щоб застосувати конфігурацію: * Для **Debian / Ubuntu**: ```bash sudo systemctl restart ssh ``` * Для **AlmaLinux / Rocky Linux**: ```bash sudo systemctl restart sshd ``` 5. Тепер ви можете підключатися до сервера по SSH, вводячи ім'я вашого користувача та пароль. ## Зверніть увагу [#зверніть-увагу] * Авторизація за паролем є значно менш безпечною, ніж використання SSH-ключів, оскільки ваш сервер стає вразливим до атак типу brute-force (підбір паролів роботами з інтернету). Наполегливо радимо обмежувати доступ до порту SSH за допомогою [Firewall VM](/uk/docs/cloud/virtual-machines/firewall-security-groups). * Якщо ви виконаєте повне перевстановлення системи ([Reinstall](/uk/docs/cloud/virtual-machines/reinstall)), системна служба `cloud-init` знову заблокує вхід за паролем. У такому разі ці кроки потрібно буде повторити. ## Наступні кроки [#наступні-кроки] загальні налаштування доступу. обмеження доступу до SSH-порту за допомогою IP-фільтрації. # API documentation (/en/docs/api) The hostd API lets you manage your account programmatically. Base URL: `https://hostd.cloud`. ## Authentication [#authentication] Most endpoints require an API key. Create a key in the portal under [Settings → API Keys](https://hostd.cloud/app/settings/api-keys) and send it as a Bearer token: ```http Authorization: Bearer ``` ```bash curl -H "Authorization: Bearer " https://hostd.cloud/api/network/ips/ ``` Listing clusters is public and does not require authentication. ## Endpoints [#endpoints] * [Public cloud](/en/docs/api/public-cloud/list-clusters) — clusters, projects, usage, tasks, and hourly pricing. * [IP addresses](/en/docs/api/ip-addresses/list-ip-addresses) — assigned IP addresses and their reverse DNS (PTR) records. # Platform capabilities (/en/docs/cloud/capabilities) The hostd Public Cloud is a reliable, scalable, and secure infrastructure (IaaS) built on top of leading enterprise-grade technologies. ## Technology Stack & Hardware [#technology-stack--hardware] We use only proven and reliable hardware from global industry leaders to ensure maximum performance and stability for your workloads. **Proxmox VE** — stable enterprise repository branch based on KVM/QEMU Exclusively **Dell PowerEdge** with **AMD EPYC** processors Switches and routers from **Dell PowerSwitch** and **Juniper** **Proxmox Backup Server (PBS)** — isolated deduplicated datastore per project Distributed all-flash NVMe (SDS) with **RoCEv2** and asynchronous `io_uring` ### Storage Performance [#storage-performance] Thanks to all-flash NVMe storage and modern transmission protocols, typical latency for **4k randwrite** operations in **t1q1** mode (1 thread, `iodepth=1`) with **fsync** is only about **0.11 ms** (measured directly at the hypervisor level). *Note: This is an infrastructure metric, not an SLA for your application inside the VM, as the guest OS file system and emulation add their own overheads.* Each VM virtual disk is capped at **20,000 IOPS** read and write and **1,000 MB/s** read and write throughput. Details: [Storage](/en/docs/cloud/storage). ### Available Zones [#available-zones] * **WAW-AMD1** — Warsaw, Poland. The infrastructure is located in certified **Atman WAW-2** and **Equinix WA2** data centers (Tier III+ compliance). Your data and backups physically remain in Poland. ## Compute Resources [#compute-resources] * **Modern Linux OS:** Instant deployment of clean and stable images of Ubuntu, Debian, Rocky Linux, and AlmaLinux. * **Flexible CPU modes:** * **Performance:** Dedicated vCPUs with maximum performance (up to 100% CPU time) for high-load systems. * **Eco:** Balanced utilization up to 50% CPU time for standard web applications and services. * **Slim:** Optimal mode up to 25% CPU time for testing, development, and light background tasks. * **Instant Scaling (Resize):** Increase vCPU, RAM, and system disk size on-the-fly without stopping the system. * **Guaranteed High Availability (HA):** Free automatic protection against hardware failures. If a physical host fails, your VM is automatically rebooted on another working host in less than a minute. * **Snapshots:** Take an instant snapshot of the disk state for quick and safe rollbacks during system updates or testing. ## Networking & Security [#networking--security] * **Public WAN (IPv4 / IPv6):** Attach a public address in **IPv4**, **IPv6**, or **IPv4 + IPv6** mode (or leave WAN off). Addresses are assigned directly to the instance interface without overlay NAT. Hourly public IP billing applies to **IPv4 only**. * **Private Networks (VLAN):** Create fully isolated Layer 2 local network segments for secure communication between instances, featuring built-in IPAM (IP Address Management). * **Reverse DNS (PTR):** Manage PTR records for your public IPv4 and IPv6 addresses directly through the portal. * **Firewall:** Set up traffic filtering rules on public WAN interfaces. * **Security Groups:** Reusable firewall rule templates that can be quickly applied to multiple virtual machines. * **Network Map:** Interactive visual representation of your entire infrastructure, showing connections between instances, private networks, and gateways. * **External VLAN:** Integrate the cloud with your physical hardware (bare metal or on-premises) via a dedicated Layer 2 channel. ## Cloud Gateway [#cloud-gateway] A specialized, fully managed infrastructure router for your private networks. * **Full Automation:** Configure NAT, port forwarding, VPN, and proxying without the need to manually administer the router's operating system. * **WireGuard VPN:** Fast and secure access for administrators and developers to local cloud resources over an encrypted tunnel. * **Reverse Proxy:** A high-performance reverse proxy based on Caddy with automatic Let's Encrypt SSL certificate generation upon the first domain request. ## Backups & Recovery [#backups--recovery] An integrated, fully automated backup system powered by enterprise-grade Proxmox Backup Server (PBS) technologies. * **Regular Schedules (Backup jobs):** Configure flexible automated backup schedules for groups of virtual machines. * **Incrementality & Deduplication:** Backups copy only modified disk blocks and undergo deduplication at the storage level, resulting in massive savings in disk space (on-disk size) and reducing storage costs. * **File-level Restore (File restore):** Browse the backup file tree and download individual files or folders directly from the backup without a full system rollback. * **Backup Protection:** Protect critical backup copies from accidental or automatic deletion by retention policies. ## Management & Billing [#management--billing] * **Team Access:** Add members by email and assign roles (Superadmin, Admin, Auditor) for secure joint infrastructure management. * **Hourly Billing:** Charges are accrued solely for actually allocated resources with hourly precision. * **Two Payment Models:** Pay in advance (Prepaid with auto-reload) or after consumption (Postpaid with invoices at the beginning of the month). # Getting started (/en/docs/cloud/getting-started) This guide will help you create your first project, securely configure access rules, launch your first virtual machine, protect it with a firewall, enable High Availability (HA), and configure automated backups. ## Roadmap [#roadmap] 1. [Project creation](#step-1-project) 2. [VM launch](#step-2-vm) 3. [Security Group configuration](#step-3-security-group) 4. [Firewall configuration on the VM](#step-4-firewall) 5. [High Availability (HA) enablement](#step-5-ha) 6. [Backup Job configuration](#step-6-backup-job) ## Before you begin [#before-you-begin] * Review the [Resources and limits](/en/docs/cloud/public-cloud-overview) page to understand how the platform works and what limits apply. * Prepare an SSH key on your computer (you will need the public part of the key to paste into the form). * Install an SSH client. You can also use the web console (`VM → Console`) if needed. * For prepaid accounts, make sure you have sufficient balance. ## Steps [#steps] ### 1. Create a project [#step-1-project] 1. Open the management panel: `Console → Public Cloud`. 2. Click **Create project**, choose a convenient zone, enter the **Project name**, and confirm the creation. Create project — Public Cloud ### 2. Create a virtual machine (VM) [#step-2-vm] 1. On the overview page of your new project, click **Create VM**. 2. Select the operating system image, specify the `hostname`, `username`, and password. 3. Add your **public SSH key** into the corresponding field. 4. Configure the required resources (vCPU, RAM, disk size, and `CPU mode`). 5. Enable the **public WAN** (Public WAN) option so the machine gets internet access. 6. Click **Create**. The VM creation and initial setup via `cloud-init` takes up to one minute. Create VM — form with image, SSH key, and WAN ### 3. Create a Security Group [#step-3-security-group] To easily manage the same rules (such as SSH access) across multiple servers, it is recommended to use Security Groups. 1. Navigate to the `Datacenter → Security groups` section. 2. Create a new security group. Use a short Latin name (up to **15** characters). 3. Add an **IN** rule to allow connections: select protocol **TCP**, port **22** (SSH). In the **Source** field, specify your IP addresses in the `x.x.x.x/32` format. Security groups in Datacenter ### 4. Configure Firewall on the VM [#step-4-firewall] Now you need to protect your virtual machine from unwanted traffic. To do this, open `VM → Firewall` (rules apply only to the public WAN interface). 1. Toggle the **Global Status** switch to **On**. 2. Change **Policy In** to **DROP** — this will block all incoming traffic except for what you explicitly allow. 3. Click **Apply** to apply the policy. 4. Add permission for SSH: click **Insert Security Group** and select the group from step 3, or click **Add Rule** and create a standard rule only for this machine. 5. Now you can securely connect to the machine via SSH. VM Firewall — Global Status, Policy In, and rules ### 5. Enable High Availability (HA) [#step-5-ha] HA mode automatically restarts your virtual machine on another physical server if the current node fails. This feature is provided completely **free of charge** — you only pay the standard hourly cost of your VM's vCPU and RAM. 1. Navigate to the `Datacenter → High Availability` section. 2. Toggle the **HA** switch to **On** for your virtual machine. 3. If necessary, create an **affinity rule** to determine whether specific VMs should run on the same physical server or must run on different ones. 4. You can always check the current HA status on the `Summary` tab in the VM's settings. High Availability in Datacenter ### 6. Create a Backup Job [#step-6-backup-job] Automatic schedules (backup jobs) are the primary tool for regularly saving the state of your VMs. By default, you can create **1** backup job per project, but you can add multiple virtual machines to it. 1. Open `Backup → Jobs`. 2. Click **Create backup job**. 3. Specify a **Job name** (e.g., `Production VMs`) and make sure the **Enabled** toggle is active. 4. Select the days of the week for the backup (at least one day is required). Backups are initiated within the allowed time window: **00:00–06:00**. 5. Configure **Retention**: for a typical VM, **Keep daily = 7** is sufficient. 6. Select your VM in the **Virtual machines** table and click **Save**. Create backup job — dialog ## Watch out [#watch-out] * Until you activate the Firewall (step 4), your VM with a public IP will be completely open to the internet on all ports. Configure the firewall immediately before hosting any important data or services on the machine. * If you stop the VM, billing for CPU and RAM stops. However, you will continue to pay for the allocated disk, attached Floating IP, backups, and Cloud Gateway. * HA protects against hardware failures (restart usually takes up to a minute) but not from OS-level crashes. Use backups (step 6) to protect your data. * Backups are billed based only on the real (on-disk) space used after compression and deduplication — see [Datastore](/en/docs/cloud/backup/datastore). # Introduction (/en/docs/cloud) This section contains all the necessary information to work with the hostd Public Cloud — from creating your first virtual machine to configuring networking and backups. ## Where to start [#where-to-start] Detailed overview of our technology stack, architecture, and hardware. Step-by-step guide to launching a secure VM. Resource organization at the account and project levels, CPU modes, and default limits. Team management, cost monitoring, and limits. Creation, connection, resizing, reinstallation, snapshots, backups, and deletion. Public IPs, PTR records, private networks, and external VLANs. NAT, port forwarding, WireGuard, and reverse proxy settings. Backup schedules, datastore management, and file restoration. Tasks, security groups, High Availability (HA), and access management. Prepaid and postpaid models, invoicing, and resource costs. ## Please note [#please-note] * Public Cloud is an IaaS (Infrastructure as a Service) platform. We guarantee the operation of physical hardware, virtualization, and network, while operating system and software management is handled on your side. # Resources and limits (/en/docs/cloud/public-cloud-overview) This page contains detailed information about account and project organization, the weights of virtual CPU modes, and default system limits. ## Resource Organization [#resource-organization] Cloud infrastructure management is divided into two logical levels: **account** and **projects**. | Management Level | Contents | | ---------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | **Account** | General profile settings, financial balance, and total vCPU limit (shared across all projects). | | **Project** | Virtual machines, private networks (VLANs), reserved public IPs, Cloud Gateways, backup storage (PBS datastore), team access permissions, and hourly cost details. | Public Cloud services are billed **hourly in Polish Zlotys (PLN)**. We offer two payment models: * **Prepaid** — funds are deducted hourly from your balance. Automatic balance replenishment from a saved card is available (auto-reload). * **Postpaid** — pay for actually consumed resources. You receive a single invoice at the beginning of each month for the previous period (requires approval). For more details on payment models, see the [Billing models](/en/docs/cloud/billing/models) section. ## CPU Modes [#cpu-modes] When creating a virtual machine or resizing it, you choose the **CPU mode** and the number of **vCPUs**. The number of vCPUs determines how many virtual cores the guest operating system "sees." On the other hand, the CPU mode defines the **total maximum limit** of processor time that the VM can use collectively on the physical host. One fully loaded vCPU corresponds to **100%** of a physical core's time. | CPU Mode | Total CPU Limit for VM | | --------------- | --------------------------------------------------------------------------- | | **Performance** | Up to **100%** per vCPU (e.g., 4 vCPUs = up to **400%** CPU time) | | **Eco** | Up to **50%** per vCPU (e.g., 4 vCPUs = up to **200%** CPU time) | | **Slim** | Up to **25%** per vCPU (e.g., 4 vCPUs = up to **100%** CPU time) | *Example of running in Eco with 4 vCPUs (200% limit):* The virtual machine can use any load combination within the limit — for instance, loading all four virtual cores at 50% each, or two virtual cores at a full 100% (while the other two cores idle). Total physical CPU consumption will never exceed 200%. The selected CPU mode also determines how many resources the VM consumes from your global account limit. ## Limits (Default) [#limits-default] To protect new accounts from uncontrolled expenses, default starting limits are in place. If your business needs more resources, please send a request to our support team. ### Account Limits [#account-limits] | Resource | Default Limit | | ----------------------------- | --------------------------------------- | | Projects within one zone | **5** | | Total vCPU budget on account | **16** (in Performance mode equivalent) | | Maximum vCPUs for a single VM | **16** | There is no separate limit on how many virtual machines you can create — only the vCPU budget and the derived RAM and disk quotas apply. The vCPU budget is shared across all projects of the account and is calculated based on mode weights: | CPU Mode | vCPU Weight | | ----------- | ----------- | | Performance | **1** | | Eco | **0.5** | | Slim | **0.25** | *Example of using a 16 vCPU budget:* You can create 16 vCPUs in Performance mode, 32 vCPUs in Eco mode, 64 vCPUs in Slim mode, or any other combination within the budget. The absolute number of cores on a single VM is limited to 16. ### Project Limits [#project-limits] | Resource | Default Limit | | ------------------------------------- | -------------------------------------------------------- | | Private networks (VLAN) | **1** | | Automated backup jobs | **1** | | Total RAM for all VMs | Account vCPU budget × **6** GiB (default **96** GiB) | | Total system disks (NVMe) for all VMs | Account vCPU budget × **100** GiB (default **1600** GiB) | ### Virtual Machine (VM) Limits [#virtual-machine-vm-limits] | Resource | Limits and Steps | | -------------------------------- | ---------------------------------------------------------------- | | vCPU Count | From **2** to limit (increases in steps of **2**) | | Operational Memory (RAM) | From **vCPU × 1** to **vCPU × 6** GiB | | System Disk | From **vCPU × 10** to **vCPU × 100** GiB (in steps of ×10) | | User Snapshots | **1** at a time per VM | | Private Network Interfaces (LAN) | Up to **8** interfaces (each requires a created private network) | | SSH Keys at Creation | Up to **5** keys | *Note: Decreasing VM configuration (vCPU, RAM, or switching to a lower CPU mode) is allowed no more than once a day per machine. Lowering vCPU and RAM requires a mandatory stop of the server. For more details, see the [Resize VM](/en/docs/cloud/virtual-machines/resize) section.* ### Network Limits and Rules [#network-limits-and-rules] | Feature | Limit or Rule | | ---------------- | -------------------------------------------------------------------------------------------------- | | Public IPv4 | Reverse DNS (PTR record) can be easily changed directly in the portal. | | IPv6 | Planned for implementation. | | Private Networks | Default **1** per project (only IPv4 addressing is supported). | | External VLAN | Connection interface is available in the UI, but support assistance is required for configuration. | | WAN Bandwidth | 100 / 200 / 300 / 400 Mbps for VMs with 2–7 / 8–15 / 16–23 / 24+ vCPUs respectively. | | LAN Bandwidth | 2 / 3 / 4 / 5 Gbps for the same vCPU levels (exact metrics are specified in the VM creation form). | | VM Firewall | Filters public WAN interface only. Subnets (CIDR) up to **/26** are allowed in rules. | # Storage (/en/docs/cloud/storage) Read-only view of a project storage pool in the console, plus the performance limits applied to each VM virtual disk. ## Overview [#overview] See which VM virtual disks are on a given storage pool — disk capacity is billed in the project. VM system disks use distributed all-flash NVMe storage. See [Platform capabilities](/en/docs/cloud/capabilities) for architecture notes (RoCEv2, `io_uring`, latency reference). ## Disk performance limits [#disk-performance-limits] Every virtual disk is capped at the hypervisor with fixed IOPS and throughput limits. The values are the same for all VMs and are not configurable in the portal. | Limit | Value | | ---------------- | -------------- | | Read IOPS | **20,000** | | Write IOPS | **20,000** | | Read throughput | **1,000 MB/s** | | Write throughput | **1,000 MB/s** | ## Watch out [#watch-out] Additional VM disks are not available in the portal. Increase the system disk on [Resize a VM](/en/docs/cloud/virtual-machines/resize). ## Related [#related] * [Virtual machines](/en/docs/cloud/virtual-machines) * [Capabilities](/en/docs/cloud/capabilities) — storage architecture and planned additional VM disks. # Get an IP address (/en/docs/api/ip-addresses/get-ip-address) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # List IP addresses (/en/docs/api/ip-addresses/list-ip-addresses) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # Update PTR record (/en/docs/api/ip-addresses/update-ptr-record) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # Get account usage (/en/docs/api/public-cloud/get-account-usage) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # Get a cluster (/en/docs/api/public-cloud/get-cluster) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # Get a project (/en/docs/api/public-cloud/get-project) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # List clusters (/en/docs/api/public-cloud/list-clusters) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # List project resource usage (/en/docs/api/public-cloud/list-project-resource-usage) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # List project tasks (/en/docs/api/public-cloud/list-project-tasks) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # List projects (/en/docs/api/public-cloud/list-projects) {/* This file was generated by Fumadocs. Do not edit this file directly. Any changes should be made by running the generation command again. */} # Datastore (/en/docs/cloud/backup/datastore) In the **Datastore** section, you can inspect existing backups, check how much space they occupy, set protection for critical copies, or manually delete unnecessary volumes. Backup Datastore — statistics and volume list ## Steps [#steps] 1. Open the `Backup → Datastore` section. 2. Find the relevant virtual machine in the list. 3. Expand it to see specific backup copies (volumes). You can check their logical size, actual on-disk size, and creation date. 4. If a copy is critically important, enable **protection** for it. This will safeguard it against automatic or accidental deletion. 5. Delete copies manually only when you are absolutely sure that the data is no longer needed. You can also **Delete all backups** for a VM group from the group row menu. 6. Use **File restore** on a volume to browse and download individual files (without a full VM restore). ## Watch out [#watch-out] To delete a protected backup, you must first remove its protection. Remember that if you delete a virtual machine but keep its backups, the storage space used for them will continue to be billed. Full VM restore is on `VM → Backups`; this page is for management and file restore. # File restore (/en/docs/cloud/backup/file-restore) If you accidentally deleted a few files and do not want to roll back the state of the entire system, you can download individual files or folders directly from a backup. File restore — file tree ## Steps [#steps] 1. Open the `Backup → Datastore` section. 2. Find the backup copy you need and click **File restore**. 3. A file tree of your system will open — you can expand folders and search for the required data. 4. Once you find the file or folder, click the corresponding button to download it (folders will be downloaded as a zip archive). ## Watch out [#watch-out] This tool is designed mainly for downloading configuration files or smaller directories (roughly up to **200 MB**). If you need to recover a massive database or a full machine archive, it is better to use full VM restoration or contact [support](https://hostd.cloud/contact). # Backup (/en/docs/cloud/backup) Here you will find instructions for backing up your virtual machines: from configuring regular schedules to restoring individual files. Configuring schedules (weekdays, time window) and retention policies. Viewing existing backup copies, protecting them from accidental deletion, and statistics. Downloading individual files or folders without having to fully restore the entire virtual machine. Full recovery of a virtual machine from a saved copy. ## Watch out [#watch-out] The platform infrastructure ensures safe and reliable backup storage, but configuring schedules and regularly testing data recovery remains your responsibility. We recommend periodically verifying that your data can be successfully restored. # Backup jobs (/en/docs/cloud/backup/jobs) Create and maintain scheduled VM backup jobs. Create backup job — modal ## Before you begin [#before-you-begin] * Admin or Superadmin access to the project. * VMs you want to protect are listed in the project. ## Steps [#steps] 1. Open `Backup → Jobs`. 2. Click **Create backup job** (or edit an existing job). 3. Fill in the **Create backup job** dialog (see below). 4. Select VMs under **Virtual machines** and click **Create**. 5. Check the warning list for VMs without a backup job. ## Fields in **Create backup job** [#fields-in-create-backup-job] **General** * **Enabled** — turns the job on or off without deleting the schedule. * **Job name** — short label in the portal (e.g. `Production VMs`). * **Backup time window** — when a backup may start (currently **00:00–06:00**). **Schedule** * Weekdays — which days the job may run (at least one day required). **Retention** * **Keep daily**, **Keep weekly**, **Keep monthly**, **Keep yearly** — how many copies to keep at each tier (see below). Empty or **0** disables that tier. **Virtual machines** * Project VM table — select machines covered by this job. A VM already in another job is greyed out (**in another job**). ## Retention — how it works [#retention--how-it-works] Retention controls how many backup copies stay on the datastore. Older copies are removed automatically. * **Keep daily** — how many recent day-level copies to keep (e.g. **7** ≈ one week of daily restore points). * **Keep weekly** — additionally keep one copy per week (e.g. **4** ≈ about a month of weekly history). * **Keep monthly** / **Keep yearly** — longer history; set only when you need older copies. **How to set it:** for a typical VM, keep the defaults **7** daily and **4** weekly. For test environments, **3** daily and **0** weekly is often enough. For production with longer history, raise daily or add monthly (e.g. **3**). Form limits: daily up to **90**, weekly **26**, monthly **12**, yearly **2**. The more copies you keep in retention, the more storage backups use and the higher retention cost can be. ## Backup storage cost [#backup-storage-cost] Backups on PBS are **incremental** and **deduplicated**. In `Backup → Datastore` you see two sizes: * **Logical** — total data size in the backup index. * **On-disk** — actual disk usage after deduplication and compression. **Billing is hourly based on on-disk** GiB on the project datastore, not logical size. You can also check usage in `Datacenter → Resource usage` (backup column: logical / on-disk). ### Illustrative example [#illustrative-example] A test VM with a **100 GiB** disk. About **5%** of data changes each day (\~**5 GiB**). Daily backups, **7** daily retention (default): | Stage | Rough estimate | | ---------------------------- | --------------------------------------------------------------------- | | First backup (full) | \~**100 GiB** on the datastore | | Each following day | \~**+5 GiB** of changed data, not another full 100 GiB | | After \~7 days | on the order of **\~130 GiB** on-disk (100 + 6×5), not 7×100 GiB | | With **keep daily** = **30** | on the order of **\~245 GiB** (100 + 29×5) — much higher storage cost | This is a simplified example: real on-disk usage depends on how many blocks repeat between copies. Always check **on-disk** in the datastore before raising retention. ## Watch out [#watch-out] The default project backup job limit is **1**. A backup job does not replace restore testing. # Billing (/en/docs/cloud/billing) The public cloud infrastructure is billed **hourly in Polish Zlotys (PLN)**. You pay for the resources allocated to your project: vCPU, operational memory, disk space, public IPv4 addresses, Cloud Gateway, and backup storage. You can manage your balance in the [`Billing`](https://hostd.cloud/app/settings/billing) panel and view or pay invoices in [`Invoices`](https://hostd.cloud/app/settings/invoices). How Prepaid and Postpaid models work and how they differ. When we issue invoices and what exactly they include. What resources you continue to pay for, even if you stop your server. # Invoices (/en/docs/cloud/billing/invoices) All your invoices can be viewed or downloaded in PDF format in the [`Invoices`](https://hostd.cloud/app/settings/invoices) panel. You can also pay them online there. The invoicing schedule depends on your payment model. ## Prepaid (prepayment) [#prepaid-prepayment] In this model, you top up your balance in advance, and the cost of services is deducted from it hourly. A VAT invoice is generated **at the moment of each balance top-up** (it is listed on the invoice as *Doładowanie salda rozliczeniowego*). Ongoing daily resource consumption does not generate new invoices. ## Postpaid (payment in arrears) [#postpaid-payment-in-arrears] In this model, you pay for actual consumption over the past period. A single consolidated VAT invoice is issued **at the beginning of each month**. * Each of your projects is displayed on the invoice as a separate line item: `Public Cloud {uuid} | {project name}` with a consolidated summary of resource consumption (vCPU hours, RAM, disk, etc.). * If the amount due is less than **1 PLN net**, an invoice is not generated. * If you have a compensation credit or discount, they are shown as a separate **Rabat** line item with the specified reason. ### How to pay an invoice [#how-to-pay-an-invoice] You can pay invoices via bank transfer (payment details are specified in the PDF file itself) or online directly in the portal using a card, Apple Pay, or Google Pay. For your convenience, you can enable the **auto-pay** feature so the system automatically charges the saved card on the invoice issue date. # Billing models (/en/docs/cloud/billing/models) The platform accrues charges **hourly** for all resources allocated to your project (even if they are not 100% loaded). Your account can operate under one of two payment models, and this model applies to all of your projects simultaneously. | | **Prepaid** (default) | **Postpaid** | | ---------- | -------------------------------------- | ---------------------------------------------------- | | Payment | Upfront — from account balance | In arrears — monthly invoice | | Accounting | Hourly balance deduction | Hourly resource usage recording | | Invoice | Instantly upon each balance top-up | At the beginning of the month for the previous month | | Automation | Auto-reload (automatic balance top-up) | Auto-pay (automatic invoice payment) | ## Prepaid (prepayment) [#prepaid-prepayment] This model is enabled automatically upon registration. You top up your balance in the Billing panel, and the cost of used resources is deducted from this amount every hour. * **Top-up** — the minimum amount is **50 PLN net** (maximum is 2000 PLN). You can pay by card, Apple Pay, or Google Pay. VAT is added at the moment of payment. * **Auto-reload** — a very convenient feature that allows you to automatically top up your balance from a saved payment card when it falls below a specified threshold. * If you have promotional or bonus funds on your balance, the system will always deduct resources from these funds first, and only then from your real money. ## Postpaid (payment in arrears) [#postpaid-payment-in-arrears] This model allows you to use services without prepayment and receive an invoice after the consumption period. To switch to this model, you need to submit a request to support via the **Request contract billing** button in the Billing panel. * At the beginning of each month, you receive a single invoice for all resources consumed during the previous month. * If an **individual discount** is agreed for your account, it is automatically taken into account in hourly charges. * **Auto-pay** — allows you to automatically pay issued invoices from a saved payment card. * In this model, your current accrued total is visible in real-time, while the direct balance top-up feature is disabled since you simply pay the issued invoices. ### Compensation credit [#compensation-credit] In case of outages or as a gesture of goodwill, hostd may grant you a one-time compensation credit. It will automatically reduce your future invoices (displayed as a **Rabat** line item). Such a credit can cover up to **75%** of a single invoice, and any unused portion carries over to the following months. # Stopped VM costs (/en/docs/cloud/billing/stopped-vm-costs) Stopping (Stop) a virtual machine halts the billing of compute resources (**vCPU** and **RAM**). However, all other reserved resources continue to be billed hourly because the platform continues to reserve them for you. | Resource | Billed for a stopped VM? | | ------------------------- | ------------------------ | | vCPU and RAM | No | | System disk (storage) | Yes | | Floating IP (public IPv4) | Yes | | PBS backup storage | Yes | Therefore, a stopped virtual machine **does not equal zero cost**. If you want to completely stop the billing of, for example, a disk or a public IP, you must permanently delete the virtual machine (along with its disk) or release the IP address from your project. You can always check the hourly breakdown of costs on the `Datacenter → Resource usage` page (available only to the account owner). # Cloud Gateway (/en/docs/cloud/cloud-gateway) Cloud Gateway is a managed router that hostd automatically deploys for your private network. It allows you to configure NAT, port forwarding, WireGuard VPN, and a reverse proxy. ## What is it? [#what-is-it] It is a completely isolated router virtual machine. Its main difference from your standard VMs is that **you do not have SSH or console access to it**. All settings are configured exclusively through the hostd portal interface, and the infrastructure automatically applies them under the hood. To ensure reliability, Cloud Gateway runs with **High Availability (HA)** enabled right from the moment of creation. If the physical server hosting your router fails, the system will automatically restart it on another working node (this usually takes less than a minute). You do not need to configure HA for it manually. ## When you need it [#when-you-need-it] Cloud Gateway is useful when VMs on a private network **do not have their own public IPs**, and you need: * outbound internet access (NAT) via the gateway WAN address; * inbound access to specific services on VMs (port forwarding); * secure admin access to the private network (WireGuard); * HTTP/HTTPS publishing with a Let's Encrypt certificate (reverse proxy). If an isolated VLAN without internet routing is enough, you can disable or remove Cloud Gateway at any time. ## How to enable Cloud Gateway [#how-to-enable-cloud-gateway] You can activate it when creating a new private network (`Network → Private networks → New` → **Enable Cloud Gateway**) or add it later to an existing VLAN (using the **Enable Cloud Gateway** button in the network's menu). For Internal VLAN networks, the gateway is enabled by default when you create the network. The router will automatically occupy the **`.1`** IP address in your subnet and act as the default gateway for all connected VMs. Therefore, make sure this address is free. You can assign the gateway's public IPv4 automatically (first free address from the pool) or pick one already reserved in the project. The public IP is billed separately from the Cloud Gateway service itself. Creating a private network with Cloud Gateway ## Services [#services] Once the gateway is running, you configure in the portal: Forwarding ports from the router's public IP address to the internal IP addresses of your VMs. Secure VPN access to the private network for your administrators or developers. Configuring an HTTP/HTTPS proxy with automatic Let's Encrypt SSL certificate generation. ## Watch out [#watch-out] You can completely delete Cloud Gateway at any time to stop its billing. The private network (VLAN) itself will not be deleted, and your VMs will continue to communicate with each other over the local network. # Port forwarding (/en/docs/cloud/cloud-gateway/port-forwarding) Port forwarding (DNAT) allows you to receive network traffic on the public IP address of your Cloud Gateway and automatically forward it to a specific virtual machine inside the private network. Port forwarding — DNAT rule ## Steps [#steps] 1. Open your private network settings and go to the **Port forwards** tab. 2. Click **Add** and specify the parameters: protocol, public port on the router, as well as the internal IP address and port (backend) of the target VM. 3. Click **Save** to save the rule. 4. Verify the connection from the outside. ## Watch out [#watch-out] If you plan to use the [Reverse proxy](/en/docs/cloud/cloud-gateway/reverse-proxy) service, remember that TCP ports **80** and **443** will be reserved for it and cannot be used for standard port forwarding. In this case, use other public ports or configure proxy routing for the traffic. # Reverse proxy (/en/docs/cloud/cloud-gateway/reverse-proxy) You can use Cloud Gateway as a reverse proxy (powered by Caddy), which will accept HTTP and HTTPS traffic and forward it to your backend servers. It automatically obtains and renews free SSL certificates from Let's Encrypt for your domains. Reverse proxy — vhost and backend ## Steps [#steps] 1. In your DNS provider's control panel, create an **A record** pointing your domain to the public IP address of your Cloud Gateway. 2. In the hostd portal, open the **Reverse proxy** tab in your private network's settings and **enable** the service. 3. Add your domain name (hostname) and specify the private IP address and port of your target VM (backend). 4. Click **Save** to save the configuration. 5. Try opening your domain in a browser via HTTPS. If the A record is configured correctly, the system will automatically generate an SSL certificate during the first visit to the site. ## Watch out [#watch-out] Managing direct DNS records (A records) for your domain is handled entirely on the side of your DNS provider. Please note: enabling the Reverse proxy service completely reserves TCP ports **80** and **443**, as well as UDP port **443** on the Cloud Gateway, preventing them from being used for standard port forwarding. # WireGuard (/en/docs/cloud/cloud-gateway/wireguard) WireGuard allows you to create a secure VPN tunnel between your computer and your private network in the cloud. This is ideal for administrative access to databases or internal services without exposing them to the public internet. WireGuard — page overview ## Steps [#steps] 1. In your private network settings, navigate to the **WireGuard** tab. 2. If the server is not configured yet, click **Set up WireGuard server** (or **Enable** if it was previously disabled). 3. Click **Add peer** and enter a clear name for your device (for example, "Admin's Laptop"). 4. In the list of peers, open the **Peer config** menu. You can scan the QR code using the WireGuard mobile app or click **Download** to save the configuration file (`.conf`) for your desktop client. 5. Import the file into your WireGuard client, connect, and verify access (for example, by pinging the private IP address of any of your VMs). Peer config — QR code and download ## Watch out [#watch-out] The downloaded configuration is set up so that **only traffic destined for your private network** is routed through the VPN (split tunneling). All of your normal internet traffic (web browsing, YouTube, etc.) will go through your usual connection as always, without putting load on the Cloud Gateway. # High Availability (HA) (/en/docs/cloud/datacenter/high-availability) High Availability (HA) mode automatically protects your virtual machines against hardware failures. If the physical server hosting your machine fails, the platform will independently restart it on another working server. ## Steps [#steps] 1. Navigate to the `Datacenter → High Availability` section. 2. Toggle the **HA** switch for the desired virtual machine. 3. If necessary, create an **affinity rule** to define whether certain VMs should run on the same physical server or must run on different ones. 4. You can always check the current HA status on the Summary tab in the settings of a specific VM. ## Watch out [#watch-out] * Restarting a virtual machine on another server during a failure typically takes **up to one minute**. Please note that this is a hardware reboot (similar to powering on after a power outage), so it does not protect against internal failures of the operating system itself. * The High Availability feature is provided entirely **free of charge** — you only pay the standard hourly cost of your machine's vCPU and RAM. * Each affinity rule can combine between **2 and 3 VMs**. A single virtual machine can belong to only one placement rule. # Datacenter (/en/docs/cloud/datacenter) The **Datacenter** section aggregates tools for monitoring and configuring your cloud infrastructure at the level of the entire project. Viewing operation history, execution statuses, and errors. Creating and configuring templates for firewall rules. Activating high availability for virtual machines and configuring mutual placement rules (affinity rules). Managing project members and their roles (via the `Datacenter → Permissions` tab). A detailed hourly report on resource consumption and financial expenses for the current month. ## Watch out [#watch-out] Most configurations in the Datacenter section require **Admin** or **Superadmin** access permissions. Detailed financial statistics and the billing section are available exclusively to the account owner (**Superadmin**). # IP sets (/en/docs/cloud/datacenter/ip-sets) IP sets are named lists of IPv4/IPv6 addresses and CIDRs. Create a list once, then reference it in firewall rules as **source** or **destination** instead of repeating the same addresses in every rule. ## Steps [#steps] 1. Open `Datacenter → IP sets`. 2. Click **Add** and enter a short Latin name (up to **15** characters). 3. Select the IP set and click **Add address** to add hosts or CIDRs (IPv4 up to **/24**, IPv6 up to **/64**). 4. Open `VM → Firewall` (or a security group’s rules) and create or edit a rule. 5. In **Source Address** or **Destination Address**, choose the IP set from **Use IP set…**, or type `+name` manually. 6. Later changes to the IP set members apply everywhere that set is referenced. ## Watch out [#watch-out] * An IP set only affects traffic when a firewall rule uses it and the VM firewall is enabled (**Global Status** = **On** on `VM → Firewall`). * Direct CIDR in a rule is still limited to **/26**; members inside an IP set may be IPv4 up to **/24** or IPv6 up to **/64**. * Deleting an IP set clears that reference from rules that used it. # Resource usage (/en/docs/cloud/datacenter/resource-usage) The **Resource usage** tab allows the project owner (Superadmin) to track hourly expenses in Polish Zlotys (PLN) for each type of active resource in detail. Resource usage — hourly costs ## Steps [#steps] 1. Open `Datacenter → Resource usage` (only the project owner can access this section). 2. Review the hourly breakdown of costs across key categories: processors (compute), operational memory (RAM), disks (storage), **public IPv4**, backups, and Cloud Gateway. 3. Compare this data with active services in your project to understand the structure of your expenses. 4. For payments and viewing accounting documents, navigate to the `Billing` section. ## Watch out [#watch-out] * The **Public IPv4** column counts and prices **IPv4 addresses only**. Public IPv6 is not billed as a separate IP line. * The data on this page is intended for internal monitoring and budget planning. It is updated hourly but is not a financial or accounting document (official invoices are generated exclusively in the `Billing` section). # Security groups (/en/docs/cloud/datacenter/security-groups) Security Groups are templates for traffic filtering rules. They allow you to configure access rules (for example, opening ports for a web server or limiting access to a database) once and quickly apply them to multiple virtual machines. ## Steps [#steps] 1. Open the `Datacenter → Security groups` section. 2. Click **Create group** and enter a short Latin name for the group (up to **15** characters). 3. Add the required rules for incoming (**IN**) or outgoing (**OUT**) traffic inside the created group. 4. Go to the settings of the desired virtual machine, open the `VM → Firewall` tab, and click the **Insert Security Group** button to attach the created rule template. 5. In the future, any changes you make to the security group in the Datacenter section will automatically apply to all attached virtual machines. ## Watch out [#watch-out] A security group will only start filtering a virtual machine's traffic after you attach it to that VM and make sure that the firewall is enabled (the **Global Status** switch is set to the **On** position in the `VM → Firewall` settings). # Tasks (/en/docs/cloud/datacenter/tasks) The task log displays the history of all infrastructure operations in your project (such as creating virtual machines, resizing them, starting and stopping them, etc.). This helps identify which team member initiated a specific action and check its current status. Tasks — project task history To view the log, open the `Datacenter → Tasks` section. Any project member, regardless of their role, can view the detailed table: * **Start Time / End Time** — the exact start and completion times of the task. * **Operation Description** — what specific action was performed. * **Status** — the current execution status (`OK`, `running`, or an error description if something went wrong). * **User** — the email of the team member who started the task. ## Watch out [#watch-out] * This log only records operations related to cloud management at the hostd portal level. It does not display system events or logs inside the operating system of the virtual machine itself. * Automated scheduled backup jobs and High Availability (HA) automatic restart operations are part of the platform's internal system logic and are not displayed in this user actions table. # External VLAN (/en/docs/cloud/networking/external-vlan) **External VLAN** is a service that allows you to create a shared Layer 2 network environment within your zone (cluster). This enables you to combine virtual machines in the cloud with any external infrastructure located outside our platform. This allows you to connect: * Physical dedicated servers (bare metal); * Your own routers or switches; * Local infrastructure (on-premises) via your operator's or provider's transport channels. Unlike standard private networks that you can create and configure independently in the portal, setting up an **External VLAN** connection requires technical coordination and switch configuration from our side. To set up such a connection, contact our support team. # Floating IP (/en/docs/cloud/networking/floating-ip) Keep a public IPv4 reserved in the project after VM or gateway delete, and attach it to another VM or gateway later. ## How it works [#how-it-works] In hostd Public Cloud, a Floating IP is a **real public IPv4** assigned directly to the WAN interface of your VM or Cloud Gateway — not a separate virtual address mapped through 1:1 NAT, as in a typical OpenStack floating IP. * The address lives on the instance itself; traffic to that IP reaches the VM or gateway without an extra overlay or proxy hop. * Inside the guest OS you see the same public address on the network interface (for example `net0` on a VM). * **Floating** means the IPv4 stays in your project when you delete the VM or gateway, so you can attach it to another resource later — not that the address is virtual. ## Before you begin [#before-you-begin] * A public IPv4 assigned to a VM or Cloud Gateway, or already reserved in the project. ## Steps [#steps] 1. Check the address in `Network → Public IPs`. 2. When deleting a VM or gateway, turn off **Release public IP address** to keep the IP reserved in the project. 3. When creating another VM or gateway, select the reserved IP instead of **Auto**. 4. To change the public IP on the same VM: in [Resize VM](/en/docs/cloud/virtual-machines/resize), turn WAN (net0) off, save, then turn WAN on again and choose **Auto** or another reserved address. ## Watch out [#watch-out] * While WAN is on, you cannot swap to another address directly — turn the public interface off first. * Changing the WAN IP does not require a VM reboot. # Networking (/en/docs/cloud/networking) This section contains instructions for configuring public IP addresses, creating private networks (VLANs), and managing your project's network topology. A visual topology of your project, showing active connections and VM statuses. Real public IPv4 addresses for your virtual machines and gateways, with the ability to reserve and reuse them. Configuring reverse DNS (PTR) records for public IP addresses. Creating isolated local networks (VLANs) and configuring internal address allocation (IPAM). Connecting a dedicated Layer 2 channel to your physical or external infrastructure (outside the cloud). Configuring NAT, WireGuard VPN, port forwarding, and a reverse proxy on a virtual router. ## Watch out [#watch-out] If you want to reassign a public IP address to another virtual machine, first disable the public interface (WAN) in the `VM → Resize` section, save the settings, and then connect the interface again by selecting your desired reserved address. This works without requiring an operating system reboot. # Network map (/en/docs/cloud/networking/network-map) The **Network map** tab provides an intuitive logical schema of your entire project infrastructure, displaying the connections between the public internet, Cloud Gateway, private networks, and virtual machines. Network map in the portal ## What is displayed on the schema [#what-is-displayed-on-the-schema] 1. **WAN Node** (on the left) — shows the status of your public IPv4 address pool: the total number of addresses in the project, how many of them are currently in use, and how many remain free. 2. **Virtual Machines** (cards) — display the machine name, its public and private IP addresses, current power status, vCPU/RAM configuration, and load graph. Clicking on a VM name allows you to quickly navigate to its detailed settings. 3. **Private Networks** (circles with the name **vnet** and CIDR subnet) — visualize your internal VLANs. All machines connected to a local network are linked by lines to the corresponding subnet circle. 4. **Cloud Gateway** — displayed at the intersection of the public internet and your private network. Clicking on the gateway name opens the settings for WireGuard, reverse proxy, or port forwarding. 5. **Power Management and Console** — on the card of each running VM, there is a console icon (**Open Console in New Window**), and via the three-dots menu `⋯` you can quickly restart or stop the machine. ## Watch out [#watch-out] * This page is designed solely for visual monitoring and quick navigation. To change network or interface parameters, you must go to the appropriate sections (for example, `VM → Resize` or the settings of a specific private network). * Animated lines leading to virtual machines indicate that the server is currently running (status **running**). Cloud Gateway lines are always animated. This is a visual indicator of activity status and not a real-time network traffic graph. * Virtual machines that are not connected to any network are grouped and displayed separately on the right side of the screen. # Private network (/en/docs/cloud/networking/private-network) A private network (local VLAN) allows you to combine your virtual machines into an isolated Layer 2 network segment. Traffic within such a network is completely protected from external access and is not metered or billed. Private network — list and VLAN layout ## Steps [#steps] 1. Open the `Network → Private networks` section. 2. Click **New** and create an internal VLAN, specifying your desired IPv4 subnet range (CIDR). 3. If virtual machines in this local network require secure internet access (NAT) or other network services, enable the **Enable Cloud Gateway** option. 4. Connect your virtual machines to the created network (this can be done either during the creation of a new VM or on a running machine via the `VM → Resize` section). 5. You can view the list of allocated addresses and manage them under the **IPAM** tab in your private network's settings. # PTR / reverse DNS (/en/docs/cloud/networking/ptr) A reverse DNS record (PTR record) is used to verify that your public IP address matches a domain name. Most commonly, a correct PTR record is necessary for the stable operation of mail servers (to prevent your emails from ending up in spam) or for access authorization and monitoring systems. Editing PTR in Network → IP Addresses ## Steps [#steps] 1. Navigate to the `Network → Public IPs` section. 2. Select the desired public IP address and click on the **PTR** edit field. 3. Enter your domain name (FQDN) that you want to associate with this address. 4. Click **Save** to save the changes. ## Watch out [#watch-out] Managing direct DNS records for your domain (such as A, MX, CNAME, TXT) is handled on the side of your DNS provider (for example, Cloudflare or your domain registrar). Configuring PTR in our portal works exclusively for the reverse lookup of public IPv4 addresses allocated by our platform. # Projects (/en/docs/cloud/projects) A project in our system is the primary tool for grouping and isolating your cloud resources. Project overview — VM list and resource limits ## What a project consolidates [#what-a-project-consolidates] * Virtual machines and operations on them (starting, stopping, restarting, resizing); * Network infrastructure (private VLAN networks, dedicated public IP addresses, Cloud Gateway); * Backup system (personal backup schedules and a dedicated PBS datastore); * Access permissions, security groups, High Availability, and task log; * Financial statistics of project expenses (available only to the account owner). ## Watch out [#watch-out] You can delete a project only after all virtual machines and private networks have been completely removed from it. Project deletion is irreversible: it automatically releases all your public IP addresses, completely clears the backup storage (PBS datastore), and permanently deletes all backups. # Project costs (/en/docs/cloud/projects/resource-usage) All current charges and financial analytics of your project are calculated hourly in Polish Zlotys (PLN). These statistics are available exclusively to the project owner (**Superadmin**) on the `Datacenter → Resource usage` page. Other team members with Admin or Auditor roles do not see financial information. Detailed information on how to properly read the consumption report and compare it with active services can be found in the [Resource usage](/en/docs/cloud/datacenter/resource-usage) section. # Team access (/en/docs/cloud/projects/team-access) You can work on a project together with your colleagues or partners. Managing access and member roles is restricted to the project owner — the user with the **Superadmin** role. Add user and role ## Steps to grant access [#steps-to-grant-access] 1. Navigate to the `Datacenter → Permissions` section. 2. Click the **Add permission** button. 3. Enter the email address of the user who has a registered hostd account and select their role (**Admin** or **Auditor**). 4. If necessary, you can always revoke access or change a user's role on the same list. ## Available system roles [#available-system-roles] | Role | Access Permissions | | -------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | **Superadmin** | Project owner. Has full rights: managing members, viewing billing and financial expenses, creating, modifying, and deleting any VMs and networks. | | **Admin** | Technical administrator. Has full access to infrastructure management (creating, resizing, deleting VMs, network configuration) but cannot see financial information or the team access management section. | | **Auditor** | Observer. Has read-only access to view VM and network parameters without the right to make any changes. | ## Watch out [#watch-out] To successfully add a team member, they must already have a registered account in the hostd system. Immediately after entering their email address, the project will instantly appear in their personal control panel. # VM backups and restore (/en/docs/cloud/virtual-machines/backups-restore) Restore a full VM from a selected PBS backup. ## Before you begin [#before-you-begin] * VM must be **stopped** before restore. * A backup copy exists on `VM → Backups`. ## Steps [#steps] 1. Stop the VM. 2. Open `VM → Backups`. 3. Select a backup and click **Restore**. 4. Choose the start-after-restore option if available and needed. 5. After completion, verify the VM and applications. ## Watch out [#watch-out] * Restore requires a stopped VM. * HA VMs: turn off autostart for restore — restore will not start with autostart enabled. Start the VM manually after completion. * To protect, delete, or download individual files from a backup, use **Backup → Datastore** — the VM Backups page is restore-only. # SSH and console (/en/docs/cloud/virtual-machines/connect-console) To manage your virtual machine, you can connect to it over the network via SSH (primary method) or use the noVNC web console built into the portal (emergency method if the network is unavailable). noVNC console ## Before you begin [#before-you-begin] * The virtual machine must be in the **running** state. * Make sure you remember the username you specified during the VM creation or reinstallation. * If connecting via SSH over the internet (WAN): the machine must have a public IP address, and you must have the corresponding private SSH key configured on your computer. ## Connection methods [#connection-methods] ### 1. Connecting via SSH (Recommended) [#1-connecting-via-ssh-recommended] Open a terminal on your computer and execute the connection command (if your private key is saved in the default path `~/.ssh/id_rsa` or `~/.ssh/id_ed25519`, the `-i` parameter is not required): ```bash ssh username@public_ip ``` If you are using a key with a custom name or path: ```bash ssh -i ~/.ssh/id_rsa username@public_ip ``` ### 2. Connecting via noVNC web console [#2-connecting-via-novnc-web-console] If the network is disabled on the machine, ports are blocked, or you are experiencing issues with SSH key configuration: 1. Go to your VM settings and open the `VM → Console` tab (or click the **Open Console in New Window** button). 2. Log into the system by entering your username and the password you specified during VM creation or system reinstallation. ## Watch out [#watch-out] On all our standard Linux images, SSH password authentication is disabled by default. If you try to connect via SSH using a password, you will receive an access error (Permission denied). To enable password login, please refer to our [dedicated guide](/en/docs/cloud/virtual-machines/ssh-password-login). # Create a VM (/en/docs/cloud/virtual-machines/create) Creating a Linux VM: image, CPU mode, resources, SSH keys, and networking. Create a VM — form with image, SSH key, and WAN ## Before you begin [#before-you-begin] * Access to the project with Admin or Superadmin role. ## Steps [#steps] 1. Open the project and click **Create VM**. 2. Choose an image, hostname, and username, and set a password. We do not store passwords — you cannot view it in the portal later. 3. Set **CPU mode** (Performance, Eco, or Slim), vCPU, RAM, and OS disk using the form tiers. 4. Add SSH keys. 5. Choose networking: public WAN mode (**Off**, **IPv4**, **IPv6**, or **IPv4 + IPv6**), a private network LAN interface, or both. 6. Click **Create** and wait about a minute (initial system setup runs in the background). ## Watch out [#watch-out] * On all Linux images, SSH password login is disabled — only SSH keys work. To enable password SSH, see [SSH password login](/en/docs/cloud/virtual-machines/ssh-password-login). * Minimum vCPU is **2**, step is **2**. RAM and OS disk are chosen from tiers based on vCPU count. * The system disk is limited to **20,000 IOPS** and **1,000 MB/s** (read and write). See [Storage](/en/docs/cloud/storage). * Public WAN modes: **Off** (no public address), **IPv4**, **IPv6**, or **IPv4 + IPv6**. On an attached VM you can only switch **Off ↔ the same mode**; to change between IPv4 / IPv6 / dual-stack, turn WAN off first. * Hourly **public IP** billing applies to **IPv4 only**. Public IPv6 is included without a separate IP charge. * HA is not enabled at create time; enable it later in `Datacenter → High Availability`. # Delete a VM (/en/docs/cloud/virtual-machines/destroy) Delete a VM and choose what happens to backups and the public IP. Destroy VM — backup and public IP options ## Before you begin [#before-you-begin] * VM must be **stopped**. * Decision on whether to delete VM backups and release or keep the public IP. ## Steps [#steps] 1. Stop the VM. 2. Open `VM → Destroy`. 3. Choose whether to delete VM backups. 4. Choose whether to **release** the public IP or **keep it reserved** in the project. 5. Confirm delete. ## Watch out [#watch-out] A kept floating IP continues to bill, but you can attach it to another VM or gateway later. # Firewall and security groups (/en/docs/cloud/virtual-machines/firewall-security-groups) On VM WAN you add your own firewall rules or insert security groups created under `Datacenter → Security groups`. Create firewall rule — modal ## Before you begin [#before-you-begin] * VM with a WAN (`net0`) interface. * Admin or Superadmin access to the project. ## Steps — rule on the VM [#steps--rule-on-the-vm] 1. Open `VM → Firewall`. 2. Set **Global Status** to **On**, **Policy In** to **DROP**, and click **Apply** if the firewall is off. 3. Click **Add rule**. 4. Fill in the **Create firewall rule** dialog (see below) and click **Add**. 5. Check rule order in the table — within each direction, rules apply top to bottom. ### Fields in **Create firewall rule** [#fields-in-create-firewall-rule] * **Type** — **IN** (traffic to the VM) or **OUT** (traffic from the VM). * **Action** — **ACCEPT** (allow) or **DROP** (deny). * **Protocol** — **TCP**, **UDP**, or **ICMP**. * **Source Address** — sender address or CIDR; active for **IN**, greyed out for **OUT**. * **Destination Address** — recipient address or CIDR; active for **OUT**, greyed out for **IN**. * **Source Port** — source port (e.g. `80`, `80:85`, `80,443`); usually empty for **IN**, fill in for **OUT**. * **Destination Port** — destination port; fill in for **IN** (e.g. `22` for SSH), usually empty for **OUT**. * **Comment** — optional note. * **Enabled** — disabled rules stay in the list but are not applied. ## Security groups [#security-groups] Insert Security Group on VM Firewall To reuse the same rules on many VMs, create a security group under [Security groups](/en/docs/cloud/datacenter/security-groups), then on the VM firewall click **Insert Security Group** and choose the group. ## Watch out [#watch-out] * Portal VM firewall applies to WAN (`net0`) only. LAN interfaces are not filtered by this firewall. * CIDR in rules is limited to **/26** maximum. * Outbound SMTP (ports 25 / 465 / 587) is blocked at the network edge by default, independent of these rules — see [Outbound email (SMTP)](/en/docs/cloud/virtual-machines/outbound-email). # Virtual machines (/en/docs/cloud/virtual-machines) Links to VM lifecycle guides: create, connect, resize, backups, and delete. Image, username, CPU mode, resources, SSH keys, WAN/LAN. When to use SSH and when to use noVNC. Enable SSH password login on Linux. CPU/RAM/disk/NIC and downgrade limits. Reinstall the OS from an image. One fast rollback point. Restore a selected backup. Backups and floating IP during delete. WAN rules and Datacenter groups. ## Watch out [#watch-out] A powered-off VM no longer bills CPU and RAM, but disk, floating IPs, backups, and other active project resources still bill. # Outbound email (SMTP) (/en/docs/cloud/virtual-machines/outbound-email) Outbound email from instances (SMTP on ports **25**, **465**, and **587**) is **blocked by default** at the hostd network edge. This applies even when Proxmox VM firewall rules allow the traffic. We do this to protect the reputation of our IP ranges. ## Status in the portal [#status-in-the-portal] On **VM → Firewall** you see whether outbound email is **Blocked** or **Allowed** for that instance. ## Request an unlock [#request-an-unlock] 1. Open **VM → Firewall**. 2. Use **Request unlock**. 3. Describe the purpose, the sending domain(s), and the expected volume. 4. Submit — a support ticket is created. You can follow it under **Support**. We review the request (typical checks: legitimate use, domains, account history). After approval, outbound email is unlocked for the instance. ## Watch out [#watch-out] * Unlock is per instance / its public IP(s). If the public IP changes, contact support so we can update the allowlist. * Guest or Proxmox firewall rules alone cannot open outbound SMTP while the edge block is in place. * Configure SPF, DKIM, and DMARC for domains you send from. # Reinstall a VM (/en/docs/cloud/virtual-machines/reinstall) Wipe the system disk and reinstall the OS from a portal image. CPU, RAM, OS disk size, network interfaces, and their MAC addresses stay unchanged. VM Reinstall — OS image, credentials, and SSH keys ## Before you begin [#before-you-begin] * VM must be **stopped**. * If the system disk has data you need to keep, make sure backups exist in `VM → Backups`. ## Steps [#steps] 1. Stop the VM. 2. Open `VM → Reinstall`. 3. Choose an OS image, hostname, and username, and set a password. We do not store passwords — you cannot view it in the portal later. 4. Add SSH keys. 5. Run reinstall and optionally start the VM after completion. ## Watch out [#watch-out] * Reinstall deletes all data on the system disk. * Reinstall removes the VM snapshot if one exists. # Resize a VM (/en/docs/cloud/virtual-machines/resize) Change CPU mode, vCPU, RAM, disk size, and network interfaces. VM Resize — CPU mode, vCPU, RAM, and networking ## Before you begin [#before-you-begin] * Admin or Superadmin access to the project. * While the VM is **running**, you can increase vCPU, RAM, and OS disk, change **CPU mode**, and edit WAN/LAN interfaces. * To lower CPU or RAM: VM must be **stopped**. ## Steps [#steps] 1. Open `VM → Resize`. 2. Change **CPU mode**, vCPU, and RAM within available tiers. 3. Grow the OS disk if you need more space. 4. Change WAN or private NICs and review the access impact. To change the public IP: turn WAN off, save, turn WAN on again, and choose **Auto** or a reserved address (no VM reboot). 5. Click **Save**. ## Watch out [#watch-out] * Lowering vCPU, RAM, or moving to a weaker **CPU mode** (e.g. Performance → Eco): at most **once per day** per VM. Lowering vCPU/RAM requires a stopped VM. * OS disk can only grow; it cannot shrink. * **CPU mode** can be changed while the VM is running. # Snapshots (/en/docs/cloud/virtual-machines/snapshots) Create one user snapshot per VM and roll back if needed. ## Before you begin [#before-you-begin] * Admin or Superadmin access to the VM. * No existing snapshot on the VM — you can have only **one**. ## Steps [#steps] 1. Open `VM → Snapshots`. 2. Click **Create snapshot** before changing the system. 3. After testing, delete the snapshot or use **Rollback** if the change failed. ## Watch out [#watch-out] A snapshot is not a backup. You can have only one snapshot per VM. # Enable SSH password login (/en/docs/cloud/virtual-machines/ssh-password-login) On Linux images, hostd disables SSH password login by default. This guide explains how to turn it on manually in the guest OS. ## Before you begin [#before-you-begin] * VM in **running** state. * Access to the VM by SSH key or [noVNC console](/en/docs/cloud/virtual-machines/connect-console). * VM user password from [create](/en/docs/cloud/virtual-machines/create) or [reinstall](/en/docs/cloud/virtual-machines/reinstall). ## Steps [#steps] 1. Sign in to the VM by SSH key or `VM → Console`. 2. Create `/etc/ssh/sshd_config.d/99-password-auth.conf` with the line `PasswordAuthentication yes`. 3. Restart SSH: `systemctl restart ssh` (Debian, Ubuntu) or `systemctl restart sshd` (AlmaLinux, Rocky Linux). 4. Connect by SSH with the VM user password. ## Watch out [#watch-out] * Password login is less secure than SSH keys — enable it only if you really need it. * After [reinstall](/en/docs/cloud/virtual-machines/reinstall), initial system setup disables SSH password login again — repeat these steps if you still need password SSH. * If SSH does not respond, check the [VM firewall](/en/docs/cloud/virtual-machines/firewall-security-groups) and the guest OS firewall.