Offshore webhosting opzetten: stap voor stap een website offshore hosten

Kort gezegd: offshore webhosting betekent je website draaien op een server buiten het land waar je woont, meestal bij een provider die weinig persoonsgegevens vraagt. Om het op te zetten huur je een VPS in het buitenland, registreer je het domein met WHOIS-privacy en betaal je in crypto, laat je DNS naar de server wijzen, serveer je de site met Caddy voor automatische HTTPS, en hard je daarna de server, maak je back-ups en houd je de identiteit van de site gescheiden van die van jezelf.

Offshore hosting verandert wie je server en accountgegevens beheert. Het maakt illegale inhoud niet legaal, verbergt je niet voor je registrar of je betaalspoor en lost operationele fouten niet op. Het laatste deel behandelt die grenzen in detail. Voor een breder overzicht, zie offshore hosting.

Stap 1: kies een offshore VPS

Een VPS geeft je volledige root, dus jij beheert de webserver, de logs en de TLS-sleutels in plaats van afhankelijk te zijn van een gedeeld hostingpaneel. Voor een statische site of een klein CMS volstaan 1–2 vCPU en 1–2 GB RAM; databases en zwaardere apps hebben meer nodig.

Bij NoctisNode worden nieuwe servers uitgerold in FI-1 (Finland). Aanmelden vereist alleen een e-mailadres en wachtwoord, betalen kan alleen in crypto met XMR als standaard, en een server wordt ongeveer 35 seconden nadat de betaling is bijgeschreven uitgerold. Het Wisp-pakket (1 vCPU, 1 GB RAM, 20 GB NVMe, $6 per 28 dagen) kan een statische site aan; Pulse (2 vCPU, 2 GB, 40 GB, $10) past bij WordPress of iets vergelijkbaars. Let op: er is geen wachtwoordreset via e-mail, dus bewaar je inloggegevens veilig. Vergelijk opties in beste offshore VPS.

Stap 2: registreer het domein privé en betaal met crypto

• ▹Kies een registrar die cryptocurrency accepteert en gratis WHOIS-privacy of -afscherming biedt, zodat je contactgegevens niet worden gepubliceerd.
• ▹Onthoud dat de registrar nog steeds opslaat wat je hem geeft. Gebruik een apart e-mailadres voor het domein, niet je persoonlijke.
• ▹Registrars eisen doorgaans contactgegevens die volgens hun voorwaarden kloppen; onjuiste gegevens kunnen reden zijn voor opschorting, dus lees de voorwaarden voordat je beslist wat je opgeeft.
• ▹Sommige landcode-TLD's hebben verblijfsvereisten of staan geen privacy toe. Controleer het beleid van de TLD voordat je koopt, in plaats van het aan te nemen.
• ▹Schakel 2FA in voor je registraraccount en een transfer lock. Het domein kwijtraken is een groter risico dan de server kwijtraken.
• ▹Betaal de VPS met Monero voor de minste koppeling on-chain; zie [een VPS betalen met Monero](/guides/pay-for-vps-with-monero).

Stap 3: laat DNS naar de server wijzen

Gebruik de DNS van de registrar of een aparte DNS-provider. Hoe dan ook kan de DNS-host zien welke records bestaan en vaak ook de querievolumes. Zet tijdens het inrichten een lage TTL (300 seconden), zodat wijzigingen snel doorkomen.

Stap 4: serveer de site met Caddy en automatische HTTPS

Caddy haalt en vernieuwt TLS-certificaten automatisch zodra DNS naar de server wijst en poort 80 en 443 open zijn. Debian 12/13 en Ubuntu 24.04 leveren een `caddy`-pakket mee; de eigen apt-repository van Caddy heeft nieuwere versies als je die nodig hebt. Zet je bestanden in `/var/www/example`, vervang `example.com` door je domein en herlaad. Wil je naar een app proxyen in plaats van statische bestanden te serveren, zie dan Caddy als reverse proxy.

sudo apt update && sudo apt install -y caddy
sudo mkdir -p /var/www/example

# /etc/caddy/Caddyfile
example.com {
    root * /var/www/example
    file_server
    encode zstd gzip
    header {
        Strict-Transport-Security "max-age=31536000"
        X-Content-Type-Options "nosniff"
        Referrer-Policy "no-referrer"
        -Server
    }
    log {
        output discard
    }
}

www.example.com {
    redir https://example.com{uri} permanent
}

sudo systemctl reload caddy

Stap 5: hard de server en richt back-ups in

1. 01.Maak een sudo-gebruiker aan die geen root is, stap over op SSH-sleutels en schakel inloggen met wachtwoord uit; volg [SSH-hardening](/guides/ssh-hardening).
2. 02.Schakel een firewall in: `sudo ufw allow OpenSSH && sudo ufw allow 80/tcp && sudo ufw allow 443/tcp && sudo ufw enable`.
3. 03.Zet automatische beveiligingsupdates aan: `sudo apt install -y unattended-upgrades && sudo dpkg-reconfigure -plow unattended-upgrades`.
4. 04.Bewaar alleen de logs die je nodig hebt. De Caddyfile hierboven gooit access logs weg; maak een bewuste keuze in plaats van de standaard te volgen.
5. 05.Maak buiten de server versleutelde back-ups van sitebestanden en databases, bijvoorbeeld met restic naar een tweede locatie; zie [restic-back-ups](/guides/restic-backups).
6. 06.Test minstens één keer een restore. Ook het vooraf betaalde saldo bij je provider telt: raakt het op, dan wordt de server opgeschort, dus houd het aangevuld.

Houd de website en je identiteit gescheiden

• ▹Gebruik een apart e-mailadres voor het hostingaccount, de registrar en alle sitediensten; hergebruik nooit je persoonlijke adres of gebruikersnaam.
• ▹Vermijd ID's van externe analytics, advertenties of tags die je ook op persoonlijke sites gebruikt; gedeelde ID's koppelen sites aan elkaar.
• ▹Certificate Transparency-logs publiceren elke hostnaam waarvoor je een certificaat krijgt, dus maak geen subdomeinen aan die meer prijsgeven dan je wilt.
• ▹Verwijder metadata uit afbeeldingen en documenten (EXIF, auteursvelden) en controleer de git-geschiedenis op echte namen en e-mailadressen voordat je publiceert.
• ▹Beheer de server via Tor of een VPN in plaats van vanaf je thuis-IP, en host je persoonlijke projecten niet op hetzelfde IP.
• ▹Houd ook de betaling gescheiden: vul het account aan vanuit een wallet die niet gekoppeld is aan een exchange-account op jouw naam.

Waartegen offshore webhosting niet beschermt

• ▹Je lokale wetgeving: een site in het buitenland hosten verandert niets aan de regels die gelden waar jij woont.
• ▹Domein-takedowns: de registrar of de TLD-beheerder kan een domein opschorten, ongeacht waar de server staat.
• ▹Afhandeling van misbruik: hosts treden nog steeds op bij geverifieerde misbruikmeldingen, offshore of niet.
• ▹Betaal- en accountsporen: exchanges, kaartverwerkers en e-mailproviders houden hun eigen administratie bij.
• ▹Je eigen fouten: hergebruikte gebruikersnamen, gedeelde analytics-ID's, metadata en beheerlogins vanaf je thuis-IP maken de rest ongedaan.
• ▹Aanvallen op de site: een offshore locatie is geen DDoS-bescherming, en een niet-gepatcht CMS wordt overal gecompromitteerd.

Veelgestelde vragen