FAQ

Vanliga frågor

Praktiska korta guider för serviceinställning, åtkomst och vanliga kundåtgärder.

> Skapa en offentlig SSH-nyckel i terminalen

Skapa en offentlig SSH-nyckel för åtkomst och dela bara den offentliga nyckeln.
faq/generate-public-ssh-key-sv

Använd bara den offentliga nyckeln

SSH använder ett nyckelpar. Klistra bara in den offentliga nyckeln, oftast filen som slutar på .pub, i tjänstens inställningar. Den privata nyckeln stannar på din enhet.

Steg i terminalen

  1. Öppna Terminal, Windows Terminal eller PowerShell.
  2. Kör: ssh-keygen -t ed25519 -C "your-email@example.com".
  3. Acceptera standardplatsen eller välj en säker sökväg.
  4. Visa den offentliga nyckeln med: cat ~/.ssh/id_ed25519.pub.
  5. I Windows PowerShell använder du: Get-Content $env:USERPROFILE\.ssh\id_ed25519.pub.
  6. Kopiera hela raden som börjar med ssh-ed25519 till fältet för SSH public key.

Kontrollera före inklistring

Kopiera aldrig den privata nyckeln. Om du anger en passphrase ska den sparas säkert eftersom den kan behövas senare.

> Skapa en SSH-nyckel grafiskt i Windows

Använd PuTTYgen i Windows för att skapa en SSH-nyckel och kopiera den offentliga delen.
faq/create-ssh-key-windows-gui-sv

Endast den offentliga delen

PuTTYgen skapar både en offentlig och en privat nyckel. Lägg bara till den offentliga nyckeln i Cli>_ och behåll den privata nyckeln lokalt.

Steg i Windows

  1. Öppna PuTTYgen.
  2. Välj EdDSA / Ed25519 när det finns.
  3. Använd RSA 4096 endast som reserv.
  4. Klicka på Generate och rör musen tills nyckeln är skapad.
  5. Spara den privata nyckeln på datorn.
  6. Kopiera texten för den offentliga nyckeln till fältet för SSH public key.

Dela inte privat material

Skicka aldrig .ppk-filer, privata nycklar, passphrases, lösenord eller tokens till support eller web formulär.

> Anslut din egen doman

Kontrollera auktoritativ DNS, exakt hostname, record-typ, apex/subdomän och gamla konflikter.
faq/anslut-din-egen-doman

Exakt hostname styr valet

Bestäm om du kopplar apex som example.com eller subdomän som app.example.com. DNS-typen beror på hostname, registrar och DNS-leverantörens stöd för CNAME, A/AAAA, ALIAS eller ANAME.

Före DNS-ändring

  1. Verifiera var auktoritativa DNS records redigeras.
  2. Ta bort eller ändra konflikter för samma hostname.
  3. Använd record-typen som tjänsten rekommenderar.
  4. Vänta på DNS propagation före slutligt HTTPS-test.

Säker rollback

Stäng inte gammal hosting innan nytt hostname svarar korrekt. Dela domän, förväntat mål och publikt DNS-resultat vid felsökning, inte registrar-login.

> Delegera en DNS-zon

A/AAAA pekar på adresser, CNAME på alias, MX på mail och TXT på verifieringar, SPF, DKIM eller DMARC.
faq/delegera-en-dns-zon

Blanda inte records på chans

A och AAAA pekar på IP-adresser, CNAME skapar alias för subdomän, MX styr mail, TXT bär verifieringar och mailpolicy, och CAA begränsar certifikatutfärdare.

När records kopieras

  1. Kopiera namn, typ och värde exakt.
  2. Lägg inte CNAME på hostname som redan har andra records om DNS-regler förbjuder det.
  3. Placera DKIM under leverantörens selector och DMARC ofta under _dmarc.
  4. Ändra CAA försiktigt eftersom fel värde kan blockera certifikat.

När DNS inte fungerar

Skicka hostname, record-typ, förväntat värde och publikt synligt resultat. Skicka inte DNS-login eller screenshots med API tokens.

> Kontoregistrering och första inloggning

Skapa ett arbetskonto för beställningar, fakturering och tjänstehantering.
faq/account-registration-and-login

Ett konto som teamet inte tappar

Kontot används för beställningar, fakturauppgifter, tjänster, domäner och supportärenden. Välj en arbetsadress som teamet kan behålla över tid.

Innan första beställningen

  1. Registrera med arbets-e-post.
  2. Bekräfta e-posten om sidan begär det.
  3. Fyll i fakturauppgifter före betald beställning.
  4. Aktivera tvåfaktorsautentisering när den finns.

Teamåtkomst utan lösenordsdelning

Skicka inte lösenord via chatt eller e-post. Använd en password manager internt och ge support ordernummer och synligt fel i stället för inloggningsuppgifter.

> Så fungerar förbetald kredit

Kredit visar saldo, uppskattad driftstid, daglig kostnad och risk för suspension eller radering.
faq/prepaid-credit-how-it-works

Kredit förbrukas när tjänster kör

Aktiva förbetalda tjänster drar kredit över tid enligt valda resurser och tillval. Synligt saldo, daglig kostnad och runway visar när du bör fylla på.

Undvik suspension

  1. Följ saldo och runway i kundzonen.
  2. Kontrollera ny daglig kostnad före order eller ändring.
  3. Fyll på med marginal före kredit tar slut.
  4. Läs raderingsfristen direkt om en tjänst suspenderas.

När saldot behöver kontrolleras

Skicka ordernummer, tjänstenamn och period. Skicka inte kortuppgifter, lösenord, privata nycklar eller kompletta bankunderlag.

> Månadsestimat, årsestimat och daglig kreditförbrukning

Månads- och årsbelopp är jämförelser; förbetalda tjänster drar kredit per aktiv dag.
faq/billing-periods-and-credit-burn

Estimat är inte en kalenderfaktura

Månadsestimat använder 31 dagar och årsestimat 372 dagar. Kredit dras efter aktiv driftstid, CPU, RAM, lagring och betalda val efter att ordern eller ändringen är bekräftad, betald vid behov och applicerad.

När priset ändras

  1. Jämför daglig kostnad före och efter ändringen.
  2. Räkna med högre förbrukning vid mer CPU, RAM, disk eller Offsite Archive.
  3. Se ändringen som aktiv först när den är applicerad.
  4. Spara orderbekräftelser och synlig kredithistorik.

Utred en exakt period

Support behöver ordernummer, tjänst och datumintervall. Dela inte bankdata eller screenshots med onödiga personuppgifter.

> Orderstatus efter betalning

En order kan vänta på betalningsbekräftelse; skapa inte en dubblett innan den första är tydligt avslutad.
faq/order-status-and-payment-confirmation

Pending betyder inte automatiskt fel

Efter betalningssidan kan ordern fortfarande vänta på bekräftelse från betalningsleverantören. En dubblett kan försvåra matchningen om den första ordern senare bekräftas.

Efter betalningen

  1. Återvänd till Cli>_ från betalningsleverantören.
  2. Kontrollera orderstatus i kontot.
  3. Vänta på leverantörens bekräftelse om status är pending.
  4. Kontakta support med ordernummer och betalningsreferens om status inte ändras.

Betalningsdata som räcker

Support behöver inte kortnummer, lösenord eller full bankbekräftelse. Ordernummer, tidpunkt, synlig status och maskerad bild räcker.

> Uppgifter som snabbar upp tjänsteinställning

Förbered tjänstenamn, domän, lagring, åtkomstmejl och offentlig SSH-nyckel; hemligheter hör inte hemma i formulär.
faq/service-setup-information-needed

Exakta värden sparar tid

Orderformulär ska innehålla publika eller icke-hemliga värden som tjänstenamn, domän, DNS-plan, CPU, RAM, lagring, adminmejl och public SSH key. Passwords, private keys och tokens ska inte klistras in.

Förbered före checkout

  1. Välj ett tjänstenamn teamet känner igen.
  2. Bestäm egen domän eller tillfälligt system-hostname.
  3. Ta fram offentlig SSH-nyckel om produkten kräver den.
  4. Kontrollera lagring och resurser mot applikationens behov.

Om värdet kan vara hemligt

Fråga först utan att skicka värdet. Dela inte privata nycklar, lösenord, tokens, databasdumpar eller hela konfigurationsfiler.

> Ändra CPU, RAM, disk eller retention efter order

Ändra befintlig tjänst från dess detaljsida och kontrollera pris, kreditförbrukning och eventuell nedtid.
faq/change-service-resources-after-order

Ändra tjänsten, skapa inte en ny

Om tjänsten redan kör ska ändringen göras från tjänstens detaljvy. En ny order skapar en ny tjänst i stället för att ändra den befintliga och kan påverka pris och daglig kreditförbrukning.

Före bekräftelse

  1. Granska CPU, RAM, disk, backup retention och Offsite Archive retention.
  2. Kontrollera ny daglig kostnad och runway.
  3. Läs varning om restart, underhåll eller avbrott.
  4. Exportera viktig data före riskabla ändringar.

Om ändringen misslyckas

Skicka tjänstenamn, tidpunkt, synlig status och felmeddelande. Skicka inte private keys, passwords eller tokens.

> Avsluta tjänst och dataretention

En provisioned tjänst suspenderas först, visar konfigurerbar raderingsfrist och kan sedan rensas permanent.
faq/cancel-service-and-data-retention

Avslut är inte alltid direkt radering

En provisioned tjänst suspenderas först och visar en konfigurerbar synlig raderingsfrist. Obetalda, ej provisioned ordrar kan avslutas utan samma datalivscykel.

Innan du avslutar

  1. Gör egen export av data som ska sparas.
  2. Läs datum och tid för möjlig radering.
  3. Blanda inte ihop backups, Offsite Archive och lifecycle-radering.
  4. Kontakta support före fristen om du behöver återställning eller export.

Efter fristen

Efter synlig frist ska data inte räknas som tillgänglig. Skicka ordernummer och tjänstenamn, inte databasexporter eller inloggningshemligheter.

> Backups och restore-förfrågningar

Backups är för driftåterställning, inte ersättning för export; restore kan skriva över nyare data.
faq/backups-and-restore-requests

Backup är inte arkiv eller export

Backup retention beror på produkt och val. Backup hjälper vid driftfel men ersätter inte egen export eller Offsite Archive. Restore kan återgå till äldre läge och skriva över senare ändringar.

Förbered restore request

  1. Ange tjänstenamn och ordernummer.
  2. Beskriv ungefärlig tidpunkt att återgå till.
  3. Skriv om hela tjänsten eller en del ska återställas.
  4. Bifoga synligt fel utan passwords, tokens eller private keys.

Innan restore körs

Informera teamet och exportera data som inte får förloras om tjänsten har fått nya ändringar efter vald restore-tidpunkt.

> Vad Offsite Archive är till för

Offsite Archive håller fjärrarkivkopior skilda från korta driftbackups och tjänstens livscykel.
faq/offsite-archive-purpose

Arkiv utanför normal drift

Offsite Archive är för fjärrarkivkopior i ett annat datacenter. Det är inte live applikationsdisk, lokal export eller samma sak som korta operationella backups.

Välj retention

  1. Välj retention i dagar efter compliance eller recovery-mål.
  2. Beräkna MB-days som lagrade MB multiplicerat med dagar.
  3. Kom ihåg att pris visas som EUR/GB/månad och avrundas till hela cent.
  4. Planera stora datamängder ihop med egen exportprocess.

Skilt från raderingsfrist

Offsite Archive ändrar inte den synliga raderingsfristen för en suspenderad tjänst och ersätter inte vanliga restore-backups.

> Välj CPU, RAM och disk för VPS

Välj storlek efter applikation, databas, cache, loggar och tillväxt; OOM och swap visar ofta för lite RAM.
faq/vps-cpu-ram-and-disk-sizing

Utgå från arbetslasten

En statisk webbplats, databas, Java-app, sökning eller build-container har olika behov. Räkna med appminne, cache, loggar, uppladdningar, databas och tillväxtmarginal.

När planen är för liten

  1. Öka RAM vid OOM, out of memory, process killed eller konstant swap.
  2. Öka CPU vid långvarig compute, komprimering, builds eller upptagna workers.
  3. Öka disk innan filsystem, loggar eller databas blir fulla.
  4. Följ upp efter ändringen att flaskhalsen försvann.

Vid sizing-fråga

Skicka tjänstenamn, applikationstyp, synligt fel, ungefärlig tid och nuvarande CPU, RAM och disk. Skicka inte lösenord eller interna konfigurationsfiler.

> När publik IP för VPS behövs

Dedikerad publik IP hjälper med allowlists, inbound access, stabil outbound source eller adressbundna tjänster.
faq/vps-public-ip-options

Ta reda på trafikens riktning

Publik IP behövs inte för varje tjänst. Den löser ofta krav från externa partners, leverantörer eller brandväggar på allowlist, stabil outbound source eller inbound access på en viss port.

Före beställning

  1. Fråga om allowlist gäller inbound, outbound eller båda.
  2. Använd DNS-namn i stället för numeriska IP där det går.
  3. Öppna bara portar applikationen faktiskt behöver.
  4. Skicka allowlist-kravet till support innan produktionsaccess ändras.

Håll exponeringen liten

Publik IP ska inte betyda alla portar öppna. Dela inte firewallbilder med hemliga värden, private keys eller passwords.

> Delad SSH-åtkomst till VPS

Utan köpt publik IP ansluts VPS via delad SSH endpoint med hög port; med publik IP kan en direkt SSH-väg också finnas.
faq/shared-ssh-access-for-vps

Varför delad SSH har hög port

Flera VPS-tjänster kan dela samma offentliga SSH-host. Varje tjänst får därför en egen hög port som styr trafiken till rätt VPS. Utan porten kan anslutningen inte routas entydigt.

Anslut efter åtkomsttyp

  1. Vid delad SSH kopierar du username, public host och hög port från tjänsten.
  2. Använd ssh -p <port> <username>@<public-host>.
  3. Om tjänsten har dedikerad publik IP kan den också visa en andra SSH-väg direkt på IP:n eller dess DNS-namn.
  4. Använd private key lokalt i SSH-klient eller agent; dela bara public host, port, username och synligt fel.

När publik IP finns

Den publika IP:n tar inte nödvändigtvis bort den delade endpointen. Den lägger till en separat direkt väg, så du kan se både delad host med hög port och direkt host/IP.

> Checklista före eget domännamn

Kontrollera auktoritativ DNS, exakt hostname, record-typ, apex/subdomän och gamla konflikter.
faq/custom-domain-readiness-checklist

Exakt hostname styr valet

Bestäm om du kopplar apex som example.com eller subdomän som app.example.com. DNS-typen beror på hostname, registrar och DNS-leverantörens stöd för CNAME, A/AAAA, ALIAS eller ANAME.

Före DNS-ändring

  1. Verifiera var auktoritativa DNS records redigeras.
  2. Ta bort eller ändra konflikter för samma hostname.
  3. Använd record-typen som tjänsten rekommenderar.
  4. Vänta på DNS propagation före slutligt HTTPS-test.

Säker rollback

Stäng inte gammal hosting innan nytt hostname svarar korrekt. Dela domän, förväntat mål och publikt DNS-resultat vid felsökning, inte registrar-login.

> DNS record-typer för tjänster

A/AAAA pekar på adresser, CNAME på alias, MX på mail och TXT på verifieringar, SPF, DKIM eller DMARC.
faq/dns-record-types-for-services

Blanda inte records på chans

A och AAAA pekar på IP-adresser, CNAME skapar alias för subdomän, MX styr mail, TXT bär verifieringar och mailpolicy, och CAA begränsar certifikatutfärdare.

När records kopieras

  1. Kopiera namn, typ och värde exakt.
  2. Lägg inte CNAME på hostname som redan har andra records om DNS-regler förbjuder det.
  3. Placera DKIM under leverantörens selector och DMARC ofta under _dmarc.
  4. Ändra CAA försiktigt eftersom fel värde kan blockera certifikat.

När DNS inte fungerar

Skicka hostname, record-typ, förväntat värde och publikt synligt resultat. Skicka inte DNS-login eller screenshots med API tokens.

> DNS propagation och TTL utan minutlöften

TTL styr hur länge resolvers kan hålla gamla svar; gamla och nya svar kan finnas samtidigt.
faq/dns-propagation-and-ttl

Propagation är cachebeteende

DNS har inget fast löfte på minuter. Efter ändring i auktoritativ DNS kan olika resolvers visa gamla eller nya svar tills deras cache löper ut enligt TTL.

Vid planerad ändring

  1. Sänk TTL i förväg om leverantören tillåter det.
  2. Gör ändringen en gång och undvik slumpmässiga upprepade ändringar.
  3. Testa från flera resolvers om resultaten skiljer sig.
  4. Skriv ned ändringstid, gammalt värde, nytt värde och TTL.

För supportdiagnos

Skicka hostname, förväntat mål, synligt gammalt svar, synligt nytt svar, TTL och ändringstid. Skicka inte DNS-kontots åtkomstuppgifter.

> Planera lagring för Nextcloud

Räkna med användarfiler, delningar, versioner, papperskorg, previews, sync overhead och teamtillväxt.
faq/nextcloud-storage-planning

Nextcloud växer utanför synliga filer

Kapacitet används av användarfiler, delade mappar, raderade filer, versionshistorik, previews, thumbnails, sync-klienter och importer. Nära gränsen kan upload och sync börja misslyckas.

Före kapacitetsval

  1. Räkna nuvarande användardata och gemensamma mappar.
  2. Lägg till marginal för versioner, papperskorg, previews och sync overhead.
  3. Planera stora importer och nya team.
  4. Öka lagring innan användare når gränsen.

Vid sync-problem

Skicka tjänstestorlek, ungefärlig användning, tidpunkt och synligt klientfel. Skicka inte personliga filer eller användardataexporter utan överenskommen säker metod.

> Migrera repositories till Gitea

Planera Git-migrering med LFS, submodules, rättigheter, deploy keys, webhooks och CI/CD.
faq/gitea-repository-migration

Migrering är mer än git clone

Utöver historik måste ägare, team, protected branches, protected tags, Git LFS, submodules, deploy keys, webhooks och CI/CD flyttas eller återskapas.

Check före cutover

  1. Lista repositories, ägare, åtkomstgrupper och automationskonton.
  2. Verifiera Git LFS objects, submodules och branch/tag protections.
  3. Testa clone, push, Git LFS, submodules och CI efter flytt.
  4. Rotera eller ta bort gamla tokens utan att dela värdena.

Känsliga uppgifter

Skicka inte tokens, private keys, privat del av deploy keys eller CI secrets. Dela repository-namn, integrationstyp, synligt fel och vad som fungerade före migrering.

> Avsändardomän för Listmonk

Förbered sender domain eller subdomän, From-identitet, SPF, DKIM, DMARC, bounce och unsubscribe.
faq/listmonk-sender-domain-basics

Leverans börjar vid domänen

Listmonk behöver tydlig From-identitet och DNS records som mottagande mailsystem kan verifiera. SPF, DKIM och DMARC ska stämma med domänen eller subdomänen som skickar kampanjer.

Före första kampanjen

  1. Välj sender domain eller subdomän och From-namn.
  2. Lägg till verifieringsrecords, SPF, DKIM selector och DMARC.
  3. Testa leverans, bounce eller Return-Path och länkar.
  4. Kontrollera unsubscribe och List-Unsubscribe före utskick.

Mailhemligheter stannar hos dig

Vid diagnos delas domän, record-typ, publikt DNS-resultat och feltext. Skicka inte SMTP-lösenord, API token, private DKIM key eller mottagarlistor med persondata.

> Runtime-inställningar för Classic Hosting

Classic Hosting kan köras i auto eller manuell Runtime; CPU, RAM, lagring, backups, Offsite Archive, uploads, cache och logs påverkar pris och stabilitet.
faq/classic-hosting-runtime-settings

Auto är inte alltid rätt val

Auto Runtime hjälper vid igenkända projekt, men manuell Runtime passar när du vill välja Nginx, Apache, FrankenPHP eller en specifik language runtime. PHP 8.2, 8.3 eller 8.4 används bara där vald runtime stöder det.

Före deploy

  1. Välj auto eller manuell Runtime efter framework och buildmetod.
  2. Välj PHP selector bara för stödda PHP-scenarier.
  3. Sätt CPU, RAM, disk, backup retention och Offsite Archive efter data och trafik.
  4. Testa uploads, cache, logs och synliga appfel efter deploy.

När appen inte startar

Skicka runtime mode, språk eller PHP-version, synligt fel, vad som ändrats och ungefärlig tid. Skicka inte .env filer, passwords, tokens eller fulla logs med hemligheter.

> Vilken information är säker att dela med support

Dela ordernummer, tjänstenamn, domäner, tider, public hosts, portar, inställningar och synliga fel utan hemligheter.
faq/support-safe-information-to-share

Ett bra ärende har kontext, inte hemligheter

Support kan svara snabbare med ordernummer, tjänstenamn, domän, public host eller port, tidpunkt, vad som ändrades och exakt synlig feltext.

Säkert innehåll i meddelandet

  1. Ange order, tjänst, domän, tid och steget där felet uppstod.
  2. För hosting kan du lägga till runtime, PHP eller språk, CPU, RAM, disk, uploads, cache och logs utan secret-värden.
  3. Maskera screenshots före uppladdning.
  4. Fråga först utan att skicka värdet om du är osäker.

Skicka aldrig detta

Skicka inte passwords, private keys, recovery seeds, API tokens, session cookies, databasexporter, hela .env filer, fulla logs med känsliga värden eller interna infrastrukturdetaljer.