FAQ

Algengar spurningar

Hagnýtar stuttar leiðbeiningar um þjónustuuppsetningu, aðgang og algengar aðgerðir viðskiptavina.

> Búðu til opinberan SSH-lykil í skel

Búðu til opinberan SSH-lykil fyrir aðgang og deildu aðeins opinbera hlutanum.
faq/generate-public-ssh-key-is

Notaðu aðeins opinbera lykilinn

SSH notar lyklapar. Límdu aðeins opinbera lykilinn, oftast .pub skrána, í stillingar þjónustunnar. Einkalykillinn helst á tækinu þínu.

Skref í skel

  1. Opnaðu Terminal, Windows Terminal eða PowerShell.
  2. Keyrðu: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Samþykktu sjálfgefna staðsetningu eða veldu örugga slóð.
  4. Sýndu opinbera lykilinn með: cat ~/.ssh/id_ed25519.pub.
  5. Í Windows PowerShell notarðu: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Afritaðu alla ssh-ed25519 línuna í SSH public key reitinn.

Athugaðu áður en þú límir

Ekki afrita einkalykilinn. Ef þú setur passphrase skaltu geyma það örugglega.

> Búðu til SSH-lykil myndrænt í Windows

Notaðu PuTTYgen í Windows og afritaðu aðeins opinbera lykilinn.
faq/create-ssh-key-windows-gui-is

Aðeins opinberi hlutinn

PuTTYgen býr til opinberan lykil og einkalykil. Bættu aðeins opinbera lyklinum við Cli>_ og geymdu einkalykilinn staðbundið.

Skref í Windows

  1. Opnaðu PuTTYgen.
  2. Veldu EdDSA / Ed25519 ef það er í boði.
  3. Notaðu RSA 4096 aðeins sem varaleið.
  4. Smelltu á Generate og hreyfðu músina þar til lykillinn verður til.
  5. Vistaðu einkalykilinn á tölvunni þinni.
  6. Afritaðu texta opinbera lykilsins í SSH public key reitinn.

Ekki deila leynigögnum

Ekki senda .ppk skrár, einkalykla, passphrase, lykilorð eða token til þjónustudeildar eða í form.

> Tengdu eigid len

Staðfestu authoritative DNS, nákvæmt hostname, apex eða subdomain, studda record-gerð og gamlar árekstrarstillingar.
faq/tengdu-eigid-len

Nákvæmt hostname ræður leiðinni

example.com og app.example.com geta þurft mismunandi DNS-gerðir og haft mismunandi takmarkanir hjá registrar eða DNS-veitu. Finndu líka hvar authoritative records eru raunverulega breytt.

Áður en DNS er breytt

  1. Leitaðu að núverandi A/AAAA, CNAME, ALIAS, ANAME eða redirect fyrir sama hostname.
  2. Fjarlægðu eða lagaðu árekstra áður en nýtt target er sett inn.
  3. Notaðu record-gerð sem þjónustan mælir með fyrir hostname-gerðina.
  4. Bíddu eftir DNS-propagation og certificate check áður en gamla umhverfið er slökkt.

Skipuleggðu afturköllun

Skráðu gömul DNS gildi áður en þú breytir og haltu gamla umhverfi þar til certificate og ný leið virka. Þá er auðveldara að bakka ef villa kemur upp.

> Framselja DNS-svaedi

A/AAAA benda á vistföng, CNAME er alias, MX stýrir pósti og TXT er notað fyrir verification, SPF, DKIM og DMARC.
faq/framselja-dns-svaedi

Hver record-gerð hefur hlutverk

A og AAAA benda á IP-vistföng, CNAME er leyfilegt alias fyrir subdomain, MX stýrir pósti, TXT geymir verification og mail policy, og CAA takmarkar certificate authorities. Rangt CAA getur stöðvað certificate útgáfu.

Pósttengdar stillingar

  1. SPF fer þar sem póstveitan biður um það.
  2. DKIM fer undir selector frá veitunni.
  3. DMARC er yfirleitt undir _dmarc.
  4. Ekki setja CNAME á hostname sem má ekki hafa aðrar records með sér.

Forðastu árekstur á sama nafni

CNAME hostname má oft ekki hafa aðrar records með sér. Athugaðu að web, póstur og verification keppi ekki um sama hostname.

> Skráning aðgangs og fyrsta innskráning

Búðu til einn viðskiptavinaaðgang fyrir pantanir, reikninga og þjónustustjórnun með netfangi sem teymið heldur aðgangi að.
faq/account-registration-and-login

Veldu netfang sem lifir með teyminu

Aðgangurinn heldur utan um pantanir, reikningsgögn, lén, þjónustur og samskipti við aðstoð. Notaðu vinnunetfang sem fleiri geta varðveitt aðgang að þegar fólk fer í frí eða skiptir um hlutverk.

Áður en greidd pöntun er send

  1. Skráðu þig með vinnunetfangi.
  2. Staðfestu tölvupóst ef beðið er um það.
  3. Fylltu út reikningsupplýsingar áður en greidd þjónusta er pöntuð.
  4. Kveiktu á tveggja þátta auðkenningu þegar hún er í boði.

Forðastu að missa aðgang

Ákveðið hver sér um netfang, lykilorðageymslu og endurheimt. Þá heldur teymið aðgangi að reikningum, pöntunum og þjónustustjórnun þó fólk skipti um hlutverk.

> Hvernig fyrirframgreidd inneign virkar

Inneign sýnir stöðu, áætlaðan keyrslutíma, daglegan kostnað og hættu á stöðvun eða sýnilegum eyðingarfresti.
faq/prepaid-credit-how-it-works

Inneign brennur á meðan þjónusta keyrir

Virkar fyrirframgreiddar þjónustur nota inneign eftir tíma og valinni CPU, RAM, geymslu og greiddum valkostum. Sýnileg staða og áætlaður keyrslutími hjálpa þér að fylla á áður en þjónusta stöðvast.

Komdu í veg fyrir stöðvun

  1. Fylgstu með stöðu og keyrslutíma í viðskiptavinasvæði.
  2. Skoðaðu sýnt verð og daglegan kostnað áður en pöntun eða breyting er staðfest.
  3. Taktu eftir lágri stöðu, stöðvunartilkynningu og sýnilegum eyðingarfresti.
  4. Fylltu á með fyrirvara áður en inneign klárast.

Þegar inneign lækkar

Ef inneign klárast getur þjónusta stöðvast og sýnt eyðingarfrest. Fylltu á eða hafðu samband við aðstoð fyrir frestinn ef þú vilt forðast seinni gagnahreinsun.

> Mánaðarviðmið, ársviðmið og dagleg notkun

Mánaðar- og ársupphæðir eru samanburður; raunveruleg fyrirframgreidd notkun gerist daglega eftir staðfesta breytingu.
faq/billing-periods-and-credit-burn

Viðmið er ekki reikningsdagatal

Mánaðarviðmið notar 31 dag og ársviðmið 372 daga. Fyrirframgreidd þjónusta notar inneign eftir virkum tíma og staðfestri stillingu; breyting hefur áhrif eftir staðfestingu, mögulega greiðslu og virkjun.

Þegar kostnaður breytist

  1. Berðu saman daglegan kostnað fyrir og eftir breytingu.
  2. Meiri CPU, RAM, diskur eða greiddir valkostir geta hækkað daglega notkun.
  3. Bíddu þar til breyting er virkjuð áður en þú treystir nýjum kostnaði.
  4. Vistaðu pantanastaðfestingar, reikninga og sýnilega inneignarsögu.

Stýrðu eftir daglegum kostnaði

Notaðu daglegan kostnað til að áætla inneign. Eftir breytingu skaltu fyrst staðfesta að hún sé virk áður en þú reiknar hversu lengi inneign dugar.

> Pöntunarstaða eftir greiðslu

Pöntun getur beðið staðfestingar greiðsluaðila; forðastu tvípöntun þar til fyrsta pöntun er augljóslega útrunnin eða misheppnuð.
faq/order-status-and-payment-confirmation

Pending er ekki alltaf bilun

Eftir greiðslu getur pöntun beðið staðfestingar frá greiðsluaðila. Ný samskonar pöntun áður en sú fyrsta er greinilega hætt eða útrunnin getur flækt afstemmingu.

Eftir greiðslu

  1. Farðu aftur í Cli>_ eftir að greiðslu lýkur.
  2. Athugaðu pöntunarstöðu í aðgangnum.
  3. Bíddu eftir staðfestingu ef staðan er enn pending.
  4. Hafðu samband við aðstoð með pöntunarnúmer og sýnilega greiðslutilvísun ef staðan breytist ekki.

Ekki búa til tvítekningu

Þótt greiðsluglugga sé lokað eða farið til baka getur fyrsta pöntun enn staðfestst. Skráðu pöntunarnúmerið og bíddu eftir skýrri stöðu áður en pantað er aftur.

> Upplýsingar sem flýta uppsetningu

Undirbúðu þjónustuheiti, lén, DNS-áætlun, admin netfang, auðlindir og opinberan SSH-lykil, ekki leyndarmál.
faq/service-setup-information-needed

Nákvæm opinber gildi spara tíma

Uppsetningarreitir eru fyrir þjónustuheiti, lén, DNS, geymslu, CPU, RAM, admin netfang og opinbera SSH-lykla. Lykilorð, einkalyklar, token og gagnagrunnsútflutningur eiga ekki heima í slíkum reitum.

Hafðu tilbúið fyrir pöntun

  1. Veldu þjónustuheiti sem teymið þekkir.
  2. Ákveddu hvort eigið lén eða tímabundið hostname verður notað.
  3. Útbúðu opinberan SSH-lykil ef þjónustan krefst þess.
  4. Metið CPU, RAM og geymslu eftir forritinu sem á að keyra.

Haltu leyndarmálum utan forms

Opinber SSH-lykill má fara í stillingar, en einkalyklar og lykilorð ekki. Deildu opinberum gildum, valinni stærð og sýnilegum villum.

> Breyta CPU, RAM, disk eða varðveislu eftir pöntun

Breyttu núverandi þjónustu úr þjónustusíðunni og skoðaðu nýtt verð, daglega inneignarnotkun, endurræsingu og niðuritímaáhættu.
faq/change-service-resources-after-order

Breyttu þjónustunni í stað þess að panta aðra

Ef þjónustan er þegar í gangi skaltu gera breytinguna á hennar þjónustusíðu. Ný pöntun getur búið til aðra þjónustu. Breyting tekur gildi eftir staðfestingu, mögulega greiðslu og virkjun.

Áður en þú staðfestir

  1. Skoðaðu núverandi CPU, RAM, disk, backup-varðveislu og Offsite Archive-varðveislu.
  2. Athugaðu nýtt verð og daglega inneignarnotkun.
  3. Lestu viðvaranir um endurræsingu, viðhald eða niðuritíma.
  4. Flyttu út mikilvæg gögn fyrir áhættusama breytingu.

Metið áhrif breytingar

CPU og RAM breytingar geta þurft stutta endurræsingu, en diskur og varðveisla geta tekið lengri tíma. Staðfestu þegar áhrif á notendur eða vinnutíma eru ljós.

> Afturköllun þjónustu og gagnavarðveisla

Þjónusta sem hefur verið sett upp fer fyrst í stöðvun, sýnir sýnilegan eyðingarfrest og getur svo verið hreinsuð varanlega.
faq/cancel-service-and-data-retention

Afturköllun er ekki alltaf tafarlaus eyðing

Þjónusta sem hefur verið sett upp stöðvast venjulega fyrst og sýnir stillanlegan sýnilegan eyðingarfrest. Eftir frestinn getur varanleg hreinsun átt sér stað. Ógreiddar pantanir sem hafa ekki verið settar upp geta hagað sér öðruvísi.

Áður en þú hættir þjónustu

  1. Gerðu eigin útflutning á gögnum sem þarf að geyma.
  2. Lestu stöðvunartilkynningu og sýnilegan eyðingarfrest.
  3. Aðskildu backup og Offsite Archive frá eyðingarfresti þjónustunnar.
  4. Hafðu samband við aðstoð fyrir frestinn ef þú ert óviss.

Taktu gögn út fyrst

Flyttu út skrár, gagnagrunn eða forritsgögn sem þú þarft að geyma áður en þjónustu er hætt. Backup og Offsite Archive tryggja ekki varanlega geymslu eftir eyðingu þjónustu.

> Backup og beiðnir um endurheimt

Backup er fyrir rekstrarendurheimt, ekki staðgengill eigin útflutnings; restore getur skrifað yfir nýrri gögn.
faq/backups-and-restore-requests

Backup er ekki skjalasafn

Varðveisla fer eftir vöru og valkostum. Backup hjálpar við rekstrarendurheimt en kemur ekki í stað eigin útflutnings, audit-arkífs eða Offsite Archive. Restore getur fært gögn aftur í eldra ástand.

Skrifaðu nytsamlega restore-beiðni

  1. Gefðu upp þjónustuheiti og pöntunarnúmer.
  2. Lýstu áætluðum tíma sem á að endurheimta til.
  3. Segðu hvort öll þjónustan eða ákveðinn hluti á að endurheimtast ef stutt.
  4. Sendu sýnilega villu eða samhengi án lykilorða, tokena eða einkalykla.

Skilgreindu umfang restore

Restore getur átt við alla þjónustu eða ákveðinn hluta og getur yfirskrifað nýrri breytingar. Segðu hvaða tímapunkt og hvaða gögn þú þarft.

> Til hvers Offsite Archive er

Offsite Archive geymir fjarlæg afrit aðskilin frá stuttum rekstrarbackupum og eyðingarlífsferli þjónustu.
faq/offsite-archive-purpose

Arkíf utan daglegs rekstrar

Offsite Archive er fyrir fjarlæg arkíf, útflutningssett og eldra efni. Það er ekki lifandi diskur fyrir forrit, ekki sama og stutt backup og ekki trygging fyrir lengri eyðingarfrest þjónustu.

Reiknaðu með dögum og magni

  1. Veldu varðveisludaga eftir reglum eða endurheimtarmarkmiði.
  2. Hugsaðu MB-daga sem geymd MB sinnum daga.
  3. Verð birtist sem EUR/GB/mánuði og er námundað að heilum sentum.
  4. Endurskoðaðu kostnað þegar gagnamagn eða varðveisla vex.

Aðskilið frá lifandi rekstri

Offsite Archive er ekki staður sem forrit notar í rauntíma. Notaðu það fyrir afrit sem eiga að lifa lengur og mettu kostnað eftir magni og varðveisludögum.

> Velja CPU, RAM og disk fyrir VPS

Stærð fer eftir forriti, gagnagrunni, cache, logs og vexti; OOM og swap benda oft til of lítils RAM.
faq/vps-cpu-ram-and-disk-sizing

Álagið ræður stærðinni

Lítil statísk síða þarf annað en gagnagrunnur, leit, Java-forrit eða build-worker. Taktu með minni, cache, logs, upload, gagnagrunn og vaxtarrými.

Merki um of litla áætlun

  1. Auktu RAM við OOM, out of memory, process killed eða mikinn swap.
  2. Auktu CPU við langvarandi reiknivinnu, þjöppun, builds eða upptekna workera.
  3. Auktu disk áður en skráakerfi, logs eða gagnagrunnur fyllast.
  4. Fylgstu með eftir breytingu hvort upprunalega villan hverfur.

Byrjaðu hóflega og fylgstu með

Hófleg byrjun getur dugað, en fylgstu með logs, gagnagrunnsvexti, uploads og minni. Stækkaðu áður en þjónustan rekst á hörð mörk.

> Hvenær opinber IP fyrir VPS nýtist

Sérstök opinber IP hjálpar við allowlist, inbound aðgang, stöðuga outbound uppsprettu eða þjónustur bundnar við vistfang.
faq/vps-public-ip-options

Skýrðu samskiptastefnuna fyrst

Opinber IP er ekki nauðsynleg fyrir alla þjónustu. Hún nýtist þegar samstarfsaðilar, þjónustur eða eldveggir þurfa stöðugt vistfang fyrir inbound aðgang, outbound source eða bæði.

Spurningar áður en IP er bætt við

  1. Spyrðu hvort allowlist sé inbound, outbound eða bæði.
  2. Notaðu DNS-nöfn í stað talna þegar hægt er.
  3. Opnaðu aðeins port sem forritið þarf raunverulega.
  4. Deildu allowlist-kröfu með aðstoð áður en production-aðgangi er breytt.

Þegar bein leið þarf að vera til

Sérstök opinber IP hentar þegar ytri kerfi þurfa að ná beint í VPS eða þegar samstarfsaðili krefst fastrar outbound uppsprettu. Ef sameiginlegt SSH dugar er eigin IP ekki skylda.

> Sameiginlegur SSH-aðgangur að VPS

Án sérstakrar opinberrar IP er tengst um sameiginlega SSH-slóð með háu porti; með opinberri IP getur beint SSH líka verið til staðar.
faq/shared-ssh-access-for-vps

Háa portið leiðir á rétta VPS

Margar VPS þjónustur geta deilt sama opinbera SSH-hosti. Hver þjónusta fær því sitt háa port, og portið er hluti af leiðinni að þinni VPS. Án þess veit sameiginlega SSH-slóðin ekki hvaða þjónusta á að fá tenginguna.

Veldu rétta SSH-slóð

  1. Fyrir sameiginlegt SSH afritarðu SSH-notandanafn, opinberan SSH-host og hátt port af þjónustusíðunni.
  2. Notaðu ssh -p <port> <username>@<public-host>.
  3. Ef þjónustan hefur sérstaka opinbera IP getur hún líka sýnt beint SSH á þeirri IP eða DNS-nafni.
  4. Notaðu einkalykil aðeins staðbundið; aðstoð þarf host, port, username og sýnilega villu.

Sameiginlegt SSH eða beint SSH

Sameiginlegt SSH notar sama opinbera host fyrir margar VPS þjónustur, svo háa portið auðkennir rétta VPS. Með sérstakri opinberri IP getur þjónustan einnig boðið beint SSH á IP eða DNS-nafn, oft á venjulegu SSH-porti.

> Gátlisti áður en eigið lén er tengt

Staðfestu authoritative DNS, nákvæmt hostname, apex eða subdomain, studda record-gerð og gamlar árekstrarstillingar.
faq/custom-domain-readiness-checklist

Nákvæmt hostname ræður leiðinni

example.com og app.example.com geta þurft mismunandi DNS-gerðir og haft mismunandi takmarkanir hjá registrar eða DNS-veitu. Finndu líka hvar authoritative records eru raunverulega breytt.

Áður en DNS er breytt

  1. Leitaðu að núverandi A/AAAA, CNAME, ALIAS, ANAME eða redirect fyrir sama hostname.
  2. Fjarlægðu eða lagaðu árekstra áður en nýtt target er sett inn.
  3. Notaðu record-gerð sem þjónustan mælir með fyrir hostname-gerðina.
  4. Bíddu eftir DNS-propagation og certificate check áður en gamla umhverfið er slökkt.

Skipuleggðu afturköllun

Skráðu gömul DNS gildi áður en þú breytir og haltu gamla umhverfi þar til certificate og ný leið virka. Þá er auðveldara að bakka ef villa kemur upp.

> DNS record-gerðir fyrir þjónustur

A/AAAA benda á vistföng, CNAME er alias, MX stýrir pósti og TXT er notað fyrir verification, SPF, DKIM og DMARC.
faq/dns-record-types-for-services

Hver record-gerð hefur hlutverk

A og AAAA benda á IP-vistföng, CNAME er leyfilegt alias fyrir subdomain, MX stýrir pósti, TXT geymir verification og mail policy, og CAA takmarkar certificate authorities. Rangt CAA getur stöðvað certificate útgáfu.

Pósttengdar stillingar

  1. SPF fer þar sem póstveitan biður um það.
  2. DKIM fer undir selector frá veitunni.
  3. DMARC er yfirleitt undir _dmarc.
  4. Ekki setja CNAME á hostname sem má ekki hafa aðrar records með sér.

Forðastu árekstur á sama nafni

CNAME hostname má oft ekki hafa aðrar records með sér. Athugaðu að web, póstur og verification keppi ekki um sama hostname.

> DNS propagation og TTL

TTL og resolver cache ráða því hve lengi gömul DNS svör geta lifað með nýjum svörum.
faq/dns-propagation-and-ttl

Propagation er hegðun cache

Þegar authoritative DNS breytist geta resolvers samt skilað gömlu svari þar til TTL rennur út. Þess vegna geta mismunandi net, lönd eða resolvers sýnt mismunandi niðurstöður tímabundið.

Skipuleg breyting

  1. Lækkaðu TTL fyrir áætlaða breytingu ef veitan leyfir.
  2. Gerðu breytinguna einu sinni og forðastu tilviljanakenndar endurskrifanir á meðan cache rennur út.
  3. Prófaðu frá fleiri en einum resolver ef svör eru ólík.
  4. Skráðu gamla gildið, nýja gildið, TTL og breytingartíma.

Athugaðu frá fleiri stöðum

Strax eftir breytingu getur einn resolver sýnt gamalt gildi og annar nýtt. Berðu saman authoritative DNS, annað net og public resolver áður en þú telur stillingu ranga.

> Geymsluáætlun fyrir Nextcloud

Reiknaðu með notendaskrám, sameiginlegum möppum, útgáfum, rusli, previews, sync overhead og vexti teymis.
faq/nextcloud-storage-planning

Nextcloud vex utan sýnilegra skráa

Geymsla fer í notendaskrár, sameiginlegar möppur, eyddar skrár, útgáfusögu, previews, thumbnails, sync clients og innflutning. Þegar mörkum er nálgast geta upload og sync bilað.

Áður en pláss er pantað

  1. Leggðu saman núverandi notendagögn og sameiginlegar möppur.
  2. Bættu við svigrúmi fyrir útgáfur, rusl, previews og sync overhead.
  3. Taktu með stóran innflutning, ný teymi og væntan vöxt.
  4. Auktu geymslu áður en notendur rekast á mörkin.

Svigrúm kemur í veg fyrir sync-villur

Þegar geymsla er næstum full geta uploads, sync, previews og versions bilað. Bættu við plássi áður en nýir notendur eða stór import hefjast.

> Flytja repositories í Gitea

Skipuleggðu flutning Git repositories með LFS, submodules, réttindum, deploy keys, webhooks og CI/CD.
faq/gitea-repository-migration

Flutningur er meira en git clone

Saga repository er aðeins hluti verksins. Eigendur, teymi, protected branches, protected tags, Git LFS, submodules, deploy keys, webhooks og CI/CD tengingar þarf að flytja eða endurstilla.

Prófanir fyrir cutover

  1. Skráðu repositories, eigendur, hópa og automation-aðganga.
  2. Athugaðu Git LFS, submodules, branch protections og tag protections.
  3. Prófaðu clone, push, Git LFS, submodules og CI eftir flutning.
  4. Snúðu eða afturkallaðu gömul tokens án þess að deila gildunum.

Flyttu réttindi og sjálfvirkni

Saga ein og sér dugar ekki. Prófaðu deploy keys, webhooks, branch protection og CI áður en gamli staðurinn er gerður read-only eða lokaður.

> Sendilén fyrir Listmonk

Undirbúðu sender domain eða subdomain, From identity, SPF, DKIM, DMARC, bounce og afskráningu fyrir herferð.
faq/listmonk-sender-domain-basics

Afhending byrjar á léninu

Fréttabréf skila sér betur þegar sender domain hefur rétt DNS og skýrt From identity. SPF, DKIM og DMARC þurfa að passa léninu eða subdomain sem sendir herferðina.

Fyrir fyrstu sendingu

  1. Veldu sender domain eða subdomain og From-nafn.
  2. Birtu verification DNS, SPF, DKIM selector og DMARC.
  3. Sendu prófpóst og athugaðu spam, bounce eða Return-Path og tengla.
  4. Haltu unsubscribe og List-Unsubscribe réttum.

Prófaðu með litlu magni

Sendu fyrst til innanhúss eða fárra viðtakenda. Athugaðu spam mat, tengla, afskráningu og bounce áður en stór herferð hefst.

> Keyrsluumhverfi fyrir Classic Hosting

Classic Hosting getur notað sjálfvirkt eða handvirkt keyrsluumhverfi; PHP-val og auðlindir þurfa að passa forritinu.
faq/classic-hosting-runtime-settings

Auto er gagnlegt en ekki alltaf rétt

Sjálfvirkt keyrsluumhverfi hjálpar við þekkt PHP, Node.js, Java, Python, .NET, Go og Ruby verkefni. Handvirkt keyrsluumhverfi hentar þegar þú vilt stýra Nginx, Apache, FrankenPHP eða tungumáli nákvæmar. PHP-val gildir aðeins þar sem valið umhverfi styður það.

Stilltu fyrir birtingu

  1. Veldu sjálfvirkt eða handvirkt umhverfi eftir framework og build-aðferð.
  2. Veldu PHP 8.2, 8.3 eða 8.4 aðeins fyrir studd PHP tilfelli.
  3. Stilltu CPU, RAM, geymslu, backup-varðveislu og Offsite Archive-varðveislu.
  4. Prófaðu upload, cache, logs og sýnilegar forritavillur eftir birtingu.

Veldu eftir forritinu

Auto er þægilegt, en manual getur verið öruggara þegar startskipun, public directory, varanlegar skrár eða nauðsynlegar PHP viðbætur eru þekktar.

> Upplýsingar sem er öruggt að senda aðstoð

Pöntunarnúmer, þjónustuheiti, lén, tími, public host/port og sýnilegar villur hjálpa; leyndarmál eiga ekki að fylgja.
faq/support-safe-information-to-share

Góð beiðni hefur samhengi, ekki leyndarmál

Aðstoð vinnur hraðar með pöntunarnúmeri, sýnilegu þjónustuheiti, léni, public host eða porti, tíma vandans, nýlegum breytingum og nákvæmum sýnilegum villutexta.

Öruggt efni í skilaboðum

  1. Settu inn pöntun, þjónustu, lén, tíma og skrefið þar sem vandinn kom upp.
  2. Fyrir hosting: runtime, PHP eða tungumál, CPU, RAM, disk, uploads, cache og logs án leynigilda.
  3. Maskaðu skjáskot áður en þau eru send.
  4. Sendu aldrei lykilorð, einkalykla, API tokens, seed phrases, gagnagrunnsútflutning eða fulla logga með viðkvæmum gildum.

Lýstu endurtekningu stutt

Skrifaðu hvað þú gerðir, vænta niðurstöðu, raunverulega villu og tíma. Feldu leyndarmál og deildu aðeins opinberum gildum.