Melhores alternativas ao Jira auto-hospedadas em 2026: OpenProject, Plane e Redmine

Se você executa o Jira Server em 2026, está executando software sem suporte. A Atlassian encerrou o suporte em 15 de fevereiro de 2024. Sem patches de segurança. Sem correções de bugs. Sem suporte do fornecedor.

Em 30 de março de 2026, a Atlassian deixou de aceitar novas assinaturas do Data Center de novos clientes. Clientes existentes podem continuar certas compras até 30 de março de 2028 e renovações até 28 de março de 2029, quando os produtos afetados passam a ser somente leitura conforme o cronograma de fim de vida do Data Center publicado pela Atlassian.

Então, e agora?

Existem três opções auto-hospedadas sérias que vale a pena comparar em 2026: OpenProject, Plane e Redmine. Este artigo compara-as por arquétipo de caso de uso em vez de uma lista de recursos, examina o Jira Migrator oficial do OpenProject, agora em beta para versões suportadas do Jira Server e do Data Center, e termina com o contraponto honesto: quando o Jira Cloud ainda é a resposta certa.

Se você está aqui porque "temos de migrar até 2029 e preciso conhecer as minhas opções reais", continue lendo. Se está aqui porque "quero uma tabela de pontuação com 47 colunas", há outros artigos para isso. Este não é um deles.

A versão curta

• O Jira Server já está sem suporte e o Jira Software Data Center está a ser descontinuado. As novas vendas de Data Center a novos clientes terminaram em 2026; as assinaturas existentes afetadas chegam ao fim de vida em 2029.
• Três caminhos auto-hospedados reais em 2026. OpenProject para equipas que querem um substituto com o formato do Jira e uma ferramenta de migração, Plane para equipas lideradas por engenharia que querem a UX do Linear sem a fatura de SaaS, Redmine para equipas que querem um rastreador de issues leve que funciona há duas décadas.
• O OpenProject tem um Jira Migrator integrado em beta para o Jira Server e o Data Center 10.x e 11.x, mas não para o Jira Cloud. As suas fontes oficiais estão neste momento dessincronizadas: o guia técnico de maio lista um conjunto de dados base mais restrito, ao passo que as páginas mais recentes de julho dizem que o Migrator também importa o histórico de issues, os comentários e os utilizadores e grupos envolvidos. Trate essas afirmações mais recentes como dependentes da versão e confirme-as num piloto sobre a versão exata do OpenProject que vai implementar. O Plane, por seu lado, anuncia uma importação controlada do Jira e apoio de migração personalizado para equipas com mais de 100 lugares. O Redmine não tem um caminho próprio comparável.
• O dimensionamento do VPS é modesto. As orientações oficiais começam o OpenProject e o Plane em 4 GB de RAM; o Plane recomenda 8 GB para produção. A imagem Redmine da Cloudzy indica 2 GB de RAM como mínimo.
• O Jira Cloud continua a ser o certo para algumas equipas, sobretudo as que não têm capacidade de operações. Os preços da Atlassian variam consoante o número de lugares e a periodicidade de faturação, por isso consulte a página de preços atual do Jira em vez de confiar numa tarifa antiga fixada à mão.

O relógio de contagem decrescente da Atlassian: o que está mesmo a acontecer

Três datas que acertam o relógio do Jira:

• 15 de fevereiro de 2024: a Atlassian encerrou o suporte ao Jira Server. Não são fornecidos suporte técnico, atualizações de segurança nem correções de bugs para produtos ou aplicações Server.
• 30 de março de 2026: a Atlassian deixou de vender novas assinaturas do Data Center e aplicações Marketplace para Data Center a novos clientes. Os clientes existentes ainda podem renovar.
• 28 de março de 2029: as assinaturas e aplicações Data Center afetadas expiram e passam a ser somente leitura. A Atlassian indica que pode haver manutenção alargada excecional para determinados clientes.

As equipas estão a reagir de cerca de três formas. Algumas migram para o Jira Cloud, pagam a fatura por lugar e aceitam a simplificação operacional. Outras vão adiando com renovações do Data Center até 2029 e tratam o prazo como um problema do seu eu futuro. Outras avaliam já alternativas auto-hospedadas para evitar tanto o preço como o prazo.

Se está no grupo dois ("logo se vê"), a avaliação honesta é que o "logo se vê" só é um problema de 2029 se, até lá, também não tiver mais nada no seu roteiro. A maioria das equipas que vi fazer isto acaba por migrar em pânico, porque o calendário anda mais depressa do que qualquer um espera.

Dica profissional: Se a sua equipa está no Server, só o risco de segurança já justifica tratar isto como um problema de 2026, e não de 2029. Rastreadores de issues sem suporte continuam a ser superfície de ataque e tendem a ficar em baixa prioridade nas revisões de segurança precisamente porque "funcionam sem dar trabalho".

Conclusão da seção: O relógio tem datas, é público e é oficial. Planeie em torno de 2026-2027, não de 2029.

Os três caminhos auto-hospedados realistas em 2026

O ecossistema open source tem dezenas de rastreadores de issues. Para uma comparação focada, este artigo cobre três caminhos distintos: OpenProject para gestão de projetos formal e com as ferramentas de migração mais diretas; Plane para um fluxo de trabalho de engenharia moderno; e Redmine para um rastreador maduro e extensível. Taiga, Tuleap, Kanboard e outros projetos podem continuar a encaixar melhor em requisitos mais restritos.

Eis o que cada um é realmente.

OpenProject

O OpenProject é uma aplicação Ruby on Rails apoiada em PostgreSQL. A Community Edition está sob GPLv3 e é gratuita para auto-hospedar; os planos pagos Enterprise on-premises acrescentam suporte e funcionalidades Enterprise.

O posicionamento de UX é utilitário e denso em funcionalidades. Parece software de gestão de projetos empresarial porque é isso mesmo. Bom suporte a gráficos de Gantt, relatórios formais de portefólio de projetos, colaboração baseada em BCF para construção e engenharia e fluxos de responsabilização das partes interessadas. Se a sua equipa alguma vez pediu "Gantt a sério" ou "dependências entre épicos de projetos diferentes", esta é a sua ferramenta.

A equipa ideal para o OpenProject é a que precisa que a cascata tradicional e o ágil coexistam na mesma instância, de relatórios formais para cima na hierarquia e de um caminho de migração oficial a partir de versões suportadas do Jira Server ou do Data Center. Falaremos do Migrator, e dos seus limites atuais, mais abaixo.

O ponto fraco é a curva de aprendizagem. Os membros da equipa que vêm do Jira Cloud ou do Linear vão dizer-lhe que o OpenProject parece pesado. Não estão enganados. Muitos conceitos centrais do Jira têm equivalentes no OpenProject, mas pode ser preciso ler a documentação para os encontrar.

O OpenProject está no o marketplace da Cloudzy como implantação com um clique, se quiser saltar a dança do Compose.

Plane

O Plane é um projeto mais recente, fundado em 2022. A sua distribuição auto-hospedada atual é uma implantação empacotada em Docker ou Kubernetes com vários serviços de aplicação mais PostgreSQL, Redis e armazenamento de objetos, em vez de uma simples pilha de cinco contentores.

• Serviços web e de API
• Workers em segundo plano
• PostgreSQL
• Redis
• Armazenamento de objetos

A Community Edition está licenciada sob AGPLv3.

O posicionamento de UX é abertamente inspirado no Linear. Ciclos, módulos, projetos, vistas. Moderno, rápido, com opinião própria. Se alguma vez gostou dos atalhos de teclado predefinidos do Linear ou do seu modelo de issues, o Plane vai parecer-lhe familiar numa hora.

A equipa ideal é liderada por engenharia: startups, equipas de produto independentes, pequenas casas de desenvolvimento em que os engenheiros são os utilizadores principais e a ferramenta de gestão de projetos é sobretudo um rastreador de issues mais um quadro de sprint. É aqui que o Plane brilha.

Há fraquezas reais a reconhecer. O projeto é mais novo do que os outros, o que significa um ecossistema de integrações menor e uma superfície de implantação que muda mais depressa. A sua licença AGPLv3 também merece análise antes de modificar o software para um serviço de rede comercial.

Em julho de 2026 o Plane não está no marketplace da Cloudzy, pelo que este exige a implantação própria do Plane em Docker ou Kubernetes no VPS que escolher. É gerível para uma equipa já à vontade com contentores, mas acrescenta mais configuração e manutenção do que uma imagem de um clique.

Redmine

O Redmine é o veterano. Primeira versão em 2006. Ruby on Rails, com backend MySQL ou PostgreSQL. GPLv2. Leve para os padrões atuais, em parte porque o núcleo é mesmo pequeno e em parte porque quase tudo o que as pessoas querem do Redmine chega através de plugins.

A UX é mais antiga. Não vale a pena fingir o contrário. O Redmine 7.0 tornou-se o ramo estável mais recente em junho de 2026, mas a interface predefinida continua a parecer tradicional. O tema Bleuclair moderniza o Redmine 6.1; verifique a compatibilidade do tema e dos plugins antes de passar para o Redmine 7. Se uma UX moderna for um requisito inegociável, veja o Plane.

A equipa ideal é a que já usa o Redmine, ou a que quer um rastreador de issues estável e leve, sem um fluxo de trabalho rígido imposto pela ferramenta. O ecossistema de plugins é enorme:

• Quadros ágeis
• Gantt
• Registo de tempo
• Integrações SCM
• Fluxos de trabalho personalizados

Se uma equipa tem uma necessidade específica de fluxo de trabalho, é provável que exista um plugin do Redmine para isso.

A fraqueza é dupla. A UX, como já vimos. E o próprio ecossistema de plugins, que é uma faca de dois gumes: os plugins resolvem problemas, mas criam dores de cabeça de compatibilidade de versões na altura da atualização. Uma instância do Redmine com oito plugins é uma instância em que cada atualização menor exige testes.

Uma nota para equipas que já usam o Redmine: se a única queixa é a UX e está no Redmine 6.1, o tema Bleuclair é uma experiência barata que pode eliminar a necessidade de migrar de plataforma. Teste-o primeiro e verifique a compatibilidade antes de qualquer atualização para o Redmine 7.

Conclusão da seção: Escolha por arquétipo. OpenProject para um substituto com o formato do Jira. Plane para a UX do Linear sem a fatura de SaaS. Redmine para rastreio de issues estável com um plugin para tudo.

Comparação Lado a Lado

Agora que cada ferramenta foi coberta em detalhe, vamos colocá-las num formato fácil de distinguir.

O Jira Migrator do OpenProject: o que faz realmente

Este é o detalhe que a maioria das comparações de 2026 salta ou remete para nota de rodapé. É também a razão de peso pela qual o OpenProject é a escolha mais natural para equipas atualmente em Jira.

O OpenProject disponibilizou o seu Jira Migrator em beta em 2026 como parte da Community Edition. Liga-se por API e com um Personal Access Token de administrador ao Jira Server ou Data Center 10.x e 11.x. O Jira Cloud não é atualmente suportado.

O que as páginas oficiais atuais do OpenProject dizem, no conjunto, que é importado:

• Projetos e identificadores de projeto
• Issues: resumo ou título, descrição, anexos, histórico, comentários, data de vencimento, horas estimadas e horas restantes; os identificadores de issue também são suportados em beta
• Utilizadores e grupos envolvidos, incluindo nomes, endereços de e-mail, pertença a projetos e pertença a grupos
• Campos personalizados suportados que tenham correspondência no OpenProject
• Estados e tipos de issue

O que deve continuar a considerar como não suportado:

• Relações entre issues e atribuições de sprint
• Fluxos de trabalho, permissões e esquemas ao nível do projeto
• Etiquetas, versões, componentes e outros campos não listados como cobertos devem ser considerados não suportados até que um piloto prove o contrário
• Jira Cloud, dados de aplicações do Marketplace, regras de automação e integrações externas

Dois detalhes operacionais importam tanto como a lista de campos. As importações caem primeiro num modo de revisão, e uma importação pode ser revertida enquanto ainda estiver em revisão. Assim que aprovar a importação, deixa de ser possível revertê-la. E como a cobertura ainda muda de versão para versão, consulte a documentação atual antes de cada migração.

Um modelo mental razoável: o Migrator em beta trata um conjunto crescente de dados essenciais de projeto, não um ambiente Jira completo. Planeie um piloto controlado e reserve tempo para reconstruir a lógica de fluxos de trabalho, permissões, aplicações e integrações não suportadas.

Nota: o guia técnico de 6 de maio do OpenProject lista um conjunto de dados mais restrito do que as páginas mais recentes de julho, que acrescentam histórico, comentários e utilizadores e grupos envolvidos. Como o Migrator continua em beta, confirme a cobertura na versão exata que vai implementar e teste-a num projeto Jira representativo antes da transição.

Um caminho de migração de alto nível mais seguro é assim:

1. Levante uma instância não produtiva do OpenProject num VPS (a imagem de um clique da Cloudzy serve, ou use os métodos de implantação suportados pelo OpenProject).
2. Confirme que a origem é Jira Server ou Data Center 10.x ou 11.x e crie depois um Personal Access Token de administrador.
3. Faça cópia de segurança da instância de teste do OpenProject e configure depois o Migrator com o URL do Jira e o token.
4. Execute um piloto sobre um projeto representativo e verifique identificadores de projeto, utilizadores, pertenças a grupos, estados, tipos de issue, campos personalizados suportados, anexos, histórico, comentários, datas de vencimento, estimativas e horas restantes.
5. Analise o piloto com cuidado. Enquanto a importação estiver em revisão, reverta-a se os mapeamentos estiverem errados; após a aprovação, essa importação já não pode ser revertida.
6. Planeie a migração de produção apenas depois de o piloto passar. Use uma janela de manutenção, congele as escritas no Jira, preserve as cópias de segurança e reconstrua à parte os fluxos de trabalho e integrações não suportados.

O Plane anuncia agora uma importação do Jira própria e controlada que mapeia projetos, issues, sprints, tipos de issue, estados, campos personalizados, comentários e anexos; equipas com mais de 100 lugares podem pedir apoio de migração dedicado. O caminho do Redmine continua menos direto, apoiando-se em plugins da comunidade ou fluxos com CSV que exigem testes contra versões e configurações exatas.

Conclusão da seção: O Migrator em beta do OpenProject suporta Jira Server/Data Center 10.x e 11.x, mas as suas fontes oficiais divergem quanto à cobertura atual. Valide a sua versão exata. O Plane oferece importação guiada; o Redmine não tem um caminho próprio comparável. Faça piloto do OpenProject e do Plane antes da produção.

Dimensionamento do VPS: o que cada ferramenta precisa mesmo

O custo de infraestrutura para auto-hospedar estas ferramentas é modesto. Fiabilidade, cópias de segurança, testes de restauro e monitorização pesam mais do que espremer a pilha no plano mais pequeno. A Cloudzy publica atualmente um SLA de uptime 99,95%, e os seus planos de VPS podem ser redimensionados à medida que o uso cresce.

Ponto de planeamento	OpenProject	Plane	Redmine
Recomendação inicial	4 núcleos, 4 GB de RAM	2 núcleos, 4 GB de RAM	A partir de 2 GB de RAM (imagem Cloudzy)
Nota de produção	Mínimo para servidor único; até 200 utilizadores no total	Recomenda 8 GB de RAM	Os plugins e a concorrência determinam a carga
Escale quando	As filas, a latência da base de dados ou a RAM sobem	Os serviços competem por RAM e CPU	A latência da base de dados ou a carga dos plugins sobe

Algumas notas que contam do ponto de vista operacional:

• O mínimo oficial do OpenProject para uma instalação em servidor único é um CPU de quatro núcleos, 4 GB de RAM e 20 GB de espaço livre em disco. O exemplo de instância pequena lista separadamente 2 núcleos de CPU e 4 GB de RAM para a aplicação, mais 2 núcleos de CPU e 4 GB de RAM para o PostgreSQL.
• Os requisitos oficiais de auto-hospedagem do Plane especificam um mínimo de 2 núcleos de CPU e 4 GB de RAM, com 8 GB recomendados para produção.
• A imagem Redmine da Cloudzy indica 2 GB de RAM como mínimo. Não converta isso num número garantido de utilizadores: são os plugins, o volume de anexos, os pedidos concorrentes e o comportamento da base de dados que determinam a capacidade real.

Como referência, o plano padrão de 4 GB da Cloudzy oferece 2 vCPU, 120 GB de armazenamento NVMe e 5 TB de tráfego. Cumpre o mínimo de RAM do OpenProject, mas não o mínimo oficial de quatro núcleos, por isso use um plano ou configuração personalizada com pelo menos 4 vCPU para o OpenProject. Monitorize a latência da base de dados, as filas de workers e a pressão de memória antes de escalar; não prometa um multiplicador de desempenho fixo apenas pelo tipo de armazenamento.

Construa num VPS Linux com acesso root, NVMe e o poder do AMD EPYC.

Ver planos Linux

Conclusão da seção: Aos preços de tabela padrão atuais da Cloudzy, antes de promoções, o Redmine pode começar perto de 15 $ por mês e o Plane perto de 29 $ por mês. O OpenProject exige pelo menos quatro núcleos de CPU no seu mínimo oficial, por isso calcule o preço a partir de uma configuração equivalente e não do plano de 2 vCPU e 4 GB.

Quando o Jira Cloud ainda é a resposta certa

Auto-hospedar troca dinheiro por tempo. Existe uma configuração de equipa em que o dinheiro vale mais do que o tempo que pouparia, e essa equipa deve pagar à Atlassian.

Preços de tabela do Jira Cloud em julho de 2026, retirados da página pública de preços da Atlassian (as tarifas são definidas pela Atlassian, variam consoante a periodicidade de faturação e o número de lugares e mudam sem aviso, por isso trate cada valor abaixo como um retrato de 2026 e confirme-o na página de preços atual do Jira antes de fazer o orçamento):

• Gratuito: até 10 utilizadores.
• Standard: around $8 per user per month as of mid-2026.
• Premium: around $14 per user per month as of mid-2026.
• Enterprise: contratos anuais, preços à medida.

At that rate, 25 seats total roughly $2,400 per year. A Cloudzy 4 GB VPS is $28.95 per month at standard list price, or about $347 per year before promotions. Jira Cloud's subscription is therefore roughly seven times the VPS infrastructure cost on those 2026 figures, but that comparison excludes operator time, backups, monitoring, paid support, and any Enterprise features.

Agora faça a pergunta honesta: quem vai assumir as cópias de segurança, os testes de restauro, as atualizações, a manutenção do Postgres, a monitorização, os certificados SSL, a criação de utilizadores e a resposta a incidentes? Compare a assinatura do Jira Cloud com o custo total de operar a pilha auto-hospedada, e não apenas com a fatura da VM. Se ninguém assumir esse trabalho, a poupança aparente pode desaparecer depressa.

O valor do Jira Cloud é sobretudo operacional. A Atlassian gere a plataforma, as atualizações, os patches e as cópias de segurança ao nível do serviço; a sua equipa continua responsável pelas políticas de acesso, integração de identidade, governação de aplicações e decisões de retenção de dados. Para uma equipa em que ninguém consegue operar uma pilha de gestão de projetos, essa camada gerida vale mesmo a pena.

Dito com franqueza: auto-hospedar serve a equipas que já têm um VPS a funcionar, contam com um engenheiro à vontade com Docker e têm capacidade para o trabalho operacional. O Jira Cloud serve a equipas onde ninguém quer ser quem é acordado porque o Postgres ficou sem espaço em disco.

Se não tem a certeza de que equipa é a sua, faça um piloto de duas semanas do OpenProject num VPS. Se a sua origem for uma versão suportada do Jira Server ou do Data Center, importe um projeto representativo com o Migrator em beta; o Jira Cloud ainda não é suportado. Ou a equipa adota a ferramenta e você fica a conhecer a carga operacional, ou a fatura do serviço gerido do Jira Cloud começa a parecer mais razoável.

Veredicto rápido

• Está a migrar de uma versão suportada do Jira Server ou do Data Center e quer um beta integrado de autosserviço: OpenProject. Valide a cobertura de campos específica da versão antes da produção.
• Equipa liderada por engenharia que quer UX moderna e uma importação guiada do Jira: Plane. Exige 4 GB de RAM, recomenda 8 GB para produção e oferece migração acompanhada a equipas com mais de 100 lugares.
• Já usa o Redmine e quer um rastreador de issues estável num VPS leve: fique no Redmine. Faça a experiência do tema Bleuclair antes de pensar em migrar.

LER

AFFiNE vs AppFlowy vs Docmost: Alternativas Self-Hosted ao Notion

Perguntas frequentes

O Jira Server ainda tem suporte em 2026?

Não. A Atlassian encerrou o suporte ao Jira Server em 15 de fevereiro de 2024. Quem o executa em 2026 está em software sem suporte e sem patches de segurança. Os novos clientes já não podem comprar o Jira Data Center, por isso os caminhos suportados realistas são o Jira Cloud ou uma alternativa mantida; os clientes existentes de Data Center podem continuar segundo o calendário de descontinuação publicado pela Atlassian.

Ainda posso comprar o Jira Data Center?

Não, não como cliente novo. A Atlassian parou as vendas de Data Center a novos clientes em 30 de março de 2026. Os clientes existentes podem comprar novas assinaturas, aplicações e expansões até 30 de março de 2028 e renovar assinaturas existentes até 28 de março de 2029. Depois disso, os produtos afetados passam a ser somente leitura, salvo se a Atlassian conceder uma extensão excecional.

Como migro do Jira para o OpenProject?

O Jira Migrator do OpenProject está atualmente em beta. Liga-se por API ao Jira Server ou Data Center 10.x e 11.x com um Personal Access Token de administrador; o Jira Cloud não é suportado. As páginas oficiais mais recentes de julho de 2026 indicam que importa projetos e identificadores; issues com descrições, anexos, histórico e comentários; utilizadores e grupos envolvidos; estados e tipos; e campos personalizados suportados. O guia técnico de maio do OpenProject ainda lista um conjunto mais restrito, por isso confirme a cobertura exata na versão que implementar. Fluxos de trabalho, permissões, esquemas, relações entre issues e atribuições de sprint continuam sem suporte ou no roteiro.

Qual é a alternativa ao Jira auto-hospedada mais barata?

Com base nos pontos de partida atualmente documentados, o Redmine na imagem de 2 GB da Cloudzy é a opção mais barata. O mínimo do OpenProject em servidor único é de quatro núcleos de CPU e 4 GB de RAM. O Plane exige 2 núcleos e 4 GB de RAM, com 8 GB recomendados para produção. As edições Community não acrescentam custos de licença de software, mas o suporte pago, as cópias de segurança, a monitorização e o tempo do operador continuam a contar.

O Plane é um substituto real do Jira?

Para equipas lideradas por engenharia, sim. A UX do Plane está mais próxima do Linear do que do Jira, e o seu modelo de issues adequa-se aos fluxos de trabalho de engenharia. O Plane documenta uma importação do Jira controlada que abrange projetos, issues ativas e do backlog, responsáveis, etiquetas, prioridades, sprints, tipos de issue, estados, campos personalizados, comentários e anexos. Também oferece migração acompanhada acima de 100 lugares, mas equipas com aplicações do Marketplace ou fluxos complexos devem, ainda assim, validar um piloto.

O Redmine tem uma ferramenta de migração do Jira?

Oficialmente não. Existem plugins de importação da comunidade e fluxos com CSV, mas a compatibilidade e a cobertura de dados variam consoante a versão do Jira e do Redmine. Teste o caminho exato com um projeto representativo. O OpenProject tem um Migrator integrado em beta para origens suportadas do Jira Server ou Data Center, enquanto o Plane oferece uma importação própria guiada.

Posso executar algum destes num VPS pequeno?

A imagem Redmine da Cloudzy indica 2 GB de RAM como mínimo, o que corresponde a 14,95 $ por mês ao preço de tabela padrão. O OpenProject exige pelo menos quatro núcleos de CPU e 4 GB de RAM. O Plane exige 2 núcleos e 4 GB de RAM, com 8 GB recomendados para produção. O plano padrão de 4 GB da Cloudzy tem 2 vCPU e está listado a 28,95 $ por mês, valor que as promoções por vezes reduzem. Executar os três no mesmo VPS pequeno não é um desenho de produção sensato.