Melhores sistemas wiki autohospedados para servidores

Escolher uma wiki não é apenas escolher um editor. A decisão define como as pessoas encontram informação, quem pode ler ou alterar cada área, como o conteúdo será copiado e restaurado e quanto trabalho o servidor exigirá daqui a cinco anos. Esta pesquisa compara 112 projetos utilizáveis, prioriza os que estão ativos e distingue wikis verdadeiras, bases de conhecimento colaborativas, documentação gerada a partir de Git e cadernos pessoais. O foco é prático: instalar em servidor próprio, proteger com senha, controlar permissões, personalizar, manter e migrar.

Resumo executivo

Não existe um vencedor absoluto. Para a maioria das instalações, a lista curta é esta:

1. BookStack é a recomendação geral para família, pequena empresa e equipe não técnica: editor agradável, organização previsível em estantes/livros/capítulos/páginas e permissões por função e conteúdo.
2. DokuWiki é a escolha mais leve e simples de recuperar: PHP, arquivos de texto, sem banco de dados e grande ecossistema de plugins. É excelente em VPS pequena, mas sua aparência e edição exigem mais ajustes.
3. Wiki.js equilibra interface moderna, Markdown, múltiplos métodos de autenticação e regras por caminho. É uma excelente wiki privada moderna, desde que se aceite Node.js e banco.
4. XWiki é a mais customizável como plataforma: campos estruturados, aplicações dentro da wiki, extensões, direitos detalhados e integração empresarial. Em troca, Java e sua amplitude elevam consumo e administração.
5. MediaWiki continua imbatível para uma enciclopédia pública grande, com discussão, histórico, categorias, templates e moderação. Para uma wiki privada simples, costuma exigir mais configuração e cuidado especial com anexos.
6. Docmost oferece a experiência moderna mais próxima de Notion/Confluence entre os projetos abertos recentes. É promissor e ativo, mas parte dos recursos empresariais fica na edição Enterprise.
7. Outline entrega excelente experiência editorial para equipes, porém é source-available, não software livre clássico, e a implantação envolve PostgreSQL, Redis e armazenamento de objetos; deve-se revisar quais recursos pertencem à licença Business.
8. TiddlyWiki é extraordinário para uso pessoal e portabilidade: pode ser um único arquivo HTML. Não é a primeira opção para edição simultânea por uma equipe.
9. MkDocs com Material é excelente para documentação pública versionada em Git, rápida e barata de servir. Não é uma wiki de edição direta: editar requer arquivos, Git e reconstrução.
10. Otter Wiki e Pepperminty Wiki são alternativas mínimas para quem quer Markdown, autenticação simples e poucos recursos.

Respostas diretas às perguntas principais

Recomendação objetiva: comece uma prova de conceito com BookStack, DokuWiki e Wiki.js. Acrescente XWiki se permissões, SSO ou dados estruturados forem essenciais; acrescente MkDocs Material se o conteúdo for documentação técnica mantida em Git. A melhor escolha é aquela em que três usuários reais conseguem criar, localizar, restringir, exportar e restaurar conteúdo sem depender do administrador.

Metodologia e critérios

A pesquisa foi concluída em 7 de setembro de 2026. Foram consultados sites, documentação, repositórios, páginas de lançamentos e instruções de instalação oficiais. Projetos foram classificados como ativo, maduro/estável, ativo com ritmo baixo, jovem ou legado. “Ativo” não garante longevidade; significa apenas que havia sinais públicos recentes de desenvolvimento, lançamento ou manutenção na data da verificação.

Os critérios usados foram:

• Natureza: wiki genuína, knowledge base, documentação estática ou caderno pessoal.
• Operação: número de serviços, banco, imagem de contêiner, atualização e facilidade de backup.
• Peso qualitativo: mínimo, leve, médio ou pesado. Não é benchmark; depende de tráfego, indexação, anexos, JVM, banco e configuração.
• Privacidade: login local, bloqueio de leitura anônima, proteção de anexos e compatibilidade com proxy de autenticação.
• Permissões: global, por espaço/coleção/livro/caminho/página e integração com grupos.
• Edição: WYSIWYG, Markdown, wikitext, edição simultânea, histórico e busca.
• Customização: temas, plugins, APIs, templates e dados estruturados.
• Portabilidade: formato em disco, exportação, API, Git e facilidade de restauração.
• Licença: software livre, open core ou source-available. Recursos anunciados podem variar entre Community e Enterprise.

As estimativas de facilidade e peso são avaliações editoriais, não promessas dos projetos. Para não inflar a lista, projetos claramente encerrados foram deixados numa seção histórica curta, fora dos 112 recomendáveis.

Antes de escolher: quatro produtos diferentes chamados “wiki”

Wiki colaborativa verdadeira

Permite criar e ligar páginas no navegador, guarda histórico, compara revisões, mantém páginas órfãs e recentes e normalmente oferece discussão, categorias ou backlinks. Exemplos: MediaWiki, DokuWiki, XWiki e PmWiki.

Base de conhecimento colaborativa

Privilegia editor visual, coleções, permissões, comentários, busca e organização de equipe. Pode ser melhor que uma wiki clássica para procedimentos internos, mas menos livre na estrutura. Exemplos: BookStack, Docmost, Outline e SiYuan.

Documentação estática

Transforma Markdown/AsciiDoc em HTML. O resultado é rápido, seguro e fácil de publicar, mas autores normalmente editam por Git e aguardam uma construção. Exemplos: MkDocs, Docusaurus, VitePress e Antora. Uma senha deve ser aplicada no proxy ou no provedor de identidade; o HTML em si não possui ACL por página.

Caderno pessoal/publicador

É otimizado para uma pessoa, notas interligadas ou um pequeno grupo. Pode ser extremamente leve, mas não deve ser confundido com intranet multiusuário. Exemplos: TiddlyWiki, SilverBullet, TriliumNext e Memos.

Ranking dos 20 sistemas mais fortes

1. BookStack — melhor equilíbrio para começar

Tipo e estado: base de conhecimento/wikidocs madura e ativa; licença MIT. Stack: PHP/Laravel e MySQL ou MariaDB. Peso: leve a médio. Instalação: documentação manual e imagens comunitárias amplamente usadas; exige banco, cron e cuidado com chaves/volumes.

O BookStack reduz a ambiguidade com uma hierarquia fixa de estantes, livros, capítulos e páginas. Possui editor visual, Markdown opcional, pesquisa, anexos, histórico e exportação. A documentação de permissões descreve funções e restrições de conteúdo, úteis para separar áreas familiares, departamentos ou clientes. Suporta autenticação local e integrações documentadas como LDAP, SAML2 e OIDC.

Por que escolher: aprendizado curto, interface clara, boa privacidade e administração compreensível. Customização: temas básicos, editor de tema e API; menor ecossistema que MediaWiki/DokuWiki. Limitações: a hierarquia rígida incomoda quem quer uma teia livre de páginas; é preciso validar exportação de anexos e restaurar banco + uploads + .env juntos. Público ideal: família, associação, escola, PME e manuais internos.

2. DokuWiki — mais seguro para uma VPS pequena

Tipo e estado: wiki clássica madura e ativa; GPL-2.0. Stack: PHP e arquivos de texto, sem banco. Peso: leve. Instalação: copiar arquivos e executar instalador; Docker costuma vir de mantenedores terceiros.

O DokuWiki armazena páginas em texto e oferece ACL, histórico, namespaces, busca e centenas de plugins. O controle de acesso permite restringir leitura, edição, criação, upload, exclusão e administração por usuário/grupo e namespace. Pode ser totalmente privado.

Por que escolher: poucas peças, backup legível, recuperação simples e ampla customização. Limitações: sintaxe própria por padrão, interface conservadora e qualidade variável dos plugins. Uma atualização deve incluir teste de compatibilidade do template e extensões. Público ideal: homelab, documentação de rede, wiki familiar, pequenas equipes e máquinas com pouca RAM.

3. Wiki.js — melhor wiki moderna e flexível

Tipo e estado: wiki moderna ativa; AGPL-3.0. Stack: Node.js e banco SQL, com PostgreSQL como escolha natural. Peso: médio. Instalação: Docker e múltiplas plataformas são documentados.

O Wiki.js combina editor Markdown/visual, histórico, busca, temas, módulos e autenticação local ou externa. Seu modelo de grupos e regras de página permite retirar acesso do grupo Guest, tornar toda a wiki privada e liberar caminhos específicos a departamentos. A documentação lista módulos de autenticação.

Por que escolher: visual atual, boa combinação de conteúdo técnico e equipe, ACL por caminho e integrações. Customização: módulos, renderizadores, temas e armazenamento remoto. Limitações: a versão 3 permaneceu por longo período como grande transição; verifique a versão estável e o caminho de upgrade antes de adotar. Público ideal: equipe técnica, intranet moderna e documentação de produtos.

4. XWiki — mais customizável e empresarial

Tipo e estado: wiki e plataforma de aplicações madura e ativa; LGPL-2.1. Stack: Java, servlet container e banco relacional. Peso: pesado. Instalação: pacotes, Docker e distribuição standalone.

O XWiki combina WYSIWYG, histórico, anexos, espaços aninhados, direitos, extensões e dados estruturados. Seu diferencial são classes, objetos e scripts que permitem construir catálogos, formulários e pequenos aplicativos dentro da wiki. O guia de direitos cobre níveis de acesso e herança; o Extension Manager amplia a plataforma.

Por que escolher: requisitos complexos, intranet, SSO e customização profunda. Limitações: JVM, banco, indexação e grande superfície administrativa; exige mais RAM, atualização planejada e governança. Público ideal: empresa, universidade e organização que quer transformar a wiki em sistema de informação.

5. MediaWiki — melhor para enciclopédia pública

Tipo e estado: wiki clássica de referência, madura e muito ativa; GPL-2.0-or-later. Stack: PHP e MariaDB/MySQL ou PostgreSQL. Peso: médio, escalável com caches. Instalação: pacotes, tarball e contêiner oficial.

O MediaWiki oferece revisão, namespaces, categorias, templates, páginas de discussão, moderação, internacionalização e um enorme catálogo de extensões. Os direitos de usuário podem ser alterados por grupos; extensões ampliam ACL e SSO.

Privacidade: é possível retirar leitura anônima, mas a própria documentação alerta que uploads podem continuar acessíveis por URL direta sem img_auth.php ou arquitetura equivalente. Por que escolher: enciclopédia, comunidade pública, muito conteúdo e workflows de revisão. Limitações: editor e templates têm curva de aprendizagem; ACL fina não é seu caso mais simples. Público ideal: projetos públicos, glossários extensos e comunidades.

6. Docmost — melhor alternativa aberta e moderna a Notion/Confluence

Tipo e estado: knowledge base colaborativa jovem e muito ativa; AGPL-3.0 no núcleo, com recursos Enterprise comerciais. Stack: Node.js, PostgreSQL e Redis. Peso: médio. Instalação: Docker Compose oficial.

O Docmost oferece editor visual colaborativo, espaços, comentários, histórico, pesquisa, diagramas e permissões. A página de preços e edições deve ser lida com atenção: SSO empresarial, MFA ou controles avançados podem variar conforme a edição.

Por que escolher: experiência moderna, colaboração em tempo real e implantação clara. Limitações: projeto mais novo, mais serviços que BookStack e fronteira Community/Enterprise. Público ideal: startups, equipes de produto e substituição gradual do Confluence.

7. Outline — melhor experiência editorial, com ressalva de licença

Tipo e estado: knowledge base ativa, source-available sob BSL para versões atuais. Stack: Node.js, PostgreSQL, Redis e armazenamento compatível com S3 ou local conforme configuração. Peso: médio. Instalação: Docker, porém requer mais variáveis e integração.

O Outline é polido, rápido e orientado a coleções, busca, colaboração e integrações. A documentação de hospedagem explica dependências e autenticação. Confira a licença no repositório e a matriz entre edição comunitária e comercial.

Por que escolher: adoção fácil pelos usuários e excelente editor. Limitações: não é FOSS clássico, configuração inicial maior e alguns recursos corporativos podem exigir licença. Público ideal: equipe que valoriza UX e aceita essas condições.

8. TiddlyWiki — melhor wiki pessoal portátil

Tipo e estado: caderno não linear maduro e ativo; BSD-3-Clause. Stack: HTML/JavaScript em arquivo único ou Node.js. Peso: mínimo. Instalação: abrir um arquivo; servidor Node para uso contínuo.

O TiddlyWiki guarda pequenos “tiddlers” interligados, filtros, campos, macros e plugins. É radicalmente customizável e pode viajar num único HTML. Autenticação e multiusuário dependem do servidor escolhido; TiddlyWiki on Node.js não equivale, sozinho, a colaboração empresarial.

Limitações: conflitos e edição concorrente; arquivo único grande pode ficar pesado. Público ideal: uma pessoa, pesquisa, diário técnico, catálogo e publicação portátil.

9. BlueSpice — MediaWiki pronto para empresa

Tipo e estado: distribuição empresarial ativa baseada em MediaWiki; GPL/open core. Stack: PHP, banco, busca e serviços auxiliares. Peso: pesado. Instalação: pacotes e Docker conforme edição.

O BlueSpice adiciona editor visual, workflows, qualidade, busca, administração e permissões ao MediaWiki. Por que escolher: organização que quer a semântica MediaWiki com pacote corporativo e suporte. Limitações: arquitetura maior e recursos que variam entre Free e Pro. Público ideal: empresa e setor público.

10. Tiki Wiki CMS Groupware — maior conjunto integrado

Tipo e estado: wiki/CMS/groupware madura e ativa; LGPL-2.1. Stack: PHP e banco SQL. Peso: médio a pesado. Instalação: web tradicional e contêineres comunitários.

O Tiki reúne wiki, fóruns, trackers, formulários, arquivos, calendário, workflows e dezenas de recursos ativáveis. Customização: excepcional sem juntar muitos plugins. Limitações: interface e administração densas; excesso de recursos para uma wiki simples. Público ideal: associação ou intranet que deseja suíte integrada.

11. PmWiki — clássico flat-file configurável

O PmWiki é PHP, GPL-3.0, flat-file, leve e maduro. Possui grupos de páginas, senhas e “cookbook” de extensões. É mais simples que MediaWiki e mais programável que aparenta. Limitações: visual antigo e configuração textual. Ideal para servidor pequeno e administradores confortáveis com PHP.

12. MoinMoin — tradição Python, nova geração ainda exige avaliação

O MoinMoin é uma wiki Python histórica. A linha 1.9 é legada; o Moin2 moderniza arquitetura e continua sendo a referência a avaliar. Oferece ACL e extensibilidade, mas sua implantação e maturidade relativa pedem uma prova de conceito cuidadosa. Ideal para comunidades Python que já conhecem o projeto.

13. Gollum — melhor para wiki que já é um repositório Git

O Gollum é Ruby, MIT, ativo e usado como mecanismo das wikis do GitHub. Lê vários formatos e registra páginas em Git. É leve a médio e simples para equipes técnicas. Autenticação/ACL geralmente ficam no proxy ou numa camada externa; não é a melhor solução para departamentos com permissões distintas.

14. Gitit — wiki Git com Pandoc

O Gitit é Haskell, GPL, usa Git e Pandoc e aceita muitos formatos. É atraente para texto técnico e exportação. Possui contas e configuração, mas seu ritmo é mais baixo e a operação Haskell pode ser menos familiar. Ideal para autores técnicos que valorizam formatos e histórico Git.

15. Otter Wiki — Markdown simples com login

O Otter Wiki é uma wiki Markdown pequena, em Python/Flask, com armazenamento Git, autenticação e Docker. É leve, legível e adequada a uso pessoal/familiar. Limitações: ACL e ecossistema menores que os líderes. Ideal para quem quer “instalar e escrever” sem uma plataforma pesada.

16. Pepperminty Wiki — wiki realmente mínima

O Pepperminty Wiki é um único arquivo PHP, MPL-2.0, modular e muito leve. Tem login, proteção e módulos. Limitações: menor comunidade, menos integração corporativa e cuidado extra ao atualizar arquivo/configuração. Ideal para VPS minúscula, laboratório e wiki pessoal.

17. Foswiki — wiki estruturada para intranet

O Foswiki deriva do TWiki e combina páginas com formulários, consultas, macros e plugins. Perl, GPL, maduro e de ritmo conservador. Permissões e autenticação são fortes, mas a interface e a operação refletem sua linhagem. Ideal para organizações que precisam de dados estruturados sem adotar XWiki.

18. Ikiwiki — publicação estática com semântica de wiki

O Ikiwiki converte páginas versionadas em Git em site estático e possui plugins, backlinks e edição web opcional. Perl, GPL e leve. A superfície pública é segura e barata; edição/autenticação requer configuração cuidadosa. Ideal para documentação e sites duráveis, não para colaboração visual em tempo real.

19. MkDocs + Material — melhor documentação técnica estática

O MkDocs gera documentação de Markdown; o tema Material for MkDocs adiciona navegação, busca e recursos editoriais. Python, BSD/MIT conforme componente, ativo e leve no servidor, pois a saída é HTML. Senha: aplicar no proxy/SSO ou publicar em ambiente privado. Limitações: sem edição web, ACL por página ou colaboração simultânea nativas. Ideal para manuais de software e documentação versionada.

20. SilverBullet — caderno Markdown programável

O SilverBullet é uma aplicação autohospedável, aberta, baseada em Markdown, com links, consultas e automações. Instalação por binário/contêiner e consumo leve a médio. Autenticação é simples; para múltiplos papéis, use solução mais forte. Ideal para uma pessoa ou pequeno grupo técnico que deseja arquivos portáveis e extensibilidade.

Matriz comparativa dos principais

Escala editorial: 1 = fraco/difícil; 5 = excelente/fácil. “Privado” significa capacidade prática de exigir login, não auditoria formal.

Catálogo ampliado: 92 alternativas adicionais

As opções abaixo completam 112 sistemas avaliados. “Ativo baixo” indica manutenção esporádica ou comunidade pequena; não significa necessariamente inseguro. Antes de instalar, confira a data do último release, issues de segurança e compatibilidade com sua versão de linguagem/banco.

Wikis clássicas, estruturadas e CMS com wiki

Markdown, Git e documentação estática

Knowledge bases, notas e colaboração moderna

Wikis pessoais, flat-file e minimalistas

Ferramentas de nicho que podem ser a wiki certa

Nota sobre a contagem: os 112 itens são projetos utilizáveis, mas alguns são CMS, gestores documentais, editores colaborativos ou publicadores estáticos — estão identificados assim para não serem confundidos com motores wiki completos.

Os mais leves

Nível mínimo: arquivo único ou HTML estático

1. Feather Wiki: praticamente nenhum backend; ideal para uma pessoa.
2. TiddlyWiki: um HTML ou Node simples; enorme poder por megabyte.
3. Pepperminty Wiki: um arquivo PHP; login e módulos.
4. W: PHP e arquivos; multiusuário básico.
5. MkDocs/VitePress/Zola: depois do build, apenas arquivos estáticos.

Leves, mas apropriados para servidor contínuo

1. DokuWiki: melhor combinação de leveza, ACL e maturidade.
2. PmWiki: flat-file e senhas, com visual tradicional.
3. Otter Wiki: Markdown/Git, Python e Docker.
4. Memos: binário/contêiner simples e SQLite para notas rápidas.
5. Fossil: um binário reúne repositório, wiki e tickets.

Em uma VPS de 1 GB, prefira DokuWiki, PmWiki ou conteúdo estático. BookStack pode funcionar com dimensionamento cuidadoso, mas banco e PHP-FPM disputam memória. Wiki.js/Docmost/Outline/XWiki ficam mais confortáveis com margem superior, especialmente durante atualização, indexação e importação. Isso é orientação, não requisito oficial.

Os mais fáceis de instalar e administrar

Os mais customizáveis

1. XWiki: dados estruturados, scripts, aplicações, extensões e temas.
2. MediaWiki + Semantic MediaWiki/Cargo: templates, módulos, extensões e consultas.
3. Tiki: dezenas de módulos integrados e trackers sem montar uma colcha de plugins.
4. DokuWiki: plugins e templates sobre base simples e legível.
5. TiddlyWiki: filtros, macros, widgets, campos e plugins no próprio documento.
6. Foswiki/TWiki: formulários, macros e aplicações wiki estruturadas.
7. Drupal/Wagtail: não são wikis puras, mas permitem modelar um portal editorial sob medida.
8. Geradores estáticos: liberdade visual total para desenvolvedor, pouca customização pelo editor comum.

Customização tem custo: cada plugin é dependência, superfície de ataque e teste de upgrade. Prefira recursos nativos quando o sistema será administrado por uma só pessoa.

Senha, privacidade e permissões

Três modelos de proteção

Contas internas: a aplicação cadastra usuários e guarda hashes de senha. É o modelo mais simples para BookStack, DokuWiki ou Wiki.js. Exija senhas longas, bloqueie cadastro público e teste recuperação.

SSO: OIDC, SAML ou LDAP centraliza entrada e desligamento. É preferível em empresa, mas uma falha no provedor pode bloquear todos. Mantenha uma conta administrativa local de emergência, protegida e testada, se o produto permitir.

Proteção no proxy: Authelia, Authentik, Keycloak, oauth2-proxy, Caddy Security ou Basic Auth podem proteger toda a aplicação. Isso é valioso para geradores estáticos e apps sem ACL. Contudo, o aplicativo enxerga todos como uma pessoa, a menos que aceite cabeçalhos de identidade; não há autoria nem permissão por página automaticamente.

Ranking para wiki privada

1. Wiki.js: grupo Guest removível e regras por caminho.
2. BookStack: funções e restrições em estantes/livros/capítulos/páginas.
3. XWiki: direitos por wiki/espaço/página e grupos; exige entender herança.
4. DokuWiki: ACL por namespace/página, simples de auditar.
5. Docmost/Outline: coleções/espaços modernos e compartilhamento; confirmar edição/licença.
6. BlueSpice: forte para corporação, mas maior operação.
7. MediaWiki: grupos excelentes; confidencialidade fina e anexos exigem desenho cuidadoso.

Teste obrigatório de privacidade

Antes de colocar dados reais, crie usuários visitante, familia, financeiro e admin; depois teste, em janela anônima e por URL direta:

• página, histórico, diff, versão antiga e impressão;
• busca, sugestões, índice, recentes, tags e sitemap;
• imagem, PDF, miniatura e URL original do upload;
• exportação, API, RSS/Atom, preview Open Graph e cache do proxy;
• página movida ou excluída e arquivos que permaneceram no armazenamento;
• convite vencido, usuário removido e sessão já aberta.

Se qualquer recurso vazar título ou conteúdo, a wiki ainda não está pronta para dados confidenciais.

Recomendações por cenário

Família e casa

Use BookStack se todos editarão pelo navegador; DokuWiki se o administrador prioriza recuperação; Mealie para receitas; TiddlyWiki para coleção individual. Crie livros como Casa, Saúde, Equipamentos e Receitas, mas evite guardar senhas e segredos: use um gerenciador de senhas.

Homelab e servidor pequeno

Use DokuWiki. Ele documenta IPs, serviços, procedimentos e inventário sem depender de outro banco. Alternativas: Otter Wiki para Markdown/Git e Fossil quando a documentação acompanha scripts. Não armazene a única cópia do procedimento de recuperação dentro do servidor que ele descreve.

Pequena empresa

Use BookStack; teste Wiki.js se caminhos livres, Markdown e autenticação forem mais importantes. Organize papéis por função, não por pessoa. Desative compartilhamentos públicos e faça revisão trimestral de acesso.

Empresa com SSO e departamentos

Avalie XWiki, BlueSpice, Wiki.js, Docmost Enterprise e Outline. A prova deve incluir OIDC/SAML/LDAP, desligamento de funcionário, grupos sincronizados, logs, exportação, retenção e suporte. Compare o custo de operação com a edição comercial, não apenas a licença.

Enciclopédia pública ou comunidade

Use MediaWiki. DokuWiki é alternativa menor. Planeje antispam, CAPTCHA, moderação, rate limiting, licenças do conteúdo, política de privacidade e cópias públicas. Separar usuários públicos de administradores reduz risco.

Documentação de software

Use MkDocs Material para Python/Markdown simples, Docusaurus para React e versões, Antora para múltiplos repositórios AsciiDoc, Sphinx para referência técnica e VitePress/Starlight para front-end moderno. Edição passa por pull request; isso é vantagem quando revisão e rastreabilidade importam.

Pesquisa e conhecimento pessoal

Use TiddlyWiki, SilverBullet, TriliumNext, SiYuan, Zim ou Emanote/Quartz. Escolha arquivos legíveis e exportação antes de escolher grafo bonito.

Segurança e operação

Arquitetura mínima recomendada

Internet → DNS → proxy reverso com TLS → wiki em rede interna → banco/armazenamento não expostos. Abra apenas 80/443; redirecione HTTP para HTTPS; não publique PostgreSQL, MariaDB ou Redis. Use firewall, atualizações automáticas apenas quando o projeto as suporta com segurança, e alertas de falha de backup.

TLS e proxy reverso

Caddy, Traefik ou Nginx podem terminar TLS. Configure cabeçalhos X-Forwarded-*, limite de upload, WebSocket quando houver colaboração ao vivo e IP real conforme documentação. HSTS só deve ser ativado quando todos os subdomínios estão prontos. Nunca confie cegamente em cabeçalhos de identidade vindos da internet; aceite-os apenas do proxy conhecido.

Segredos e conta administrativa

• Guarde chaves e senhas em secret files/manager, não no Compose versionado.
• Use senha exclusiva e MFA quando disponível.
• Desative registro aberto e contas padrão.
• Mantenha conta de emergência offline para falha do SSO.
• Revogue sessões e tokens ao remover usuário.
• Restrinja instalação de plugins e edição de HTML/JavaScript.

Plugins e temas

Instale o mínimo. Antes de cada upgrade, inventarie plugin, versão, origem e última atualização. Extensões abandonadas são o principal motivo para ficar preso em versões antigas. Faça clone de homologação e teste login, edição, upload, busca, exportação e restauração.

Backups que realmente funcionam

Um backup de wiki deve conter:

1. banco consistente ou dump transacional;
2. anexos/uploads e conteúdo flat-file;
3. configuração, chaves de criptografia e segredo de sessão necessários;
4. lista de plugins/temas e versões;
5. configuração do proxy, DNS e IdP;
6. procedimento escrito de restauração.

Use a regra 3-2-1, criptografe cópias externas e teste restauração em máquina separada. Snapshot de volume enquanto o banco escreve pode ser inconsistente; use o método indicado pelo banco. Para DokuWiki, copie todos os diretórios de dados/configuração preservando permissões. Para BookStack, restaure banco, uploads e APP_KEY de forma coordenada.

Atualizações

Assine releases e avisos de segurança. Não use a tag Docker latest sem registrar a versão implantada. Leia notas de migração, faça backup, teste em clone, atualize uma versão suportada por vez e valide tarefas em segundo plano. Tenha rollback claro, mas não faça rollback de banco sem restaurar snapshot compatível.

Migração e prevenção de aprisionamento

Formatos preferíveis

Markdown e texto plano são mais fáceis de reutilizar, mas podem perder comentários, ACL, histórico, IDs, macros e anexos. Exportações HTML/PDF preservam leitura, não estrutura. XML/JSON/API preservam mais semântica, mas exigem conversor.

Checklist de exportação

• exportar todas as páginas, inclusive arquivadas e versões antigas;
• mapear usuários/grupos sem transportar hashes inseguros;
• baixar anexos originais e relacioná-los às páginas;
• preservar redirects, slugs, links internos e datas;
• converter macros/templates para sintaxe de destino;
• gerar relatório de links quebrados e páginas órfãs;
• manter a wiki antiga somente leitura durante validação;
• registrar licença e autoria do conteúdo.

Teste migração com 50 páginas representativas, não com duas páginas simples. Inclua tabela grande, diagrama, código, acentos, anexos, links relativos, permissão restrita e histórico.

Roteiro de prova de conceito em 14 dias

Dias 1–2: requisitos e candidatos

Defina número de usuários, conteúdo público/privado, RAM, SSO, editor, hierarquia, anexos e retenção. Selecione BookStack, DokuWiki e Wiki.js; acrescente XWiki ou MkDocs conforme o cenário.

Dias 3–5: implantação isolada

Crie subdomínios de teste, TLS, volumes separados e versões fixadas. Não importe dados confidenciais. Registre tempo de instalação, serviços, portas e consumo em repouso.

Dias 6–8: conteúdo realista

Importe/crie 50 páginas, 100 anexos, tabelas, links e código. Convide três perfis de usuário. Meça tempo para criar, localizar, corrigir e reorganizar conteúdo.

Dias 9–10: segurança

Execute o teste anônimo de páginas, anexos, API, feeds e cache. Teste bloqueio, redefinição de senha, MFA/SSO, revogação e logs. Faça varredura de configuração e revise dependências.

Dias 11–12: backup e desastre

Apague deliberadamente o ambiente de teste e restaure em novo host. Registre duração, itens perdidos e passos manuais. Se não restaurou, o candidato não passou.

Dias 13–14: usuários e decisão

Peça aos usuários para executar cinco tarefas sem ajuda. Pontue facilidade, busca, edição, organização, permissão, backup, exportação e custo. Escolha pelo menor custo de cinco anos, não pela tela inicial mais bonita.

Planilha de decisão recomendada

Projetos históricos que não devem iniciar uma implantação nova

Use esta lista para reconhecer nomes antigos e planejar migração, não para escolher servidor novo: UseModWiki, MoinMoin 1.9, CodiMD (migrar para HedgeDoc), GitBook CLI legado, WikkaWiki, ScrewTurn Wiki, FlexWiki, JSPWiki antigo sem manutenção local, Instiki, PukiWiki em instalações desatualizadas, Oddmuse em ambientes sem mantenedor e Wikispaces (serviço encerrado). Alguns ainda rodam com estabilidade, mas a ausência de manutenção, compatibilidade ou comunidade eleva o risco.

Recomendações práticas

1. Instale BookStack, DokuWiki e Wiki.js em paralelo com dados fictícios.
2. Se a VPS tiver pouca memória ou você quiser o backup mais compreensível, comece por DokuWiki.
3. Se usuários não técnicos são prioridade, comece por BookStack.
4. Se deseja caminhos livres, Markdown e autenticação variada, teste Wiki.js.
5. Se precisa modelar formulários, dados e aplicações ou integrar uma grande empresa, faça POC com XWiki.
6. Para conteúdo público mantido por desenvolvedores, use MkDocs Material, Docusaurus ou Antora em vez de forçar uma wiki.
7. Não coloque senhas, chaves privadas ou tokens na wiki. Use Bitwarden/Vaultwarden, KeePassXC ou outro cofre apropriado.
8. Fixe versões, automatize backup, teste restauração e documente a própria wiki fora dela.
9. Prefira contas individuais e grupos; use senha única no proxy apenas para conteúdo de baixo risco e poucos usuários.
10. Reavalie projeto, versão, plugins e permissões a cada seis meses.

Conclusão

Para um servidor comum e sem requisitos ainda fechados, BookStack é o ponto de partida mais seguro para pessoas, DokuWiki é o ponto de partida mais seguro para operação, e Wiki.js é o ponto de partida mais equilibrado para uma experiência moderna. XWiki vence em customização e controle empresarial; MediaWiki vence em enciclopédia pública; MkDocs Material vence em documentação técnica versionada; TiddlyWiki vence em conhecimento pessoal portátil.

A decisão não deve ser tomada pelo número de funções. Uma wiki só é boa quando as pessoas escrevem nela, encontram o que precisam e o administrador consegue restaurá-la. A prova de conceito com dados representativos, quatro perfis de acesso e restauração em host limpo vale mais do que qualquer tabela comparativa.

Fontes consultadas

• MediaWiki — site oficial
• MediaWiki — direitos de usuários
• MediaWiki — autorização de imagens e anexos
• DokuWiki — documentação oficial
• DokuWiki — controle de acesso
• DokuWiki — catálogo de plugins
• BookStack — documentação oficial
• BookStack — funções e permissões
• BookStack — autenticação
• Wiki.js — site oficial
• Wiki.js — instalação
• Wiki.js — grupos e permissões
• Wiki.js — autenticação
• XWiki — site e documentação
• XWiki — direitos de acesso
• XWiki — extensões
• Docmost — site oficial
• Docmost — documentação
• Docmost — código-fonte
• Outline — documentação de self-hosting
• Outline — repositório e licença
• TiddlyWiki — documentação oficial
• BlueSpice — documentação
• Tiki — documentação oficial
• PmWiki — documentação
• MoinMoin — projeto
• Moin2 — repositório
• Gollum — repositório oficial
• Gitit — repositório oficial
• Otter Wiki — repositório oficial
• Pepperminty Wiki — repositório oficial
• Foswiki — site oficial
• Ikiwiki — site oficial
• MkDocs — documentação oficial
• Material for MkDocs — documentação
• SilverBullet — documentação
• Awesome-Selfhosted — catálogo de wikis
• WikiMatrix — comparação de mecanismos

Nota sobre atualidade

Pesquisa concluída em 7 de setembro de 2026. Versões, licenças, edições Community/Enterprise, recursos de autenticação e estado de manutenção podem mudar; confirme as informações nas fontes oficiais antes de instalar ou tomar decisões importantes.