Indice del diarioDockup / nota dal campo
Note / self-host-grocy

Come fare il self-hosting di Grocy nel 2026: dati dell'inventario, fuso orario e backup

Configura il self-hosting di Grocy con porte corrette, storage persistente, HTTPS, secret, backup e controlli degli upgrade. Scopri come risolvere il problema per cui il database SQLite non è scrivibile.

Considera Grocy come un piccolo sistema, non come una Docker image. L'obiettivo per chi usa Grocy è chiaro: gestire l'inventario domestico, la spesa, le faccende e le attrezzature; il deployment è accettabile solo quando puoi sostituire il login predefinito, aggiungere un prodotto, registrare un acquisto e un consumo, scansionare un barcode e attivare un promemoria per una faccenda o una scadenza.

Questa distinzione fa emergere il problema che gli operatori incontrano dopo i test locali: il database SQLite non è scrivibile oppure le faccende pianificate usano il fuso orario sbagliato. Inoltre, rende il piano di backup e upgrade abbastanza specifico da poter essere testato.

Porte, processi e servizi privati

Un diagramma utile di Grocy mostra il percorso pubblico, la porta privata 80, il confine dei dati persistenti e ogni requisito di supporto. Indica quali frecce trasportano credenziali e quali rappresentano il normale traffico degli utenti. Il requisito del runtime locale consiste in un volume di configurazione persistente e nell'accesso opzionale al dispositivo per la scansione dei barcode. Dimensiona e monitora questa risorsa insieme al container, invece di esporre un servizio di rete non correlato.

Verifica il diagramma con un'azione reale: sostituisci il login predefinito, aggiungi un prodotto, registra un acquisto e un consumo, scansiona un barcode e attiva un promemoria per una faccenda o una scadenza. Il carico più probabile deriva dalle scritture su SQLite, dalle immagini caricate, dai job pianificati e dal traffico dei dispositivi domestici; monitora questo percorso invece di trattare tutte le richieste HTTP allo stesso modo.

Monitora il workload, non solo il container

Osserva il lavoro svolto da Grocy: scritture su SQLite, immagini caricate, job pianificati e traffico dei dispositivi domestici. Imposta i limiti lasciando margine sufficiente per questo lavoro ed evita un liveness probe che vi entri in competizione. Il controllo operativo dovrebbe comunque provare, secondo una pianificazione, a sostituire il login predefinito, aggiungere un prodotto, registrare un acquisto e un consumo, scansionare un barcode e attivare un promemoria per una faccenda o una scadenza.

Per gli aggiornamenti, ricorda che le migrazioni del database di Grocy e le estensioni custom devono essere provate su una directory di configurazione copiata. Esegui la versione candidata su una copia ripristinata e ripeti il test noto. Se il database SQLite non è scrivibile oppure le faccende pianificate usano il fuso orario sbagliato, usa i log del runtime e la richiesta di rete effettiva per individuare quale ipotesi è cambiata.

Cosa deve superare i controlli prima che arrivino dati reali in Grocy

Un gate di produzione per Grocy deve poter essere eseguito da una persona che non ha realizzato il deployment. Fornisci a questa persona la versione fissata, un account di test non sensibile e questa attività: sostituire il login predefinito, aggiungere un prodotto, registrare un acquisto e un consumo, scansionare un barcode e attivare un promemoria per una faccenda o una scadenza. Se le istruzioni richiedono un accesso shell non documentato, il servizio non è ancora pronto dal punto di vista operativo.

Ripeti il gate dopo aver sostituito solo il container. Poi ripristina database, file caricati, ricette e configurazione su un'infrastruttura vuota e dimostra che scorte, ricette, faccende, attrezzature e cronologia vengono recuperate e che il promemoria pianificato successivo presenta la data corretta. Misura le scritture su SQLite, le immagini caricate, i job pianificati e il traffico dei dispositivi domestici durante entrambe le esecuzioni riuscite; differenze inattese rivelano spesso una cache, un indice, un worker o un mount dei dati mancante.

Aggiungi un'esercitazione di failure drill: invia un input innocuo vicino al limite di risorse o di formato associato a questo confine: il database SQLite non è scrivibile oppure le faccende pianificate usano il fuso orario sbagliato. Grocy dovrebbe produrre un errore utile, conservare lo stato esistente e recuperare quando la condizione valida ritorna. Salva i timestamp e le righe di log pertinenti, oscurando i secret. Questa evidenza diventa il riferimento per la prossima modifica all'immagine o alla configurazione.

Crea un container Grocy sostituibile

Usa un comando che esponga ogni scelta importante. Questa configurazione di base collega Grocy al loopback dell'host, aggiunge i mount dei dati noti e fornisce la prima impostazione richiesta. Conferma il requisito locale prima dell'esposizione: un volume di configurazione persistente e l'accesso opzionale al dispositivo per la scansione dei barcode.

docker run -d \
  --name grocy \
  --restart unless-stopped \
  -p 127.0.0.1:80:80 \
  -v grocy-data:/config \
  lscr.io/linuxserver/grocy:latest

Sostituisci i tag mobili con una versione testata o un digest. Dopo l'avvio, controlla docker logs --tail 200 grocy e verifica che il processo sia in ascolto sulla porta 80. Esegui quindi l'azione di acceptance di Grocy; una risposta della pagina principale non può dimostrare che lo scenario completo abbia successo: sostituire il login predefinito, aggiungere un prodotto, registrare un acquisto e un consumo, scansionare un barcode e attivare un promemoria per una faccenda o una scadenza.

Progetta il restore di Grocy prima del lancio

Proteggi lo stato di Grocy prima di ottimizzare il container. L'insieme richiesto comprende database, file caricati, ricette e configurazione. Monta /config prima del bootstrap, scrivi dati di esempio innocui e sostituisci il container per dimostrare che il percorso è effettivamente persistente. Se più storage devono restare coerenti, documenta l'ordine in cui mettere in pausa le scritture ed eseguire i backup.

Conserva copie al di fuori del server di deployment e cifra il materiale che contiene credenziali o contenuti privati. Il recovery ha successo quando scorte, ricette, faccende, attrezzature e cronologia vengono recuperate e il promemoria pianificato successivo presenta la data corretta. La differenza tra un mount persistente e una copia indipendente è descritta in storage persistente e snapshot.

Testa Grocy dall'esterno del server

Scegli l'hostname finale di Grocy prima che gli utenti salvino callback o impostazioni client, poi pubblica l'interfaccia su HTTPS e configura il fuso orario corretto. Il percorso della piattaforma dovrebbe terminare TLS una sola volta e puntare alla porta privata 80.

Esegui la transazione di acceptance dall'esterno. Se il client non raggiunge mai Grocy, usa la checklist di validazione SSL per i controlli DNS e del certificato. Se la richiesta raggiunge Grocy ma il database SQLite non è scrivibile oppure le faccende pianificate usano il fuso orario sbagliato, smetti di modificare i redirect del proxy e controlla invece il confine specifico dell'applicazione.

Scegli il trust boundary di Grocy

Esegui il threat modeling dell'azione che Grocy svolge, non solo del suo form di login. In questo caso, l'errore più rischioso è mantenere il login predefinito dopo la configurazione. Implementa questo confine: rimuovi le credenziali predefinite, scegli il fuso orario corretto e limita i dati domestici agli utenti previsti.

Questa configurazione di base non richiede un secret di bootstrap obbligatorio per Grocy; proteggi invece il suo account amministratore effettivo o l'autenticazione upstream. Non risolvere un errore di permessi eseguendo il container come root o montando l'host senza restrizioni. Anche i limiti delle risorse fanno parte del security design quando gli utenti possono attivare scritture su SQLite, immagini caricate, job pianificati e traffico dei dispositivi domestici.

Anche un deployment Grocy su Dockup richiede un acceptance test

Dockup può occuparsi dei componenti sostituibili della piattaforma: instradare il traffico verso la porta 80, emettere il dominio e il certificato, iniettare i secret, collegare lo storage persistente e connettere Grocy a servizi gestiti o collegati privatamente. Può farlo sull'infrastruttura Dockup o su un server che colleghi.

Il lavoro di acceptance di Grocy resta esplicito. Dopo il one-click deployment, pubblica l'interfaccia su HTTPS e configura il fuso orario corretto, conferma il requisito locale — un volume di configurazione persistente e l'accesso opzionale al dispositivo per la scansione dei barcode — ed esegui questo scenario: sostituisci il login predefinito, aggiungi un prodotto, registra un acquisto e un consumo, scansiona un barcode e attiva un promemoria per una faccenda o una scadenza. Questa separazione è intenzionale: Dockup elimina la configurazione ripetitiva dell'infrastruttura senza fingere che ruoli applicativi, credenziali dei provider o policy di restore si scelgano da soli.

Domande frequenti

Di cosa ha bisogno Grocy per un deployment di produzione?

Instrada il container Grocy sulla porta 80 attraverso un'unica origin HTTPS. Il requisito del runtime locale consiste in un volume di configurazione persistente e nell'accesso opzionale al dispositivo per la scansione dei barcode. Non considerare Grocy pronto finché non puoi sostituire il login predefinito, aggiungere un prodotto, registrare un acquisto e un consumo, scansionare un barcode e attivare un promemoria per una faccenda o una scadenza.

Quali dati di Grocy devono rientrare in un backup?

Rendi persistente /config e includi database, file caricati, ricette e configurazione nello stesso manifest di recovery. Un restore pulito di Grocy ha esito positivo solo quando scorte, ricette, faccende, attrezzature e cronologia vengono recuperate e il promemoria pianificato successivo presenta la data corretta.

Grocy richiede HTTPS dietro un reverse proxy?

Usa HTTPS per l'origin pubblico di Grocy e mantieni la porta 80 sul percorso interno. Applica correttamente l'impostazione di Grocy: pubblica l'interfaccia su HTTPS e configura il fuso orario corretto. Per Grocy, HTTPS protegge le credenziali o i contenuti degli utenti durante il transito e mantiene coerente il comportamento client sensibile all'origin.

Come deve essere testato un upgrade di Grocy?

Ripristina lo stato corrente di Grocy in un deployment isolato, applica la versione candidata e ripeti la transazione di acceptance. Presta particolare attenzione perché le migrazioni del database di Grocy e le estensioni custom devono essere provate su una directory di configurazione copiata. Conserva la precedente image di Grocy finché non avrai compreso i confini della migrazione dei dati e del rollback.