Slik selvhoster du Grocy i 2026: lagerdata, tidssone og sikkerhetskopier
Selvhost Grocy med riktige porter, persistent lagring, HTTPS, secrets, sikkerhetskopier og kontroller før oppgradering. Lær hvordan du løser problemer når SQLite-databasen ikke kan skrive.
Behandle Grocy som et lite system, ikke som et Docker-image. Målet for brukerne av Grocy er tydelig: oversikt over husholdningens lagerbeholdning, dagligvarer, oppgaver og utstyr. Distribusjonen er først godkjent når du kan erstatte standardpåloggingen, legge til et produkt, registrere et innkjøp og forbruk, skanne en strekkode og utløse et oppgave- eller utløpsvarsel.
Dette skillet avdekker feilen operatører møter etter lokal testing: SQLite-databasen kan ikke skrive, eller planlagte oppgaver bruker feil tidssone. Det gjør også planen for sikkerhetskopiering og oppgradering konkret nok til at den kan testes.
Porter, prosesser og private tjenester
Et nyttig Grocy-diagram viser den offentlige ruten, privat port 80, grensen for persistent data og alle støttende krav. Marker hvilke piler som overfører credentials, og hvilke som er vanlig brukertrafikk. Kravet til det lokale runtime-miljøet er ett persistent config-volum og valgfri tilgang til strekkodeleserenheter. Dimensjoner og overvåk denne ressursen sammen med containeren i stedet for å eksponere en irrelevant nettverkstjeneste.
Bevis diagrammet med én faktisk handling: erstatt standardpåloggingen, legg til et produkt, registrer et innkjøp og forbruk, skann en strekkode og utløs et oppgave- eller utløpsvarsel. Den sannsynlige belastningen kommer fra SQLite-skriving, opplastede bilder, planlagte jobber og trafikk fra husholdningsenheter. Overvåk denne banen i stedet for å behandle alle HTTP-forespørsler som like.
Overvåk arbeidsbelastningen, ikke bare containeren
Følg med på arbeidet Grocy utfører: SQLite-skriving, opplastede bilder, planlagte jobber og trafikk fra husholdningsenheter. Sett grenser med tilstrekkelig headroom for dette arbeidet, og unngå en liveness probe som konkurrerer med det. Operatørkontrollen bør fortsatt forsøke å erstatte standardpåloggingen, legge til et produkt, registrere et innkjøp og forbruk, skanne en strekkode og utløse et oppgave- eller utløpsvarsel etter en fast plan.
Ved oppdateringer må du huske at databasemigreringer i Grocy og custom extensions bør øves på i en kopiert config-katalog. Distribuer kandidaten mot en gjenopprettet kopi og gjenta den kjente testen. Hvis SQLite-databasen ikke kan skrive, eller planlagte oppgaver bruker feil tidssone, bruker du runtime-logger og det faktiske nettverkskallet for å finne ut hvilken antakelse som er endret.
Dette må være godkjent før ekte Grocy-data tas i bruk
En produksjonskontroll for Grocy bør kunne utføres av noen som ikke bygget distribusjonen. Gi personen den fastlåste versjonen, en ikke-sensitiv testkonto og denne oppgaven: erstatt standardpåloggingen, legg til et produkt, registrer et innkjøp og forbruk, skann en strekkode og utløs et oppgave- eller utløpsvarsel. Hvis instruksjonene krever udokumentert shell-tilgang, er tjenesten ennå ikke driftsklar.
Gjenta kontrollen etter at du bare har erstattet containeren. Gjenopprett deretter databasen, opplastede filer, oppskrifter og konfigurasjon til en tom infrastruktur, og bevis at lagerbeholdning, oppskrifter, oppgaver, utstyr og historikk kommer tilbake, og at neste planlagte varsel har riktig dato. Mål SQLite-skriving, opplastede bilder, planlagte jobber og trafikk fra husholdningsenheter under begge vellykkede kjøringer. Uventede forskjeller avdekker ofte en manglende cache, indeks, worker eller datamount.
Legg til en feilsimuleringsøvelse: send ufarlige data nær ressurs- eller formatgrensen som gjelder for denne grensen: SQLite-databasen kan ikke skrive, eller planlagte oppgaver bruker feil tidssone. Grocy skal generere en nyttig feilmelding, bevare eksisterende tilstand og hente seg inn når den gyldige tilstanden er tilbake. Lagre tidsstemplene og relevante logglinjer, med secrets maskert. Disse bevisene blir referansen for neste image- eller konfigurasjonsendring.
Bygg en Grocy-container som kan erstattes
Bruk en kommando som viser alle viktige valg. Denne grunnkonfigurasjonen binder Grocy til hostens loopback, legger til de kjente datamountene og angir den første nødvendige innstillingen. Bekreft det lokale kravet før eksponering: ett persistent config-volum og valgfri tilgang til strekkodeleserenheter.
docker run -d \
--name grocy \
--restart unless-stopped \
-p 127.0.0.1:80:80 \
-v grocy-data:/config \
lscr.io/linuxserver/grocy:latest
Erstatt flytende tags med en testet versjon eller digest. Etter oppstart inspiserer du docker logs --tail 200 grocy og bekrefter at prosessen lytter på port 80. Kjør deretter Grocy-akseptansetesten. Et svar fra rot-siden kan ikke bevise at hele scenariet lykkes: erstatt standardpåloggingen, legg til et produkt, registrer et innkjøp og forbruk, skann en strekkode og utløs et oppgave- eller utløpsvarsel.
Utform gjenoppretting av Grocy før lansering
Beskytt tilstanden i Grocy før du optimaliserer containeren. Det nødvendige settet består av database, opplastede filer, oppskrifter og konfigurasjon. Monter /config før bootstrap, skriv ufarlige eksempeldata og erstatt containeren for å bevise at banen faktisk er persistent. Hvis flere lagringssteder må være konsistente, dokumenterer du rekkefølgen for å sette skriving på pause og ta sikkerhetskopier.
Oppbevar kopier utenfor distribusjonsserveren, og krypter materiale som inneholder credentials eller privat innhold. Gjenopprettingen er vellykket når lagerbeholdning, oppskrifter, oppgaver, utstyr og historikk kommer tilbake, og neste planlagte varsel har riktig dato. Forskjellen mellom et persistent mount og en uavhengig kopi er beskrevet i persistent lagring og snapshots.
Test Grocy utenfra serveren
Velg det endelige Grocy-vertsnavnet før brukere lagrer callbacks eller klientinnstillinger, publiser deretter brukergrensesnittet over HTTPS og konfigurer riktig tidssone. Plattformruten skal terminere TLS én gang og peke mot privat port 80.
Kjør akseptansetransaksjonen eksternt. Hvis klienten aldri når Grocy, bruker du sjekklisten for SSL-validering for DNS- og sertifikatkontroller. Hvis forespørselen når Grocy, men SQLite-databasen ikke kan skrive, eller planlagte oppgaver bruker feil tidssone, må du slutte å endre proxy-redirects og heller inspisere den applikasjonsspesifikke grensen.
Velg tillitsgrensen for Grocy
Gjør en threat model av handlingen Grocy utfører, ikke bare av påloggingsskjemaet. Den største risikoen her er å beholde standardpåloggingen etter oppsettet. Implementer denne grensen: fjern standardcredentials, velg riktig tidssone og begrens husholdningsdata til de tiltenkte brukerne.
Grocy har ingen obligatorisk bootstrap-secret i denne grunnkonfigurasjonen. Beskytt i stedet den faktiske administratorkontoen eller autentiseringen oppstrøms. Ikke løs et tillatelsesproblem ved å kjøre containeren som root eller mounte hosten bredt. Ressursgrenser hører også hjemme i sikkerhetsdesignet når brukere kan utløse SQLite-skriving, opplastede bilder, planlagte jobber og trafikk fra husholdningsenheter.
En Dockup-distribusjon trenger fortsatt en Grocy-akseptansetest
Dockup kan håndtere de utskiftbare plattformdelene: rute trafikk til port 80, utstede domenet og sertifikatet, injisere secrets, koble til persistent lagring og koble Grocy til administrerte eller privat tilkoblede tjenester. Dette kan gjøres på Dockup-infrastruktur eller på en server du kobler til.
Akseptansetesten for Grocy må fortsatt være eksplisitt. Etter one-click-distribusjonen publiserer du brukergrensesnittet over HTTPS og konfigurerer riktig tidssone, bekrefter det lokale kravet — ett persistent config-volum og valgfri tilgang til strekkodeleserenheter — og kjører dette scenariet: erstatt standardpåloggingen, legg til et produkt, registrer et innkjøp og forbruk, skann en strekkode og utløs et oppgave- eller utløpsvarsel. Denne arbeidsdelingen er bevisst: Dockup fjerner repetitivt infrastrukturarbeid uten å late som om applikasjonsroller, provider-credentials eller policyen for gjenoppretting velger seg selv.
Vanlige spørsmål
Hva trenger Grocy for en produksjonsdistribusjon?
Rout Grocy-containeren på port 80 gjennom én HTTPS-origin. Kravet til det lokale runtime-miljøet er ett persistent config-volum og valgfri tilgang til strekkodeleserenheter. Ikke erklær Grocy som klar før du kan erstatte standardpåloggingen, legge til et produkt, registrere et innkjøp og forbruk, skanne en strekkode og utløse et oppgave- eller utløpsvarsel.
Hvilke Grocy-data bør inngå i en sikkerhetskopi?
Gjør /config persistent, og inkluder database, opplastede filer, oppskrifter og konfigurasjon i det samme gjenopprettingsmanifestet. En ren Grocy-gjenoppretting er først vellykket når lagerbeholdning, oppskrifter, oppgaver, utstyr og historikk kommer tilbake, og neste planlagte varsel har riktig dato.
Krever Grocy HTTPS bak en reverse proxy?
Bruk HTTPS for den offentlige Grocy-originen, og behold port 80 på den interne ruten. Bruk Grocy-innstillingen riktig: publiser brukergrensesnittet over HTTPS og konfigurer riktig tidssone. For Grocy beskytter HTTPS credentials eller brukerinnhold under overføring og sørger for at klientadferd som er avhengig av origin, forblir konsistent.
Hvordan bør en Grocy-oppgradering testes?
Gjenopprett gjeldende Grocy-tilstand i en isolert distribusjon, bruk kandidatversjonen og gjenta akseptansetransaksjonen. Vær spesielt oppmerksom på at databasemigreringer i Grocy og custom extensions bør øves på i en kopiert config-katalog. Behold det forrige Grocy-imaget til grensen for datamigrering og rollback er forstått.
