Alternative self-hosted a Trello: confronto

Quale alternativa self-hosted a Trello dovresti scegliere?

Tre alternative self-hosted a Trello meritano attenzione: Planka se vuoi la stessa struttura a bacheche di Trello e il relativo file di importazione, Vikunja quando un team ha bisogno del single sign-on e di funzionalità che vanno oltre una semplice bacheca, e Kanboard quando il VPS (virtual private server) dispone di poca memoria. Non iniziare un nuovo progetto con Focalboard. Il suo server standalone non riceve release da 783 giorni e il relativo README ora cerca un maintainer.

Wekan è il quinto dei 5 strumenti qui elencati. Funziona, ma consuma diverse volte la memoria richiesta da tutte le altre soluzioni. Ogni versione, licenza e data riportata di seguito è stata verificata il 5 agosto 2026.

Di quanta RAM ha bisogno ogni strumento per le bacheche?

[
  {
    "tool": "Planka + Postgres",
    "idle_memory_mb": 280
  },
  {
    "tool": "Vikunja + SQLite",
    "idle_memory_mb": 110
  },
  {
    "tool": "Focalboard + SQLite",
    "idle_memory_mb": 120
  },
  {
    "tool": "Wekan + FerretDB",
    "idle_memory_mb": 750
  },
  {
    "tool": "Kanboard + SQLite",
    "idle_memory_mb": 70
  }
]

Questi sono valori tipici a riposo per una nuova installazione non utilizzata, del tipo di valore che docker stats riporta un minuto dopo l'avvio dello stack. Usali per dimensionare un piano, quindi misura il tuo ambiente. L'andamento conta più del numero esatto di megabyte.

Kanboard è il valore minimo, con 70 MB, perché usa PHP con SQLite. Nessun processo applicativo a esecuzione prolungata mantiene le bacheche in memoria, quindi il container resta quasi inattivo tra una richiesta e l'altra. Vikunja è un singolo binario Go da 110 MB e usa SQLite come database predefinito, quindi un solo container costituisce l'intero stack. Planka richiede 280 MB perché è sempre composto da due container: un server Node e PostgreSQL. Planka non supporta SQLite, quindi il database non è sostituibile.

Wekan si attesta su 750 MB perché è un'applicazione Meteor. Meteor mantiene in memoria Node un livello di query in tempo reale e invia ogni modifica della bacheca a tutti i browser aperti tramite WebSocket, quindi il consumo di memoria cresce con il numero di utenti connessi invece di restare stabile. Su una VPS da 1 GB Wekan si avvia, poi termina la prima volta che alcune persone aprono una bacheca di grandi dimensioni. Il sintomo è un container che scompare e ricompare con codice di uscita 137; docker compose ps lo mostra come un ciclo continuo di riavvii. Confermalo sull'host con dmesg -T | grep -i "out of memory", perché il killer del kernel per esaurimento della memoria non comunica mai nulla all'applicazione.

La dipendenza dal database determina metà del lavoro di backup, quindi ecco un riepilogo in una riga per ciascuno strumento. Planka richiede PostgreSQL. Vikunja usa SQLite per impostazione predefinita e supporta anche PostgreSQL e MySQL o MariaDB. Kanboard usa SQLite per impostazione predefinita e supporta anche MySQL, MariaDB e PostgreSQL; la documentazione raccomanda PostgreSQL e sconsiglia SQLite su NFS (network file system). Focalboard usa SQLite per impostazione predefinita. Wekan supporta il protocollo wire di MongoDB e il relativo file Compose predefinito ora include FerretDB v1 con un backend SQLite integrato invece di un server MongoDB reale; è disponibile un file Compose separato per MongoDB 7, se ne vuoi utilizzare uno.

Quali di questi progetti sono ancora mantenuti?

[
  {
    "tool": "Planka 2.1.1",
    "release_age": 109
  },
  {
    "tool": "Vikunja 2.5.0",
    "release_age": 1
  },
  {
    "tool": "Focalboard 8.0.0",
    "release_age": 783
  },
  {
    "tool": "Wekan 10.67",
    "release_age": 1
  },
  {
    "tool": "Kanboard 1.2.53",
    "release_age": 12
  }
]

Focalboard è l'eccezione, con 783 giorni. L'ultima release standalone, v8.0.0, risale a giugno 2024. Mattermost ha spostato lo sviluppo delle board in un plugin, in un repository separato, e il README standalone indica che il repository non è attualmente mantenuto. Questo è l'unico "no" evidente in questo confronto. Per tutto il resto si tratta di valutare i compromessi.

I 109 giorni di Planka indicano una situazione sana per un progetto che pubblica poche release all'anno. La versione 2.1.1 risale ad aprile 2026. Kanboard ha pubblicato v1.2.53 12 giorni prima della verifica, mentre le due release precedenti sono state pubblicate a marzo e aprile 2026.

Vikunja e Wekan hanno pubblicato entrambi una release entro un giorno dalla verifica, ma questi due dati vanno interpretati in modo diverso. Vikunja ha contrassegnato v2.5.0 come una normale release minor. Wekan ha contrassegnato v10.65, v10.66 e v10.67 lo stesso giorno, secondo la propria cadenza normale. Release frequenti non significano necessariamente un target stabile. Con Wekan scegliete di seguire un numero di versione che cambia rapidamente: bloccate il tag e leggete le note prima di ogni aggiornamento.

Oltre a una bacheca, cosa offre?

La maggior parte degli articoli comparativi si limita a dire che "assomiglia a Trello". Questo criterio incide sulla scelta più della RAM, perché una bacheca non è adatta a tutto ciò che ha una scadenza.

• Planka è esclusivamente uno strumento per bacheche: progetti, bacheche, elenchi, schede, etichette, checklist, commenti e allegati. Le viste calendario e mappa sono funzionalità Pro ad agosto 2026.
• Vikunja offre quattro viste sullo stesso insieme di attività: Elenco, Kanban, Tabella e Gantt. Un'attività esiste una sola volta; si cambia vista senza duplicarla.
• Kanboard offre bacheche con limiti sul lavoro in corso, sottoattività, allegati, commenti, azioni automatiche e un piccolo linguaggio di query per i filtri. La homepage del progetto afferma: "Il numero di funzionalità è limitato volutamente". È una descrizione corretta.
• Wekan offre bacheche con corsie, oltre a checklist, campi personalizzati, un'API REST (representational state transfer) e webhook.
• Focalboard offriva viste bacheca, tabella e calendario sulle stesse schede. È incluso qui per completezza.

Se ciò che serve realmente è un wiki con alcune funzionalità per il monitoraggio delle attività, questo confronto non è adatto. BookStack, Wiki.js e Outline tratta questo tipo di soluzione, mentre le alternative self-hosted a Notion trattano gli spazi di lavoro all-in-one.

Accesso multiutente e single sign-on

Planka supporta OpenID Connect nell’edizione gratuita Community. Il file Compose ufficiale contiene le impostazioni commentate, tra cui OIDC_ISSUER, OIDC_CLIENT_ID e OIDC_CLIENT_SECRET, quindi è sufficiente rimuovere i commenti senza eseguire un upgrade. I ruoli guest per le persone esterne alla propria organizzazione sono una funzionalità Pro.

Vikunja supporta OpenID Connect con più provider contemporaneamente. Impostare VIKUNJA_AUTH_OPENID_ENABLED=true, quindi aggiungere un blocco di variabili VIKUNJA_AUTH_OPENID_PROVIDERS_<ID>_* per ogni provider. Supporta anche team e condivisione per progetto, funzioni effettivamente necessarie in un’organizzazione di venti persone.

Wekan supporta LDAP (lightweight directory access protocol), OAuth2, OIDC e SAML. Kanboard include il supporto LDAP e offre un plugin OAuth2 generico per gli altri casi, oltre a ruoli e gruppi per progetto. Il server standalone di Focalboard non supporta alcuna funzione di single sign-on: questo è un secondo motivo per escluderlo.

Ognuna di queste soluzioni può essere abbinata a un identity provider Authentik gestito autonomamente, che di norma è una scelta migliore rispetto ad assegnare a venti persone una password separata per ogni applicazione.

È possibile importare le bacheche Trello?

Planka offre il percorso più semplice. Esporta la bacheca da Trello in formato JSON, crea una bacheca in Planka, fai clic su Import e scegli Trello. Leggi prima i limiti, perché sono effettivi: gli utenti e gli allegati non vengono importati, per ogni scheda viene trasferita una sola checklist e l’esportazione JSON predefinita di Trello si interrompe dopo 1,000 azioni senza segnalare il troncamento. Controlla personalmente il file prima di considerare affidabile il risultato.

Vikunja importa i dati tramite il flusso OAuth di Trello, in Settings, quindi "Import from other services". Ogni migratore deve essere abilitato nella configurazione prima che la relativa icona venga visualizzata e VIKUNJA_SERVICE_PUBLICURL deve essere corretto, perché il reindirizzamento OAuth avviene nel browser e non dal server. Vikunja importa anche dati da Todoist, Microsoft To Do, TickTick e Wekan.

Wekan accetta il JSON di una bacheca Trello incollato nel modulo di importazione. Kanboard non dispone di un importatore Trello integrato. Questo è il motivo principale per cui conviene evitarlo se devi trasferire anni di cronologia Trello.

Qual è l’esperienza da dispositivo mobile?

Vikunja è l’unico dei cinque progetti con app mobile ufficiali. Le versioni per Android e iOS vengono rilasciate insieme a ogni versione del software. Il repository dell’app la definisce alpha, quindi considerala un complemento dell’interfaccia web, non il principale punto di accesso. Planka non dispone di un’app ufficiale del progetto, ma la sua interfaccia web è responsive ed esistono client di terze parti. Wekan e Kanboard sono accessibili soltanto via web e l’interfaccia di Kanboard è chiaramente progettata per uno schermo desktop.

La questione della licenza e perché Planka è diverso

Planka non è più open source, ed è il fatto che la maggior parte dei confronti omette. È nato con licenza MIT, è passato ad AGPL-3.0 nel 2023 e, a partire dalla serie 2.0, viene distribuito con la PLANKA Community License, una licenza fair-code detenuta da PLANKA Software GmbH. GitHub indica la licenza come "Other" perché non è approvata da OSI. L'installazione self-hosted per i propri utenti è gratuita ed è esplicitamente consentita per uso personale, interno, non profit e didattico. La rivendita dell'accesso o l'erogazione del software come servizio per altre aziende richiede una licenza commerciale.

Per due persone è una condizione ragionevole. Per un'azienda è un termine da leggere prima che il lavoro di venti persone confluisca nel progetto. Gli altri quattro sono normali progetti open source: Vikunja è distribuito con licenza AGPL-3.0, Wekan e Kanboard con licenza MIT, mentre Focalboard utilizza una combinazione di Apache 2.0 e AGPL-3.0.

File Compose con versioni fissate per le due scelte

Fissa il tag dell’immagine. latest significa che il successivo docker compose pull può portarti a una versione principale diversa, e le versioni principali eseguono migrazioni del database che non puoi annullare facilmente. I due file riportati di seguito sono quelli upstream, con il tag fissato a una release reale.

Vikunja su SQLite, un container:

services:
  vikunja:
    image: vikunja/vikunja:2.5.0
    restart: unless-stopped
    environment:
      VIKUNJA_SERVICE_PUBLICURL: https://tasks.example.com
      VIKUNJA_SERVICE_SECRET: replace-with-a-long-random-string
      VIKUNJA_SERVICE_TIMEZONE: Europe/Berlin
      VIKUNJA_DATABASE_TYPE: sqlite
      VIKUNJA_DATABASE_PATH: /app/vikunja/files/vikunja.db
    ports:
      - "127.0.0.1:3456:3456"
    volumes:
      - ./files:/app/vikunja/files

Crea prima la directory dei dati con il proprietario corretto, perché il container viene eseguito con UID 1000 e non può scrivere in una directory di proprietà di root:

mkdir -p files && sudo chown 1000 files
docker compose up -d
docker compose ps
curl -sf http://127.0.0.1:3456/api/v1/info

In uno stack integro, il servizio risulta running e l'endpoint info restituisce JSON contenente un campo version. Un errore di connessione rifiutata in questo punto indica che il container è terminato. docker compose logs vikunja indica il motivo; la causa più comune è un errore di autorizzazioni sul file del database.

Planka su PostgreSQL, due container:

services:
  planka:
    image: ghcr.io/plankanban/planka:2.1.1
    restart: unless-stopped
    volumes:
      - data:/app/data
    ports:
      - "127.0.0.1:3000:1337"
    environment:
      - BASE_URL=https://boards.example.com
      - DATABASE_URL=postgresql://postgres@postgres/planka
      - SECRET_KEY=replace-with-openssl-rand-hex-64
    depends_on:
      postgres:
        condition: service_healthy

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

volumes:
  data:
  db-data:

POSTGRES_HOST_AUTH_METHOD=trust significa che PostgreSQL accetta qualsiasi connessione senza password. Questa configurazione è sicura solo perché la porta del database non viene pubblicata sull'host; l'unico elemento che può raggiungerla è quindi l'altro container sulla stessa rete Compose. Non aggiungere una voce ports: al servizio postgres.

Nessuno dei due stack deve essere esposto direttamente a Internet. Entrambi effettuano il bind su 127.0.0.1, quindi configura un reverse proxy davanti ai servizi e termina lì TLS (sicurezza del livello di trasporto). Traefik davanti a diverse applicazioni Compose è il metodo consueto quando ospiti più di un servizio, mentre la guida di base a Docker Compose descrive gli elementi di questi file che questa pagina non tratta.

La tua board è un database: esegui il backup

Uno strumento per gestire le board può non segnalare gli errori. Nessuno si accorge dell'assenza di un backup finché un volume non viene perso, mentre un file SQLite danneggiato può aprirsi normalmente e segnalare il problema solo database disk image is malformed settimane dopo.

Non copiare mai un file SQLite in uso con cp. La copia potrebbe acquisire una scrittura in corso. L'archivio sembrerebbe completo, ma il ripristino produrrebbe un database con alcune righe mancanti. Arresta il servizio per i pochi secondi necessari alla copia:

docker compose stop vikunja
tar czf vikunja-$(date +%F).tgz files
docker compose start vikunja

Per Planka, esegui il dump di PostgreSQL invece di copiare la directory dei dati di un cluster in esecuzione. Esegui inoltre separatamente il backup del volume degli upload, perché gli allegati non sono archiviati nel database:

docker compose exec -T postgres pg_dump -U postgres -Fc planka > planka-db.dump
docker volume ls
docker run --rm -v planka_data:/data -v "$PWD":/backup alpine \
  tar czf /backup/planka-files.tgz -C /data .

docker volume ls stampa il nome reale del volume. Il nome è quello del progetto Compose seguito da _data. Se passi un nome inesistente, viene creato un volume vuoto e viene prodotto un archivio valido ma vuoto, senza alcun errore. Controlla quindi le dimensioni del file al termine.

Esegui poi un ripristino una volta, in uno stack di test sullo stesso server, e apri una scheda che ricordi. Un backup mai ripristinato è solo un'ipotesi. Trasferisci gli archivi anche fuori dal server, perché una copia archiviata sul VPS che stai proteggendo non è un backup. backup restic da un VPS tratta questa parte.

Due raccomandazioni

Due persone su un VPS da 2 GB: usa Planka. È la soluzione più simile a Trello per aspetto e comportamento, l’importazione da Trello consiste in un file da trascinare nell’interfaccia e 280 MB di memoria a riposo lasciano libera la maggior parte dei 2 GB per il reverse proxy e per gli altri servizi che ospiti. La Community License copre senza costi un team interno di due persone. Se preferisci non dipendere da una licenza source-available, Vikunja su SQLite, con 110 MB, è la scelta open source per lo stesso server.

Venti persone in un’organizzazione: usa Vikunja su PostgreSQL. A questa scala servono OpenID Connect invece di venti password locali, i team e la condivisione per progetto; inoltre gran parte del lavoro non rientrerà in una board, quindi le viste List, Table e Gantt diventano una funzione importante, non un semplice extra. AGPL-3.0 elimina anche le discussioni sulla licenza quando aumenta il numero di utenti. Usa PostgreSQL invece di SQLite, pubblica il servizio dietro un reverse proxy e conserva il dump giornaliero su un sistema diverso da quel server.

Se il server ha meno di 1 GB di RAM, nessuna delle due opzioni è adatta. Scegli Kanboard con 70 MB, accetta di dover reinserire manualmente le schede di Trello e usa la memoria risparmiata per qualcos’altro tra le alternative self-hosted consigliate per il 2026. La procedura di installazione completa dello strumento scelto deve essere trattata in una guida dedicata. Questa pagina serve soltanto a scegliere.

FAQ

Quale alternativa self-hosted a Trello usa meno RAM?

Kanboard, con circa 70 MB in idle, perché è basato su PHP con SQLite e non mantiene dati in memoria tra una richiesta e l'altra. Segue Vikunja, con circa 110 MB, essendo un singolo binario Go. Wekan è il più pesante, con circa 750 MB, perché Meteor mantiene in memoria Node un livello di query live per ogni browser connesso. Misura il tuo ambiente con docker stats quando lo stack è in idle, perché questi sono valori tipici e non una garanzia.

Posso importare le bacheche Trello in uno strumento self-hosted?

Planka e Wekan accettano direttamente l'esportazione JSON di una bacheca Trello. Vikunja importa tramite il flusso OAuth di Trello, ma prima devi abilitare il migratore nella configurazione perché venga visualizzato nell'interfaccia. Kanboard non dispone di un importatore integrato. Considera questi due limiti: Planka non importa utenti o allegati e gestisce una sola checklist per scheda; inoltre, l'esportazione JSON predefinita di Trello si ferma a 1,000 azioni senza avvisare che i dati sono stati troncati.

Focalboard è ancora una scelta valida nel 2026?

No. L'ultima release standalone, v8.0.0, risale a giugno 2024, cioè 783 giorni prima della verifica di questo confronto, eseguita il 5 agosto 2026. Il README indica che il repository non è attualmente mantenuto. Mattermost ha continuato lo sviluppo delle bacheche soltanto come plugin in un repository separato, quindi la parte che puoi eseguire in self-hosting è quella il cui sviluppo si è fermato. Scegli invece Planka o Vikunja.

Planka è ancora open source?

Non secondo la definizione OSI. Planka era distribuito con licenza MIT, è passato ad AGPL-3.0 nel 2023 e dalla versione 2.0 in poi viene distribuito con PLANKA Community License. Il self-hosting è gratuito per uso personale, interno, non profit ed educativo. La rivendita dell'accesso o l'esecuzione come servizio per terze parti richiede una licenza commerciale; inoltre, la vista calendario, i ruoli guest e le schede ricorrenti sono disponibili nel livello Pro. Se una licenza approvata da OSI è un requisito inderogabile, Vikunja usa AGPL-3.0 e Kanboard usa MIT.

Mi serve PostgreSQL o SQLite è sufficiente?

Vikunja, Kanboard e Focalboard usano SQLite per impostazione predefinita, che è sufficiente per poche persone su un unico server. Planka richiede PostgreSQL e non offre un'opzione SQLite. Passa a PostgreSQL quando più persone devono scrivere contemporaneamente, perché SQLite serializza le scritture e un'istanza sotto carico inizia a restituire database is locked. Non collocare neppure un file SQLite su una condivisione di rete: la documentazione di Kanboard sconsiglia SQLite su NFS proprio per questo motivo.