Alternativas self-hosted ao Trello: comparação prática

Qual alternativa self-hosted ao Trello deve escolher?

Há três alternativas self-hosted ao Trello que merecem atenção: Planka se pretende o mesmo modelo de quadro do Trello e o respetivo ficheiro de importação, Vikunja quando uma equipa precisa de single sign-on e de mais do que um quadro, e Kanboard quando o VPS (virtual private server) é pequeno. Não comece um projeto novo no Focalboard. O seu servidor standalone não tem um release há 783 dias, e o README pede agora um maintainer.

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

De quanta RAM precisa cada ferramenta de quadro?

[
  {
    "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 numa instalação nova, sem utilizadores, semelhantes ao número que docker stats mostra um minuto depois de a stack arrancar. Use-os para dimensionar um plano e depois faça as suas próprias medições. O padrão de consumo é mais importante do que o valor exato em megabytes.

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, pelo que o contentor fica praticamente sem consumo entre pedidos. Vikunja é um único binário Go com 110 MB, e SQLite é a sua base de dados predefinida, portanto um contentor contém toda a stack. Planka precisa de 280 MB porque é sempre composto por dois contentores: um servidor Node e PostgreSQL. Planka não tem opção SQLite, pelo que a base de dados não é negociável.

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

A dependência da base de dados determina metade do trabalho de backup, por isso fica resumida numa linha para cada 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 recomenda PostgreSQL e desaconselha SQLite em NFS (network file system). Focalboard usa SQLite por predefinição. Wekan suporta o protocolo de rede do MongoDB, e o seu ficheiro Compose predefinido inclui agora 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. O seu último lançamento autónomo, 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 atualmente não é mantido. Este é o único "não" claro nesta comparação. Todos os restantes envolvem compromissos.

Os 109 dias do Planka são um valor saudável 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 que o alvo seja estável. Com o Wekan, está a escolher 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 limita-se a dizer que “parece o Trello”. Este critério é mais importante do que a RAM, porque um quadro é um formato inadequado para tudo o que tem um prazo.

• Planka é apenas uma ferramenta de quadros: projetos, quadros, listas, cartões, etiquetas, listas de verificação, comentários e anexos. As vistas de calendário e mapa são funcionalidades Pro desde August 2026.
• Vikunja oferece quatro vistas sobre o mesmo conjunto de tarefas: List, Kanban, Table e Gantt. Uma tarefa existe uma única vez, e muda-se de vista em vez de a duplicar.
• Kanboard é composto por quadros com limites de trabalho em curso, subtarefas, anexos, comentários, ações automáticas e uma pequena linguagem de consulta para filtragem. A própria página inicial afirma que “The number of features is voluntarily limited”, o que é uma descrição justa.
• Wekan é composto por quadros com swimlanes, além de listas de verificação, campos personalizados, uma API REST (representational state transfer) e webhooks.
• Focalboard oferecia vistas de quadro, tabela e calendário sobre os mesmos cartões. É incluído aqui para fins de completude.

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

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, por isso basta retirar os comentários, sem fazer upgrade. As funções para visitantes externos à 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 integrado 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 suporta início de sessão único, o que é uma segunda razão para o excluir.

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

Você pode importar 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 Importar e escolha Trello. Leia primeiro as limitações, porque elas são reais: usuários e anexos não são importados, apenas uma checklist por cartão é transferida, e a exportação JSON padrão do Trello para em 1,000 ações sem avisar que os dados foram truncados. Verifique o arquivo antes de confiar no resultado.

O Vikunja importa usando o fluxo OAuth do Trello, em Configurações e depois em "Importar de outros serviços". Cada migrador precisa estar habilitado na configuração antes que o respetivo ícone apareça, e VIKUNJA_SERVICE_PUBLICURL precisa estar correto, porque o redirecionamento OAuth acontece no seu navegador, 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 integrado do Trello. Esse é o principal motivo para evitá-lo se você 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 com cada versão, e o repositório da aplicação classifica-a como alpha. Por isso, considere-a um complemento da interface web, não a forma principal 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 estão disponíveis apenas na 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 sob a licença MIT, passou para a AGPL-3.0 em 2023 e, a partir da série 2.0, é distribuído sob a 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 instalação self-hosted para utilização pela própria equipa é gratuita e explicitamente permitida, abrangendo utilização pessoal, interna, sem fins lucrativos e educativa. A revenda do acesso ou a execução do 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 vinte pessoas começarem a trabalhar na plataforma. As outras quatro soluções são open source comum: o Vikunja usa AGPL-3.0, o Wekan e o Kanboard usam MIT, e o Focalboard combina Apache 2.0 com 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 levar a uma versão principal diferente, e as versões principais executam migrações da base de dados que não é fácil reverter. 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 com 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, a única origem que lhe pode ligar é o outro contentor na mesma rede Compose. Não adicione uma entrada ports: ao serviço postgres.

Nenhuma das 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 (segurança da camada de transporte) nesse ponto. Traefik à frente de várias aplicações Compose é a forma habitual de fazer isso 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 board é uma base de dados, por isso faça cópias de segurança

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

Nunca copie um ficheiro SQLite em utilização com cp. A cópia pode incluir uma operação de escrita em curso. O arquivo parece completo, mas é restaurado numa base de dados à qual faltam linhas. Pare o serviço durante os poucos segundos necessários para efetuar 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 armazenados 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 apresenta o nome real do volume. Esse nome é o nome do projeto Compose seguido de _data. Se indicar um nome inexistente, é criado um volume vazio e obtém um arquivo válido, mas vazio, sem qualquer erro. Por isso, verifique 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 armazenada 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 aparência e comportamento, a importação do Trello é feita com um ficheiro que arrasta para a aplicação, e 280 MB de memória em inatividade 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 com código disponível, o Vikunja com SQLite, usando 110 MB, é a opção open source para o mesmo servidor.

Para vinte pessoas numa organização: use Vikunja com PostgreSQL. Nessa dimensão, precisa de OpenID Connect em vez de vinte palavras-passe locais, de equipas e de partilha por projeto, e grande parte do trabalho não caberá num quadro. Por isso, 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 opções se aplica. Use Kanboard com 70 MB, aceite que terá de voltar a introduzir manualmente os cartões do Trello e use a memória poupada noutra finalidade de a lista de opções de self-hosting para 2026. O guia de instalação detalhado da ferramenta escolhida deve ser criado separadamente. Esta página serve apenas para fazer a escolha.

FAQ

Qual alternativa self-hosted ao Trello usa menos RAM?

O Kanboard, com aproximadamente 70 MB em idle, porque é PHP com SQLite e não mantém dados em 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 em tempo real na memória do Node para cada navegador ligado. Meça o seu próprio ambiente com docker stats quando a stack estiver em idle, porque estes são valores típicos e 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. Tenha em conta dois limites: 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 continua a ser uma boa escolha em 2026?

Não. A última release autónoma, v8.0.0, é de junho de 2024, ou seja, tinha 783 dias quando esta comparação foi verificada em 5 August 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 iria alojar deixou de ser mantido. Em alternativa, escolha o Planka ou o Vikunja.

O Planka continua a ser open source?

Não segundo a definição da OSI. O Planka usava a licença MIT, passou 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 uso pessoal, interno, sem fins lucrativos e educativo. A revenda de acesso ou a disponibilização como serviço para terceiros exige uma licença comercial. A vista de calendário, os papéis de convidado e os cartões recorrentes estão incluídos no plano Pro. Se for obrigatório usar uma licença aprovada pela OSI, 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, o que é suficiente para algumas pessoas num único servidor. O Planka exige PostgreSQL e não oferece uma opção SQLite. Passe para PostgreSQL quando várias pessoas escreverem ao mesmo tempo, 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.