En nettbutikk i Trondheim som vil ta imot bitcoin uten å betale 1-3 prosent til en betalingsformidler, eller en frilanser i Bergen som er trøtt av å vente tre dager på en bankoverføring fra utlandet, ender ofte opp med samme spørsmål: finnes det en måte å ta imot kryptobetaling direkte, uten mellommann og uten gebyr på selve transaksjonen? Svaret er BTCPay Server, et selvhostet, ikke-depot-basert betalingssystem for Bitcoin og Lightning Network. Du installerer det på din egen server, kobler det til en bitcoin-node og en Lightning-node, og pengene går rett til din egen lommebok. Ingen tredjepart ser transaksjonen før den er bekreftet på kjeden eller i en Lightning-kanal.
Denne guiden tar deg gjennom 14 konkrete steg: fra å skaffe en server og åpne porter, til å velge Lightning-implementasjon, låse ned API-et riktig og sette opp backup som faktisk fungerer når noe går galt. Du får kommandoene du trenger, eksempler på hvordan output skal se ut, og en liste over fallgruver som har sendt mer enn én driftig selvhoster tilbake til support-foraet klokken tre om natten. Beregn rundt 90 minutter aktiv tid til selve konfigurasjonen, men regn med at Bitcoin-noden synkroniserer i bakgrunnen i flere timer eller dager etterpå, avhengig av om du kjører full node eller pruned node.
Hva er BTCPay Server, og hvorfor er det relevant i Norden nå
BTCPay Server er et åpen kildekode-prosjekt som fungerer som en betalingsprosessor for Bitcoin, på kjeden og over Lightning Network. I motsetning til depotbaserte tjenester holder BTCPay Server aldri pengene dine. Programvaren genererer fakturaer, overvåker blokkjeden og Lightning-kanalene dine, og varsler butikken din når en betaling er bekreftet, men selve bitcoinen går direkte fra kundens lommebok til din. Det finnes ingen prosentandel BTCPay Server tar av summen. Kostnadene du faktisk betaler er VPS-leie, nettverksgebyr på kjeden og eventuelle Lightning-kanalgebyrer, ikke en avgift til programvareleverandøren.
Den siste store utgivelsen er BTCPay Server 2.4.5, sluppet 6. oktober 2026. Oppdateringen strammer inn sikkerheten rundt Lightning og LNURL, gjør fakturagenerering raskere, og gjør selve Docker-oppsettet slankere ved å fjerne integrasjoner som ikke lenger vedlikeholdes. Den fortsetter også et sikkerhetsarbeid som startet i versjon 2.4.2: Docker-oppsett eksponerer ikke lenger LND- og Core Lightning-API-ene offentlig som standard. Dette er et poeng vi kommer tilbake til i steg 11, fordi det endrer hvordan eldre guider på nettet beskriver oppsettet.
Hvorfor er dette aktuelt for nordiske foretak akkurat nå? Fordi alternativene har blitt tynnere. Coinbase Commerce stengte tjenesten for alle merchantkontoer utenfor USA og Singapore 31. mars 2026, noe som fjerner et av de mest brukte hostede alternativene for europeiske nettbutikker. Samtidig krever flere hostede Lightning-prosessorer som OpenNode og Strike fortsatt KYC og tar en løpende andel av omsetningen, selv om de konkrete gebyrsatsene for norske og nordiske foretak ikke er offentlig dokumentert per oktober 2026. For en bedrift som ønsker full kontroll over egen likviditet og data, uten å stole på en tredjeparts drift, er selvhosting av BTCPay Server i praksis det mest gjennomsiktige valget som finnes.
Hvem bruker BTCPay Server i praksis, og hva kan det ta betalt for
BTCPay Server startet som et prosjekt for enkeltpersoner som ville slippe gebyrene til hostede bitcoin-betalingsløsninger, men har siden vokst til å dekke et bredt spekter av bruksområder. Nettbutikker bruker det til å ta betalt for fysiske varer. Programvareselskaper kobler det til abonnementsløsninger for å fakturere kunder i bitcoin hver måned. Ideelle organisasjoner bruker det til å ta imot donasjoner uten at en betalingsformidler tar en andel av gaven. Enkelte serverhotell og VPN-tjenester tar nå imot betaling direkte gjennom egne BTCPay-instanser, nettopp fordi kundegruppen deres allerede er komfortabel med å betale i bitcoin eller Lightning.
Det som gjør løsningen spesielt relevant for små og mellomstore foretak i Norden, er at du ikke trenger en betalingsformidler-avtale eller en kortterminal-kontrakt for å komme i gang. Du trenger en server, et domene og tid til å gå gjennom oppsettet. BTCPay støtter i tillegg flere kryptovalutaer utover bitcoin i samme installasjon (deriblant Litecoin og Monero via egne generator-flagg), men denne guiden holder seg til bitcoin og Lightning, siden det er kombinasjonen de fleste norske og nordiske foretak faktisk etterspør.
Et vanlig spørsmål fra foretak som overveier løsningen, er hvor mye teknisk kompetanse som faktisk trengs. Svaret er at du bør være komfortabel med Linux-terminalen, grunnleggende DNS-oppsett og Docker-begreper før du starter. Du trenger derimot ikke være blockchain-utvikler. Alt oppsettet beskrevet i denne guiden går gjennom offisielle skript og miljøvariabler, ikke egenskrevet kode mot blokkjeden.
Forutsetninger: maskinvare, operativsystem og versjoner
Du trenger ikke en kraftig maskin, men du trenger riktig type maskin. BTCPay Server kjører i Docker-containere, og hele oppsettet (Bitcoin-node, Lightning-node, NBXplorer og selve BTCPay-applikasjonen) deles opp i separate containere som orkestreres med Docker Compose. Under følger minimumsoppsettet vi bruker gjennom resten av guiden.
| Komponent | Minimum for testing | Anbefalt for drift |
|---|---|---|
| Operativsystem | 64-bit Linux med Docker-støtte | 64-bit Linux, oppdatert LTS-versjon |
| RAM | 2-4 GB med swap | 4-8 GB |
| Diskplass (full node) | Flere hundre GB, øker jevnlig | 1 TB+ SSD, med god margin for logger og backup |
| Diskplass (pruned node) | Betydelig mindre enn full node | Fortsatt SSD, pruning krever random access |
| Docker Engine | 20.10.10 eller nyere (krav fra BTCPay 1.12.0) | Nyeste stabile versjon fra Docker-prosjektet |
| Nettverk | Statisk offentlig IP | Statisk IP og eget DNS-navn med HTTPS |
Legg merke til at BTCPay Server 1.12.0 (2025) oppgraderte kjerneapplikasjonen til .NET 8, noe som samtidig satte Docker Engine 20.10.10 som minimumskrav. Siden dette er en bevegelig grense, og nyere utgivelser som 2.4.5 kan stramme kravene ytterligere, bør du alltid kjøre nyeste stabile Docker-versjon fra ditt Linux-distro sine egne pakkebrønner før du starter installasjonen. Et pruned Bitcoin-node-oppsett reduserer diskbehovet markant, og er spesielt relevant hvis du planlegger å kjøre Core Lightning, siden BTCPay sin egen FAQ for Lightning Network anbefaler CLN nettopp fordi implementasjonen støtter pruned noder godt.
Steg 1-2: Skaff en VPS og pek domenet dit
Start med å leie en VPS fra en leverandør som tilbyr statisk IPv4-adresse og full root-tilgang. Du trenger ikke en norsk leverandør spesifikt, men lokal eller EU-basert hosting gjør det enklere å forholde seg til norsk og europeisk regelverk for datalagring senere. Når serveren er klar, peker du et A-record for domenet ditt (for eksempel betaling.dinbutikk.no) til IP-adressen.
Deretter åpner du portene BTCPay faktisk trenger: 80 og 443 for HTTPS-trafikk mot selve BTCPay-grensesnittet, samt Bitcoin-nodens P2P-port (8333 for mainnet) hvis du vil at noden din skal akseptere innkommende tilkoblinger fra andre noder på nettverket, noe som styrker nettverket generelt og forbedrer egen tilkobling. Lightning-nodens P2P-port (vanligvis 9735) må også åpnes hvis du vil ta imot innkommende kanaler. Du skal derimot ikke åpne REST- eller gRPC-portene til LND eller CLN mot internett. Det punktet er så viktig at hele steg 11 handler om nettopp dette.
Steg 3-4: Installer Docker og klone BTCPay-repoet
Logg inn på serveren som root eller en bruker med sudo-rettigheter, installer Docker Engine og Docker Compose fra distribusjonens offisielle kilder, og verifiser versjonen før du går videre.
docker --version
docker compose version
sudo su -
git clone https://github.com/btcpayserver/btcpayserver-docker
cd btcpayserver-dockerRepoet btcpayserver-docker er selve byggeverktøyet som genererer hele docker-compose-oppsettet basert på miljøvariablene du setter i neste steg. Byggelogikken oppdateres kontinuerlig, og du kan selv følge med på statusen for hver bygg-kjøring i prosjektets GitHub Actions-historikk, der blant annet oppgraderingen til Core Lightning 26.06.9 ble rullet ut i starten av oktober 2026. Her ser du også umiddelbart hvis en bygg-kjøring feiler, noe som er nyttig å vite om før du selv prøver å kjøre samme kommando på egen server.
Steg 5-6: Velg kjede og nodetype (full node eller pruned)
Her bestemmer du hvilken kryptovaluta BTCPay skal støtte, og om Bitcoin-noden skal lagre hele blokkjeden eller kjøre pruned. For en ren bitcoin-butikk setter du kun BTC som kjede.
export BTCPAYGEN_CRYPTO1="btc"
export BTCPAYGEN_REVERSEPROXY="nginx"
export BTCPAYGEN_LIGHTNING="clightning"
export NBITCOIN_NETWORK="mainnet"
export BTCPAY_HOST="betaling.dinbutikk.no"Full node gir deg komplett historikk og maksimal verifiserbarhet, men krever flere hundre gigabyte og vokser jevnt over tid. Pruned node sletter gamle blokkdata etter verifisering og holder bare det som trengs for å validere nye transaksjoner, noe som gjør den langt billigere å drifte på en liten VPS. Ulempen er at pruned-noder ikke kan servere historiske blokker til andre noder, og noen avanserte Lightning-operasjoner (som å gjenoppbygge en kanal fra bunnen av gamle on-chain-data) blir vanskeligere. For de fleste nordiske nettbutikker med moderat transaksjonsvolum er pruned mer enn godt nok.
Steg 7-8: Velg Lightning-implementasjon
BTCPay Server støtter per i dag fire valg for Lightning via miljøvariabelen BTCPAYGEN_LIGHTNING: clightning (Core Lightning), lnd, phoenixd og none. Valget påvirker alt fra pruning-kompatibilitet til hvor mye manuell kanalstyring du må gjøre selv.
| Implementasjon | Verdi for BTCPAYGEN_LIGHTNING | Støtter pruned node | Container-versjon (okt. 2026) |
|---|---|---|---|
| Core Lightning (CLN) | clightning | Ja, anbefalt av BTCPay for dette | v26.06.9 |
| LND | lnd | Begrenset, krever ekstra konfigurasjon | v0.21.3-beta-2 |
| Eclair | eclair (krever fragmentet opt-txindex) | Nei, krever txindex | Satt via BTCPAYGEN_ADDITIONAL_FRAGMENTS |
| Phoenixd | phoenixd | Egen node-modell, ikke relevant | Egen releasesyklus |
For Eclair må du eksplisitt sette et ekstra fragment, siden implementasjonen krever full transaksjonsindeksering på Bitcoin-noden:
export BTCPAYGEN_LIGHTNING="eclair"
export BTCPAYGEN_ADDITIONAL_FRAGMENTS="opt-txindex"Core Lightnings modulære arkitektur og pruned-støtte gjør den til BTCPay-prosjektets egen anbefaling for de fleste selvhostede oppsett, ifølge dokumentasjonens dedikerte Lightning Network FAQ. LND har et bredere plugin-økosystem og flere tredjepartsintegrasjoner (autopilot, keysend, watchtower), noe som kan være verdifullt hvis du planlegger å koble BTCPay sammen med andre Lightning-verktøy du allerede kjører. Velg CLN hvis mål nummer én er lav driftskostnad. Velg LND hvis du uansett skal bygge et bredere Lightning-oppsett rundt noden.
Den fullstendige, oppdaterte listen over hvilke container-versjoner BTCPay faktisk tester og støtter for hver Lightning-implementasjon finner du i prosjektets oversikt over støttede images. Dette er nyttig å sjekke før hver oppgradering, siden det er her du ser om versjonen du kjører fortsatt regnes som støttet, eller om den har blitt faset ut i en nyere BTCPay-utgivelse. Selve Lightning-containeren for Core Lightning er for øvrig publisert åpent på Docker Hub, der du kan se nøyaktig hvilken image-tag (for eksempel v26.06.9) som ligger bak hver versjon.
Steg 9-10: Kjør installasjonsscriptet og opprett første butikk
Med miljøvariablene satt, kjører du selve installasjonsscriptet. Dette genererer docker-compose-filene og starter containerne.
. ./btcpay-setup.sh -iScriptet laster ned image-ene, bygger nettverket mellom containerne og starter Bitcoin Core, din valgte Lightning-node, NBXplorer og BTCPay-applikasjonen i riktig rekkefølge. Forvent output som ser ut noe slik når alt går bra:
Pulling generated_bitcoind ... done
Pulling generated_clightning_bitcoin ... done
Pulling generated_nbxplorer ... done
Pulling generated_btcpayserver ... done
Creating generated_bitcoind_1 ... done
Creating generated_clightning_bitcoin_1 ... done
Creating generated_nbxplorer_1 ... done
Creating generated_btcpayserver_1 ... done
BTCPay Server is now running on https://betaling.dinbutikk.noBitcoin-noden begynner nå å synkronisere blokkjeden i bakgrunnen, noe som kan ta alt fra noen timer til et par døgn avhengig av om du kjører full eller pruned node og hvor god internettlinjen til VPS-en er. Du kan opprette admin-bruker og første butikk i webgrensesnittet mens synkroniseringen pågår, men du bør ikke ta imot reelle betalinger før noden er helt synkronisert og Lightning-kanalene har fått bekreftet likviditet. Gå til Store Settings, velg hvilke betalingsmetoder butikken skal støtte (on-chain, Lightning, eller begge), og lagre.
Når butikken er satt opp, kan du opprette en testfaktura fra Point of Sale-visningen eller direkte fra Invoices-menyen. En vellykket faktura viser både en on-chain-adresse og en Lightning-betalingsforespørsel (BOLT11) side om side, og kunden velger selv hvilken av de to vedkommende vil betale med. Fakturaen oppdaterer status automatisk fra “New” til “Processing” til “Settled” i takt med at betalingen bekreftes, uten at du må oppdatere siden manuelt. Dette er samme mekanisme butikken din senere vil lene seg på når en reell kunde betaler.
Steg 11: Lås ned Lightning-API-et riktig (2.4.5-herding)
Dette er stedet der eldre guider på nettet gir deg feil informasjon, fordi oppsettet endret seg med sikkerhetsarbeidet i BTCPay 2.4.2 og videre i 2.4.5. Standard Docker-oppsett eksponerer ikke lenger LND- eller Core Lightning-API-et offentlig. Hvis du trenger fjernaksess, må du eksplisitt styre dette med kommandoen btcpay-routes, ikke ved å åpne porten direkte i brannmuren.
cd btcpayserver-docker
./btcpay-routes.sh
# Følg menyen for å aktivere kun de rutene du faktisk trenger,
# og la gRPC/REST-grensesnittet mot Lightning-noden stå lukket
# for alt annet enn intern Docker-nettverkstrafikk.Praktisk regel: hold Lightning-API-et privat, og tilgjengeliggjør det kun gjennom det interne Docker-nettverket, en VPN du selv kontrollerer, eller strengt begrensede brannmurregler bundet til din egen IP. Et åpent gRPC- eller REST-endepunkt mot internett er fortsatt en av de vanligste årsakene til at selvhostede Lightning-noder blir drenert. BTCPay sin egen 2.4.5-utgivelse varsler nå administratorer dersom Docker sin LND REST- eller gRPC-endepunkt er tilgjengelig mens reverse-proxy-ruten er deaktivert, nettopp for å fange opp denne feilkonfigurasjonen før den blir et problem.
Legg i tillegg til en fail2ban-regel eller lignende verktøy for å begrense gjentatte innloggingsforsøk mot selve BTCPay-admin-panelet, siden dette er et offentlig HTTPS-endepunkt og dermed et naturlig mål for automatiserte brute-force-forsøk. Aktiver tofaktor-autentisering for admin-kontoen før butikken går i produksjon, ikke etter. En kompromittert admin-konto gir i praksis tilgang til butikkinnstillinger, API-nøkler og eventuelt lommebokkonfigurasjon, og er dermed et langt mer alvorlig scenario enn et vanlig innbruddsforsøk mot en nettbutikk uten krypto.
Steg 12: Sett opp backup av lommebok og kanaltilstand
En backup av kun on-chain-lommeboken er ikke en fullstendig gjenopprettingsplan for Lightning. Kanaltilstanden endrer seg for hver betaling, og en utdatert kanal-backup kan i verste fall føre til at du eller motparten taper midler ved en tvangsavslutning (force-close). Du må derfor sikkerhetskopiere tre ting separat: seed-frasen til on-chain-lommeboken, databasen til BTCPay selv, og kanaltilstanden til Lightning-noden.
# Eksempel: ta backup av BTCPay-databasen og lightning-datamappen
docker exec generated_postgres_1 pg_dump -U postgres btcpayserver > btcpay_db_backup.sql
# Kopier lightning-datamappen (CLN) til sikker, kryptert lagring
rsync -avz /var/lib/docker/volumes/generated_clightning_bitcoin_datadir/_data/ \
/sikker/backup/clightning-$(date -I)/For Core Lightning bør du i tillegg aktivere static channel backups (SCB), som lar deg gjenopprette tilgang til on-chain-midler fra en avsluttet kanal selv om selve kanaldataen går tapt. Legg backupene på en annen fysisk lokasjon enn selve VPS-en, aller helst kryptert og med minst to kopier. Test gjenoppretting minst én gang i et testmiljø før du går live med reelle beløp, siden en backup du aldri har testet i praksis er en antagelse, ikke en plan.
Steg 13: Koble BTCPay til nettbutikken din
BTCPay eksponerer et Greenfield API som nettbutikker, fakturasystemer og egne skript kan bruke til å opprette fakturaer, lytte på webhooks for betalingsstatus, og hente ut rapporter. Hvis du driver en WooCommerce- eller Shopify-basert butikk, finnes det ferdige plugin-integrasjoner som kobler seg mot denne API-en uten at du behøver å skrive kode selv.
- Opprett en API-nøkkel under Account Settings > API Keys, og begrens tillatelsene til kun det pluginet faktisk trenger (vanligvis btcpay.store.canviewinvoices og btcpay.store.cancreateinvoice).
- Sett opp en webhook-URL i butikkinnstillingene slik at nettbutikken din får beskjed øyeblikkelig når en faktura går fra “ny” til “betalt”.
- Test hele flyten med en liten reell transaksjon før du setter butikken i full drift, inkludert at kvittering og lagerstatus faktisk oppdateres korrekt.
Hvis du ikke bruker et ferdig plugin, kan egen backend-kode kalle Greenfield API-et direkte over HTTPS med API-nøkkelen i Authorization-headeren. Dette gir full kontroll, men krever at du selv håndterer feilsituasjoner som utløpte fakturaer og delvise betalinger over Lightning. Skal du i stedet integrere direkte mot Lightning-noden fra egen kode, ikke via BTCPay sitt API, finnes tilkoblingsbiblioteker som BTCPayServer.Lightning.LND for .NET-baserte prosjekter, som støtter tilkoblingsstrenger for både LND, Core Lightning og Eclair gjennom et felles grensesnitt.
Steg 14: Oppdater BTCPay og Lightning-noden trygt
Oppdateringer av selvhostet infrastruktur er ikke valgfritt. Da sikkerhetsoppdateringen for Core Lightning 26.06.9 kom 11. oktober 2026, fikset den en sårbarhet i versjon 26.06.8 og eldre som i verste fall kunne lede til tap av midler. Den typen varsel må du fange opp raskt, ikke måneder senere. Følg denne rekkefølgen hver gang du oppdaterer:
- Ta full backup av BTCPay-database og lommebokdata før du rører noe.
- Ta backup av Lightning-kanaltilstanden, og bekreft at gjenopprettingsrutinen din faktisk fungerer.
- Oppdater BTCPay Server til siste stabile versjon via git pull og ny kjøring av btcpay-setup.sh.
- Oppdater den valgte Lightning-implementasjonen separat, siden BTCPay og nodeprogramvaren ikke alltid følger samme releasesyklus.
- Kontroller at API-rutene fortsatt er lukket mot internett etter oppgraderingen.
- Test fakturaopprettelse, betaling, refusjon og webhook-levering på nytt.
- Overvåk loggene i minst et par timer etter oppgraderingen før du erklærer den vellykket.
Vanlige fallgruver ved selvhosting av BTCPay Server
De fleste problemene med BTCPay Server i produksjon kommer ikke fra feil i selve programvaren, men fra hvordan den driftes. Her er fem fallgrupper som gjentar seg oftest.
- Å eksponere Lightning-API-et offentlig. Et åpent gRPC- eller REST-endepunkt mot internett er fortsatt den vanligste veien inn for angripere som jakter på selvhostede noder.
- Å behandle on-chain-backup som fullstendig Lightning-backup. Kanaltilstand endrer seg konstant, og en gammel backup kan utløse tvangsavslutning med tap som resultat.
- Å undervurdere diskbehovet for full node. Mange selvhostere starter med for lite disk og må migrere midt i en synkronisering, noe som koster timer med nedetid.
- Å hoppe over testing av gjenoppretting. En backup som aldri er testet i praksis, er ikke en backup, det er en forhåpning.
- Å bruke eldre installasjonsguider uten å sjekke generator-opsjonene mot gjeldende Docker-dokumentasjon. Verdier for BTCPAYGEN_LIGHTNING og tilhørende fragmenter endres mellom versjoner, og en gammel blogpost kan referere til opsjoner som ikke lenger eksisterer eller fungerer annerledes.
Feilsøking: de vanligste problemene og løsningene
Selv et korrekt oppsett kan møte motstand i praksis. Under følger åtte situasjoner support-forumene ser oftest, og hva som faktisk løser dem.
- btcpay-setup.sh feiler med “permission denied”. Kjør scriptet som root (sudo su -) før du starter, og bekreft at Docker-daemonen faktisk kjører med systemctl status docker.
- Containerne starter, men BTCPay-grensesnittet svarer ikke på HTTPS. Sjekk at DNS-oppføringen faktisk peker til riktig IP, og at nginx-reverse-proxy-containeren har fått generert et gyldig sertifikat. En feilkonfigurert BTCPAY_HOST-variabel er den vanligste årsaken.
- Bitcoin-noden synkroniserer ekstremt sakte. Kontroller disk-I/O med iostat. Spinning-disker holder ofte ikke følge med initial blockchain download, og en SSD-oppgradering løser problemet i de fleste tilfeller.
- Lightning-noden kobler ikke til Bitcoin-noden. Begge containerne må være på samme Docker-nettverk, og Bitcoin-noden må være fullt synkronisert før Lightning-noden kan starte korrekt.
- Fakturaer utløper før kunden får betalt. Standard utløpstid kan være for kort for Lightning-betalinger med dårlig rutefunn. Øk utløpstiden i Store Settings, spesielt hvis noden din har lav inngående likviditet.
- “No route found” ved Lightning-betaling. Dette betyr nesten alltid for lite inngående likviditet i kanalene dine. Åpne flere kanaler, eller bruk en likviditetstjeneste for å få inngående kapasitet.
- Webhook-kall fra BTCPay når aldri nettbutikken. Kontroller at webhook-URL-en er offentlig tilgjengelig fra BTCPay-containeren, og se etter TLS-feil eller feil port i loggene til webhook-leveransen i admin-panelet.
- Oppgradering av Core Lightning feiler med versjonskonflikt. Sjekk at image-versjonen i din genererte docker-compose-fil faktisk matcher den nyeste anbefalte, siden en manuelt redigert fil kan ha låst en eldre tag som 26.06.8 fast.
Lightning-likviditet: planlegg inngående kapasitet før du går live
En nyopprettet Lightning-node har ofte mye utgående kapasitet og svært lite inngående kapasitet, siden en helt ny kanal som standard gir noden som åpner den all balansen på sin egen side. Det betyr at du i praksis kan betale ut, men ikke ta imot, før noen sender deg penger eller du aktivt skaffer inngående likviditet. For en butikk som skal ta imot betalinger, er dette et reelt driftsproblem fra dag én, ikke en teoretisk detalj.
Du løser dette på tre måter. Den første er å åpne kanaler direkte mot velkjente, velkapitaliserte noder som allerede har inngående kapasitet å avgi, ofte mot et mindre gebyr. Den andre er å bruke en likviditetstjeneste som støtter standardene LSPS1 eller LSPS2, der du kjøper en kanal med forhåndsbestemt inngående kapasitet rett fra en Lightning Service Provider. Den tredje er å la trafikken bygge seg organisk: etter at noen har betalt deg, sitter du med inngående kapasitet tilsvarende det beløpet, som igjen kan brukes til å ta imot nye betalinger. For en ny butikk med forventet jevnt transaksjonsvolum er kombinasjonen av én eller to direkte kanaler mot solide noder, pluss en liten likviditetskjøp i oppstartsfasen, vanligvis nok til å komme i gang uten å oppleve “no route found” på de første kundene.
Skatt, bokføring og regelverk for norske foretak
Å ta imot bitcoin som betalingsmiddel endrer ikke de grunnleggende bokføringspliktene dine. En faktura betalt i bitcoin skal fortsatt bokføres til verdien i norske kroner på betalingstidspunktet, og mva-behandlingen følger varen eller tjenesten som selges, ikke betalingsmiddelet. BTCPay Server lagrer kursen som ble brukt da fakturaen ble opprettet og betalt, noe som gir deg et konkret grunnlag for bokføringen uten at du må hente kurshistorikk fra et tredjepartsverktøy etterpå.
Siden du selv sitter med nøklene til midlene, har du også selv ansvaret for å dokumentere hvilken kurs som ble brukt, hvilken wallet-adresse pengene gikk til, og hvordan du eventuelt omsetter bitcoin til kroner i etterkant hvis du ikke vil sitte med kursrisiko. Mange norske regnskapsførere har i dag erfaring med kryptobokføring, men det er verdt å avklare rutinen med egen regnskapsfører før du setter butikken i produksjon, spesielt hvis transaksjonsvolumet er stort nok til at kursrisiko faktisk påvirker resultatet.
Avanserte tips for produksjonsdrift
Når grunnoppsettet fungerer stabilt, er det noen justeringer som gjør driften vesentlig tryggere og billigere over tid.
Kjør noden bak Tor i tillegg til clearnet, slik at Lightning-noden din kan nås selv om en clearnet-tilkobling faller ut, og slik at du ikke lekker IP-adressen din til hver node du åpner en kanal mot. Core Lightning og LND har begge innebygd Tor-støtte som BTCPay sitt Docker-oppsett kan aktivere via egne miljøvariabler. Legg til en watchtower-tjeneste for Lightning-kanalene dine, slik at en forsøkt bedragersk kanalavslutning blir fanget opp og motarbeidet selv om noden din er offline i øyeblikket angrepet skjer. Overvåk disk, minne og nettverkstrafikk med et eksternt verktøy, ikke bare BTCPay sitt eget dashbord, slik at du får varsel før disken går full, ikke etter at noden har krasjet.
Til sist, planlegg for redundans på infrastruktursiden lenge før du faktisk trenger den. En enkelt VPS uten failover er et akseptabelt startpunkt, men hvis betalingsvolumet vokser, bør database og node-data ligge på separat, snapshot-kapabel lagring, slik at en VPS-feil ikke betyr timer med nedetid for butikken.
Et annet tips som ofte overses: begrens hvor mye kapital du binder opp i en enkelt Lightning-kanal. Jo flere, mindre kanaler du har mot ulike moteparter, jo mindre er den samlede risikoen hvis en enkelt kanal eller motpart skulle oppføre seg uventet. Dette gjelder spesielt i oppstartsfasen, der du uansett ikke kjenner driftsmønsteret til egen butikk godt nok til å vite hvor mye likviditet som faktisk trengs løpende.
Overvåking og varsling: hvordan vite at betalingene faktisk kommer inn
Et selvhostet system gir deg full kontroll, men det betyr også at ingen andre varsler deg hvis en container stopper, disken fylles opp, eller Lightning-noden faller av nettverket midt i en handledag. Sett derfor opp overvåking fra dag én, ikke etter at den første kunden ringer og sier at betalingssiden ikke laster.
Minimum bør du overvåke tre ting kontinuerlig: at alle generated_-containerne faktisk kjører, at disken har nok ledig plass til minst en ukes normal vekst, og at Bitcoin- og Lightning-noden fortsatt er synkronisert med nettverket. Et enkelt skript som kjører docker ps og sjekker df -h på en tidsplan, sendt til en Slack-kanal eller en e-postadresse du faktisk leser, fanger opp de fleste driftsstansene lenge før en kunde merker noe. For litt mer avanserte oppsett kan du eksportere metrikker fra BTCPay og Lightning-noden til Prometheus og visualisere dem i Grafana, slik at du ser trender i kanalbalanse og synkroniseringsstatus over tid, ikke bare et øyeblikksbilde.
Sett også opp varsling direkte fra BTCPay sin egen notifikasjonsfunksjon for kritiske hendelser, som mislykkede utbetalinger eller noder som går offline. Kombinert med den eksterne overvåkingen gir dette deg to uavhengige varslingsveier, slik at ett enkelt feilpunkt i overvåkingskjeden ikke lar et reelt problem gå ubemerket forbi.
Komplett prosjekt: fra miljøvariabler til kjørende produksjonsoppsett
Under følger en samlet oversikt over hele oppsettet fra start til slutt, slik at du har hele byggesekvensen på ett sted etter å ha gått gjennom de 14 stegene over.
# 1. Klargjør serveren
sudo apt update && sudo apt install -y docker.io docker-compose-plugin git
sudo su -
# 2. Klon repoet
git clone https://github.com/btcpayserver/btcpayserver-docker
cd btcpayserver-docker
# 3. Sett miljøvariabler for produksjon
export BTCPAYGEN_CRYPTO1="btc"
export BTCPAYGEN_REVERSEPROXY="nginx"
export BTCPAYGEN_LIGHTNING="clightning"
export NBITCOIN_NETWORK="mainnet"
export BTCPAY_HOST="betaling.dinbutikk.no"
export LETSENCRYPT_EMAIL="[email protected]"
# 4. Installer og start
. ./btcpay-setup.sh -i
# 5. Lås ned Lightning-API mot internett
./btcpay-routes.sh
# 6. Verifiser status på alle containere
docker ps --filter "name=generated_"
# 7. Følg logger under første synkronisering
docker logs -f generated_bitcoind_1Dette er kjernen i et fullverdig produksjonsoppsett. Det som gjør det produksjonsklart i praksis, er alt rundt selve kommandoene: backup-rutinen fra steg 12, API-innlåsingen fra steg 11, og overvåkingen fra tipsene over. Programvaren er gratis og gebyrfri, men ansvaret for drift ligger hos deg selv.
Verdt å merke seg er at btcpay-setup.sh ikke skriver en håndredigert docker-compose.yml. Scriptet genererer filen på nytt hver gang basert på miljøvariablene dine, lagret i en separat .env-fil i samme mappe. Det betyr at du i praksis aldri bør redigere den genererte compose-filen direkte, siden endringene forsvinner ved neste oppgradering. Skal du gjøre varige tilpasninger, som å legge til en ekstra container for overvåking eller en egen backup-tjeneste, gjør du det enten gjennom en egen docker-compose.override.yml eller gjennom offisielt støttede generator-fragmenter. Dette er også grunnen til at en manuelt redigert fil, som nevnt i feilsøkingspunktet om versjonskonflikt, kan låse en gammel image-tag fast selv etter at du har oppdatert resten av systemet.
En siste praktisk detalj: ta vare på .env-filen i samme backup-rutine som database og lommeboktdata. Den inneholder alle miljøvariablene du har satt gjennom hele denne guiden, og uten den må du rekonstruere hele konfigurasjonen fra hukommelsen dersom serveren må bygges opp på nytt fra bunnen.
BTCPay Server mot hostede alternativer: hva du egentlig velger mellom
Det finnes fortsatt hostede alternativer til selvhosting, men landskapet har krympet det siste året. Tabellen under oppsummerer forskjellen i modell, ikke bare pris, siden modellen avgjør hvem som faktisk kontrollerer pengene dine mens en betaling behandles. En uavhengig sammenligning av kryptobetalingsløsninger for nettbutikker anslår typisk VPS-kostnad for en selvhostet BTCPay-installasjon til mellom 10 og 30 dollar i måneden, uten noe eget programvaregebyr på toppen.
| Tjeneste | Depotmodell | Status/tilgjengelighet 2026 | Kjent kostnadsbilde |
|---|---|---|---|
| BTCPay Server | Selvhostet, ikke-depot | Aktivt utviklet, versjon 2.4.5 (okt. 2026) | 0% programvaregebyr, kun VPS og nettverksgebyr. Uavhengig estimat antyder rundt 10-30 dollar i månedlig VPS-kostnad, men dette er ikke en offisiell BTCPay-tariff |
| OpenNode | Hostet prosessor | Aktiv | Gjeldende gebyrsats for norske/nordiske foretak ikke offentlig dokumentert i tilgjengelige kilder per okt. 2026 |
| Coinbase Commerce | Hostet, tilknyttet børs | Stengt for merchantkontoer utenfor USA og Singapore fra 31. mars 2026 | Ikke relevant for norske foretak etter stengingen |
| Strike | Hostet, Lightning-orientert | Aktiv | Gjeldende norsk/nordisk merchant-gebyrsats ikke offentlig dokumentert i tilgjengelige kilder per okt. 2026 |
Det viktigste skillet er ikke prisen, men hvem som har nøklene. Med BTCPay Server er det alltid din egen Lightning-node og din egen on-chain-lommebok som mottar pengene direkte. Med en hostet tjeneste ligger midlene et kort øyeblikk, eller lenger, i tjenesteleverandørens kontroll før de kan sendes videre til deg. For en nordisk bedrift som har sett Coinbase Commerce forsvinne fra markedet over natten, er det argumentet som teller mest i praksis: avhengighet av en enkelt tredjepart kan forsvinne med kort varsel, mens kode du selv kjører, fortsetter å kjøre.
Ofte stilte spørsmål om BTCPay Server
Må jeg kjøre en full Bitcoin-node for å bruke BTCPay Server?
Nei. En pruned node fungerer godt for de fleste butikker, og krever betydelig mindre diskplass. Ulempen er at noden ikke kan servere historiske blokker til andre, noe som ikke påvirker din egen betalingsmottak.
Hvilken Lightning-implementasjon bør jeg velge, CLN eller LND?
Core Lightning er BTCPay-prosjektets egen anbefaling for de fleste selvhostede oppsett, delvis på grunn av god pruned-node-støtte. LND har et bredere tredjepartsøkosystem og er et naturlig valg hvis du uansett planlegger andre Lightning-integrasjoner.
Tar BTCPay Server noe gebyr av betalingene mine?
Nei. Programvaren tar ingen prosentandel. Du betaler kun for egen VPS-drift, nettverksgebyr på kjeden og eventuelle Lightning-kanalgebyrer.
Er det trygt å eksponere Lightning-API-et mot internett for fjernadministrasjon?
Nei. Siden BTCPay 2.4.2, og videre i 2.4.5, er LND- og CLN-API-ene lukket mot offentlig tilgang som standard. Bruk btcpay-routes for å styre eksplisitt hvilke ruter som skal være tilgjengelige, og foretrekk VPN eller internt Docker-nettverk fremfor åpne porter.
Hvor lang tid tar det å synkronisere Bitcoin-noden første gang?
Det varierer fra noen timer til et par døgn, avhengig av om du kjører full eller pruned node og hvor rask internettlinjen til VPS-en er. Du kan opprette butikk og teste grensesnittet mens synkroniseringen pågår, men unngå å ta imot reelle betalinger før noden er helt oppdatert.
Hva skjer med kanalene mine hvis VPS-en krasjer uten backup, og kan BTCPay kobles til WooCommerce eller Shopify?
Uten gyldig backup av kanaltilstanden risikerer du å tape midlene som lå i åpne Lightning-kanaler, noe som er grunnen til at steg 12 i denne guiden er like viktig som selve installasjonen. På integrasjonssiden finnes det ferdige plugin-løsninger for flere populære nettbutikk-plattformer som bruker BTCPay sitt Greenfield API til å opprette fakturaer og motta webhook-varsler om betalingsstatus, uten at du må skrive egen integrasjonskode.
Er BTCPay Server et godt alternativ nå når Coinbase Commerce er stengt for europeiske merchants?
Ja, det er en av de mest aktuelle grunnene til at flere nordiske foretak nå ser på selvhosting. Siden BTCPay ikke er avhengig av en enkelt tredjepartsleverandør, er det ikke utsatt for samme type brå nedleggelse som traff Coinbase Commerce-brukere 31. mars 2026.
Må jeg velge mellom on-chain og Lightning, eller kan butikken ta begge?
Du kan aktivere begge betalingsmetodene samtidig i butikkinnstillingene. Kunden ser da både en on-chain-adresse og en Lightning-faktura på samme betalingsside, og velger selv hvilken metode som passer best for beløpet og tidspunktet.
