Alternativas autoalojadas ao Trello: comparação

Que alternativa autoalojada ao Trello deve escolher?

Três alternativas autoalojadas ao Trello merecem a sua atenção: Planka, se quiser os quadros exatamente como no Trello e o respetivo ficheiro de importação; Vikunja, quando uma equipa precisa de início de sessão único e de mais do que um quadro; e Kanboard, quando o VPS (servidor privado virtual) tem poucos recursos. Não inicie um projeto novo no Focalboard. O seu servidor autónomo não tem uma nova versão há 783 dias, e o README pede agora um responsável pela manutenção.

O Wekan é a quinta das 5 ferramentas apresentadas aqui. Funciona, mas consome várias vezes mais memória do que todas as restantes. Todas as versões, licenças e datas abaixo foram verificadas em 5 de agosto de 2026.

De quanta RAM precisa cada ferramenta de quadros?

[
  {
    "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
  }
]

Estes são valores típicos em idle depois de uma instalação nova, sem utilizadores, do tipo de valor que docker stats apresenta um minuto depois de a stack arrancar. Use-os para dimensionar um plano e depois meça o seu próprio ambiente. A tendência é mais importante do que o número exato de megabytes. Se esse mesmo VPS também for utilizado para alojar a sua biblioteca de fotografias, dimensione primeiro essa parte, porque os requisitos mínimos em a comparação entre PhotoPrism e Immich são de outra ordem de grandeza. A ferramenta de quadros poderá então utilizar a memória restante.

Kanboard é o valor mínimo, com 70 MB, porque usa PHP com SQLite. Nenhum processo de aplicação de longa duração mantém os seus quadros na memória. Por isso, o contentor fica praticamente sem consumo entre pedidos. Vikunja é um único binário Go com 110 MB. SQLite é a sua base de dados predefinida. Assim, um único contentor constitui toda a stack. Planka precisa de 280 MB porque tem sempre dois contentores: um servidor Node e PostgreSQL. Planka não tem opção SQLite. Por isso, a base de dados não é opcional.

Wekan utiliza 750 MB porque é uma aplicação Meteor. O Meteor mantém uma camada de consultas em tempo real na memória do Node e envia cada alteração de um quadro para todos os browsers abertos através de um WebSocket. Por isso, o consumo de memória aumenta com o número de pessoas ligadas, em vez de permanecer estável. Num VPS com 1 GB, o Wekan arranca e depois termina na primeira vez que algumas pessoas abrem um quadro grande. O sintoma é um contentor que desaparece e volta a aparecer com o código de saída 137, que docker compose ps apresenta como um ciclo de reinício. Confirme no host com dmesg -T | grep -i "out of memory", porque o out-of-memory killer do kernel nunca informa a aplicação.

A dependência da base de dados determina metade do trabalho de backup. Resumo-a aqui numa linha por ferramenta. Planka requer PostgreSQL. Vikunja usa SQLite por predefinição e também suporta PostgreSQL e MySQL ou MariaDB. Kanboard usa SQLite por predefinição e também suporta MySQL, MariaDB e PostgreSQL. A documentação do Kanboard recomenda PostgreSQL e desaconselha SQLite em NFS (network file system). Focalboard usa SQLite por predefinição. Wekan suporta o protocolo wire do MongoDB. O seu ficheiro Compose predefinido agora inclui FerretDB v1 com um backend SQLite incorporado, em vez de um servidor MongoDB real. Também existe um ficheiro Compose separado para MongoDB 7, caso pretenda utilizá-lo.

Quais destes projetos ainda são mantidos?

[
  {
    "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
  }
]

O Focalboard é a exceção, com 783 dias. A sua última versão autónoma, v8.0.0, é de junho de 2024. O Mattermost transferiu o desenvolvimento dos quadros para um plugin num repositório separado, e o README autónomo indica que o repositório não é atualmente mantido. Esse é o único "não" claro nesta comparação. Nos restantes casos, há compromissos a considerar.

Os 109 dias do Planka são um bom sinal para um projeto que lança algumas versões por ano. A versão 2.1.1 é de abril de 2026. O Kanboard lançou a v1.2.53 12 dias antes da verificação, e as duas versões anteriores foram lançadas em março e abril de 2026.

O Vikunja e o Wekan lançaram versões no prazo de um dia da verificação, mas deve interpretar esses dois factos de forma diferente. O Vikunja marcou a v2.5.0 como uma versão menor normal. O Wekan marcou as versões v10.65, v10.66 e v10.67 no mesmo dia, que é o seu ritmo normal. Lançamentos frequentes não significam um alvo estável. Ao usar o Wekan, está a optar por acompanhar um número de versão que muda rapidamente. Por isso, fixe a tag e leia as notas antes de cada atualização.

Você obtém mais do que um quadro?

A maioria dos artigos de comparação fica por “parece o Trello”. Este critério é mais importante do que a RAM, porque um quadro é um formato inadequado para qualquer coisa com prazo.

• O Planka é apenas uma ferramenta de quadros: projetos, quadros, listas, cartões, etiquetas, listas de verificação, comentários e anexos. As visualizações de calendário e mapa são funcionalidades Pro desde agosto de 2026.
• O Vikunja oferece quatro visualizações para o mesmo conjunto de tarefas: lista, Kanban, tabela e Gantt. Uma tarefa existe uma vez, e pode mudar de visualização sem a duplicar.
• O Kanboard oferece quadros com limites de trabalho em curso, subtarefas, anexos, comentários, ações automáticas e uma pequena linguagem de consulta para filtrar. A própria página inicial diz “O número de funcionalidades é voluntariamente limitado”, uma descrição justa.
• O Wekan oferece quadros com raias, além de listas de verificação, campos personalizados, uma API REST (representational state transfer) e webhooks.
• O Focalboard oferecia visualizações de quadro, tabela e calendário para os mesmos cartões. Está incluído aqui para fins de completude.

Se o que pretende na realidade é um wiki com algum acompanhamento de tarefas associado, esta não é a comparação certa. BookStack, Wiki.js e Outline aborda esse formato, e as alternativas self-hosted ao Notion abrangem os espaços de trabalho completos.

Acesso multiutilizador e início de sessão único

O Planka suporta OpenID Connect na edição Community gratuita. O ficheiro Compose oficial inclui as definições comentadas, entre elas OIDC_ISSUER, OIDC_CLIENT_ID e OIDC_CLIENT_SECRET, pelo que basta retirar os comentários em vez de fazer uma atualização. As funções de convidado para pessoas fora da sua organização são uma funcionalidade Pro.

O Vikunja suporta OpenID Connect com vários fornecedores em simultâneo. Defina VIKUNJA_AUTH_OPENID_ENABLED=true e, em seguida, adicione um bloco de variáveis VIKUNJA_AUTH_OPENID_PROVIDERS_<ID>_* por fornecedor. Também inclui equipas e partilha por projeto, que é o que uma organização com vinte pessoas realmente precisa.

O Wekan suporta LDAP (protocolo ligeiro de acesso a diretórios), OAuth2, OIDC e SAML. O Kanboard inclui suporte para LDAP e um plugin OAuth2 genérico para os restantes casos, além de funções e grupos por projeto. O servidor autónomo do Focalboard não tem início de sessão único, o que constitui uma segunda razão para o excluir.

Qualquer uma destas opções pode ser integrada com um fornecedor de identidade Authentik gerido por si, que normalmente é uma solução melhor do que dar a vinte pessoas uma palavra-passe separada para cada aplicação.

É possível importar os seus quadros do Trello?

O Planka oferece o caminho mais simples. Exporte o quadro do Trello como JSON, crie um quadro no Planka, clique em Import e escolha Trello. Leia primeiro as limitações, porque são reais: os utilizadores e os anexos não são importados, apenas uma checklist por cartão é transferida, e a exportação JSON predefinida do Trello para nas 1,000 ações sem avisar que os dados foram truncados. Verifique o ficheiro manualmente antes de confiar no resultado.

O Vikunja importa através do fluxo OAuth do Trello, em Settings e depois em "Import from other services". Cada migrador tem de ser ativado na configuração antes de o respetivo ícone aparecer, e VIKUNJA_SERVICE_PUBLICURL tem de estar correto, porque o redirecionamento OAuth ocorre no seu browser e não no servidor. O Vikunja também importa dados do Todoist, Microsoft To Do, TickTick e Wekan.

O Wekan aceita um JSON de quadro do Trello colado no formulário de importação. O Kanboard não tem um importador Trello integrado, o que é o principal motivo para o excluir se tiver anos de histórico do Trello para migrar.

Como é a experiência em dispositivos móveis?

O Vikunja é o único dos cinco com aplicações móveis oficiais. As versões para Android e iOS são lançadas juntamente com cada versão, e o repositório da aplicação identifica-a como alpha. Por isso, trate-a como um complemento da interface Web, e não como a principal forma de acesso. O Planka não tem uma aplicação oficial do projeto, embora a sua interface Web seja responsiva e existam clientes de terceiros. O Wekan e o Kanboard funcionam apenas através da Web, e a interface do Kanboard foi claramente concebida para um ecrã de computador.

A questão da licença e por que o Planka é diferente

O Planka já não é open source, e este é o facto que a maioria das comparações omite. Começou com a licença MIT, passou para a AGPL-3.0 em 2023 e, a partir da série 2.0, é distribuído ao abrigo da PLANKA Community License, uma licença fair-code detida pela PLANKA Software GmbH. O GitHub apresenta a licença como "Other" porque essa licença não é aprovada pela OSI. A sua utilização self-hosted pela própria equipa é gratuita e explicitamente permitida, incluindo utilização pessoal, interna, sem fins lucrativos e educativa. A revenda do acesso ou a sua execução como serviço para outras empresas requer uma licença comercial.

Para duas pessoas, é um acordo razoável. Para uma empresa, é uma condição que deve ser analisada antes de o trabalho de vinte pessoas ser colocado na plataforma. As outras quatro opções são open source convencional: o Vikunja usa AGPL-3.0, o Wekan e o Kanboard usam MIT, e o Focalboard combina Apache 2.0 e AGPL-3.0.

Arquivos Compose fixados para as duas opções

Fixe a tag da imagem. latest significa que o próximo docker compose pull pode avançar para outra versão principal, e as versões principais executam migrações da base de dados que não pode reverter facilmente. Os dois ficheiros abaixo são os ficheiros upstream com a tag fixada numa versão real.

Vikunja com SQLite, um contentor:

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

Crie primeiro o diretório de dados com o proprietário correto, porque o contentor é executado como UID 1000 e não consegue escrever num diretório pertencente a 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

Uma stack saudável mostra o serviço como running, e o endpoint de informações devolve JSON que contém um campo version. Uma recusa de ligação neste ponto significa que o contentor terminou. docker compose logs vikunja indica o motivo, e um erro de permissões no ficheiro da base de dados é a causa mais comum.

Planka com PostgreSQL, dois contentores:

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 que o PostgreSQL aceita qualquer ligação sem palavra-passe. Isto só é seguro porque a porta da base de dados nunca é publicada no host. Assim, o único elemento que lhe pode ligar é o outro contentor na mesma rede Compose. Não adicione uma entrada ports: ao serviço postgres.

Nenhuma das duas stacks deve ficar diretamente exposta à Internet. Ambas fazem bind a 127.0.0.1, por isso coloque um reverse proxy à frente e termine o TLS (transport layer security) nesse ponto. Traefik à frente de várias aplicações Compose é a forma habitual de fazer isto quando aloja mais do que uma aplicação, e o guia básico do Docker Compose explica as partes destes ficheiros que esta página não aborda.

A sua ferramenta de boards é uma base de dados, por isso faça cópias de segurança

Uma ferramenta de boards pode falhar silenciosamente. Ninguém nota a falta de uma cópia de segurança até um volume desaparecer, e um ficheiro SQLite danificado pode abrir normalmente e só reportar database disk image is malformed semanas mais tarde.

Nunca copie um ficheiro SQLite em utilização com cp. A cópia pode capturar uma escrita em curso. O arquivo parece completo e é restaurado como uma base de dados com linhas em falta. Pare o serviço durante os poucos segundos necessários para a cópia:

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

No Planka, faça um dump do PostgreSQL em vez de copiar o diretório de dados de um cluster em execução. Faça também uma cópia separada do volume de uploads, porque os anexos não ficam na base de dados:

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 mostra o nome real do volume. Esse nome é o nome do projeto Compose seguido de _data. Se indicar um nome inexistente, será criado um volume vazio e obterá um arquivo válido, mas vazio, sem qualquer erro. Por isso, confirme o tamanho do ficheiro depois.

Depois, restaure a cópia uma vez numa stack temporária no mesmo servidor e abra um cartão de que se lembre. Uma cópia de segurança que nunca foi restaurada é apenas uma suposição. Envie também os arquivos para fora do servidor, porque uma cópia guardada no VPS que está a proteger não é uma cópia de segurança. cópias de segurança restic a partir de um VPS aborda essa parte.

Duas recomendações

Para duas pessoas num VPS com 2 GB: use Planka. É a opção mais próxima do Trello em aspeto e comportamento, a importação do Trello é um ficheiro que pode arrastar para a aplicação, e 280 MB de memória em repouso deixam a maior parte dos 2 GB disponível para o reverse proxy e para os restantes serviços alojados. A Community License abrange uma equipa interna de duas pessoas sem custos. Se preferir não depender de uma licença source-available, Vikunja com SQLite, com 110 MB, é a opção open source para o mesmo servidor.

Para vinte pessoas numa organização: use Vikunja com PostgreSQL. Nesse tamanho, precisa de OpenID Connect em vez de vinte palavras-passe locais, de equipas e de partilha por projeto. Além disso, grande parte do trabalho não caberá num quadro, pelo que as vistas List, Table e Gantt deixam de ser apenas um extra conveniente. A AGPL-3.0 também elimina discussões sobre licenciamento à medida que a equipa cresce. Use PostgreSQL em vez de SQLite, coloque o serviço atrás de um reverse proxy e mantenha o dump diário noutro local que não esse servidor.

Se o servidor tiver menos de 1 GB de RAM, nenhuma das respostas se aplica. Considere o Kanboard em 70 MB, aceite que terá de voltar a introduzir os seus cartões do Trello e use a memória poupada noutra opção de a lista de self-hosting para 2026. Se esse servidor já executar o Jellyfin, o Halcyon reconstrói a biblioteca como uma videolocadora dos anos 90 que pode percorrer, o que é um serviço mais interessante do que uma segunda ferramenta de quadros. A instalação detalhada da ferramenta escolhida deve ficar no seu próprio guia. Esta página serve apenas para fazer a escolha.

FAQ

Qual alternativa self-hosted ao Trello usa menos RAM?

O Kanboard, com cerca de 70 MB em estado ocioso, porque é PHP com SQLite e não mantém dados na memória entre pedidos. O Vikunja vem a seguir, com cerca de 110 MB, como um único binário Go. O Wekan é o mais pesado, com cerca de 750 MB, porque o Meteor mantém uma camada de consultas ativas na memória do Node para cada navegador ligado. Meça o seu próprio ambiente com docker stats quando a stack estiver ociosa, porque estes são valores típicos, não uma garantia.

Posso importar os meus quadros do Trello para uma ferramenta self-hosted?

O Planka e o Wekan aceitam diretamente a exportação JSON de quadros do Trello. O Vikunja importa através do fluxo OAuth do Trello, e o migrador tem de ser ativado na configuração antes de aparecer na interface. O Kanboard não tem um importador integrado. Há duas limitações a considerar: o Planka não importa utilizadores nem anexos e suporta apenas uma checklist por cartão; além disso, a exportação JSON predefinida do Trello para nas 1,000 ações sem avisar que os dados foram truncados.

O Focalboard ainda é uma boa escolha em 2026?

Não. A última versão standalone, v8.0.0, é de junho de 2024, ou seja, 783 dias antes de esta comparação ser verificada em 5 de agosto de 2026, e o README indica que o repositório não é atualmente mantido. O Mattermost continuou o desenvolvimento dos quadros apenas como plugin num repositório separado. Por isso, o servidor que poderia alojar por conta própria é a parte cujo desenvolvimento parou. Escolha antes o Planka ou o Vikunja.

O Planka ainda é open source?

Não segundo a definição da OSI. O Planka usava a licença MIT, mudou para AGPL-3.0 em 2023 e é distribuído sob a PLANKA Community License a partir da versão 2.0. O self-hosting é gratuito para utilização pessoal, interna, sem fins lucrativos e educativa. Revender o acesso ou disponibilizá-lo como serviço para terceiros exige uma licença comercial. A vista de calendário, as funções de convidado e os cartões recorrentes estão incluídos no nível Pro. Se uma licença aprovada pela OSI for um requisito obrigatório, o Vikunja usa AGPL-3.0 e o Kanboard usa MIT.

Preciso de PostgreSQL ou o SQLite é suficiente?

O Vikunja, o Kanboard e o Focalboard usam SQLite por predefinição. É suficiente para algumas pessoas num único servidor. O Planka exige PostgreSQL e não oferece uma opção SQLite. Mude para PostgreSQL quando várias pessoas fizerem operações de escrita em simultâneo, porque o SQLite serializa as escritas e uma instância ocupada começa a devolver database is locked. Também não coloque um ficheiro SQLite numa partilha de rede: a documentação do Kanboard desaconselha o uso de SQLite em NFS precisamente por este motivo.