FAQ

Često postavljana pitanja

Praktični kratki vodiči za postavljanje usluge, pristup i uobičajene radnje korisnika.

> Kreiranje javnog SSH ključa u terminalu

Napravi javni SSH ključ za pristup i dijeli samo javni dio.
faq/generate-public-ssh-key-bs

Koristi samo javni ključ

SSH koristi par ključeva. U postavke usluge zalijepi samo javni ključ, obično .pub datoteku. Privatni ključ ostaje na tvom uređaju.

Koraci u terminalu

  1. Otvori Terminal, Windows Terminal ili PowerShell.
  2. Pokreni: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Prihvati zadanu lokaciju ili izaberi sigurnu putanju.
  4. Prikaži javni ključ s: cat ~/.ssh/id_ed25519.pub.
  5. U Windows PowerShell koristi: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Kopiraj cijelu ssh-ed25519 liniju u polje SSH public key.

Provjeri prije lijepljenja

Ne kopiraj privatni ključ. Ako postaviš passphrase, sačuvaj je sigurno.

> Kreiranje SSH ključa grafički u Windowsu

Koristi PuTTYgen u Windowsu i kopiraj samo javni ključ.
faq/create-ssh-key-windows-gui-bs

Dovoljan je javni dio

PuTTYgen pravi javni i privatni ključ. U Cli>_ dodaj samo javni ključ, a privatni čuvaj lokalno.

Koraci u Windowsu

  1. Otvori PuTTYgen.
  2. Izaberi EdDSA / Ed25519 kada je dostupno.
  3. RSA 4096 koristi samo kao rezervu.
  4. Klikni Generate i pomjeraj miš dok se ključ ne napravi.
  5. Sačuvaj privatni ključ na računaru.
  6. Kopiraj tekst javnog ključa u polje SSH public key.

Ne dijeli tajne podatke

Ne šalji .ppk datoteke, privatne ključeve, passphrase, lozinke ili tokene podršci ili formularima.

> Povezite vlastitu domenu

Prije prebacivanja domene provjeri registrar, autoritativne nameservere, tačan hostname, apex ili subdomenu, tip zapisa i konflikte.
faq/povezite-vlastitu-domenu

Najvažniji je tačan hostname

Prvo odluči povezuješ li apex domenu kao example.com ili subdomenu kao app.example.com. Od toga zavisi jesu li dozvoljeni CNAME, A/AAAA, ALIAS ili ANAME zapisi i gdje ih uređuješ.

Prije DNS izmjene

  1. Potvrdi da uređuješ DNS kod autoritativnih nameservera ili registrara.
  2. Ukloni konfliktne A/AAAA, CNAME, ALIAS, ANAME ili redirect zapise za isti hostname.
  3. Koristi tip zapisa koji odgovara hostnamu i podršci DNS provajdera.
  4. Sačekaj DNS propagaciju i provjeru certifikata prije produkcionog prebacivanja.

Siguran rollback

Stari hosting ne gasi dok novi hostname ne odgovara ispravno. Za pomoć pošalji domenu, očekivani cilj i javno vidljiv DNS rezultat, a ne pristup registraru ili API tokene.

> Prijenos DNS zone

A/AAAA vode na adrese, CNAME na alias, MX na poštu, TXT na verifikacije, SPF, DKIM i DMARC, a CAA može uticati na certifikate.
faq/prijenos-dns-zone

Svaki zapis ima svoju ulogu

A i AAAA pokazuju na IP adrese, CNAME pravi alias za dozvoljenu subdomenu, MX usmjerava poštu, TXT nosi verifikacije i mail politike, a CAA ograničava certifikacione autoritete.

Kopiranje DNS vrijednosti

  1. Prepiši naziv, tip i vrijednost tačno kako usluga traži.
  2. Ne stavljaj CNAME na hostname koji već ima konfliktne zapise ako DNS pravila to zabranjuju.
  3. DKIM postavi pod selector provajdera, a DMARC najčešće pod _dmarc.
  4. CAA mijenjaj pažljivo jer pogrešna vrijednost može blokirati certifikat.

Dijagnostika DNS problema

Podršci pošalji hostname, tip zapisa, očekivanu vrijednost i javno vidljiv rezultat. Ne šalji login za DNS panel, API token ili screenshot s tajnim vrijednostima.

> Registracija računa i prvo prijavljivanje

Koristi jedan radni račun za narudžbe, naplatu i upravljanje uslugama, s e-mail adresom kojoj tim dugoročno ima pristup.
faq/account-registration-and-login

Račun koji ostaje u timu

Korisnički račun povezuje narudžbe, fakturisanje, domene i usluge. Najsigurnije je koristiti poslovni e-mail kojem tim može pristupiti i nakon promjena u osoblju, a ne privatnu adresu jedne osobe.

Prije prve narudžbe

  1. Registruj se radnom e-mail adresom.
  2. Potvrdi e-mail ako sistem traži verifikaciju.
  3. Dopuni podatke za fakturisanje prije plaćene narudžbe.
  4. Uključi dvofaktorsku zaštitu kada bude dostupna.

Pristup bez dijeljenja tajni

Lozinku ne šalji kolegama niti podršci. Ako više ljudi treba raditi s računom, koristite interni password manager ili dogovoreni timski postupak; podršci nisu potrebni lozinka ni privatni token.

> Kako funkcioniše prepaid kredit

Prepaid kredit prikazuje stanje, procjenu trajanja, dnevni trošak aktivnih usluga i rizik suspenzije ili vidljivog roka brisanja.
faq/prepaid-credit-how-it-works

Kredit se troši dok usluga radi

Kod podobnih usluga kredit se smanjuje tokom aktivnog rada prema odabranim resursima i opcijama. Vidljivo stanje, procjena koliko dana preostaje i dnevna cijena pomažu da dopunu planiraš prije suspenzije.

Kako izbjeći prekid

  1. Dopuni kredit iz korisničke zone s dovoljno rezerve.
  2. Prije potvrde narudžbe ili izmjene provjeri novu dnevnu cijenu.
  3. Prati upozorenja o niskom stanju, suspenziji i vidljivom roku brisanja.
  4. Kod suspendovane usluge reaguj prije roka nakon kojeg podaci mogu biti obrisani.

Ako stanje ne izgleda očekivano

Za provjeru pošalji broj narudžbe, naziv usluge i period koji treba pregledati. Ne šalji kartične podatke, lozinke, privatne ključeve ili pune izvode s osjetljivim informacijama.

> Mjesečna procjena, godišnja procjena i dnevno trošenje kredita

Mjesečne i godišnje cijene služe za poređenje; prepaid usluge stvarno troše kredit dnevno nakon potvrde, plaćanja ako treba i primjene izmjene.
faq/billing-periods-and-credit-burn

Procjena nije kalendar računa

Mjesečna procjena koristi 31 dan, a godišnja 372 dana radi lakšeg poređenja. Kod prepaid usluga stvarna potrošnja zavisi od aktivnog vremena, CPU-a, RAM-a, diska i plaćenih opcija.

Prije prihvatanja nove cijene

  1. Uporedi dnevnu potrošnju prije i poslije promjene.
  2. Uračunaj da veći CPU, RAM, disk ili dodatne opcije mijenjaju cijenu.
  3. Promjenu smatraj aktivnom tek kad je potvrđena, plaćena ako treba i primijenjena.
  4. Sačuvaj potvrde narudžbi i vidljivu historiju kredita za računovodstvo.

Provjera naplate

Podršci pošalji broj narudžbe, naziv usluge i datume koje treba provjeriti. Ne šalji cijele bankovne izvode, kartične podatke ili screenshotove sa nepotrebnim ličnim podacima.

> Status narudžbe nakon plaćanja

Narudžba može kratko čekati potvrdu pružatelja plaćanja; duplikat pravi tek kad je prva narudžba jasno istekla ili otkazana.
faq/order-status-and-payment-confirmation

Pending ne znači odmah neuspjeh

Nakon plaćanja narudžba može ostati na čekanju dok pružatelj plaćanja ne pošalje potvrdu. Nova narudžba prije jasnog isteka ili otkazivanja može otežati uparivanje plaćanja.

Koraci nakon plaćanja

  1. Vrati se sa stranice za plaćanje nazad u Cli>_.
  2. U računu provjeri vidljiv status narudžbe.
  3. Ako je status pending, sačekaj potvrdu pružatelja plaćanja.
  4. Ako se status ne mijenja, pošalji broj narudžbe i referencu plaćanja ako je vidiš.

Šta nije potrebno slati

Podršci ne trebaju broj kartice, lozinka računa ili kompletna bankovna potvrda. Dovoljni su broj narudžbe, vrijeme plaćanja, vidljiv status i maskiran screenshot greške ako postoji.

> Podaci koji ubrzavaju podešavanje usluge

Pripremi naziv usluge, domenu, DNS plan, resurse, admin e-mail i javni SSH ključ; tajne vrijednosti ne idu u formulare.
faq/service-setup-information-needed

Tačni ulazi smanjuju čekanje

Formulari za narudžbu traže vrijednosti poput naziva usluge, domene, DNS cilja, storagea, CPU-a, RAM-a, pristupnog e-maila ili javnog SSH ključa. Lozinke, privatni ključevi i tokeni ne pripadaju tim poljima.

Priprema prije checkouta

  1. Izaberi naziv usluge koji će tim prepoznati.
  2. Pripremi tačnu domenu ili odluči koristiti privremeni hostname.
  3. Spremi javni SSH ključ ako ga proizvod traži.
  4. Provjeri potrebne resurse i veličinu diska prema aplikaciji.

Ako nisi siguran šta je tajno

Pitaj bez slanja same vrijednosti. Privatne ključeve, lozinke, API tokene, baze podataka i kompletne konfiguracije ne šalji kroz narudžbu ili tiket.

> Promjena CPU-a, RAM-a, diska ili retencije nakon narudžbe

Postojeću uslugu mijenjaj iz njenog detalja, uz provjeru nove cijene, dnevnog troška, plaćanja, restarta, zastoja i potrebe za exportom.
faq/change-service-resources-after-order

Mijenjaš postojeću uslugu

Ako usluga već radi, promjenu resursa pokreni iz njenog detalja. Nova narudžba najčešće znači novu uslugu, dok izmjena postojeće mijenja dnevnu potrošnju tek nakon potvrde, eventualnog plaćanja i primjene.

Provjera prije potvrde

  1. Pogledaj trenutni CPU, RAM, disk, backup retenciju i Offsite Archive retenciju.
  2. Provjeri novu cijenu i uticaj na dnevnu potrošnju kredita.
  3. Pročitaj upozorenje o restartu, održavanju ili prekidu rada.
  4. Prije rizične izmjene napravi vlastiti export važnih podataka.

Ako izmjena ne prođe očekivano

Pošalji naziv usluge, vrijeme izmjene, vidljiv status i tekst greške. Ne šalji lozinke, privatne ključeve, tokene ili konfiguracije s tajnim vrijednostima.

> Otkazivanje usluge i rok brisanja podataka

Provisioned usluga se prvo suspenduje, prikazuje podesiv vidljiv rok brisanja, a trajno čišćenje dolazi nakon životnog ciklusa.
faq/cancel-service-and-data-retention

Otkazivanje nije uvijek trenutno brisanje

Kod već provisioned usluge otkazivanje prvo dovodi do suspenzije i prikaza podesivog vidljivog roka brisanja. Neplaćene narudžbe koje nikada nisu pokrenule podatke mogu imati drugačiji tok.

Prije otkazivanja

  1. Napravi vlastiti export podataka koje želiš zadržati.
  2. Pročitaj datum i vrijeme mogućeg brisanja prikazane kod usluge.
  3. Ne miješaj backup retenciju i Offsite Archive retenciju s brisanjem same usluge.
  4. Kontaktiraj podršku prije roka ako nisi siguran šta će biti obrisano.

Nakon roka oporavak nije siguran

Kada vidljiv rok prođe, ne treba računati da su podaci i dalje dostupni. U tiketu navedi broj narudžbe i naziv usluge, ali ne šalji export baze ili tajne pristupne podatke.

> Backup i zahtjevi za restore

Backup služi za operativni oporavak, ne kao zamjena za vlastiti export; restore može prepisati novije podatke.
faq/backups-and-restore-requests

Backup nije arhiva za sve potrebe

Retencija zavisi od proizvoda i odabranih opcija. Backup pomaže kod operativnih grešaka, ali ne zamjenjuje poslovni export, dugoročnu arhivu ili Offsite Archive; restore može vratiti starije stanje preko novijih izmjena.

Dobar restore zahtjev

  1. Navedi naziv usluge i broj narudžbe.
  2. Napiši približno vrijeme na koje želiš povratak.
  3. Objasni treba li cijela usluga ili određeni dio ako je podržano.
  4. Dodaj vidljivu grešku ili kontekst bez lozinki, tokena i privatnih ključeva.

Planiraj uticaj oporavka

Ako su korisnici nastavili rad nakon željenog vremena oporavka, noviji podaci mogu biti izgubljeni. Prije potvrde restorea obavijesti tim i sačuvaj ono što ne želiš prepisati.

> Čemu služi Offsite Archive

Offsite Archive čuva udaljene arhivske kopije odvojeno od kratkih operativnih backupova i od životnog ciklusa usluge.
faq/offsite-archive-purpose

Arhiva izvan svakodnevnog rada

Offsite Archive je za udaljene kopije i duže čuvanje podataka. Nije live disk aplikacije, nije zamjena za lokalni export i nije isto što i kratki backup za operativni restore.

Kada ga koristiti

  1. Uključi ga za podatke koje želiš zadržati izvan redovnog životnog ciklusa usluge.
  2. Odaberi broj dana retencije prema pravilima ili recovery cilju.
  3. Računaj da cijena raste s količinom podataka i vremenom čuvanja.
  4. Za velike skupove podataka planiraj i vlastiti export proces.

Kako se čita cijena

Osnova su MB-days: koliko megabajta je sačuvano i koliko dana se drže. Cijena se prikazuje kao EUR/GB/mjesec, a obračun se zaokružuje na cijele cente.

> Izbor CPU-a, RAM-a i diska za VPS

Veličinu VPS-a biraj prema aplikaciji, bazi, cacheu, logovima i rastu; OOM, out of memory i process killed ukazuju na manjak RAM-a.
faq/vps-cpu-ram-and-disk-sizing

Kreni od stvarnog opterećenja

Statična stranica, baza podataka, Java aplikacija, pretraga ili build proces imaju različite potrebe. Pri planiranju uključi memoriju aplikacije, cache, bazu, logove, upload datoteke i rezervu za rast.

Kada povećati resurse

  1. Povećaj RAM kod OOM, out of memory, process killed poruka ili stalnog swapovanja.
  2. Povećaj CPU kod dugog compute opterećenja, kompresije, buildova ili zauzetih workera.
  3. Povećaj disk prije nego što filesystem, logovi ili baza dođu do limita.
  4. Nakon izmjene prati da li je nestao izvorni problem.

Kontekst za sizing pitanje

Korisno je poslati naziv usluge, tip aplikacije, vidljivu grešku, približno vrijeme problema i trenutne CPU, RAM i disk vrijednosti. Ne šalji lozinke, privatne ključeve ili kompletne interne konfiguracije.

> Kada VPS treba javnu IP adresu

Dedikovana javna IP pomaže kod allowlista, inbound pristupa, stabilnog outbound izvora i servisa vezanih za adresu.
faq/vps-public-ip-options

Prvo utvrdi smjer saobraćaja

Javna IP nije potrebna za svaku aplikaciju. Najčešće je traže vanjski partneri, provajderi ili firewall pravila koja očekuju stabilnu adresu za inbound pristup, outbound izvor ili oba smjera.

Pitanja prije naručivanja IP-a

  1. Pitaj partnera da li allowlist vrijedi za inbound, outbound ili oba smjera.
  2. Koristi DNS imena umjesto numeričkih adresa gdje je moguće.
  3. Otvori samo portove koje aplikacija zaista koristi.
  4. Podijeli allowlist zahtjev s podrškom prije promjene produkcionog pristupa.

Javna adresa nije otvoren server

Dedikovana IP ne znači da treba otvoriti sve portove. Pristup drži na minimalnim potrebnim servisima i ne šalji privatne ključeve, lozinke ili screenshotove firewall pravila s osjetljivim vrijednostima.

> Dijeljeni SSH pristup za VPS

Bez dedikovane javne IP VPS koristi dijeljeni SSH pristup preko visokog porta; javna IP može omogućiti direktan SSH samo ako je tako podešeno.
faq/shared-ssh-access-for-vps

Zašto postoji visok port

Više VPS usluga može dijeliti isti javni SSH host, pa svaka dobija svoj visoki port. Taj port usmjerava vezu do tvoje konkretne VPS usluge; bez njega dijeljeni host ne bi znao kojoj mašini proslijediti vezu.

Kako se povezati

  1. Za dijeljeni SSH kopiraj SSH korisničko ime, javni host i visoki port sa stranice usluge.
  2. Koristi komandu ssh -p <port> <username>@<public-host>.
  3. Ako usluga ima dedikovanu javnu IP, direktan SSH na tu IP adresu radi samo ako su SSH servis i firewall pravilo za to podešeni.
  4. Privatni ključ koristi samo lokalno kroz SSH klijent ili agent.

Dva moguća SSH puta

Dedikovana javna IP ne ukida automatski dijeljeni pristup i ne znači da je port 22 otvoren. Ona može dodati direktan pristup za allowlist, monitoring ili integracije. U podršku šalji samo javni host, port, korisničko ime i vidljivu grešku, nikad privatni ključ.

> Provjera prije povezivanja vlastite domene

Prije prebacivanja domene provjeri registrar, autoritativne nameservere, tačan hostname, apex ili subdomenu, tip zapisa i konflikte.
faq/custom-domain-readiness-checklist

Najvažniji je tačan hostname

Prvo odluči povezuješ li apex domenu kao example.com ili subdomenu kao app.example.com. Od toga zavisi jesu li dozvoljeni CNAME, A/AAAA, ALIAS ili ANAME zapisi i gdje ih uređuješ.

Prije DNS izmjene

  1. Potvrdi da uređuješ DNS kod autoritativnih nameservera ili registrara.
  2. Ukloni konfliktne A/AAAA, CNAME, ALIAS, ANAME ili redirect zapise za isti hostname.
  3. Koristi tip zapisa koji odgovara hostnamu i podršci DNS provajdera.
  4. Sačekaj DNS propagaciju i provjeru certifikata prije produkcionog prebacivanja.

Siguran rollback

Stari hosting ne gasi dok novi hostname ne odgovara ispravno. Za pomoć pošalji domenu, očekivani cilj i javno vidljiv DNS rezultat, a ne pristup registraru ili API tokene.

> Tipovi DNS zapisa za usluge

A/AAAA vode na adrese, CNAME na alias, MX na poštu, TXT na verifikacije, SPF, DKIM i DMARC, a CAA može uticati na certifikate.
faq/dns-record-types-for-services

Svaki zapis ima svoju ulogu

A i AAAA pokazuju na IP adrese, CNAME pravi alias za dozvoljenu subdomenu, MX usmjerava poštu, TXT nosi verifikacije i mail politike, a CAA ograničava certifikacione autoritete.

Kopiranje DNS vrijednosti

  1. Prepiši naziv, tip i vrijednost tačno kako usluga traži.
  2. Ne stavljaj CNAME na hostname koji već ima konfliktne zapise ako DNS pravila to zabranjuju.
  3. DKIM postavi pod selector provajdera, a DMARC najčešće pod _dmarc.
  4. CAA mijenjaj pažljivo jer pogrešna vrijednost može blokirati certifikat.

Dijagnostika DNS problema

Podršci pošalji hostname, tip zapisa, očekivanu vrijednost i javno vidljiv rezultat. Ne šalji login za DNS panel, API token ili screenshot s tajnim vrijednostima.

> DNS propagacija i TTL bez obećanja na minut

TTL i cache resolvera određuju koliko dugo stare i nove DNS vrijednosti mogu koegzistirati nakon izmjene.
faq/dns-propagation-and-ttl

Propagacija je ponašanje cachea

Ne postoji fiksno obećanje koliko tačno traje DNS propagacija. Nakon promjene autoritativnog zapisa različiti resolveri mogu vraćati stare i nove odgovore dok im ne istekne cache prema TTL vrijednosti.

Planirana DNS promjena

  1. Ako provajder dozvoljava, smanji TTL prije planiranog prebacivanja.
  2. Napravi izmjenu jednom i izbjegavaj nasumično prepisivanje dok cache ističe.
  3. Testiraj s više resolvera ili mreža kada se rezultati razlikuju.
  4. Zapiši vrijeme izmjene, staru vrijednost, novu vrijednost i TTL.

Šta poslati podršci

Pošalji hostname, očekivani cilj, vidljiv stari odgovor, vidljiv novi odgovor, TTL i vrijeme izmjene. Ne šalji pristup DNS računu ili interne bilješke provajdera.

> Planiranje Nextcloud skladišta

U kapacitet uračunaj korisničke datoteke, dijeljene foldere, verzije, korpu, previews, thumbnails, sync overhead i rast tima.
faq/nextcloud-storage-planning

Prostor troše i nevidljivi slojevi

Pored korisničkih datoteka, kapacitet koriste dijeljenja, obrisane datoteke, historija verzija, previews, thumbnails, sinhronizacioni klijenti i uvozi. Blizina limita može lomiti upload i sync.

Prije naručivanja kapaciteta

  1. Izmjeri trenutne korisničke datoteke i zajedničke foldere.
  2. Dodaj rezervu za verzije, korpu, previews i thumbnails.
  3. Uračunaj velike uvoze, nove timove i očekivani rast.
  4. Povećaj storage prije nego što korisnici dođu do limita.

Kada sync počne grešiti

Pošalji veličinu usluge, približno zauzeće, vrijeme problema i vidljivu grešku klijenta. Ne šalji privatne datoteke, lozinke ili exporte korisničkih podataka bez dogovorenog sigurnog kanala.

> Migracija repozitorija u Gitea

Migraciju Git repozitorija planiraj zajedno s LFS, submodules, pravima, protected branches, deploy keys, webhookovima i CI/CD.
faq/gitea-repository-migration

Migracija nije samo git clone

Pored historije koda treba provjeriti vlasnike, timove, protected branches, protected tags, Git LFS, submodules, deploy keys, tokene, webhookove i CI/CD tokove. Tajne vrijednosti tokena ne treba dijeliti.

Kontrola prije cutovera

  1. Popiši repozitorije, vlasnike, grupe pristupa i automation račune.
  2. Provjeri Git LFS objekte, submodules, protected branches i protected tags.
  3. Nakon prenosa testiraj clone, push, Git LFS, submodules i CI.
  4. Stare tokene nakon migracije opozovi ili rotiraj bez slanja njihovih vrijednosti.

Sigurni podaci za pomoć

U tiket ne šalji tokene, privatne ključeve, privatni dio deploy keya ili CI secrets. Dovoljni su nazivi repozitorija, tip integracije, vidljiva greška i šta je ranije radilo.

> Sender domena za Listmonk

Za kampanje pripremi sender domenu ili subdomenu, From identitet, SPF, DKIM, DMARC, bounce i odjavu.
faq/listmonk-sender-domain-basics

Dostavljivost počinje domenom

Listmonk kampanje bolje prolaze kada sender domena ima tačne DNS zapise i jasan From identitet. SPF, DKIM i DMARC moraju odgovarati domeni ili subdomeni s koje šalješ.

Prije prve kampanje

  1. Izaberi sender domenu ili subdomenu i From naziv.
  2. Dodaj verifikacione DNS zapise, SPF, DKIM selector i DMARC na _dmarc.
  3. Testiraj poruke, bounce ili Return-Path i linkove prije stvarne kampanje.
  4. Provjeri odjavu i List-Unsubscribe prije slanja većoj listi.

Mail tajne ne idu u tiket

Za dijagnostiku pošalji domenu, tip zapisa, javno vidljivu DNS vrijednost i grešku. Ne šalji SMTP lozinke, API tokene, privatni DKIM ključ ili export liste primalaca.

> Runtime podešavanja za Classic Hosting

Classic Hosting može koristiti auto ili manuelni Runtime; CPU, RAM, storage, backup, Offsite Archive, uploadi, cache i logovi utiču na cijenu i stabilnost.
faq/classic-hosting-runtime-settings

Auto režim nije jedini ispravan izbor

Auto Runtime pomaže kod prepoznatih projekata, ali manuelni režim je bolji kada želiš birati Nginx, Apache, FrankenPHP ili konkretan jezički runtime. PHP selector koristi samo gdje ga odabrani runtime podržava.

Podešavanja prije deploya

  1. Izaberi auto ili manuelni Runtime prema frameworku i build procesu.
  2. Odaberi PHP 8.2, 8.3 ili 8.4 samo za podržane PHP scenarije.
  3. Postavi CPU, RAM, disk, backup retenciju i Offsite Archive prema podacima i posjeti.
  4. Nakon deploya testiraj upload, cache, logove i vidljive greške aplikacije.

Ako aplikacija ne startuje

Pošalji runtime režim, jezik ili PHP verziju, vidljivu grešku, šta se promijenilo i vrijeme deploya. Ne šalji .env datoteke, lozinke, tokene ili cijele logove s osjetljivim vrijednostima.

> Koje informacije je sigurno poslati podršci

Najviše pomažu brojevi narudžbi, nazivi usluga, domene, vremena, javni hostovi, portovi, backup retencija, Offsite Archive, uploadi, cache, logovi i vidljive greške bez tajni.
faq/support-safe-information-to-share

Dobar tiket ima kontekst, ne tajne

Podrška brže reaguje kada dobije broj narudžbe, naziv usluge, domenu, javni host ili port, vrijeme problema, šta se mijenjalo i tačan vidljiv tekst greške.

Siguran sadržaj poruke

  1. Navedi narudžbu, uslugu, domenu, vrijeme i korak gdje nastaje problem.
  2. Za hosting dodaj runtime, PHP ili jezik, CPU, RAM, disk, backup retenciju, Offsite Archive retenciju, uploade, cache i logove bez tajnih vrijednosti.
  3. Screenshotove prije slanja maskiraj na mjestima s ličnim ili tajnim podacima.
  4. Ako nisi siguran da li podatak pripada tiketu, pitaj bez slanja same vrijednosti.

Šta nikada ne slati

Ne šalji lozinke, privatne ključeve, recovery seedove, API tokene, session cookies, exporte baza, kompletne .env datoteke, pune logove sa tajnama ili povjerljive tehničke detalje.