Homelab & egen server

Länge ville jag driva en egen server, men jag hade respekt för kostnaderna och komplexiteten. Sedan stötte jag på Proxmox VE — och i efterhand undrar jag varför jag inte gjorde det tidigare. Proxmox är en gratis virtualiseringsplattform med öppen källkod baserad på Debian: KVM för fullfjädrade virtuella maskiner, LXC för lätta containrar och ett webbgränssnitt som verkligen underlättar vardagen.

Det fina är att man inte behöver någon dyr server. Jag började med en begagnad mini-pc (en Dell OptiPlex Micro) med uppgraderat RAM och en NVMe-SSD — tyst, strömsnål och fullt tillräcklig för 10–15 containrar plus några VM:ar. Med elpriserna här gör en mini-pc som drar 10–15 watt i viloläge en enorm skillnad jämfört med en rackserver.

Efter installationen var det första jag gjorde att inaktivera Enterprise-förrådet och konfigurera community-förråden, säkra SSH-inloggningen med nyckel och installera Fail2ban. Sedan kom de första tjänsterna: Pi-hole som nätverksomfattande annonsblockerare, Nginx Proxy Manager och Portainer. Den ordningen har visat sig fungera bra — börja smått, inte med tjugo containrar på en gång.

Mitt viktigaste råd, som jag själv fick lära mig den hårda vägen: sätt upp säkerhetskopior innan du installerar den första tjänsten. Enligt 3-2-1-regeln — och Proxmox inbyggda snapshot-säkerhetskopior gör det nästan för enkelt. RAID är förresten ingen säkerhetskopia — det fick jag också lära mig.

Börja bara. En container, en tjänst, och du lär dig mer om infrastruktur än på vilken onlinekurs som helst. Och den som först bara vill testa kan också använda en billig molnserver för att lära sig.

Källa: Homelab Guide

Enligt IT之家 säljs QNAP:s NAS med fyra fack, Qu405-N150-8G, nu på JD.com. Den har 8 GB minne och en standardgaranti på två år. Enheten kostar 2599 yuan ensam, och paketet med en Seagate IronWolf-hårddisk på 4 TB kostar 3599 yuan.

Designen är enkel. Chassit mäter 165 mm x 168 mm x 217 mm och väger 2,15 kg. Processorn är en Intel N150 med 4 kärnor och 4 trådar. Enligt tillverkaren klarar den transkodning av 4K-video och kan köra virtuella maskiner och Docker-containrar, vilket är en stor fördel för den som gillar att pyssla med hemservrar. Minnet på 8 GB SODIMM DDR4 som levereras går att uppgradera till 16 GB.

Lagringen består av fyra fack för SATA-diskar i 3,5 eller 2,5 tum. Inuti finns dessutom två M.2 2280 NVMe-platser med PCIe Gen 3 x1, som kan användas för cache eller för system- och containerdata. Anslutningarna omfattar två 2.5GbE-nätverksportar, två USB-A 3.2 Gen 2, en USB-C 3.2 Gen 2 och en HDMI 2.1.

Jag tycker att kombinationen av dubbla 2,5G och N150 de senaste två åren har blivit en vanlig konfiguration för enklare hemma-NAS. Den kör Docker utan att dra mycket ström, och priset är rimligt. Artikeln redovisar dock bara specifikationer utan verkliga tester, så om du funderar på att köpa den bör du kontrollera ljudnivå, strömförbrukning och programvarans användarupplevelse i oberoende recensioner först.

Källa: IT之家

Synology har tillkännagett den nya serien neo+ för Tyskland, bestående av DS725neo+, DS925neo+, DS1525neo+ och DS1825neo+. ComputerBase beskriver dem som billigare varianter av Plus-modellerna, där bara minneskonfigurationen har ändrats.

Enligt rapporten står "neo" för "Non-ECC-option". Enheterna använder vanligt minne utan ECC-funktion, och alltid bara 4 GB. DS725+ och DS925+ har 4 GB ECC-minne, medan DS1525+ och DS1825+ har 8 GB ECC-minne, så neo+-varianterna har mindre. I övrigt motsvarar utrustning, funktioner och utbyggbarhet Plus-modellerna, och även DSM med sina appar är identiskt.

Vid det rekommenderade utpriset är skillnaden cirka 200 euro: DS725neo+ ligger på 549 euro netto och DS725+ på 748 euro netto. I handeln är avståndet dock inte lika stort: DS725+ finns för närvarande från 663 euro och DS725neo+ från 629 euro. Minnet går senare enkelt att uppgradera till ECC-minne.

Som skäl anger Synology den nuvarande situationen på minnesmarknaden, alltså de kraftiga prisökningarna som även har drabbat Plus-modellerna.

För hemservrar tycker jag att detta är en intressant avvägning. Den som främst använder sin NAS till säkerhetskopior, media och några containrar klarar sig troligen med 4 GB utan ECC. Den som värderar dataintegritet bör noga kontrollera vad man får för merpriset.

Källa: ComputerBase

Hardware.com.br uppmärksammar ett hemlab som sticker ut på grund av sin lilla storlek. En Reddit-användare publicerade på r/HomeServer ett litet 10-tumsrack med brandvägg, tre minidatorer, en NAS och all nätverksinfrastruktur som krävs för att köra dussintals tjänster hemma.

Bearbetningen sköts av tre minidatorer, var och en med en processor med 8 kärnor och 16 trådar samt 32 GB RAM, sammanlagt 24 kärnor, 48 trådar och 96 GB för virtualisering. Proxmox används för att skapa virtuella maskiner och LXC-containrar. Bland arbetsbelastningarna finns en VM för Jellyfin, den så kallade arr-stacken som körs i Docker, ytterligare en Docker-värd med Portainer, Pi-hole och instrumentpaneler som Homer och Homepage, samt spelservrar som Terraria och Core Keeper.

Lagringen sitter i en HP ProLiant MicroServer med fyra 4 TB:s hårddiskar i ZFS RAIDZ1, vilket gör att man fortfarande kan komma åt data även om en disk går sönder. Det blir 16 TB brutto, med mindre användbart utrymme på grund av paritet. Nätverket styrs av en Fortinet FortiGate som sköter routing, VLAN och SSL-VPN, och en APC Back-UPS 850 skyddar mot strömavbrott.

Den mest intressanta delen är enligt mig utanför bostaden: ägaren har två VPS:er med Debian i externa datacenter, anslutna till hemlabbet via ett WireGuard-nät i hub-and-spoke-konfiguration. De fungerar som infrastrukturens publika lager, med Traefik som reverse proxy.

Det är ett bra exempel på att ett hemlab inte behöver ett jättestort rack: med god planering, små enheter och bra ordning kan man köra mycket på lite utrymme.

Källa: Hardware.com.br

När en och samma server kör fler än ett projekt stöter man förr eller senare på portarna 80 och 443, som bara en process kan lyssna på. En artikel på Habr från Selectels blogg visar steg för steg hur man löser det med Nginx Proxy Manager.

Författaren förklarar först problemet: privilegierade portar, regeln en lyssnare per port, CORS-problem när frontend och backend delas upp på olika portar och avsaknaden av HTTPS. En omvänd proxy löser detta som mellanhand genom att dirigera trafiken efter domän och sökväg. En extra fördel är att brandväggen bara behöver portarna 22, 80 och 443 öppna.

Testmiljön är en VDS med 2 vCPU, 2 GB RAM och 40 GB NVMe, med Ubuntu 24.04 och Docker från det officiella förrådet. Nätverket skapas med docker network create proxy, och containern jc21/nginx-proxy-manager startas med volymer för data och certifikat. Jag gillade att adminpanelen på port 81 bara är bunden till 127.0.0.1 och nås via en SSH-tunnel.

Sedan konfigureras en proxyvärd: i fältet Forward Hostname anges containerns namn, och SSL-certifikatet kopplas på fliken SSL. För testerna används traefik/whoami. Även fallet där applikationen körs direkt på värdmaskinen tas upp: gatewayadressen för Docker-nätverket hämtas med docker network inspect, och brandväggen ställs in så att applikationen inte går att nå förbi proxyn.

Det finns också invändningar. Exemplen blandar olika domäner och avbildningen använder taggen latest, vilket över tid kan försämra reproducerbarheten. Ändå är det en bra startpunkt för den som vill köra flera tjänster hemma eller på en VDS utan att redigera nginx-konfigurationer för hand.

Källa: Habr (Selectels blogg)

Veckans Self-Host Weekly från selfh.st samlar nyheter som folk med homelab vill känna till. Jag gillar den här typen av sammanfattningar eftersom de sparar mycket tid i flödesläsningen.

Huvudhistorien är en rörig affär: en ny svit med öppen källkod som alternativ till Adobe anklagades för att kopiera befintliga projekt, framför allt den populära Photopea, vars utvecklare var bland de första att slå larm. De två projekten i centrum, PhotoSuite och PhotoCraft, verkar vara kopplade till varandra, och tidslinjen är svår att följa. Veckobrevet råder till att hålla sig borta tills de visar att de är mer än härledda verk.

Fler små nyheter är värda att notera. Let's Encrypt meddelade att livslängden för gratis SSL-certifikat kortas från 90 till 64 dagar i februari 2027, vilket gör en pålitlig automatisk förnyelse ännu viktigare för den som kör en reverse proxy hemma. Nabu Casa byter namn på Home Assistant Cloud till Home Assistant Link, på grund av den negativa klangen i ordet cloud. Det krypterade hemlighetsdelningsprojektet Hemmelig har arkiverats på GitHub, och NVIDIA Shield TV, en sju år gammal streamingbox som är populär bland homelab-folk, blev 100 dollar dyrare, något som förklaras med AI-driven inflation i hårdvara.

Författaren har också startat Self-Host User Survey 2026 med 45 möjliga frågor om hårdvara, programvara, operativsystem, demografi och AI. Förra årets enkät fick drygt 4 000 svar, och årets hade redan 2 000 på två dagar. Den är öppen till 31 oktober, och resultaten väntas i början av november.

Personligen tycker jag att certifikatändringen är mest praktisk. Om din förnyelsekonfiguration är lite ömtålig är det en bra tid att testa den.

Källa: selfh.st

RedesZone svarar på en fråga som många som bygger en hemserver ställer: behöver en NAS startas om med jämna mellanrum, eller kan den vara påslagen hela tiden?

Det korta svaret är ja, den kan vara igång dygnet runt. En NAS är gjord för att gå kontinuerligt, den använder lagringsenheter avsedda för just det och den används för säkerhetskopior, för att frigöra utrymme på andra enheter eller för att dela stora filer. Den förbrukar naturligtvis ström, precis som en router eller en säkerhetskamera. Men dessa enheter är konstruerade för att använda mycket lite energi i vila. Även efter månader av kontinuerlig användning finns det ingen tvingande anledning att starta om den, förutom att spara energi eller helt enkelt att man inte behöver den.

Det finns situationer där en omstart är värd besväret: efter en uppdatering av operativsystemet, den fasta programvaran eller vissa paket, även om enheten inte begär det; vid programvaruproblem, som när en app slutar fungera, en tjänst är långsam, ett webbgränssnitt beter sig konstigt eller det uppstår fel i någon del; efter ett hårdvarubyte och efter varje större förändring i hur den fungerar. Ibland har en process fastnat eller ett program inte avslutats ordentligt, och en omstart återställer allt till det normala.

Jag tycker att det här är ett förnuftigt råd utan dramatik. För ett hemlab är den praktiska regeln att låta NAS:en arbeta och starta om den medvetet, efter en uppdatering eller när något beter sig konstigt, i stället för av vana.

Källa: RedesZone

När man kör öppen källkods-appar på en hemserver behöver man ofta skicka mejl, till exempel för registreringar eller återställning av lösenord. Att skicka mejl direkt från hemmet kräver dock en SMTP-server och en konfigurerad avsändardomän, och det är mer jobb än man kan tro. Den här artikeln, som jag hittade på Qiita, löser problemet på ett enkelt sätt med Mailpit och Discord.

Mailpit var från början ett verktyg för att testa utskick av mejl. Det kan användas som SMTP-server och har dessutom ett test-API. Med en webhook konfigurerad kan det anropa en extern applikation så fort ett meddelande kommer in. Artikeln utnyttjar den funktionen för att bygga en lösning som skickar innehållet i inkommande mejl till Discord.

Upplägget består av två containrar som startas med Docker Compose: Mailpit och en webhook-handler. Webhook-handlern är en liten Python-applikation byggd med FastAPI. Den tar emot webhooks från Mailpit, formaterar avsändare och mottagare och skickar vidare dem till en Discord-webhook. Aviseringen kan också innehålla en länk till Mailpits webbgränssnitt, så att man kan titta på mejlet vid behov. Inställningar som webhook-URL:en ligger i en separat .env-fil.

Även utan att skicka några mejl till omvärlden är det praktiskt att direkt få veta att ett mejl för lösenordsåterställning har kommit. För den som kör flera appar i ett homelab bör det att samla all post på ett ställe göra förvaltningen betydligt enklare. Inlägget är från augusti 2026.

Källa: Qiita

En liten historia, men värd en tanke för alla som sköter sitt eget hemnätverk. Enligt GenK kontrollerade en X-användare vid namn @NomadsGalaxy Wi-Fi:t hos sina föräldrar och upptäckte att en Keurig-kaffemaskin på bara tio dagar hade genererat cirka 1 TB uppladdning och nästan 10 GB nedladdning.

Han upptäckte det när han tittade på UniFi-nätverkssystemet hemma hos sina föräldrar. Den ovanliga datamängden överbelastade en av Wi-Fi-accesspunkterna. I stället för att undersöka orsaken kopplade han ur maskinen och köpte en annan produkt åt sina föräldrar. Enligt artikeln verkade större delen av trafiken stanna inom det interna nätverket i stället för att gå ut på internet, så det finns ännu inga bevis för att maskinen skickade familjens data till externa servrar. Den troligaste orsaken är ett programfel eller ett kommunikationsfel i nätverket, och en omstart kan ha löst problemet.

Artikeln tar också upp den större bilden av det smarta hemmet: ju fler uppkopplade enheter man har, desto större är risken för fel, säkerhetshål eller driftavbrott. IoT-enheter kan bli en ingångspunkt för attacker om tillverkaren inte uppdaterar programvaran regelbundet, och vissa produkter förlorar större delen av sina funktioner när företaget stänger sina servrar.

För mig är den praktiska lärdomen att ha ett verktyg som visar trafiken per enhet i hemnätet, och att överväga att lägga IoT-enheter i ett separat nätverk. Utan siffror är det mycket svårt att märka vad en kaffemaskin egentligen gör.

Källa: GenK

Den som driver ett hemnätverk eller ett litet homelab känner väl till suffixet .lan: det dyker upp i routrarnas gränssnitt, på interna DNS-servrar och i de adresser vi använder för att nå enheter utan en registrerad domän. IlSoftware.it rapporterar att en ansökan till ICANN skulle kunna göra den till en internetdomän som går att nå över hela världen.

Ansökan om toppdomänen .lan har lämnats in av det amerikanska företaget Coffee Danger och ligger fortfarande i fasen Pre-Evaluation Processing. Det betyder att domänen inte är godkänd och ännu inte kan användas för att registrera publika adresser. Ansökan ingår i den nya omgången för tilldelning av toppdomäner som ICANN startade 2026, och som omfattar hundratals företag: bland de sökande finns Google med .browser, OpenAI med .openai och .chatgpt, Meta med .facebook och det italienska företaget Aruba med domäner som .pec, .vps, .lab, .roma och .ciao. Alla ansökningar är fortfarande föremål för bedömning.

Det känsliga är att .lan inte är ett namn som vilket annat som helst. Många tekniker har använt det länge, till exempel nas.lan, router.lan eller camera.lan. Om ett namn som ansetts vara internt hamnar i den publika DNS-tjänsten finns risk för fel, DNS-frågor som lämnar nätverket och kommunikation som kan nå andra mål än de avsedda.

Som entusiast för hemnätverk tycker jag att nyheten är en bra påminnelse: för interna namn är det bättre att använda suffix som är avsedda för just det, i stället för att förlita sig på etablerade konventioner. Det finns ingen beslut ännu, men det är värt att följa utvecklingen.

Källa: IlSoftware.it

Korben tar upp ett Cloudflare-kommando som många utvecklare redan använder: cloudflared tunnel --url. Det publicerar en server som körs på din dator under en trycloudflare.com-adress, utan konto, utan domännamn och framför allt utan att någon port behöver öppnas i routern. För den som kör tjänster hemma är det ett enkelt sätt att visa ett projekt för någon under ett kort test.

Den senaste nyheten är alternativet --allowed-mail. Tidigare kunde alla med länken ansluta till tjänsten. Nu kan åtkomsten begränsas till några e-postadresser som du anger, med en engångskod som skickas via Cloudflare Access.

Guiden börjar med en liten lokal webbserver på port 8080 som levererar en testsida via Python. cloudflared är den öppna källkodskopplingen som upprättar den utgående anslutningen till Cloudflares nätverk. På Mac installeras den via Homebrew. På Debian eller Ubuntu behöver du Cloudflares officiella paketförråd, vars signeringsnyckel nyligen bytts, så författaren råder dig att använda de aktuella kommandona och inte de i äldre guider.

En punkt fångade mitt intresse: om du låter AI-agenter arbeta med verktyget rekommenderar Cloudflare en PreToolUse-hook som blockerar alla kommandon utan --allowed-mail, så att en agent inte av misstag exponerar en publik tunnel.

För ett homelab är detta ett lättviktigt alternativ till att öppna portar eller köra VPN, så länge du kommer ihåg att en publik tunnel ändå är en exponering mot internet, även om den bara är tillfällig.

Källa: Korben