FAQ

Pyetjet e bëra shpesh

Udhëzues të shkurtër praktik për konfigurimin e shërbimit, aksesin dhe veprimet e zakonshme të klientit.

> Krijo një çelës publik SSH në terminal

Krijo një çelës publik SSH për akses dhe ndaj vetëm pjesën publike.
faq/generate-public-ssh-key-sq

Përdor vetëm çelësin publik

SSH përdor një çift çelësash. Në cilësimet e shërbimit ngjit vetëm çelësin publik, zakonisht skedarin .pub. Çelësi privat mbetet në pajisjen tënde.

Hapat në terminal

  1. Hap Terminal, Windows Terminal ose PowerShell.
  2. Ekzekuto: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Prano vendndodhjen standarde ose zgjidh një rrugë të sigurt.
  4. Shfaq çelësin publik me: cat ~/.ssh/id_ed25519.pub.
  5. Në Windows PowerShell përdor: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Kopjo të gjithë rreshtin ssh-ed25519 në fushën SSH public key.

Kontrollo para ngjitjes

Mos kopjo çelësin privat. Nëse vendos passphrase, ruaje në mënyrë të sigurt.

> Krijo një çelës SSH grafikisht në Windows

Përdor PuTTYgen në Windows dhe kopjo vetëm çelësin publik.
faq/create-ssh-key-windows-gui-sq

Mjafton pjesa publike

PuTTYgen krijon çelës publik dhe privat. Shto në Cli>_ vetëm çelësin publik dhe mbaje çelësin privat lokalisht.

Hapat në Windows

  1. Hap PuTTYgen.
  2. Zgjidh EdDSA / Ed25519 kur është i disponueshëm.
  3. Përdor RSA 4096 vetëm si rezervë.
  4. Kliko Generate dhe lëviz miun derisa të krijohet çelësi.
  5. Ruaj çelësin privat në kompjuterin tënd.
  6. Kopjo tekstin e çelësit publik në fushën SSH public key.

Mos ndaj të dhëna sekrete

Mos dërgo skedarë .ppk, çelësa privatë, passphrase, fjalëkalime ose token te suporti apo formularët.

> Lidh domenin tend

Konfirmo DNS autoritativ, hostname të saktë, apex apo subdomain, llojin e record të mbështetur dhe konfliktet e vjetra.
faq/lidh-domenin-tend

Hostname i saktë vendos rrugën

example.com dhe app.example.com mund të kërkojnë lloje DNS të ndryshme dhe kufizime të ndryshme te registrar ose DNS provider. Gjej edhe ku redaktohen records autoritative.

Para ndryshimit DNS

  1. Kërko A/AAAA, CNAME, ALIAS, ANAME ose redirect ekzistues për të njëjtin hostname.
  2. Hiq ose korrigjo konfliktet para target-it të ri.
  3. Përdor llojin e record që rekomandon shërbimi për atë hostname.
  4. Prit propagimin DNS dhe kontrollin e certifikatës para se të fikësh mjedisin e vjetër.

Planifiko kthimin prapa

Shëno vlerat e vjetra DNS para ndryshimit dhe mbaj mjedisin e vjetër derisa certifikata dhe rruga e re të funksionojnë. Kjo e bën rikthimin më të lehtë.

> Delegimi i zones DNS

A/AAAA tregojnë adresa, CNAME krijon alias, MX rrugëzon email dhe TXT përdoret për verification, SPF, DKIM dhe DMARC.
faq/delegimi-i-zones-dns

Çdo record ka rol të veçantë

A dhe AAAA tregojnë IP, CNAME është alias i lejuar për subdomain, MX është për email, TXT mban verifikime dhe politika emaili, ndërsa CAA kufizon autoritetet e certifikatave. CAA e gabuar mund të bllokojë certifikatën.

Records për email

  1. SPF vendoset aty ku kërkon ofruesi i emailit.
  2. DKIM vendoset nën selector të ofruesit.
  3. DMARC zakonisht vendoset nën _dmarc.
  4. Mos vendos CNAME te hostname që duhet të ketë records të tjera nëse rregullat DNS e ndalojnë.

Shmang konfliktet në të njëjtin emër

Një hostname me CNAME zakonisht nuk mund të ketë records të tjera njëkohësisht. Kontrollo që web, email dhe verifikimet të mos konkurrojnë për të njëjtin emër.

> Regjistrimi i llogarisë dhe hyrja e parë

Krijo një llogari klienti për porosi, faturim dhe menaxhim shërbimesh me një email pune që ekipi e ruan.
faq/account-registration-and-login

Përdor një adresë pune afatgjatë

Llogaria mban porositë, faturimin, domenet, shërbimet dhe komunikimin me mbështetjen. Zgjidh një email pune që ekipi mund ta mbajë edhe kur ndryshojnë rolet, jo një kuti personale të vetme.

Para porosisë së parë me pagesë

  1. Regjistrohu me email pune.
  2. Përfundo konfirmimin e emailit nëse kërkohet.
  3. Plotëso të dhënat e faturimit para shërbimeve me pagesë.
  4. Aktivizo autentikimin me dy faktorë kur është i disponueshëm.

Mos humb aksesin

Përcaktoni kush mban emailin, ruajtjen e fjalëkalimeve dhe rikuperimin. Kështu ekipi ruan faturat, porositë dhe menaxhimin e shërbimeve edhe kur ndryshojnë rolet.

> Si funksionon krediti i parapaguar

Krediti tregon bilancin, kohën e mbetur, koston ditore dhe rrezikun e pezullimit ose afatit të dukshëm të fshirjes.
faq/prepaid-credit-how-it-works

Krediti konsumohet kur shërbimi punon

Shërbimet aktive të parapaguara përdorin kredit sipas kohës së punës, CPU, RAM, hapësirës dhe opsioneve me pagesë. Bilanci i dukshëm dhe vlerësimi i kohës ndihmojnë të mbushësh para pezullimit.

Shmang ndalimin e papritur

  1. Ndiq bilancin dhe kohën e mbetur në zonën e klientit.
  2. Kontrollo çmimin dhe koston ditore para konfirmimit të porosisë ose ndryshimit.
  3. Vëzhgo paralajmërimin për bilanc të ulët, pezullimin dhe afatin e fshirjes.
  4. Mbush kreditin para se të mbarojë.

Kur bilanci ulet

Kur krediti mbaron, shërbimet mund të pezullohen dhe të shfaqin afat fshirjeje. Mbush kreditin ose kontakto mbështetjen para afatit për të shmangur heqjen e të dhënave.

> Vlerësimi mujor, vjetor dhe konsumi ditor

Muaji dhe viti janë vlera krahasimi; konsumi real i parapaguar ndodh çdo ditë pasi ndryshimi zbatohet.
faq/billing-periods-and-credit-burn

Vlerësimi nuk është kalendar faturimi

Çmimi mujor përdor 31 ditë dhe ai vjetor 372 ditë për krahasim. Shërbimet e parapaguara konsumojnë kredit sipas kohës aktive dhe konfigurimit të konfirmuar, vetëm pas konfirmimit, pagesës nëse duhet dhe zbatimit.

Kur ndryshon çmimi

  1. Krahaso koston ditore para dhe pas ndryshimit.
  2. Më shumë CPU, RAM, disk ose opsione me pagesë mund të rrisin konsumin.
  3. Prit derisa ndryshimi të zbatohet para se të mbështetesh në çmimin e ri.
  4. Ruaj konfirmimet e porosisë, faturat dhe historikun e kreditit.

Përdor koston ditore për planifikim

Shiko koston ditore kur planifikon bilancin. Pas ndryshimit, kontrollo që ai është zbatuar para se të llogaritësh sa ditë zgjat krediti.

> Statusi i porosisë pas pagesës

Porosia mund të presë konfirmim nga ofruesi i pagesës; mos krijo dublikatë derisa e para të jetë qartë e skaduar ose e dështuar.
faq/order-status-and-payment-confirmation

Pending nuk do të thotë gjithmonë dështim

Pas pagesës porosia mund të presë konfirmim nga ofruesi i pagesës. Një porosi e dytë para se e para të jetë anuluar ose skaduar qartë mund të ngatërrojë përputhjen.

Pas pagesës

  1. Kthehu në Cli>_ pasi pagesa të përfundojë.
  2. Kontrollo statusin e porosisë në llogari.
  3. Prit konfirmimin nëse statusi mbetet pending.
  4. Kontakto mbështetjen me numrin e porosisë dhe referencën e pagesës nëse shihet.

Mos krijo porosi dublikatë

Edhe nëse mbyllet faqja e pagesës ose kthehesh prapa, porosia e parë mund të konfirmohet. Ruaj numrin e porosisë dhe prit status të qartë para riporosimit.

> Të dhënat që duhen për konfigurimin e shërbimit

Përgatit emrin e shërbimit, domenin, planin DNS, emailin admin, burimet dhe çelësin publik SSH, jo sekrete.
faq/service-setup-information-needed

Vlerat publike të sakta kursejnë kohë

Fushat e konfigurimit janë për emër shërbimi, domen, DNS, hapësirë, CPU, RAM, email admin dhe çelës publik SSH. Fjalëkalimet, çelësat privatë, tokenët dhe eksportet e databazës nuk duhen futur aty.

Përgatit para porosisë

  1. Zgjidh një emër shërbimi që ekipi e njeh.
  2. Vendos nëse do të përdorësh domen personal apo hostname të përkohshëm.
  3. Krijo çelës publik SSH nëse shërbimi e kërkon.
  4. Vlerëso CPU, RAM dhe hapësirë sipas aplikacionit që do të punojë.

Mbaji sekretet jashtë formularit

Çelësi publik SSH mund të ndahet, por çelësi privat dhe fjalëkalimet jo. Ndaj vlera publike, burimet e zgjedhura dhe gabimet e dukshme.

> Ndryshimi i CPU, RAM, diskut ose retencionit pas porosisë

Ndrysho shërbimin ekzistues nga faqja e tij dhe kontrollo çmimin e ri, konsumin ditor, restartin dhe rrezikun e ndërprerjes.
faq/change-service-resources-after-order

Ndrysho shërbimin, mos porosit kopje të re

Nëse shërbimi punon, bëje ndryshimin nga detajet e tij. Një porosi e re mund të krijojë shërbim shtesë. Ndryshimi vlen vetëm pas konfirmimit, pagesës nëse duhet dhe zbatimit.

Para konfirmimit

  1. Shiko CPU, RAM, disk, backup retention dhe Offsite Archive retention aktual.
  2. Kontrollo çmimin e ri dhe konsumin ditor të kreditit.
  3. Lexo njoftimet për restart, mirëmbajtje ose ndërprerje.
  4. Eksporto të dhënat e rëndësishme para ndryshimeve me rrezik.

Vlerëso ndikimin praktik

Ndryshimet CPU ose RAM mund të kërkojnë restart të shkurtër, ndërsa disku dhe retencioni mund të zgjasin më shumë. Konfirmo kur e di ndikimin te përdoruesit ose orari i punës.

> Anulimi i shërbimit dhe ruajtja e të dhënave

Shërbimi që është krijuar pezullohet fillimisht, tregon afatin e dukshëm të fshirjes dhe pastrohet më vonë sipas ciklit.
faq/cancel-service-and-data-retention

Anulimi nuk është gjithmonë fshirje e menjëhershme

Një shërbim që është krijuar zakonisht pezullohet dhe shfaq një afat të dukshëm fshirjeje. Pas afatit mund të bëhet pastrim i përhershëm. Porositë e papaguara që nuk janë krijuar ende mund të sillen ndryshe.

Para anulimit

  1. Krijo eksportin tënd për të dhënat që duhet të mbash.
  2. Lexo njoftimin e pezullimit dhe afatin e fshirjes.
  3. Mos e ngatërro backup ose Offsite Archive me afatin e fshirjes së shërbimit.
  4. Kontakto mbështetjen para afatit nëse je i pasigurt.

Nxirr të dhënat fillimisht

Eksporto file, databazë ose të dhëna aplikacioni që duhet t’i mbash para anulimit. Backup dhe Offsite Archive nuk garantojnë ruajtje të përhershme pasi shërbimi fshihet.

> Backup dhe kërkesat për restore

Backup shërben për rikuperim operativ, jo si zëvendësim i eksportit; restore mund të mbishkruajë të dhëna më të reja.
faq/backups-and-restore-requests

Backup nuk është arkiv

Retencioni varet nga produkti dhe opsionet. Backup ndihmon rikuperimin pas gabimeve, por nuk zëvendëson eksportin tënd, arkivin auditues ose Offsite Archive. Restore mund ta kthejë shërbimin në gjendje më të vjetër.

Shkruaj kërkesë të saktë restore

  1. Jep emrin e shërbimit dhe numrin e porosisë.
  2. Përshkruaj kohën e përafërt ku do të kthehesh.
  3. Thuaj nëse duhet restore i plotë apo pjesë e caktuar nëse mbështetet.
  4. Shto gabim të dukshëm ose kontekst pa fjalëkalime, tokenë ose çelësa privatë.

Përcakto fushën e restore

Restore mund të prekë gjithë shërbimin ose vetëm një pjesë dhe mund të mbishkruajë ndryshime të reja. Shkruaj kohën dhe të dhënat që pret të kthehen.

> Për çfarë shërben Offsite Archive

Offsite Archive ruan kopje arkivore në distancë, të ndara nga backup-et e shkurtra dhe nga cikli i fshirjes së shërbimit.
faq/offsite-archive-purpose

Arkiv jashtë operimit ditor

Offsite Archive është për kopje arkivore në distancë, eksporte dhe material më të vjetër. Nuk është disk live për aplikacion, nuk është i njëjtë me backup të shkurtër dhe nuk garanton zgjatje të afatit të fshirjes së shërbimit.

Llogarit me ditë dhe volum

  1. Zgjidh ditët e retencionit sipas rregullave ose objektivit të rikuperimit.
  2. Mendo MB-days si MB të ruajtur shumëzuar me ditët.
  3. Çmimi shfaqet si EUR/GB/muaj dhe rrumbullakoset në cent.
  4. Rishiko koston kur volumi ose retencioni rritet.

I ndarë nga operimi live

Offsite Archive nuk është vend ku aplikacioni shkruan në kohë reale. Përdore për kopje që duhet të ruhen më gjatë dhe vlerëso çmimin nga volumi dhe ditët e retencionit.

> Zgjedhja e CPU, RAM dhe diskut për VPS

Madhësia varet nga aplikacioni, databaza, cache, logs dhe rritja; OOM dhe swap shpesh tregojnë RAM të pamjaftueshëm.
faq/vps-cpu-ram-and-disk-sizing

Ngarkesa përcakton madhësinë

Një faqe statike ka nevoja të tjera nga një databazë, kërkim, aplikacion Java ose worker build. Përfshi memorien, cache, logs, uploads, databazën dhe hapësirën për rritje.

Shenja se plani është i vogël

  1. Rrit RAM kur sheh OOM, out of memory, process killed ose shumë swap.
  2. Rrit CPU për llogaritje të vazhdueshme, kompresim, builds ose workers të ngarkuar.
  3. Rrit diskun para se filesystem, logs ose databaza të mbushen.
  4. Pas ndryshimit kontrollo nëse gabimi fillestar u zhduk.

Fillo me kujdes dhe monitoro

Mund të nisësh me madhësi të moderuar, por ndiq logs, rritjen e databazës, uploads dhe memorien. Rrite planin para se shërbimi të arrijë kufij të fortë.

> Kur ka kuptim IP publike për VPS

IP publike dedikuar ndihmon për allowlist, hyrje inbound, burim outbound stabil ose shërbime të lidhura me adresë.
faq/vps-public-ip-options

Së pari sqaro drejtimin e trafikut

IP publike nuk nevojitet për çdo shërbim. Ajo ndihmon kur partnerë, ofrues ose firewall kërkojnë adresë stabile për inbound, outbound source ose të dyja.

Pyetje para IP-së

  1. Pyet nëse allowlist është inbound, outbound apo në të dy drejtimet.
  2. Përdor emra DNS në vend të adresave numerike kur është e mundur.
  3. Hap vetëm portet që aplikacioni i përdor realisht.
  4. Ndaj kërkesën e allowlist me mbështetjen para ndryshimit të aksesit në prodhim.

Kur duhet rrugë direkte

IP publike dedikuar zgjidhet kur sisteme të jashtme duhet të arrijnë direkt VPS-in ose kur partneri kërkon burim outbound fiks. Nëse SSH i përbashkët mjafton, IP e veçantë nuk është e detyrueshme.

> Akses SSH i përbashkët për VPS

Pa IP publike dedikuar, VPS lidhet përmes adrese SSH të përbashkët me port të lartë; me IP publike mund të ketë edhe SSH direkt.
faq/shared-ssh-access-for-vps

Porti i lartë drejton te VPS i saktë

Disa VPS mund të ndajnë të njëjtin host publik SSH. Prandaj çdo shërbim merr portin e vet të lartë, dhe porti është pjesë e rrugëzimit drejt VPS tënd. Pa të, adresa e përbashkët SSH nuk di cilin shërbim të arrijë.

Zgjidh adresën e duhur SSH

  1. Për SSH të përbashkët kopjo përdoruesin SSH, hostin publik SSH dhe portin e lartë nga faqja e shërbimit.
  2. Përdor ssh -p <port> <username>@<public-host>.
  3. Nëse shërbimi ka IP publike dedikuar, mund të shfaqet edhe SSH direkt në atë IP ose emër DNS.
  4. Përdor çelësin privat vetëm lokalisht; mbështetjes i duhen host, port, username dhe gabimi i dukshëm.

SSH i përbashkët ose SSH direkt

SSH i përbashkët përdor të njëjtin host publik për disa VPS, prandaj porti i lartë identifikon VPS-in e saktë. Me IP publike dedikuar, shërbimi mund të ofrojë edhe SSH direkt te IP ose DNS, shpesh në portin normal SSH.

> Kontroll para lidhjes së domenit personal

Konfirmo DNS autoritativ, hostname të saktë, apex apo subdomain, llojin e record të mbështetur dhe konfliktet e vjetra.
faq/custom-domain-readiness-checklist

Hostname i saktë vendos rrugën

example.com dhe app.example.com mund të kërkojnë lloje DNS të ndryshme dhe kufizime të ndryshme te registrar ose DNS provider. Gjej edhe ku redaktohen records autoritative.

Para ndryshimit DNS

  1. Kërko A/AAAA, CNAME, ALIAS, ANAME ose redirect ekzistues për të njëjtin hostname.
  2. Hiq ose korrigjo konfliktet para target-it të ri.
  3. Përdor llojin e record që rekomandon shërbimi për atë hostname.
  4. Prit propagimin DNS dhe kontrollin e certifikatës para se të fikësh mjedisin e vjetër.

Planifiko kthimin prapa

Shëno vlerat e vjetra DNS para ndryshimit dhe mbaj mjedisin e vjetër derisa certifikata dhe rruga e re të funksionojnë. Kjo e bën rikthimin më të lehtë.

> Llojet e DNS records për shërbime

A/AAAA tregojnë adresa, CNAME krijon alias, MX rrugëzon email dhe TXT përdoret për verification, SPF, DKIM dhe DMARC.
faq/dns-record-types-for-services

Çdo record ka rol të veçantë

A dhe AAAA tregojnë IP, CNAME është alias i lejuar për subdomain, MX është për email, TXT mban verifikime dhe politika emaili, ndërsa CAA kufizon autoritetet e certifikatave. CAA e gabuar mund të bllokojë certifikatën.

Records për email

  1. SPF vendoset aty ku kërkon ofruesi i emailit.
  2. DKIM vendoset nën selector të ofruesit.
  3. DMARC zakonisht vendoset nën _dmarc.
  4. Mos vendos CNAME te hostname që duhet të ketë records të tjera nëse rregullat DNS e ndalojnë.

Shmang konfliktet në të njëjtin emër

Një hostname me CNAME zakonisht nuk mund të ketë records të tjera njëkohësisht. Kontrollo që web, email dhe verifikimet të mos konkurrojnë për të njëjtin emër.

> Propagimi DNS dhe TTL

TTL dhe cache e resolver përcaktojnë sa gjatë përgjigjet e vjetra DNS mund të bashkëjetojnë me të rejat.
faq/dns-propagation-and-ttl

Propagimi është sjellje cache

Kur DNS autoritativ ndryshon, resolver-at mund të kthejnë vlerën e vjetër deri sa TTL të skadojë. Prandaj rrjete, vende ose resolver të ndryshëm mund të tregojnë rezultate të ndryshme përkohësisht.

Ndryshim i kontrolluar

  1. Ule TTL para ndryshimit të planifikuar nëse provider e lejon.
  2. Bëje ndryshimin një herë dhe mos e rishkruaj rastësisht gjatë cache.
  3. Testo nga më shumë se një resolver kur përgjigjet ndryshojnë.
  4. Shëno vlerën e vjetër, të renë, TTL dhe kohën e ndryshimit.

Kontrollo nga disa vende

Menjëherë pas ndryshimit, një resolver mund të tregojë vlerën e vjetër dhe një tjetër të renë. Krahaso DNS autoritativ, rrjet tjetër dhe resolver publik para se ta quash gabim konfigurimi.

> Planifikimi i hapësirës për Nextcloud

Llogarit file-t e përdoruesve, dosjet e ndara, versionet, koshin, previews, sync overhead dhe rritjen e ekipit.
faq/nextcloud-storage-planning

Nextcloud rritet përtej file-ve të dukshëm

Hapësira përdoret nga file-t e përdoruesve, dosjet e ndara, file-t e fshirë, historiku i versioneve, previews, thumbnails, klientët sync dhe importet. Afër limitit mund të dështojnë upload dhe sync.

Para porosisë së kapacitetit

  1. Mblidh të dhënat aktuale të përdoruesve dhe dosjet e përbashkëta.
  2. Shto rezervë për versione, kosh, previews dhe sync overhead.
  3. Përfshi importe të mëdha, ekipe të reja dhe rritje të pritshme.
  4. Rrit hapësirën para se përdoruesit të arrijnë limitin.

Rezerva shmang gabime sync

Kur hapësira është gati plot, uploads, sync, previews dhe versionet mund të dështojnë. Shto kapacitet para përdoruesve të rinj ose importeve të mëdha.

> Migrimi i repositories në Gitea

Planifiko migrimin Git bashkë me LFS, submodules, të drejta, deploy keys, webhooks dhe CI/CD.
faq/gitea-repository-migration

Migrimi është më shumë se git clone

Historia e repository është vetëm një pjesë. Pronari, ekipet, protected branches, protected tags, Git LFS, submodules, deploy keys, webhooks dhe integrimet CI/CD duhet të transferohen ose rikrijohen.

Kontroll para cutover

  1. Listo repositories, pronarët, grupet dhe llogaritë e automatizimit.
  2. Kontrollo Git LFS, submodules, branch protections dhe tag protections.
  3. Testo clone, push, Git LFS, submodules dhe CI pas migrimit.
  4. Rrotullo ose revoko tokenët e vjetër pa ndarë vlerat e tyre.

Kalo të drejtat dhe automatizimin

Historia vetëm nuk mjafton. Testo deploy keys, webhooks, branch protection dhe CI para se platforma e vjetër të bëhet read-only ose të mbyllet.

> Domeni dërgues për Listmonk

Përgatit sender domain ose subdomain, From identity, SPF, DKIM, DMARC, bounce dhe unsubscribe para fushatës.
faq/listmonk-sender-domain-basics

Dorëzimi nis te domeni

Newsletter-at dorëzohen më mirë kur domeni dërgues ka DNS të saktë dhe From identity të qartë. SPF, DKIM dhe DMARC duhet të përputhen me domenin ose subdomain që dërgon.

Para dërgimit të parë

  1. Zgjidh sender domain ose subdomain dhe emrin From.
  2. Publiko DNS verifikimi, SPF, DKIM selector dhe DMARC.
  3. Dërgo teste dhe kontrollo spam, bounce ose Return-Path dhe linket.
  4. Mbaj unsubscribe dhe List-Unsubscribe të sakta.

Testo me volum të ulët

Dërgo fillimisht te ekipi ose te pak marrës. Kontrollo spam, linket, unsubscribe dhe bounce para fushatës së madhe.

> Mjedisi i ekzekutimit për Classic Hosting

Classic Hosting mund të përdorë mjedis automatik ose manual; zgjedhja PHP dhe burimet duhet t’i përshtaten aplikacionit.
faq/classic-hosting-runtime-settings

Auto është i dobishëm, por jo gjithmonë zgjedhja e duhur

Mjedisi automatik ndihmon për projekte PHP, Node.js, Java, Python, .NET, Go dhe Ruby që njihen automatikisht. Mjedisi manual përshtatet kur do kontroll mbi Nginx, Apache, FrankenPHP ose gjuhën. Zgjedhja PHP vlen vetëm ku mjedisi e mbështet.

Cilësime para publikimit

  1. Zgjidh mjedis automatik ose manual sipas framework dhe build.
  2. Përdor PHP 8.2, 8.3 ose 8.4 vetëm në skenarë PHP të mbështetur.
  3. Vendos CPU, RAM, hapësirë, backup retention dhe Offsite Archive retention.
  4. Testo uploads, cache, logs dhe gabimet e dukshme pas publikimit.

Zgjidh sipas aplikacionit

Auto është praktik, por manual mund të jetë më i sigurt kur di komandën e nisjes, public directory, file-t e qëndrueshëm ose PHP extensions të nevojshme.

> Informacion që mund t’i dërgosh sigurt mbështetjes

Numra porosie, emra shërbimi, domene, kohë, public host/port dhe gabime të dukshme ndihmojnë; sekretet nuk duhen dërguar.
faq/support-safe-information-to-share

Një kërkesë e mirë ka kontekst, jo sekrete

Mbështetja reagon më shpejt me numër porosie, emër të dukshëm shërbimi, domen, public host ose port, kohën e problemit, çfarë ndryshoi dhe tekstin e saktë të gabimit.

Detaje të sigurta në mesazh

  1. Përfshi porosinë, shërbimin, domenin, kohën dhe hapin ku ndodhi problemi.
  2. Për hosting: runtime, PHP ose gjuhë, CPU, RAM, disk, uploads, cache dhe logs pa vlera sekrete.
  3. Masko screenshot-et para dërgimit.
  4. Mos dërgo fjalëkalime, çelësa privatë, API tokenë, seed phrases, eksporte databaze ose logs të plota me vlera sensitive.

Përshkruaj riprodhimin shkurt

Shkruaj çfarë bëre, rezultatin e pritur, gabimin real dhe kohën. Masko sekretet dhe ndaj vetëm vlera publike.