Dozzle è un log viewer per container Docker leggero e in tempo reale pensato per essere l’alternativa pratica al classico docker logs -f lanciato a mano su ogni container.

È stateless (non salva nulla su disco), pesa pochi MB e si installa con un solo comando Docker.

Nelle versioni più recenti supporta anche query SQL sui log tramite DuckDB in-browser monitoraggio multi-host con agent dedicati e notifiche verso Slack, Discord, ntfy o webhook generici.

In questa guida vedremo come installarlo su Ubuntu 26.04 con configurazione tramite Docker Compose, persistenza dei dati, autenticazione e pubblicazione dietro reverse proxy con certificato TLS.

PREREQUISITI

• Un server Ubuntu 26.04 con accesso sudo
• Docker Engine (versione 19.03 o superiore, API 1.40+) e il plugin Docker Compose
• Un container già in esecuzione, giusto per avere qualche log da guardare

INSTALLAZIONE DI DOCKER

Se Docker non è ancora installato eseguire i comandi:

sudo apt update

sudo apt install -y ca-certificates curl gnupg

sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg

sudo chmod a+r /etc/apt/keyrings/docker.gpg

echo \
"deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo "$VERSION_CODENAME") stable" | \
sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

sudo usermod -aG docker $USER

Dopo l’ultimo comando, esci e rientra nella sessione SSH (o esegui newgrp docker) per usare Docker senza sudo.

CREAZIONE DELLA DIRECTORY DELLO STACK

Come per gli altri servizi self-hosted conviene tenere ogni stack in una cartella dedicata sotto /opt:

sudo mkdir -p /opt/stacks/dozzle

cd /opt/stacks/dozzle

CREAZIONE DEL DOCKER-COMPOSE.YML

Creare il file docker-compose.yml con il comando:

sudo nano docker-compose.yml

Contenuto minimo, con persistenza del volume /data (necessaria per non perdere le impostazioni di notifica tra un riavvio e l’altro del container):

services:
dozzle:
image: amir20/dozzle:latest
container_name: dozzle
restart: unless-stopped
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
- dozzle_data:/data
ports:
- "8080:8080"
environment:
- DOZZLE_HOSTNAME=dozzle-srv01
# - DOZZLE_ENABLE_ACTIONS=true # abilita start/stop/restart dei container dalla UI
# - DOZZLE_ENABLE_SHELL=true # abilita l'accesso alla shell dei container dalla UI
# - DOZZLE_AUTH_PROVIDER=simple # abilita l'autenticazione (vedi Passo 5)

volumes:
dozzle_data:

NOTA BENE: il flag :ro sul mount del socket Docker perchè Dozzle ha bisogno solo di leggere lo stato dei container e i log, quindi montarlo in sola lettura è una buona pratica anche se, va detto, l’accesso al socket Docker resta comunque equivalente a un accesso root sull’host.

AVVIO DEL CONTAINER

Avviare il Container con il comando:

docker compose up -d

Dovremmo visualizzare un output simile al seguente:

[+] up 9/9
 Image amir20/dozzle:latest Pulled 3.1s
 Network dozzle_default Created 0.0s
 Volume dozzle_dozzle_data Created 0.0s
 Container dozzle Started

Fare un check con il comando:

docker ps | grep dozzle

Dovremmo visualizzare un output simile al seguente:

d7c03c6a3fb8 amir20/dozzle:latest "/dozzle" 33 seconds ago Up 31 seconds 0.0.0.0:8080->8080/tcp, [::]:8080->8080/tcp dozzle

Verificare che sia raggiungibile il link con il comando:

curl -I http://localhost:8080

ACCESSO A DOZZLE DA WEBGUI

Se tutto è a posto da un qualsiasi browser richiamare il link http://IP-DEL-SERVER:8080

Se è tutto OK dovremmo visualizzare la dashboard con l’elenco dei container in esecuzione sull’host.

CONFIGURAZIONE DEL FIREWALL

Se si vuole esporre la porta solo sulla rete interna limitare la regola alla subnet invece di aprirla su 0.0.0.0 con il comando:

sudo ufw allow from 192.168.0.0/16 to any port 8080 proto tcp

Se invece si pubblica Dozzle dietro reverse proxy la porta 8080 non deve essere esposta pubblicamente: basta che sia raggiungibile dal proxy.

ABILITARE L’AUTENTICAZIONE SU DOOZLE

Di default Dozzle è senza autenticazione quindi chiunque raggiunge la porta vede i log di tutti i container.

Per qualsiasi esposizione oltre al semplice localhost va abilitata l’autenticazione con il comando:

docker run -it --rm -v dozzle_data:/data amir20/dozzle generate admin \
--password "PASSWORD_SICURA" \
--email admin@lab.prv \
--name "Admin"

Poi nel docker-compose.yml scommentare la seguente riga:

yaml environment:
- DOZZLE_AUTH_PROVIDER=simple

Quindi riavviare lo stack con il comando:

docker compose up -d

Da questo momento l’accesso alla UI richiederà la login.

MONITORAGGIO MULTI-HOST (OPZIONALE)

Se si hanno più host Docker da monitorare da un’unica dashboard Dozzle supporta un’architettura ad agent: su ogni host remoto lanci un agent leggero, e li colleghi tutti al Dozzle principale.

Su ogni host remoto eseguire i comandi:

docker run -d \
--name dozzle-agent \
--restart unless-stopped \
-v /var/run/docker.sock:/var/run/docker.sock:ro \
-p 7007:7007 \
amir20/dozzle:latest agent

Sul Dozzle principale aggiungere nel docker-compose.yml le seguenti righe:

environment:
- DOZZLE_REMOTE_AGENT=IP_HOST_REMOTO:7007

L’agent comunica via gRPC sulla porta 7007: verificare che sia raggiungibile prima di dare per scontato che non funzioni.

FUNZIONALITA’ DI DOOZER

Ecco un quadro completo delle funzionalità di Dozzle, con pro e contro di ciascuna:

Monitoraggio log in tempo reale

Streaming live dei log di tutti i container Docker, senza bisogno di aprire terminali multipli con docker logs -f.

Pro: zero configurazione, log visibili immediatamente all’avvio

Contro: nessuna persistenza se un container va giù, vedi solo quello che rimane nel buffer del log driver Docker (limitato da max-size in daemon.json)

Ricerca e filtri sui log

Supporta ricerca regex, fuzzy search e (nelle versioni recenti) query SQL complete tramite DuckDB, eseguite via WebAssembly direttamente nel browser.

Pro: ricerca potente senza bisogno di un backend esterno o database

Contro: la ricerca SQL funziona solo sui log attualmente in buffer/visibili, non su uno storico persistente non è un sostituto di Loki o ELK per ricerche su settimane di log

Statistiche container (CPU, memoria, rete)

Grafici con storico “rolling” delle risorse per ogni container, aggiornati in tempo reale.

Pro: utile per un colpo d’occhio rapido senza aprire docker stats o Portainer

Contro: storico limitato alla sessione, non pensato per capacity planning a lungo termine

Multi-container / split view

Visualizzazione affiancata dei log di più container contemporaneamente.

Pro: comodo per debug su stack con più servizi correlati (es. app + db + reverse proxy)

Contro: con molti container aperti insieme l’interfaccia diventa affollata

Azioni sui container (start/stop/restart, shell)

Da abilitare esplicitamente con DOZZLE_ENABLE_ACTIONS e DOZZLE_ENABLE_SHELL.

Pro: gestione rapida senza uscire dal browser

Contro: disattivate di default per motivi di sicurezza — abilitarle su un’istanza esposta pubblicamente amplia parecchio la superficie di rischio, dato che chi ha accesso può eseguire comandi nei container

Notifiche/alert su pattern di log

Match su espressioni configurabili con notifica verso Slack, Discord, ntfy o webhook generico.

Pro: permette un minimo di alerting reattivo senza integrare uno stack di observability completo

Contro: nessuna gestione di stato/silenziamento evoluta come in un vero sistema di alerting (Alertmanager, ecc.)

Multi-host e Swarm/Kubernetes

Architettura ad agent per collegare più host Docker o cluster Swarm da un’unica dashboard; supporto anche per Kubernetes (DOZZLE_MODE=k8s, con RBAC per accesso ai log dei pod).

Pro: scala bene per contesti MSP con più host da monitorare centralmente

Contro: richiede di esporre/raggiungere la porta 7007 (gRPC) dell’agent su ogni host remoto, quindi va pianificato bene su reti segmentate o dietro VPN/tunnel

Autenticazione

Provider “simple” con utenti generati via CLI, oppure integrazione con reverse proxy di autenticazione tipo Authelia.

Pro: copre il caso base senza bisogno di terze parti

Contro: disattivata di default è facile dimenticarsene e lasciare un’istanza aperta su una rete condivisa; nessun supporto nativo a RBAC granulare (es. utenti che vedono solo certi container)

Impronta e leggerezza

Immagine da 7-10 MB, footprint minimo di CPU/RAM, nessun database.

Pro: ideale per homelab o affiancato ad app leggere senza overhead percepibile

Contro: proprio perché stateless, non fa retention: non è adatto a compliance/audit log a lungo termine

Accesso al socket Docker

Richiede il mount di /var/run/docker.sock (idealmente in sola lettura, :ro).

Pro: nessuna configurazione aggiuntiva per “vedere” tutti i container

Contro: l’accesso al socket Docker è di fatto equivalente a un accesso root sull’host è il principale motivo per cui va protetto dietro autenticazione/reverse proxy e mai esposto direttamente su internet

Analytics anonime

Raccoglie dati anonimi di utilizzo (Google Analytics) per orientare lo sviluppo, disattivabile col flag –no-analytics.

Pro: aiuta il progetto (open source, non finanziato) a capire dove investire

Contro: va disattivato esplicitamente se in ambienti con policy privacy stringenti (es. NIS2, clienti regolamentati)

In sintesi Dozzle è ottimo come vista live leggera e immediata, ma non sostituisce una piattaforma di log management vera e propria quando servono retention, ricerca storica, alerting strutturato o controlli di accesso granulari lì restano scelte più adatte Loki+Grafana, ELK o soluzioni a pagamento tipo Dash0.

Chi gestisce progetti in team o anche solo la propria lista di attività personali prima o poi si scontra con lo stesso dilemma: affidarsi a un servizio cloud di terze parti, con tutti i limiti in termini di privacy e controllo dei dati che questo comporta, oppure cercare un’alternativa self-hosted altrettanto semplice da usare.

Planka risponde proprio a questa esigenza: una board Kanban open source, leggera e reattiva, che riprende l’esperienza di Trello ma gira interamente sul proprio server.

In questa guida vedremo come installare e configurare Planka su Ubuntu Server 26.04 utilizzando Docker Compose, l’approccio più pulito e manutenibile per chi, come nel mio caso, gestisce già altri servizi containerizzati in homelab.

Partiremo dall’installazione di Docker, passeremo per la configurazione del container PostgreSQL necessario come backend, fino ad arrivare alla creazione dell’utente amministratore e a qualche accorgimento pratico per evitare i problemi più comuni che si possono incontrare al primo avvio, come la classica race condition tra database e applicazione.

Alla fine della guida avrete un’istanza di Planka funzionante e pronta per organizzare i vostri progetti, con le basi solide per aggiungere in un secondo momento un reverse proxy con HTTPS e altre personalizzazioni.

PREREQUISITI

• Ubuntu 26.04 con accesso sudo
• Almeno 1 GB di RAM libera
• Docker ed il plugin Compose

INSTALLAZIONE DI DOCKER

Installare Docker con i seguenti comandi:

curl -fsSL https://get.docker.com | sudo sh

sudo usermod -aG docker $USER

newgrp docker

sudo apt install docker-compose-plugin -y

Quindi verificare Docker con il comando:

docker --version

Dovremmo visualizzare un output simile al seguente:

Docker version 29.6.1, build 8900f1d

Verificare Docker Compose con il comando:

docker compose version

Dovremmo visualizzare un output simile al seguente:

Docker Compose version v5.3.1

CREAZIONE DELLE STRUTTURA DI PROGETTO

Creare la struttura di cartella con i seguenti comandi:

sudo mkdir -p /opt/planka

cd /opt/planka

CONFIGURAZIONE DEL DOCKER-COMPOSE.YML

Usare l’immagine ufficiale ghcr.io/plankanban/planka con PostgreSQL come backend.

Creare il file docker-compose.yml con il comando:

sudo nano docker-compose.yml

Quindi copiare all’interno il seguente output:

services:
planka:
image: ghcr.io/plankanban/planka:latest
container_name: planka
restart: unless-stopped
depends_on:
postgres:
condition: service_healthy
ports:
- "3000:1337"
environment:
- BASE_URL=http://TUO_IP_O_DOMINIO:3000
- DATABASE_URL=postgres://planka:CAMBIA_QUESTA_PASSWORD@postgres:5432/planka
- SECRET_KEY=CAMBIA_CON_STRINGA_CASUALE_LUNGA
- TRUST_PROXY=false
volumes:
- ./data/user-avatars:/app/public/user-avatars
- ./data/project-background-images:/app/public/project-background-images
- ./data/attachments:/app/private/attachments

postgres:
image: postgres:16-alpine
container_name: planka-db
restart: unless-stopped
environment:
- POSTGRES_USER=planka
- POSTGRES_PASSWORD=CAMBIA_QUESTA_PASSWORD
- POSTGRES_DB=planka
volumes:
- ./db_data:/var/lib/postgresql/data
healthcheck:
test: ["CMD-SHELL", "pg_isready -U planka -d planka"]
interval: 5s
timeout: 5s
retries: 5

Salvare il file e generare una SECRET_KEY sicura con il comando:

openssl rand -hex 64

Copiare il risultato dentro il file al posto di CAMBIA_CON_STRINGA_CASUALE_LUNGA e impostare una password robusta uguale in entrambi i punti CAMBIA_QUESTA_PASSWORD.

AVVIARE IL CONTAINER

Avviare il container con i seguenti comandi:

cd /opt/planka

docker compose up -d

Dovremmo visualizzare un output simile al seguente:

[+] up 31/31
 Image postgres:16-alpine Pulled 8.9s
 Image ghcr.io/plankanban/planka:latest Pulled 10.5s
 Network planka_default Created 0.0s
 Container planka-db Started 4.7s
 Container planka Started

Verificare i log con il comando:

docker compose logs -f planka

Attendere che i log mostrino che il server è pronto, poi Ctrl+C per uscire dai log (i container restano attivi).

CREAZIONE DELL’UTENTE AMMINISTRATORE

Dalla versione 1.13 in poi Planka non crea più un admin di default automaticamente. Va creato a mano con il seguente comando:

docker compose run --rm planka npm run db:create-admin-user

Ti verranno chiesti email, password, nome e username.

In alternativa, puoi impostare le variabili DEFAULT_ADMIN_EMAIL, DEFAULT_ADMIN_PASSWORD, DEFAULT_ADMIN_USERNAME e DEFAULT_ADMIN_NAME nel compose e fare un restart in modo che l’utente viene creato al primo avvio.

ACCESSO TRAMITE WEBGUI

Da un quslaisi browser aprire il link http://TUO_IP:3000 (o l’IP del server) ed effettuare il login con le credenziali admin appena create.

Inserire le credenziali create in precedenza quindi cliccare su Accedi

Accettare l’EULA e cliccare Continua

Dovremmo accedere alla Home di Planka

Da questa schermata è possibile iniziare a creare Progetti

BACKUP DI PLANKA

Planka fornisce script dedicati per backup/restore quando si usa docker-compose utile per uno script cron periodico che salvi sia il volume db_data sia le cartelle data/.

TROUBLESHOOTING RAPIDO

Check di Errori di avvio con il seguente comando:

docker compose logs planka | grep -i error

Check Problemi di autenticazione DB con il comando:

docker compose logs postgres

Per un Riavvio pulito utilizzare i comandi:

docker compose down

docker compose up -d

FUNZIONALITA’ PRINCIPALI

Gestione progetti e board

• Board in stile Kanban con liste e card trascinabili (drag-and-drop)
• Card con checklist, sotto-attività, etichette colorate, scadenze
• Allegati file sulle card
• Aggiornamenti in tempo reale via WebSocket (se più persone lavorano insieme, vedono i cambiamenti istantaneamente)

Collaborazione

• Gestione utenti e membri per progetto/board
• Assegnazione di card a membri specifici
• Commenti sulle card
• Import da Trello (utile se stai migrando)

Amministrazione

• Autenticazione OIDC (OpenID Connect) — comodo se vuoi integrarlo con un provider SSO che magari già usi in ambito M365/Azure AD
• Personalizzazione dei termini di utilizzo per utenti finali
• API disponibili (con client Python non ufficiale, plankapy)
• Supporto Swagger/Postman per chi vuole integrarlo via API

Deployment

• Docker/Docker Compose (il metodo che abbiamo appena configurato)
• Installazione manuale su Debian/Ubuntu
• Helm chart per chi gira su Kubernetes — potenzialmente interessante visto il tuo K3S

PRO E CONTRO DI PLANKA

Pro

• Leggero e veloce: footprint di risorse minimo, gira bene anche su una VM homelab modesta
• Interfaccia pulita: nessun sovraccarico di funzionalità inutili, esperienza molto simile a Trello
• Open source e self-hosted: controllo completo dei dati, nessuna dipendenza da servizi cloud terzi
• Real-time collaboration affidabile: funziona bene senza configurazioni complesse
• Community attiva: sviluppo continuo, immagini Docker aggiornate regolarmente

Contro

• Funzionalità limitate rispetto a strumenti più completi: non ha Gantt chart, timeline, dashboard di reportistica avanzata, automazioni (tipo Trello Butler o Jira workflows)
• Nessuna gestione avanzata di permessi/ruoli granulari: i controlli di accesso sono piuttosto semplici rispetto a strumenti enterprise
• Nessuna app mobile nativa: è web-based, va bene ma manca l’esperienza mobile dedicata
• Gestione admin utente cambiata di recente: dalla versione 1.13 non c’è più creazione automatica dell’admin, richiede uno step manuale in più (come abbiamo visto)
• Meno adatto a project management “pesante”: se hai bisogno di dipendenze tra task, milestone, roadmap, conviene guardare altrove (es. Taiga, che hai citato come alternativa nella guida che abbiamo trovato)
• Notifiche limitate: manca un sistema di notifiche via email/Slack robusto out-of-the-box

IN SINTESI

Planka è la scelta giusta se cerchi un Trello self-hosted semplice ed essenziale per organizzare task di un piccolo team o per uso personale esattamente il tipo di tool che si inserisce bene nel tuo stack homelab accanto a Portainer, Gitea, ecc.

Se invece hai bisogno di project management più strutturato con reportistica, automazioni o gestione risorse, è meglio orientarsi su alternative più feature-rich come Taiga o OpenProject.

Negli ultimi anni la gestione delle password è diventata un tema centrale per chiunque si occupi di sicurezza informatica, sia in ambito personale che professionale.

Tra i tanti password manager disponibili, Bitwarden si è affermato come una delle soluzioni open source più apprezzate, grazie alla sua compatibilità multipiattaforma e alle funzionalità avanzate di condivisione e organizzazione dei dati.

Per chi, come me, preferisce mantenere il pieno controllo dei propri dati attraverso soluzioni self-hosted, Vaultwarden rappresenta l’alternativa ideale: si tratta di un’implementazione non ufficiale del server Bitwarden, scritta in Rust, estremamente leggera e perfettamente compatibile con tutti i client ufficiali (estensioni browser, app mobile, desktop).

Questo la rende una scelta particolarmente indicata per ambienti homelab, dove risorse hardware contenute e semplicità di gestione sono priorità assolute.

In questa guida vedremo passo per passo come installare e configurare Vaultwarden su Ubuntu Server 26.04, utilizzando Docker e Docker Compose per un deployment pulito e facilmente riproducibile.

Affronteremo l’installazione del container, la configurazione delle variabili d’ambiente essenziali, l’impostazione di un reverse proxy per l’accesso sicuro via HTTPS, e la gestione dei certificati in un contesto di laboratorio locale. Al termine della guida avrete un’istanza di Vaultwarden pienamente funzionante, pronta per essere utilizzata come gestore password centralizzato per la vostra infrastruttura.

AGGIORNAMENTO DEL SISTEMA E PREREQUISITI

Eseguire i comandi:

sudo apt update && sudo apt upgrade -y

sudo apt install -y ca-certificates curl

INSTALLAZIONE DI DOCKER

Ubuntu 26.04 supporta nativamente il repository ufficiale Docker. Docker CE 29.4.0 supporta Ubuntu 26.04 nativamente dal giorno del rilascio, senza bisogno di workaround o pinning a codename precedenti.

Installare la chiave GPG ufficiale Docker con i comandi:

sudo install -m 0755 -d /etc/apt/keyrings

sudo curl -fsSL https://download.docker.com/linux/ubuntu/gpg -o /etc/apt/keyrings/docker.asc

sudo chmod a+r /etc/apt/keyrings/docker.asc

Confiugurare il repository (formato DEB822) con i comandi:

sudo tee /etc/apt/sources.list.d/docker.sources <<EOF
Types: deb
URIs: https://download.docker.com/linux/ubuntu
Suites: $(. /etc/os-release && echo "${UBUNTU_CODENAME:-$VERSION_CODENAME}")
Components: stable
Architectures: $(dpkg --print-architecture)
Signed-By: /etc/apt/keyrings/docker.asc
EOF

Quindi eseguire i comandi:

sudo apt update

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-buildx-plugin docker-compose-plugin

NOTA BENE: se ricevi un 404 sull’apt update (repository Docker non ancora popolato per resolute), puoi sostituire temporaneamente il codename con noble (Ubuntu 24.04), dato che i pacchetti sono compatibili a livello binario. In tal caso modifica il file docker.sources cambiando Suites: resolute in Suites: noble. Margrop Blog

Verificare l’installazione con i seguenti comandi:

sudo systemctl enable --now docker

sudo docker run --rm hello-world

Aggiungere il tuo utente al gruppo docker se vuoi eseguire comandi senza sudo con il comando:

sudo usermod -aG docker $USER

newgrp docker

STRUTTURA DIRECTORY PER VAULTWARDEN

Creare le cartelle con il comando:

sudo mkdir -p /opt/vaultwarden/data

cd /opt/vaultwarden

CREAZIONE DEL FILE DOCKER-COMPOSE

Creare il file docker-compose.yml con il comando:

sudo nano /opt/vaultwarden/docker-compose.yml

Quindi incollare il seguente contenuto:

services:
vaultwarden:
image: vaultwarden/server:latest
container_name: vaultwarden
restart: unless-stopped
environment:
DOMAIN: "https://vault.tuodominio.it"
SIGNUPS_ALLOWED: "false" # metti a true solo per il primo utente, poi disattiva
WEBSOCKET_ENABLED: "true"
ADMIN_TOKEN: "GENERA_UN_TOKEN_FORTE_QUI"
LOG_FILE: "/data/vaultwarden.log"
TZ: "Europe/Rome"
volumes:
- /opt/vaultwarden/data:/data
ports:
- "192.168.80.34:8080:80" # bind solo su localhost, esposto poi via NPM

Salvare e chiudere il file di configurazione

Generare un ADMIN_TOKEN sicuro (per accedere al pannello admin di Vaultwarden) con il comando:

openssl rand -base64 48

Incollare il risultato al posto di GENERA_UN_TOKEN_FORTE_QUI.

AVVIO DEL CONTAINER

Eseguire i comandi di seguito per avviare il container:

cd /opt/vaultwarden

sudo docker compose up -d

Verificare il container con il comando:

sudo docker compose logs -f

Se è tutto OK dovremmo visualizzare il seguente output:

vaultwarden | /--------------------------------------------------------------------\
vaultwarden | | Starting Vaultwarden |
vaultwarden | | Version 1.36.0 |
vaultwarden | |--------------------------------------------------------------------|
vaultwarden | | This is an *unofficial* Bitwarden implementation, DO NOT use the |
vaultwarden | | official channels to report bugs/features, regardless of client. |
vaultwarden | | Send usage/configuration questions or feature requests to: |
vaultwarden | | https://github.com/dani-garcia/vaultwarden/discussions or |
vaultwarden | | https://vaultwarden.discourse.group/ |
vaultwarden | | Report suspected bugs/issues in the software itself at: |
vaultwarden | | https://github.com/dani-garcia/vaultwarden/issues/new |
vaultwarden | \--------------------------------------------------------------------/
vaultwarden |
vaultwarden | [NOTICE] You are using a plain text `ADMIN_TOKEN` which is insecure.
vaultwarden | Please generate a secure Argon2 PHC string by using `vaultwarden hash` or `argon2`.
vaultwarden | See: https://github.com/dani-garcia/vaultwarden/wiki/Enabling-admin-page#secure-the-admin_token
vaultwarden |
vaultwarden | [2026-07-12 00:02:59.873][vaultwarden::auth][INFO] Private key 'data/rsa_key.pem' created correctly
vaultwarden | [2026-07-12 00:02:59.975][start][INFO] Rocket has launched from http://0.0.0.0:80

CONFIGURAZIONE REVERSE PROXY (NGINX PROXY MANAGER)

In questo tutorial utlizzerò come Reverse Proxy NPM

Creare un nuovo Proxy Host con queste info:

Domain: vault.lab.prv
Scheme: http
Forward Hostname/IP: IP del server dove gira Vaultwarden
Forward Port: 8080
Abilitare Websockets Support (fondamentale per la sync in tempo reale)
Tab SSL: richiedi certificato Let’s Encrypt, forza HTTPS.

ATTENZIONE: Vaultwarden richiede HTTPS per funzionare correttamente con le app client (browser extension, mobile), quindi il certificato non è opzionale.

PRIMO ACCESSO TRAMITE WEB GUI E CREAZIONE UTENTE

Aprire un qualsiasi browser e richiamare https://vault.lab.prv

Cliccare su Crea Account

Inserire l’indirizzo email e il nome quindi cliccare Continua

Inserire la Password quindi cliccare Create Account

Installare l’estensione o cliccare Più tardi per installarla in seguito

Cliccare Vai a Bitwarden WEB

Se è andato tutto a buon fine dovremmo visualizzare la Dashboard di Vaultwarden come mostrato nell’immagine sovrastante

Dopo aver creato l’utente admin disattivare la possibilità di registrare utenti modificando all’interno del file docker-compose.yml il seguente valore:

SIGNUPS_ALLOWED: "false"

Salvare e chiudere il file YAML

Quindi eseguire il comando:

sudo docker compose up -d

ACCESSO AL PANNELLO DI AMMINISTRAZIONE

Raggiungibile su https://vault.lab.prv/admin richiede il token generato in precedenza.

Inserire il Token quindi cliccare Enter

Se è tutto OK dovremmo accedere all’interfaccia Admin di Vaultwarden

Dal tab Users è possibile aggiungere gli utenti

Dal Tab Diagnostic è possibile vedere tutte le informazioni relative al server Vault

BACKUP

Il volume /opt/vaultwarden/data contiene tutto (database SQLite, attachments, config).

Backup consigliato con il comando:

sudo tar czf vaultwarden-backup-$(date +%F).tar.gz /opt/vaultwarden/data

Puoi integrarlo facilmente nel tuo stack Veeam/backup esistentem o schedularlo con un cron job verso il NAS.

AGGIORNAMENTI DI VAULTWARDEN

Per eseguire gli aggiornamenti di VaultWarden eseguire i comandi:

cd /opt/vaultwarden

sudo docker compose pull

sudo docker compose up -d

FUNZIONALITA’ PRINCIPALI

Gestione password e vault

• Password, note sicure, identità, carte di credito
• Cartelle e organizzazione vault
• Generatore di password/passphrase integrato
• Ricerca full-text nel vault
• Allegati ai singoli item (es. PDF, chiavi SSH)

Sincronizzazione multi-dispositivo

• Estensioni browser (Chrome, Firefox, Edge, Safari, Brave)
• App mobile (iOS/Android)
• App desktop (Windows/Mac/Linux)
• CLI ufficiale Bitwarden
• Sync in tempo reale via WebSocket (quello che abbiamo abilitato con WEBSOCKET_ENABLED)

Organizzazioni e condivisione (gratis su Vaultwarden, a pagamento su Bitwarden ufficiale)

• Creazione organizzazioni multiple
• Condivisione password tra utenti/gruppi
• Collections con permessi granulari
• Questo è uno dei motivi principali per cui la gente sceglie Vaultwarden: su Bitwarden cloud le organizzazioni richiedono piano a pagamento, qui sono gratuite

Autenticazione a due fattori (2FA)

• TOTP (Google Authenticator, Authy, ecc.)
• WebAuthn/FIDO2 (chiavi hardware tipo YubiKey)
• Duo (con configurazione aggiuntiva)
• Email 2FA
• Yubikey OTP

Bitwarden Send

• Condivisione sicura e temporanea di testo/file con link, scadenza automatica, password opzionale

Pannello admin (/admin)

• Gestione utenti (creazione, disabilitazione, eliminazione)
• Statistiche generali istanza
• Configurazione SMTP per invii email (inviti, reset password)
• Diagnostica (test connessione, versione, ecc.)
• Backup/export diagnostica

Import/Export

• Import da centinaia di altri password manager (LastPass, 1Password, KeePass, Chrome, ecc.)
• Export in formati cifrati o JSON/CSV

Emergency Access

• Designazione di un contatto di emergenza che può richiedere accesso al vault dopo un periodo di attesa configurabile

PRO E CONTRO

PRO

• Leggerissimo: Un singolo binario Rust, consumo RAM/CPU minimo — perfetto per homelab, gira bene anche su Raspberry Pi
• Compatibilità client al 100%: Usa le stesse app/estensioni ufficiali Bitwarden, nessuna app custom da installareù
• Funzionalità premium gratis: Organizzazioni, 2FA avanzato, Send: tutto ciò che su Bitwarden cloud richiede abbonamento qui è gratuito
• Self-hosted: controllo totale datiNessun dato transita su server terzi, importante per compliance/privacy
• Community attiva: Sviluppo costante, rilasci frequenti, ben documentato
• Facile da backuppare: Tutto in un volume/cartella (SQLite di default), backup semplice da integrare in Veeam o script cron
• Basso attack surface: Codice compatto rispetto al server ufficiale Bitwarden (che è containerizzato in decine di microservizi via bitwarden/self-host)

CONTRO

• Non ufficiale/non supportato da Bitwarden Inc.: Se qualcosa si rompe, supporto solo community (GitHub issues, Discord), nessun SLA
• Rischio di rottura compatibilità: Bitwarden Inc. può cambiare API client senza preavviso; Vaultwarden deve rincorrere gli aggiornamenti a volte con ritardo di giorni/settimane
• SQLite come DB di default: Va benissimo per uso personale/piccolo team, ma non scala bene per centinaia di utenti simultanei (puoi comunque passare a MySQL/PostgreSQL se serve)
• Nessuna interfaccia “enterprise”: Manca SSO/SAML nativo enterprise-grade (esiste supporto limitato, non paragonabile a Bitwarden Enterprise)
• Responsabilità di gestione tutta tua: Backup, certificati, aggiornamenti, sicurezza del server: nessuno lo fa per te (a differenza di Bitwarden cloud)
• Alcune funzionalità arrivano in ritardo: Feature nuove lato client Bitwarden a volte non sono supportate lato server finché la community non le implementa
• Termini di servizio “grigi”: Bitwarden Inc. non garantisce che i client ufficiali continueranno a funzionare con implementazioni terze in futuro (per ora nessun blocco, ma è un rischio teorico da tenere presente)
• Single point of failure: Se il tuo server va giù, perdi accesso al vault (mitigabile con backup + export periodici offline)

CONSIDERAZIONI FINALI

• Per uso personale/homelab: scelta quasi obbligata, SQLite basta e avanza
• Se in futuro pensi di offrirlo a clienti come servizio gestito: valuta il passaggio a PostgreSQL come backend (più robusto per multi-tenant) e assicurati SLA chiari con i clienti sul fatto che non è supporto ufficiale Bitwarden
• Backup: essendo SQLite, è un singolo file perfetto per backup incrementali veloci, ma verifica sempre la consistenza (evita backup “a caldo” senza dump, meglio uno stop breve o sqlite3 .backup)

Quando un servizio va giù, la prima domanda che si pone chiunque lo utilizzi è sempre la stessa: “è un problema mio o il server è down?”.

Una status page pubblica risolve elegantemente questo problema, dando visibilità trasparente sullo stato dei propri servizi senza dover rispondere a decine di messaggi durante un disservizio.

Kener è una soluzione open source per status page e uptime monitoring costruita su SvelteKit e pensata per essere leggera da self-hostare pur offrendo funzionalità che normalmente si trovano solo in prodotti SaaS a pagamento: gestione incidenti, finestre di manutenzione programmate, notifiche multi-canale, badge di stato incorporabili e supporto multilingua.

Il tutto distribuito con licenza MIT e un’immagine Docker pronta all’uso.

In questo articolo vedremo come installare Kener su una macchina Ubuntu Server 26.04 LTS tramite Docker Compose affiancandolo a Redis (dipendenza obbligatoria per cache e scheduler) e a un volume persistente per il database SQLite.

Copriremo anche alcuni accorgimenti pratici emersi direttamente durante l’installazione come la corretta gestione dei permessi sul volume dati e la scelta tra deployment in root o in subpath utili per evitare gli errori più comuni che si incontrano al primo avvio.

PREREQUISITI

• Ubuntu Server 26.04 aggiornato
• Docker Engine + Docker Compose plugin installati
• Una porta libera sull’host (default 3000)

INSTALLAZIONE DI DOCKER

Se Docker non è ancora installato eseguire i comandi:

sudo apt update

sudo apt install -y ca-certificates curl gnupg

sudo install -m 0755 -d /etc/apt/keyrings

curl -fsSL https://download.docker.com/linux/ubuntu/gpg | sudo gpg --dearmor -o /etc/apt/keyrings/docker.gpg
echo "deb [arch=$(dpkg --print-architecture) signed-by=/etc/apt/keyrings/docker.gpg] https://download.docker.com/linux/ubuntu \
$(. /etc/os-release && echo $VERSION_CODENAME) stable" | sudo tee /etc/apt/sources.list.d/docker.list > /dev/null

sudo apt update

sudo apt install -y docker-ce docker-ce-cli containerd.io docker-compose-plugin

CREAZIONE STRUTTURA DELLE CARTELLE

mkdir -p /opt/kener/database

cd /opt/kener

CONFIGURAZIONE FILE DOCKER COMPOSE

Creare il file di configurazione con il comando:

nano /opt/kener/docker-compose.yml

Quindi incollare il segente contenuto:

services:
kener-redis:
image: redis:7-alpine
container_name: kener-redis
restart: unless-stopped

kener:
image: docker.io/rajnandan1/kener:latest-status
container_name: kener-status
restart: unless-stopped
depends_on:
- kener-redis
ports:
- "3000:3000"
volumes:
- ./database:/app/database
environment:
- KENER_SECRET_KEY=CAMBIA_QUESTA_STRINGA_CASUALE
- ORIGIN=http://IP_O_DOMINIO:3000
- REDIS_URL=redis://kener-redis:6379
- TZ=Europe/Rome

Salvare e chiudere il file di configurazione

Generare una secret key sicura con il comando:

openssl rand -hex 32

Sostituire il valore generato al posto di CAMBIA_QUESTA_STRINGA_CASUALE, e impostare ORIGIN con l’IP o il dominio reale che userai per accedere.

CONFIGURAZIONE DEI PERMESSI

Eseguire i comandi in sequenza:

docker compose down
sudo chown -R 1000:1000 /opt/kener/database
docker compose up -d

AVVIO DELLO STACK

Avviare lo stack con i seguenti comandi:

cd /opt/kener

docker compose up -d

Dovremmo visualizzare il seguente output:

[+] up 35/35
 Image docker.io/rajnandan1/kener:latest-status Pulled 11.2s
 Image redis:7-alpine Pulled 4.2s
 Network kener_default Created 0.0s
 Container kener-redis Started 5.1s
 Container kener-status Started

Verificare lo stato di docker con i seguenti comandi:

docker compose ps

Dovremmo vedere un output simile al seguente:

NAME IMAGE COMMAND SERVICE CREATED STATUS PORTS
kener-redis redis:7-alpine "docker-entrypoint.s…" kener-redis About a minute ago Up About a minute 6379/tcp
kener-status docker.io/rajnandan1/kener:latest-status "./docker-entrypoint…" kener About a minute ago Up About a minute (healthy) 0.0.0.0:3000->3000/tcp, [::]:3000->3000/tcp

Eseguire quindi il comando:

docker compose logs -f kener

Se è tutto OK dovremmo visualizzare il seguente output:

kener-status | [dotenv@17.2.4] injecting env (0) from .env -- tip:  enable debug logging with { debug: true }
kener-status | [dotenv@17.2.4] injecting env (0) from .env -- tip:  load multiple .env files with { path: ['.env.local', '.env'] }
kener-status | Configuring database with type sqlite
kener-status | [dotenv@17.2.4] injecting env (0) from .env -- tip:  add access controls to secrets: https://dotenvx.com/ops
kener-status | [dotenv@17.2.4] injecting env (0) from .env -- tip:  add access controls to secrets: https://dotenvx.com/ops
kener-status | [dotenv@17.2.4] injecting env (0) from .env -- tip:  encrypt with Dotenvx: https://dotenvx.com
kener-status | [dotenv@17.2.4] injecting env (0) from .env -- tip:  prevent committing .env to code: https://dotenvx.com/precommit
kener-status | Configuring database with type sqlite
kener-status | [dotenv@17.2.4] injecting env (0) from .env -- tip:  prevent committing .env to code: https://dotenvx.com/precommit
kener-status | [dotenv@17.2.4] injecting env (0) from .env -- tip:  audit secrets and track compliance: https://dotenvx.com/ops
kener-status | Error running migrations: SqliteError: unable to open database file
kener-status | at new Database (/app/node_modules/better-sqlite3/lib/database.js:69:26)
kener-status | at Client_BetterSQLite3.acquireRawConnection (/app/node_modules/knex/lib/dialects/better-sqlite3/index.js:14:12)
kener-status | at create (/app/node_modules/knex/lib/client.js:262:39)
kener-status | at process.processTicksAndRejections (node:internal/process/task_queues:104:5) {
kener-status | code: 'SQLITE_CANTOPEN'
kener-status | }
kener-status | Running seed...
kener-status | Error running seed: Error: Error while executing "/app/seeds/generate_template.ts" seed: unable to open database file
kener-status | at Seeder._waterfallBatch (/app/node_modules/knex/lib/migrations/seed/Seeder.js:118:23)
kener-status | SqliteError: unable to open database file
kener-status | at new Database (/app/node_modules/better-sqlite3/lib/database.js:69:26)
kener-status | at Client_BetterSQLite3.acquireRawConnection (/app/node_modules/knex/lib/dialects/better-sqlite3/index.js:14:12)
kener-status | at create (/app/node_modules/knex/lib/client.js:262:39) {
kener-status | original: SqliteError: unable to open database file
kener-status | at new Database (/app/node_modules/better-sqlite3/lib/database.js:69:26)
kener-status | at Client_BetterSQLite3.acquireRawConnection (/app/node_modules/knex/lib/dialects/better-sqlite3/index.js:14:12)
kener-status | at create (/app/node_modules/knex/lib/client.js:262:39) {
kener-status | code: 'SQLITE_CANTOPEN'
kener-status | }
kener-status | }
kener-status | Kener is running on port 3000!
kener-status | Using option immediately with every does not affect the job's schedule. Job will run immediately anyway.
kener-status | Maintenance event scheduler started (runs every hour)
kener-status | Daily cleanup scheduler started (runs at 00:00 UTC)
kener-status | Running maintenance event scheduler...
kener-status | Error processing maintenances for event generation: SqliteError: unable to open database file
kener-status | at new Database (/app/node_modules/better-sqlite3/lib/database.js:69:26)
kener-status | at Client_BetterSQLite3.acquireRawConnection (/app/node_modules/knex/lib/dialects/better-sqlite3/index.js:14:12)
kener-status | at create (/app/node_modules/knex/lib/client.js:262:39)
kener-status | at process.processTicksAndRejections (node:internal/process/task_queues:104:5) {
kener-status | code: 'SQLITE_CANTOPEN'
kener-status | }
kener-status | Maintenance scheduler completed. Processed 0 maintenances, created 0 events.
kener-status | _ __ _ _ _ _
kener-status | | |/ /___ _ __ ___ _ __ __ _| || | / | / |
kener-status | | ' // _ \ '_ \ / _ \ '__| \ \ / / || |_ | | | |
kener-status | | . \ __/ | | | __/ | \ V /|__ _|| |_| |
kener-status | |_|\_\___|_| |_|\___|_| \_/ |_|(_)_(_)_|
kener-status |
kener-status | Kener version 4.1.1 is running!

PRIMO ACCESSO DA WEBGUI

Aprire il browser e richiamare il link:

http://IP_DEL_SERVER:3000/status/account/signin

Al primo avvio partirà il wizard di setup per creare l’account amministratore.

Inserire il nome dell’utente, la mail e password quindi cliccare Create Account

Se è andato tutto a buon fine dovremmo visualizzare la Dashboard di Kener

CARATTERISTICHE DI KENER

Ecco l’elenco dettagliato delle caratteristiche di Kener organizzato per area funzionale:

Monitoraggio dei servizi

• 11 tipi di monitor supportati: HTTP/API, TCP, Ping, DNS, SSL, SQL e altri protocolli comuni
• Scheduling basato su cron, con intervallo minimo di 1 minuto per check
• Configurazione flessibile via YAML: puoi definire tu stesso la logica che determina se un servizio è UP, DOWN o DEGRADED, non solo un semplice check binario
• Stato di default configurabile per un monitor (es. defaultStatus=DOWN se non viene ricevuto un aggiornamento entro l’intervallo previsto)
• Data Explorer: sezione per ispezionare lo storico dei check, analizzare i fallimenti e i trend di uptime nel tempo

Gestione incidenti

• Creazione incidenti tramite GitHub Issues con rich text, oppure via API REST dedicate
• Sistema di trigger: condizioni intelligenti per instradare automaticamente notifiche e automazioni operative in base agli eventi
• Template di messaggistica: modelli riutilizzabili per standardizzare le comunicazioni di incidenti e notifiche

Manutenzioni programmate

• Pianificazione di maintenance window con scheduler dedicato (nei log lo hai visto girare ogni ora)
• Generazione automatica degli eventi di manutenzione associati ai monitor

Notifiche

• Supporto nativo per Slack, Discord, webhook generici
• Sistema di notifica per i subscriber della status page (utenti finali che vogliono essere avvisati sui disservizi)

Interfaccia e personalizzazione

• Tema chiaro/scuro
• Costruito su SvelteKit + shadcn-svelte, interfaccia moderna e reattiva
• Responsive design per dispositivi mobili
• 100% accessibility score dichiarato
• Supporto multilingua: 21 lingue disponibili
• Badge generator per stato e uptime dei singoli monitor, embeddabili altrove
• Widget/iframe embed per integrare un monitor in altre pagine/dashboard
• Dominio personalizzato supportato
• SEO e social media ready (meta tag automatici)

Sicurezza e gestione accessi

• Vault/secret management: storage sicuro per chiavi e credenziali usate nelle integrazioni
• API Key management: emissione e revoca di chiavi per automazioni e integrazioni di terze parti
• KENER_SECRET_KEY dedicata per la sicurezza delle sessioni

Analytics

• Integrazione con provider esterni: Google Analytics, Plausible, Mixpanel, Umami, Microsoft Clarity e altri

Deployment e infrastruttura

• Immagine Docker ufficiale pronta all’uso, deploy dichiarato “in meno di 2 minuti” con Docker Compose
• Redis obbligatorio come dipendenza per cache, sessioni e coda dei job di scheduling
• Storage SQLite locale, senza necessità di un database esterno separato
• Supporto base path per hosting sotto Kubernetes/subpath
• Licenza MIT, quasi 5.000 star su GitHub
• Nessun supporto commerciale/SLA ufficiale — progetto community-driven, quindi da valutare in ottica di rischio se lo porti in produzione critica

Negli ultimi anni il mondo del self-hosting ha visto emergere alternative sempre più mature ai classici NAS OS commerciali.

Tra queste, ZimaOS sviluppato da IceWhale, gli stessi dietro ZimaBoard e ZimaCube si propone come un sistema operativo NAS “semplice, focalizzato e open”, costruito su base CasaOS, pensato per unire in un’unica interfaccia storage, gestione container Docker, multimedia e servizi da personal cloud.

Se possiedi già un’infrastruttura di virtualizzazione che sia un homelab su ESXi, un server VMware Workstation o un ambiente di test più strutturato non è necessario acquistare hardware dedicato per valutare ZimaOS: il sistema può essere installato senza troppe difficoltà anche in una macchina virtuale, con qualche accorgimento specifico legato a firmware, controller disco e formato immagine.

In questo articolo vedremo passo passo come creare una VM VMware compatibile, quali parametri di configurazione sono critici per un boot corretto (spoiler: UEFI e controller SATA non sono opzionali), e come completare l’installazione e la configurazione di base di ZimaOS, così da avere un ambiente pronto su cui sperimentare prima di un eventuale deployment su hardware reale.

DOWNLOAD DELL’IMMAGINE DI ZIMAOS

La pagina principale https://www.zimaspace.com/it/zimaos/download offre solo il file .img (pensato per USB/hardware fisico).

L’ISO per VM si trova invece sulla pagina release di GitHub:

https://github.com/IceWhaleTech/ZimaOS/releases

Lì, per ogni versione, negli “Assets” in fondo dovresti trovare sia il file .img che (per le release più recenti) un file .iso.

Cercare qualcosa tipo zimaos-x86_64-*.iso.

Durante la stesura del seguente articolo la versione disponibile è: zimaos-x86_64-1.6.2_installer.iso

CREAZIONE DELLA VM SU ESXI

New VM → Custom/Advanced

Guest OS: Linux → Other Linux 6.x (64-bit) (o Debian 64-bit, va bene lo stesso)

RAM: almeno 4 GB (min. richiesto 2 GB)

vCPU: 4 core consigliati

Storage: almeno 32 GB

Controller disco: utilizza SATA, non SCSI (default). Questo è importante perchè con SCSI l’installer spesso non vede il disco correttamente.

Firmware: prima del primo boot, vai nelle Opzioni della VM e cambia da BIOS a UEFI. ZimaOS non si avvia in modalità BIOS legacy.

CD/DVD virtuale: monta l’ISO scaricata come CD/DVD.

Accendere la VM: parte in automatico l’installer, il processo è completamente automatico e formatta il disco target (attenzione, cancella tutto). Al riaggio riparte già in ZimaOS.

INSTALLAZIONE DI ZIMAOS

Inizio dell’installazione

Premere Invio

Selezionare Install ZimaOS quindi premere Invio

Selezionare il disco dove installare ZimaOS quindi premere Invio

Selezionare Yes e premere Invio

Selezionare Yes e Premere Invio

Attendere qualche istante fino al termine del wipe del disco e alla creazione delle partizioni

Rimuovere la ISO agganciata alla VM quindi premere Invio per riavviare la VM

Se è andato tutto a buon fine dovremmo visualizzare la schermata di benvenuto di ZimaOS come mostrato nell’immagine sovrastante

ACCESSO A ZIMAOS TRAMITE WEBGUI

Richiamare in un qualsiasi browser il link mostrato nell’immagine di benvenuto

Nel mio caso richiamaerò: http://192.168.80.98/

Selezionare la Lingua, Accettare l’EULA quindi cliccare Avanti

Inserire il nome utente con la relativa password quindi cliccare Next

A questo punto dovremmo visualizzare la Dashboard di ZimaOS

FUNZIONALITA’ DI ZIMAOS

Ecco un elenco delle feature di ZimaOS:

Gestione file e storage

• File manager unificato: gestisci in un’unica interfaccia file provenienti da telefono, cloud, drive esterni e USB, con anteprima e condivisione senza attriti
• Mount istantaneo di dischi USB plug-and-play
• Integrazione cloud diretta (mount di cloud drive esterni per sync/trasferimento senza cambiare piattaforma)
• Accesso LAN/WAN da PC e Mac, con compatibilità verso NAS Synology/QNAP
• Supporto Thunderbolt come DAS (al momento limitato a ZimaCube Pro)

RAID e ridondanza storage

• Setup RAID in pochi click (JBOD, RAID 0, 1, 5, 6)
• Calcolo dello spazio disponibile stimato in tempo reale
• Vista d’insieme su salute dischi e spazio occupato

Backup

• Strategia di backup basata sul modello 3-2-1
• Dashboard centralizzata con stato dei backup, progresso task e storico sync
• Backup/sync incrociato tra cloud, storage locale e LAN

Sincronizzazione e trasferimento file

• Zima Client per Mac/PC (sync locale, editing diretto di video 4K)
• Zima Client per iOS/Android (backup e trasferimento mobile ad alta velocità
• Interfaccia web con drag-and-drop
• Condivisione file tramite link pubblico

Privacy e sicurezza

• Account locale: identità del dispositivo autogenerata, nessuna email/telefono richiesti, nessun login su piattaforme terze
• Networking P2P criptato end-to-end, senza passare da server cloud intermedi
• Multi-utente con permessi a livello di cartella (cartelle personali private di default)

App Store ed ecosistema

• Oltre 800 app installabili in un click
• Supporto completo a container Docker di terze parti
• App più popolari nella community: Immich (foto), Jellyfin/Plex/Emby (media server), Home Assistant (domotica), Paperless-ngx, Memos, Calibre, KaraKeep, n8n, Dashy, Pi-hole, Redroid, Nextcloud, Swing Music, Pinchflat, WordPress, Cloudflared

Funzionalità aggiuntive nate dalla community

• DLNA per streaming wireless verso TV/speaker compatibili
• ZVM: hypervisor leggero integrato per VM Windows/Linux one-click
• Supporto UPS per shutdown sicuro in caso di blackout
• Btop integrato per monitoraggio risorse in tempo reale (CPU, RAM, disco, rete)

Localizzazione

• Interfaccia disponibile in 28 lingue, italiano incluso

Licensing

• Versione Free: funzionalità core, Zima Client, Thunderbolt, Developer Mode, limite di 4 dischi e 3 utenti
• Licenza lifetime a $29: dischi e utenti illimitati

CrowdSec si è ormai affermato come alternativa moderna e collaborativa a Fail2ban: non si limita a bloccare IP sospetti in base ai log locali, ma sfrutta un modello di intelligence condivisa costruita dalla community quando un IP viene segnalato come malevolo su una macchina, l’informazione (in forma anonimizzata) arriva a tutti gli altri utenti del network CrowdSec, permettendo un blocco preventivo ancora prima che l’attacco arrivi sui propri sistemi.

L’architettura si basa su un motore che analizza i log in tempo reale tramite scenari e parser configurabili, un sistema di bouncer che applica il blocco effettivo (a livello di firewall, reverse proxy, o altro), e una console centralizzata opzionale per la gestione multi-macchina.

In questo articolo vedremo come installare CrowdSec su una macchina Ubuntu Server 26.04 pulita, quali collection attivare per un primo hardening (SSH, log di sistema, eventuali servizi web esposti), come configurare il bouncer firewall di base, e alcuni accorgimenti pratici per verificare che tutto funzioni correttamente prima di portarlo in produzione su un ambiente multi-sito come il mio.

PREREQUISITI

• Ubuntu Server 26.04 LTS
• Accesso root o sudo
• Connessione internet attiva
• Minimo 1 GB RAM, 10 GB storage

AGGIORNAMENTO DEL SISTEMA

Prima di tutto aggiornare i pacchetti con il comando:

sudo apt update && sudo apt upgrade -y

AGGIUNTA DEL REPOSITORY UFFICIALE DI CROWDSEC

CrowdSec distribuisce i pacchetti tramite il proprio repository APT. Aggiungilo con lo script ufficiale:

curl -s https://packagecloud.io/install/repositories/crowdsec/crowdsec/script.deb.sh | sudo bash

Lo script importa la chiave GPG, registra il repository e aggiorna la cache APT.

Dovremmo visualizzare il seguente output:

Detected operating system as Ubuntu/resolute.
Checking for curl...
Detected curl...
Checking for gpg...
Detected gpg...
Detected apt version as 3.2.0
Running apt-get update... done.
Installing apt-transport-https... done.
Installing /etc/apt/sources.list.d/crowdsec_crowdsec.list...done.
Importing packagecloud gpg key... Packagecloud gpg key imported to /etc/apt/keyrings/crowdsec_crowdsec-archive-keyring.gpg
done.
Running apt-get update... done.

The repository is setup! You can now install packages.

NOTA BENE: se preferisci non fare pipe di curl direttamente in bash, puoi scaricare lo script, esaminarlo e poi eseguirlo manualmente.

ATTENZIONE: Per Ubuntu Pro/ESM, se hai i repository universe abilitati, il sistema potrebbe proporre CrowdSec 1.4.6 (versione obsoleta). Crea un pinning per forzare il repo ufficiale:

sudo tee /etc/apt/preferences.d/crowdsec << 'EOF'
Package: crowdsec*
Pin: origin packagecloud.io
Pin-Priority: 900
EOF
sudo apt update

INSTALLAZIONE DELL’AGENT

Installare l’agent con il seguente comando:

sudo apt install -y crowdsec

Durante l’installazione CrowdSec rileva automaticamente i servizi in esecuzione (sshd, nginx, ecc.) e scarica le relative collection di default dal CrowdSec Hub.

Al termine dovremmo visualizzare il seguente output:

The following packages were automatically installed and are no longer required:
linux-headers-7.0.0-14 linux-image-unsigned-7.0.0-14-generic linux-modules-7.0.0-14-generic linux-tools-7.0.0-14-generic
linux-headers-7.0.0-14-generic linux-main-modules-zfs-7.0.0-14-generic linux-tools-7.0.0-14
Use 'sudo apt autoremove' to remove them.

Installing:
crowdsec

Summary:
Upgrading: 0, Installing: 1, Removing: 0, Not Upgrading: 2
Download size: 42.2 MB
Space needed: 140 MB / 40.1 GB available

Get:1 http://archive.ubuntu.com/ubuntu resolute/universe amd64 crowdsec amd64 1.4.6-10.1 [42.2 MB]
Fetched 42.2 MB in 2s (23.9 MB/s)
Selecting previously unselected package crowdsec.
(Reading database… 180436 files and directories currently installed.)
Preparing to unpack …/crowdsec_1.4.6-10.1_amd64.deb…
Unpacking crowdsec (1.4.6-10.1)…
Setting up crowdsec (1.4.6-10.1)…
I: Registering to LAPI (/etc/crowdsec/local_api_credentials.yaml)
I: Registering to CAPI (/etc/crowdsec/online_api_credentials.yaml)
I: Setting up offline hub (see README.Debian)
I: Enabling upstream-recommended items, first installation (via symlinks from /etc/crowdsec)
I: Enabling WAL for SQLite [fstype=ext4] (see README.Debian)
Created symlink '/etc/systemd/system/multi-user.target.wants/crowdsec.service' → '/usr/lib/systemd/system/crowdsec.service'.
W: Restarting manually to force a CAPI pull (upstream #2120)
Scanning processes...
Scanning linux images...

Running kernel seems to be up-to-date.

No services need to be restarted.

No containers need to be restarted.

No user sessions are running outdated binaries.

No VM guests are running outdated hypervisor (qemu) binaries on this host.

Verificare cosa è stato installato con il comando:

sudo cscli collections list

Dovremmo visualizzare il seguente output:

COLLECTIONS
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
Name  Status Version Local Path
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────
crowdsecurity/apache2  enabled 0.1 /etc/crowdsec/collections/apache2.yaml
crowdsecurity/base-http-scenarios  enabled 0.6 /etc/crowdsec/collections/base-http-scenarios.yaml
crowdsecurity/http-cve  enabled 1.9 /etc/crowdsec/collections/http-cve.yaml
crowdsecurity/linux  enabled 0.2 /etc/crowdsec/collections/linux.yaml
crowdsecurity/nginx  enabled 0.2 /etc/crowdsec/collections/nginx.yaml
crowdsecurity/sshd  enabled,tainted 0.2 /etc/crowdsec/collections/sshd.yaml
──────────────────────────────────────────────────────────────────────────────────────────────────────────────────────

INSTALLAZIONE DEL FIREWALL BOUNCER

Il bouncer è il componente che applica concretamente i blocchi. Scegli la versione corretta in base al tuo stack firewall:

Se si utilizza iptables (default su Ubuntu):

sudo apt install -y crowdsec-firewall-bouncer-iptables

Se si utilizza nftables nativo:

sudo apt install -y crowdsec-firewall-bouncer-nftables

ATTENZIONE: se il tuo sistema usa nftables nativo e installi il bouncer iptables, sembrerà funzionare ma non bloccherà nulla.

Verificare con il comando:

sudo nft list ruleset

Se il comando restituisce output, stai usando nftables.

Il bouncer si registra automaticamente con l’agent locale e inizia subito ad applicare blocchi, inclusa la community blocklist sincronizzata dal cloud CrowdSec.

VERIFICA DEL FUNZIONAMENTO

Abilita il servizio all’avvio e verifica lo stato con i comandi:

sudo systemctl enable crowdsec

sudo systemctl status crowdsec

Se è tutto OK dovremmo visualizzre il seguente output:

● crowdsec.service - Crowdsec agent
Loaded: loaded (/usr/lib/systemd/system/crowdsec.service; enabled; preset: enabled)
Active: active (running) since Sat 2026-07-11 14:14:40 UTC; 3min 55s ago
Invocation: 10a04e4e854f49e5b1388a0b56db5afc
Main PID: 2909 (crowdsec)
Tasks: 9 (limit: 6227)
Memory: 49.3M (peak: 50.5M)
CPU: 3.144s
CGroup: /system.slice/crowdsec.service
├─2909 /usr/bin/crowdsec -c /etc/crowdsec/config.yaml
└─2916 journalctl --follow -n 0 _SYSTEMD_UNIT=ssh.service

Jul 11 14:14:39 vm-srv-test systemd[1]: Starting crowdsec.service - Crowdsec agent...
Jul 11 14:14:40 vm-srv-test systemd[1]: Started crowdsec.service - Crowdsec agent.

Controllare le metriche di acquisizione log con il comando:

sudo cscli metrics

Dovremmo visualizzare il seguente output:

Acquisition Metrics:
╭────────────────────────┬────────────┬──────────────┬────────────────┬────────────────────────╮
│ Source │ Lines read │ Lines parsed │ Lines unparsed │ Lines poured to bucket │
├────────────────────────┼────────────┼──────────────┼────────────────┼────────────────────────┤
│ file:/var/log/auth.log │ 21 │ - │ 21 │ - │
│ file:/var/log/syslog │ 20 │ - │ 20 │ - │
╰────────────────────────┴────────────┴──────────────┴────────────────┴────────────────────────╯

Parser Metrics:
╭─────────────────────────────────┬──────┬────────┬──────────╮
│ Parsers │ Hits │ Parsed │ Unparsed │
├─────────────────────────────────┼──────┼────────┼──────────┤
│ child-crowdsecurity/syslog-logs │ 41 │ 41 │ - │
│ crowdsecurity/syslog-logs │ 41 │ 41 │ - │
╰─────────────────────────────────┴──────┴────────┴──────────╯

Local Api Metrics:
╭────────────────────┬────────┬──────╮
│ Route │ Method │ Hits │
├────────────────────┼────────┼──────┤
│ /v1/heartbeat │ GET │ 4 │
│ /v1/watchers/login │ POST │ 2 │
╰────────────────────┴────────┴──────╯

Local Api Machines Metrics:
╭──────────────────────────────────┬───────────────┬────────┬──────╮
│ Machine │ Route │ Method │ Hits │
├──────────────────────────────────┼───────────────┼────────┼──────┤
│ 85a4c273f3ce42408c076d300194eca0 │ /v1/heartbeat │ GET │ 4 │
╰──────────────────────────────────┴───────────────┴────────┴──────╯

Local Api Decisions:
╭─────────────────┬────────┬────────┬───────╮
│ Reason │ Origin │ Action │ Count │
├─────────────────┼────────┼────────┼───────┤
│ ssh:bruteforce │ CAPI │ ban │ 2702 │
│ http:bruteforce │ CAPI │ ban │ 538 │
│ http:crawl │ CAPI │ ban │ 6042 │
│ http:dos │ CAPI │ ban │ 585 │
│ http:exploit │ CAPI │ ban │ 4671 │
│ http:scan │ CAPI │ ban │ 460 │
╰─────────────────┴────────┴────────┴───────╯

Se i contatori di acquisizione crescono mentre i log si riempiono, l’agent sta leggendo correttamente.

Se rimangono a zero, il problema è quasi sempre un percorso log non standard: controllare e correggere /etc/crowdsec/acquis.yaml.

CONFIGURAZIONE DELLE COLLECTION

Le collection sono bundle di parser e scenari per uno specifico servizio. Installare solo quelle relative ai servizi realmente in esecuzione sulla macchina.

Collection base (consigliate per tutti i server)

bash# Rilevamento pattern SSH brute-force (già inclusa di default)

sudo cscli collections install crowdsecurity/sshd

# Pattern HTTP per exploit CVE generici (/.env, /wp-config.php.bak, ecc.)

sudo cscli collections install crowdsecurity/http-cve

# Pattern privilege escalation locale da auth.log

sudo cscli collections install crowdsecurity/linux-lpe

Collection aggiuntive (in base ai servizi installati)

bash# Solo se usi Nginx

sudo cscli collections install crowdsecurity/nginx

# Solo se usi Apache

sudo cscli collections install crowdsecurity/apache2

# Solo se usi WordPress

sudo cscli collections install crowdsecurity/wordpress

# Solo se MariaDB/MySQL è esposto in rete (non localhost)

sudo cscli collections install crowdsecurity/mariadb

# Solo se usi il tarpit SSH endlessh

sudo cscli collections install crowdsecurity/endlessh

Regola pratica: non installare collection per servizi che non hai. Ogni parser aggiunge overhead e rumore nel log delle decisioni. Tratta le collection come le regole firewall: minima superficie, intento esplicito.

Dopo l’installazione di nuove collection, riavvia l’agent con il comando:

sudo systemctl restart crowdsec

Verificare gli scenari attivi con i seguenti comandi:

sudo cscli collections list

sudo cscli scenarios list

CONFIGURAZIONE DELLE SORGENTI LOG (ACQUIS.YAML)

Se hai percorsi log non standard o vuoi aggiungere manualmente delle sorgenti, modificare /etc/crowdsec/acquis.yaml con il comando:

sudo nano /etc/crowdsec/acquis.yaml

Esempio di configurazione per SSH e Nginx:

yaml---
# Log SSH
filenames:
- /var/log/auth.log
labels:
type: syslog
---
# Log Nginx
filenames:
- /var/log/nginx/access.log
- /var/log/nginx/error.log
labels:
type: nginx

Dopo le modifiche eseguire il comando:

sudo systemctl restart crowdsec

COLLEGAMENTO ALLA CROWDSEC CONSOLE (OPZIONALE MA CONSIGLIATO)

La console web gratuita su app.crowdsec.net offre un dashboard centralizzato con alert, decisioni, statistiche e mappa geografica degli attacchi.

La procedura di enrollment prevede i seguenti passaggi:

Creare un account su app.crowdsec.net

Andare su Security Engines → Add → copiare il comando di enrollment

Eseguilo sul server:

sudo cscli console enroll <IL_TUO_TOKEN>

Approvare l’istanza dalla Console web

Riavviare l’agent (passaggio obbligatorio):

sudo systemctl restart crowdsec

ATTENZIONE: senza il riavvio, l’istanza risulta enrollata ma non trasmette dati alla Console.

Se è tutto OK dovremmo visualizzare la Dashboard di Crowdsec come mostrato nell’immagine sovrastante

COMANDI UTILI PER LA GESTIONE QUOTIDIANA

bash# Visualizza le decisioni attive (IP bannati)

sudo cscli decisions list

# Visualizza gli alert recenti

sudo cscli alerts list

# Aggiungi manualmente un ban

sudo cscli decisions add --ip 1.2.3.4 --duration 24h --reason "test ban"

# Rimuovi un ban

sudo cscli decisions delete --ip 1.2.3.4

# Whitelist permanente di un IP

sudo cscli allowlists add mywhitelist --ip 192.168.1.100

# Aggiorna hub (parser, scenari, collection)

sudo cscli hub update
sudo cscli hub upgrade

# Stato dei bouncer registrati

sudo cscli bouncers list

# Metriche dettagliate

sudo cscli metrics