Så självhostar du Grocy 2026: lagerdata, tidszon och säkerhetskopior
Självhosta Grocy med rätt portar, persistent lagring, HTTPS, secrets, säkerhetskopior och kontroller inför uppgraderingar. Lär dig åtgärda när SQLite-databasen inte kan skriva.
Behandla Grocy som ett litet system, inte som en Docker-avbild. Det användarorienterade målet med Grocy är tydligt: hålla koll på hushållets lager, matvaror, sysslor och utrustning. Driftsättningen är bara godkänd när du kan byta standardinloggningen, lägga till en produkt, registrera ett inköp och en förbrukning, skanna en streckkod samt utlösa en påminnelse om en syssla eller ett utgångsdatum.
Den skillnaden fångar det fel som driftansvariga stöter på efter lokal testning: SQLite-databasen kan inte skriva eller schemalagda sysslor använder fel tidszon. Den gör också planen för säkerhetskopiering och uppgraderingar tillräckligt specifik för att kunna testas.
Portar, processer och privata tjänster
Ett användbart Grocy-diagram visar den publika routen, den privata porten 80, state-gränsen och alla stödkrav. Markera vilka pilar som transporterar credentials och vilka som är vanlig användartrafik. Kravet på den lokala runtime-miljön är en persistent konfigurationsvolym och valfri åtkomst till streckkodsenheter. Dimensionera och övervaka den resursen tillsammans med containern i stället för att exponera en orelaterad nätverkstjänst.
Verifiera diagrammet med en verklig åtgärd: byt standardinloggningen, lägg till en produkt, registrera ett inköp och en förbrukning, skanna en streckkod och utlös en påminnelse om en syssla eller ett utgångsdatum. Den sannolika belastningen kommer från SQLite-skrivningar, uppladdade bilder, schemalagda jobb och trafik från hushållsenheter. Övervaka den vägen i stället för att behandla alla HTTP-anrop som likvärdiga.
Övervaka arbetsbelastningen, inte bara containern
Observera det arbete Grocy utför: SQLite-skrivningar, uppladdade bilder, schemalagda jobb och trafik från hushållsenheter. Sätt limits med marginal för det arbetet och undvik en liveness probe som konkurrerar med det. Driftkontrollen ska fortfarande försöka byta standardinloggningen, lägga till en produkt, registrera ett inköp och en förbrukning, skanna en streckkod och utlösa en påminnelse om en syssla eller ett utgångsdatum enligt ett schema.
Vid uppdateringar bör du komma ihåg att databas-migreringar i Grocy och custom extensions ska övas på en kopierad config-katalog. Driftsätt kandidaten mot en återställd kopia och upprepa det kända testet. Om SQLite-databasen inte kan skriva eller schemalagda sysslor använder fel tidszon, använder du runtime-loggarna och det faktiska nätverksanropet för att hitta vilket antagande som har ändrats.
Det här måste fungera innan riktiga Grocy-data används
En produktionsgrind för Grocy ska kunna köras av någon som inte byggde driftsättningen. Ge personen den pinnade versionen, ett icke-känsligt testkonto och följande uppgift: byt standardinloggningen, lägg till en produkt, registrera ett inköp och en förbrukning, skanna en streckkod och utlös en påminnelse om en syssla eller ett utgångsdatum. Om instruktionerna kräver odokumenterad shell-åtkomst är tjänsten ännu inte driftklar.
Upprepa grinden efter att bara ha bytt ut containern. Återställ sedan databas, uppladdade filer, recept och konfiguration till en tom infrastruktur och bevisa att lager, recept, sysslor, utrustning och historik kommer tillbaka samt att nästa schemalagda påminnelse har rätt datum. Mät SQLite-skrivningar, uppladdade bilder, schemalagda jobb och trafik från hushållsenheter under båda lyckade körningarna. Oväntade skillnader avslöjar ofta en cache, ett index, en worker eller en data mount som saknas.
Lägg till en failure drill: skicka ofarlig indata nära den resurs- eller formatgräns som hör ihop med den här gränsen: SQLite-databasen kan inte skriva eller schemalagda sysslor använder fel tidszon. Grocy ska visa ett användbart fel, bevara befintligt state och återhämta sig när det giltiga tillståndet återkommer. Spara tidsstämplarna och relevanta loggrader, med secrets redigerade. Den evidensen blir referens för nästa image- eller konfigurationsändring.
Bygg en utbytbar Grocy-container
Använd ett kommando som exponerar alla viktiga val. Den här baslinjen binder Grocy till hostens loopback, lägger till de kända data mounts och tillhandahåller den första obligatoriska inställningen. Bekräfta det lokala kravet innan exponering: en persistent konfigurationsvolym och valfri åtkomst till streckkodsenheter.
docker run -d \
--name grocy \
--restart unless-stopped \
-p 127.0.0.1:80:80 \
-v grocy-data:/config \
lscr.io/linuxserver/grocy:latest
Byt ut flytande tags mot en testad version eller digest. Efter uppstarten kör du docker logs --tail 200 grocy och bekräftar att processen lyssnar på port 80. Kör sedan Grocys acceptanstest. Ett svar från root-sidan kan inte bevisa att hela scenariot fungerar: byt standardinloggningen, lägg till en produkt, registrera ett inköp och en förbrukning, skanna en streckkod och utlös en påminnelse om en syssla eller ett utgångsdatum.
Utforma återställningen av Grocy före lansering
Skydda Grocys state innan du optimerar containern. Den obligatoriska uppsättningen är databas, uppladdade filer, recept och konfiguration. Montera /config före bootstrap, skriv ofarliga exempeldata och byt ut containern för att bevisa att sökvägen faktiskt är persistent. Om flera lagringsplatser måste vara synkroniserade dokumenterar du i vilken ordning skrivningar pausas och säkerhetskopior tas.
Förvara kopior utanför driftsättningsservern och kryptera material som innehåller credentials eller privat innehåll. Återställningen är lyckad när lager, recept, sysslor, utrustning och historik kommer tillbaka och nästa schemalagda påminnelse har rätt datum. Skillnaden mellan en persistent mount och en fristående kopia beskrivs i persistent lagring och snapshots.
Testa Grocy utanför servern
Välj det slutliga Grocy-värdnamnet innan användare sparar callbacks eller klientinställningar. Publicera sedan gränssnittet över HTTPS och konfigurera rätt tidszon. Plattformens route ska terminera TLS en gång och rikta trafiken till den privata porten 80.
Kör acceptanstestet externt. Om klienten aldrig når Grocy använder du checklistan för SSL-validering för DNS- och certifikatkontroller. Om anropet når Grocy men SQLite-databasen inte kan skriva eller schemalagda sysslor använder fel tidszon ska du sluta ändra proxy-redirects och i stället granska den applikationsspecifika gränsen.
Välj Grocys trust boundary
Gör en threat model för den åtgärd Grocy utför, inte bara för inloggningsformuläret. Det största risktagandet här är att behålla standardinloggningen efter konfigurationen. Implementera den här gränsen: ta bort standardcredentials, välj rätt tidszon och begränsa hushållsdata till avsedda användare.
Grocy har ingen obligatorisk bootstrap-secret i den här baslinjen. Skydda i stället det faktiska administratörskontot eller upstream-autentiseringen. Lös inte ett behörighetsfel genom att köra containern som root eller montera hosten brett. Resursbegränsningar hör också till säkerhetsdesignen när SQLite-skrivningar, uppladdade bilder, schemalagda jobb och trafik från hushållsenheter kan utlösas av användare.
En Dockup-driftsättning behöver fortfarande ett acceptanstest för Grocy
Dockup kan hantera de utbytbara plattformsdelarna: routa trafik till port 80, utfärda domän och certifikat, injicera secrets, ansluta persistent lagring och koppla Grocy till hanterade eller privat anslutna tjänster. Det kan göras på Dockup-infrastruktur eller på en server som du ansluter.
Acceptansarbetet för Grocy måste fortfarande vara explicit. Efter one-click-driftsättningen publicerar du gränssnittet över HTTPS och konfigurerar rätt tidszon, bekräftar det lokala kravet — en persistent konfigurationsvolym och valfri åtkomst till streckkodsenheter — och kör följande scenario: byt standardinloggningen, lägg till en produkt, registrera ett inköp och en förbrukning, skanna en streckkod och utlös en påminnelse om en syssla eller ett utgångsdatum. Den uppdelningen är avsiktlig: Dockup tar bort repetitiv infrastrukturkonfiguration utan att låtsas att applikationsroller, provider-credentials eller återställningspolicy väljer sig själva.
Vanliga frågor
Vad behöver Grocy för en produktionsdriftsättning?
Routa Grocy-containern på port 80 genom en enda HTTPS-origin. Kravet på den lokala runtime-miljön är en persistent konfigurationsvolym och valfri åtkomst till streckkodsenheter. Kalla inte Grocy redo förrän du kan byta standardinloggningen, lägga till en produkt, registrera ett inköp och en förbrukning, skanna en streckkod och utlösa en påminnelse om en syssla eller ett utgångsdatum.
Vilka Grocy-data ska ingå i en säkerhetskopia?
Gör /config persistent och inkludera databas, uppladdade filer, recept och konfiguration i samma recovery manifest. En ren Grocy-återställning är godkänd först när lager, recept, sysslor, utrustning och historik kommer tillbaka och nästa schemalagda påminnelse har rätt datum.
Kräver Grocy HTTPS bakom en reverse proxy?
Använd HTTPS för den publika Grocy-originen och behåll port 80 på den interna routen. Tillämpa Grocy-inställningen korrekt: publicera gränssnittet över HTTPS och konfigurera rätt tidszon. För Grocy skyddar HTTPS credentials eller användarinnehåll under överföring och gör klientbeteende som är känsligt för origin konsekvent.
Hur bör en Grocy-uppgradering testas?
Återställ aktuell Grocy-state till en isolerad driftsättning, tillämpa kandidatversionen och upprepa acceptanstestet. Var särskilt uppmärksam eftersom databas-migreringar i Grocy och custom extensions ska övas på en kopierad config-katalog. Behåll den tidigare Grocy-imagen tills gränsen för datamigrering och rollback är förstådd.
