O Linux foi banido no Brasil?

O texto da Lei nº 15.211/2025 (ECA Digital), o decreto regulamentador de março de 2026 e a repercussão técnica que gerou esse pânico digital.

Vou direto ao ponto: Dizer que o Linux foi "banido" no Brasil é Fake News. Não existe qualquer artigo na lei que proíba o uso, a distribuição ou a posse do sistema operacional Linux. O que existe é um desafio de conformidade técnica que foi interpretado de forma sensacionalista.

Abaixo, apresento o parecer jurídico e técnico sobre a situação:

1. O que a Lei realmente diz?

O ECA Digital (Lei 15.211/2025) foca na proteção de menores contra conteúdos inadequados e coleta predatória de dados. No seu Artigo 12, ela estabelece obrigações para:

Provedores de redes sociais;

Lojas de aplicativos (como Play Store ou Apple Store);

Sistemas operacionais de terminais.

A lei exige que esses entes ofereçam mecanismos de verificação de idade (proibindo a autodeclaração simples) e ferramentas de controle parental.

2. Por que surgiu o rumor do "Banimento"?

O problema não é uma proibição, mas a responsabilidade civil e financeira.

Projetos de software livre, como o Arch Linux 32 ou o MidnightBSD, são mantidos por voluntários e não possuem CNPJ ou recursos para implementar APIs caras de verificação de identidade (como as que exigem biometria ou checagem de documentos).

Temendo multas que podem chegar a R$ 50 milhões por infração, alguns projetos menores decidiram, por conta própria, bloquear o acesso de IPs brasileiros aos seus sites de download como medida preventiva de "segurança jurídica". Foi uma decisão dos desenvolvedores estrangeiros, e não uma ordem do governo brasileiro.

3. O Linux vai parar de funcionar?

Absolutamente não.

Grandes Distribuições: Empresas como a Canonical (Ubuntu) e a Red Hat possuem corpo jurídico e financeiro para se adequar ou negociar termos com a ANPD (Autoridade Nacional de Proteção de Dados).

Infraestrutura Nacional: O próprio Governo Brasileiro é um dos maiores usuários de Linux (em servidores, urnas eletrônicas e datacenters). Banir o Linux seria paralisar o Estado brasileiro e a internet nacional, o que é juridicamente e logicamente impossível.

Uso Pessoal: Você pode continuar usando a sua distro Linux preferida normalmente. A lei regula o fornecedor do serviço, não pune o usuário final por ter o sistema instalado.

Títulos Sensacionalistas no YouTube

Os títulos "Linux banido" são exemplos clássicos de clickbait. Eles pegam um fato real (a dificuldade técnica de pequenos projetos de código aberto em cumprir uma lei de verificação de idade) e o transformam em uma catástrofe inexistente para gerar visualizações.

Resumo do Parecer

Aspecto Analisado	Realidade Jurídica (Pós-Regulamentação 2026)
O Linux foi proibido?	Não. O sistema continua legal. A lei foca em mecanismos de proteção de menores, não na proibição de kernels ou arquiteturas de software livre.
Por que há bloqueios?	Auto-bloqueio preventivo. Alguns projetos internacionais (sem representação no Brasil) bloquearam IPs brasileiros para evitar multas de até R$ 50 milhões, por não possuírem infraestrutura de verificação de idade.
Uso em Servidores e Urnas	Garantido. O Linux é a base da infraestrutura crítica do Estado Brasileiro. Bani-lo seria tecnicamente impossível e juridicamente nulo por ferir a continuidade do serviço público.
Risco ao Usuário Final	Zero. As sanções do ECA Digital são administrativas e direcionadas aos fornecedores e distribuidores que não implementarem controle parental, nunca ao cidadão que utiliza o sistema.
Veredito sobre os Rumores	Fake News / Clickbait. Títulos que afirmam "Linux Banido" distorcem um desafio de compliance técnico transformando-o em uma proibição estatal inexistente.

Considerações finais

Não há motivo para pânico. O Linux continua sendo legal e amplamente utilizado no Brasil. O que estamos presenciando é o "atrito" entre uma legislação nova e o modelo de desenvolvimento descentralizado do software livre, algo que será ajustado via regulamentação administrativa nos próximos meses.

Para quem deseja se aprofundar e evitar cair em armadilhas de engajamento, a recomendação é uma só: leia o texto da regulamentação na íntegra. Ao analisar o documento oficial, fica evidente que os vídeos no YouTube com títulos como "Linux banido no Brasil" ou similares são puramente sensacionalistas e clickbait. Eles exploram o medo da comunidade técnica para gerar visualizações, distorcendo um desafio de conformidade em uma proibição que nunca existiu.

Referência

Governo do Brasil

Guia Offical

Feito!

Maven vs Gradle em projetos Java: Qual escolher?

No ecossistema Java, ferramentas de build automation são fundamentais para compilar código, gerenciar dependências, executar testes e gerar artefatos como JAR ou WAR. As duas ferramentas mais utilizadas são Apache Maven e Gradle.

Ambas resolvem o mesmo problema, automatizar o ciclo de build de aplicações Java, porém utilizam abordagens diferentes.

No presente artigo vamos analisar:

• O que são Maven e Gradle
• Como cada um funciona
• Prós e contras
• Quando usar cada ferramenta em projetos Java

O que é Maven?

Apache Maven é uma ferramenta de build criada pela Apache Software Foundation e lançada em 2004.

Seu principal objetivo é padronizar o processo de build em projetos Java.

Ele utiliza um arquivo chamado pom.xml (Project Object Model) onde são declarados:

• dependências
• plugins
• versão do projeto
• configuração de build
• repositórios

Exemplo do arquivo pom.xml para o projeto Spring Framework 7 com Java 21 + JUnit + cobertura mínima de 80%

pom.xml

O Maven segue o princípio Convention over Configuration, ou seja, ele já possui uma estrutura padrão:

src/main/java
src/main/resources
src/test/java
src/test/resources

Essa padronização facilita a colaboração entre equipes.

O que é Gradle?

Gradle surgiu em 2012 como uma alternativa mais flexível e performática ao Maven.

Ele utiliza uma DSL baseada em Groovy ou Kotlin para definir o build.

Exemplo de arquivo build.gradle para o projeto Spring Framework 7 e Java 21 + JUnit + cobertura mínima de 80%:

build.gradle

O Gradle foi projetado para:

• builds mais rápidos
• maior flexibilidade
• melhor suporte a projetos complexos

Hoje ele é amplamente usado em projetos modernos, incluindo o build padrão do Android Studio.

Diferenças conceituais

Característica	Maven	Gradle
Configuração	XML (pom.xml)	DSL baseada em Groovy ou Kotlin
Filosofia	Convention over Configuration	Alta flexibilidade e customização
Performance	Mais lento em builds grandes	Mais rápido com incremental build e cache
Curva de aprendizado	Mais simples para iniciantes	Maior devido à DSL programável
Customização	Limitada via plugins	Muito alta, com scripts programáveis

Prós do Maven

1. Padronização

O Maven impõe uma estrutura padrão para projetos.

Isso facilita:

onboarding de novos desenvolvedores

manutenção de projetos

integração entre equipes

2. Ecossistema maduro

O Maven possui milhares de plugins prontos.

Exemplos:

compilação

geração de documentação

análise de código

empacotamento

3. Simplicidade conceitual

Apesar do XML ser verboso, o modelo é simples:

clean
compile
test
package
install
deploy

Esse ciclo é chamado de build lifecycle.

4. Alta adoção corporativa

Muitas empresas utilizam Maven em aplicações enterprise, especialmente em projetos baseados em:

• Spring Framework
• Spring Boot
• aplicações legadas Java

Contras do Maven

1. XML verboso

Configurações simples podem virar arquivos grandes.

Exemplo comum: pom.xml com centenas de linhas.

2. Customização limitada

Criar pipelines complexos pode ser difícil.

3. Performance menor

Comparado ao Gradle, o Maven:

• recompila mais coisas
• possui menos otimizações

Prós do Gradle

1. Build mais rápido

Gradle implementa várias otimizações:

• incremental build
• build cache
• execução paralela

Isso reduz bastante o tempo de build em projetos grandes.

2. DSL mais expressiva

A configuração é escrita em Groovy ou Kotlin, permitindo:

• lógica condicional
• loops
• funções
• scripts reutilizáveis
3. Melhor para projetos grandes

Gradle funciona muito bem com:

• monorepos
• microservices
• builds multi-módulo
4. Flexibilidade extrema

É possível construir praticamente qualquer pipeline de build.

Contras do Gradle

1. Curva de aprendizado maior

Desenvolvedores precisam entender:

• Groovy ou Kotlin
• conceitos de tasks
• lifecycle do Gradle
2. Menos padronização

Como tudo pode ser customizado, projetos podem ficar inconsistentes entre equipes.

3. Debug de build mais complexo

Scripts muito dinâmicos podem dificultar troubleshooting.

Maven vs Gradle em projetos reais

Na prática, a escolha depende do tipo de projeto.

Use Maven quando:

• o projeto é corporativo tradicional
• a equipe prefere padronização
• builds não são extremamente complexos
• onboarding rápido é importante

Use Gradle quando:

• o projeto é grande ou modular
• erformance de build é crítica
• pipelines precisam de customização
• o projeto envolve Android

Tendências do ecossistema Java

Nos últimos anos, Gradle tem crescido bastante, especialmente em projetos modernos.

Entretanto, Maven ainda domina grande parte do mercado corporativo devido à sua estabilidade e padronização.

Ou seja:

• Maven -> estabilidade e padrão
• Gradle -> flexibilidade e performance

Considerações finais

Tanto Apache Maven quanto Gradle são excelentes ferramentas de build para projetos Java.

A escolha correta depende de fatores como:

• complexidade do projeto
• tamanho da equipe
• necessidade de customização
• tempo de build

Em termos simples:

• Maven é previsível e padronizado
• Gradle é poderoso e flexível

Um engenheiro de software moderno deve conhecer ambos, pois cada um continua sendo amplamente utilizado nas empresas.

Feito!

Entendendo o git worktree na prática

No dia a dia de engenharia de software, especialmente em projetos com múltiplas features, hotfixes e revisões paralelas, é comum enfrentar um problema recorrente: alternar entre branches sem quebrar o estado do workspace. Tradicionalmente, isso envolve stash, commits temporários ou até múltiplos clones do mesmo repositório. O git worktree resolve esse problema de forma elegante e eficiente.

No presente artigo, vamos entender o conceito, os benefícios arquiteturais no fluxo de trabalho e um exemplo prático que conecta teoria e prática.

O que é git worktree

git worktree é um recurso do Git que permite ter múltiplos diretórios de trabalho (working directories) associados ao mesmo repositório local. Cada diretório pode estar ligado a uma branch diferente, compartilhando o mesmo histórico e objetos Git.

Em termos técnicos:

• Um único repositório .git
• Vários diretórios de trabalho independentes
• Cada diretório com sua própria branch ativa

Isso elimina a necessidade de:

• Fazer checkout constante
• Clonar o repositório várias vezes
• Usar stash com frequência

O problema que o worktree resolve

Imagine um cenário comum em equipes de desenvolvimento.

Você está trabalhando em:

• feature nova
• correção de bug urgente
• revisão de Pull Request

Sem worktree, o fluxo geralmente é:

1. Commit parcial ou stash
2. Checkout de outra branch
3. Resolver a tarefa
4. Voltar para a branch original
5. Aplicar stash
6. Resolver conflitos eventuais

Isso gera:

• perda de foco
• risco de conflitos
• overhead mental
• contexto misturado

Em projetos grandes (monorepos, microsserviços, projetos com CI/CD pesado), isso impacta diretamente a produtividade.

Benefícios do git worktree

1. Paralelismo no desenvolvimento

Você pode trabalhar em múltiplas branches ao mesmo tempo.

Exemplo:

repo/
 ├── main-workspace
 ├── feature-pagamentos
 ├── hotfix-producao
 

Cada diretório tem sua branch ativa.

2. Redução de conflitos e erros

Ao evitar stash frequente e mudanças de branch no mesmo diretório, diminui:

• arquivos modificados esquecidos
• conflitos inesperados
• commits acidentais
3. Ideal para revisão de código

Você pode abrir uma branch de PR sem interromper o trabalho atual.

4. Excelente para testes de versões

Muito útil quando você precisa rodar duas versões do sistema:

• versão atual
• nova feature

Exemplo típico em backend:

• API executando versão estável
• nova implementação em paralelo
5. Performance melhor que múltiplos clones

Porque:

• objetos Git são compartilhados
• apenas o workspace muda

Isso economiza:

• disco
• tempo de clone
• download de dependências

Estrutura interna (como o Git organiza isso)

Quando você cria um worktree, o Git registra internamente:

.git/worktrees/

Cada worktree tem:

• referência da branch
• HEAD independente
• index próprio

Mas todos compartilham:

• histórico
• objetos
• commits

Isso torna o mecanismo extremamente eficiente.

Quando usar git worktree na prática

Situações ideais:

Desenvolvimento paralelo de features

Quando duas tarefas estão em andamento ao mesmo tempo.

Hotfix urgente

Você não quer interromper sua feature atual.

Revisão de Pull Requests

Abrir o PR localmente sem bagunçar o ambiente atual.

Testes de refatoração grande

Manter uma branch estável rodando.

Monorepos grandes

Especialmente em projetos com build pesado.

Exemplo prático (teoria -> prática)

Vamos simular um cenário real de desenvolvimento.

Projeto:

API backend com duas tarefas:

• feature: sistema de notificações
• hotfix: correção de autenticação

Branch atual:

develop

Estrutura inicial:

finance-api/

Passo 1: Criar uma nova feature com worktree

Criando um diretório para a feature:

git worktree add ../feature-notificacoes -b feature/notificacoes

O que aconteceu aqui:

• Criou um novo diretório
• Criou uma nova branch
• Ligou a branch ao novo workspace

Agora temos:

finance-api/
feature-notificacoes/

Cada um com uma branch diferente.

Passo 2: Trabalhando em paralelo

Workspace 1:

finance-api
branch: develop

Workspace 2:

feature-notificacoes
branch: feature/notificacoes

Passo 3: Hotfix urgente

Bug em produção.

Criando outro worktree:

git worktree add ../hotfix-auth -b hotfix/auth

Estrutura final:

finance-api/
feature-notificacoes/
hotfix-auth/

Agora você tem três contextos isolados.

Passo 4: Fluxo real de desenvolvimento

No diretório hotfix

cd ../hotfix-auth

Corrige o problema:

git commit -m "fix: corrige validação do token"
git push origin hotfix/auth

Merge realizado.

Enquanto isso, a feature continua intacta

Sem stash.

Sem conflitos.

Sem troca de branch.

Listando worktrees existentes

git worktree list

Saída típica:

/home/reginaldo/projetos/finance-api develop
/home/reginaldo/projetos/feature-notificacoes feature/notificacoes
/home/reginaldo/projetos/hotfix-auth hotfix/auth


Isso ajuda muito em repositórios grandes.

Removendo um worktree

Após merge da feature:

git worktree remove ../feature-notificacoes

Ou manual:

rm -rf ../feature-notificacoes
git worktree prune

Boas práticas usando git worktree

1. Criar um diretório padrão

Exemplo:

worktrees/

Estrutura recomendada:

repo/
worktrees/
   feature-x
   hotfix-y

2. Nomear worktrees por contexto

Evite nomes genéricos:

Errado:

test
dev2
branch2

Melhor:

feature-pagamentos
refactor-auth
hotfix-prod

3. Usar em conjunto com PR workflow

Fluxo eficiente:

1. Criar branch
2. Criar worktree
3. Desenvolver
4. Commit
5. Push
6. PR
7. Remover worktree
4. Automatizar com script

Exemplo simples:

new-feature.sh

#!/bin/bash

branch=$1

git worktree add ../wt-$branch -b $branch
cd ../wt-$branch

Uso:

./new-feature.sh feature/pix

Isso acelera bastante o fluxo de trabalho.

Comparação: workflow tradicional vs worktree

Sem worktree

Fluxo:

stash
checkout
pull
resolver conflito
stash pop

Problemas:

risco de erro

perda de contexto

lentidão

Com worktree

Fluxo:

novo diretório
nova branch isolada
desenvolver

Resultado:

workflow limpo

paralelismo

mais produtividade

Uso avançado em times experientes

Equipes maduras usam git worktree para:

QA paralelo

Ambiente para teste de PR local.

Refatoração grande

Manter branch estável rodando.

Testar migração de framework

Exemplo real:

Migrar:

• Spring Boot
• Angular
• React

Sem quebrar a base principal.

Integração com ferramentas modernas

Funciona muito bem com:

VSCode

Docker

Dev Containers

Monorepos

CI local

Exemplo prático com Docker:

Cada worktree pode subir um container diferente.

docker compose up

Com variáveis diferentes.

Quando não usar git worktree

Casos raros:

• projetos muito pequenos
• repositórios descartáveis
• scripts simples

Mas na maioria dos casos profissionais, vale a pena.

Considerações finais

git worktree é um recurso subestimado do Git, mas extremamente poderoso para engenheiros de software que trabalham com múltiplos contextos de desenvolvimento.

Ele melhora:

• organização
• foco
• produtividade
• segurança no workflow

E reduz drasticamente problemas comuns como:

• stash excessivo
• conflitos inesperados
• troca constante de branches

Em equipes que trabalham com:

• microserviços
• APIs
• sistemas corporativos
• projetos com CI/CD

O uso de git worktree pode se tornar um diferencial real no fluxo da engenharia de software.

Feito!

O lado obscuro do Vibe Coding

O movimento Vibe Coding transformou a maneira como criamos software. A promessa é sedutora: você descreve sua ideia em linguagem natural, e uma plataforma de IA (Bolt.new, Lovable, Abacus) que são ferramentas especializadas para gerar um aplicativo full-stack funcional em minutos.

No entanto, há um perigo silencioso nesse fluxo de trabalho. Muitas dessas ferramentas utilizam o Supabase como backend padrão. Se você não for específico no seu prompt, pode acabar com uma aplicação onde qualquer pessoa na internet consegue ler, alterar ou deletar os dados de todos os seus usuários.

O Contexto Histórico: Da Rebeldia de Karpathy ao Mainstream

O termo Vibe Coding não nasceu em um laboratório de engenharia tradicional, mas sim de uma observação provocativa de Andrej Karpathy (cofundador da OpenAI) em fevereiro de 2025. Ao descrever um fluxo de trabalho onde a sintaxe é irrelevante e a "vibe" (a intenção e o feedback visual) é tudo, Karpathy deu nome a um movimento que o lendário produtor Rick Rubin comparou ao "Punk Rock do Software".

Em 2025, o termo foi eleito a palavra do ano pelo dicionário Collins, consolidando a ideia de que qualquer pessoa com uma boa ideia e um prompt pode ser um desenvolvedor. No entanto, essa origem focada na velocidade e na expressão criativa trouxe um efeito colateral: a negligência com fundamentos invisíveis, como o RLS, que agora, em 2026, define a fronteira entre um protótipo amador e um app profissional seguro.

No presente artigo, vamos entender a vulnerabilidade de RLS (Row Level Security) desabilitado e como corrigi-la com uma simples mudança na sua instrução inicial.

O que é Vibe Coding e por que o Supabase?

Vibe Coding é o termo cunhado para descrever o desenvolvimento de software focado na intenção e na iteração rápida através de prompts de IA, onde o desenvolvedor atua mais como um "maestro" do que como um digitador de sintaxe.

Para que essa "mágica" aconteça, a IA precisa de um backend que seja fácil de configurar programaticamente. O Supabase é a escolha ideal por ser um "Firebase Open Source" baseado em PostgreSQL, oferecendo banco de dados, autenticação e armazenamento de forma instantânea.

O problema surge na configuração padrão.

O Perigo: A Chave Anon e o RLS Desabilitado

Quando uma plataforma (Bolt.new, Lovable, Abacus) cria um app Supabase para você, ela gera um arquivo de configuração (geralmente .env) contendo a SUPABASE_URL e a SUPABASE_ANON_KEY.

Diferente de backends tradicionais onde a chave do banco de dados fica escondida no servidor, no modelo de arquitetura moderna (PostgREST), a chave anon é pública e fica exposta no navegador do usuário.

O que é RLS (Row Level Security)?

RLS significa Row Level Security (Segurança em Nível de Linha). É um recurso do banco de dados PostgreSQL que permite definir regras granulares para quem pode ver ou modificar cada linha em uma tabela.

Sem RLS: Se você tem a chave anon, você tem acesso total às tabelas.

Com RLS: Mesmo com a chave anon, o banco de dados pergunta: "Quem é este usuário e ele tem permissão para ver esta linha específica?"

A Anatomia da Vulnerabilidade

Imagine que você pediu na plataforma (Bolt.new, Lovable, Abacus):

"Crie um app de gestão de clientes para minha agência".

A plataforma (Bolt.new, Lovable, Abacus) cria uma tabela chamada clientes. Por padrão, para facilitar o desenvolvimento e garantir que o app "funcione de primeira" (a famosa "vibe"), muitas ferramentas de geração de código criam as tabelas sem habilitar o RLS.

O Cenário de Desastre

1. O hacker acessa seu site.
2. Abre o console do desenvolvedor (F12) e encontra sua SUPABASE_ANON_KEY.
3. Utiliza uma ferramenta simples ou até o próprio terminal para fazer uma requisição à API do seu Supabase:
curl 'https://seu-projeto.supabase.co/rest/v1/clientes?select=*' \
-H "apikey: SUA_CHAVE_ANON" \
-H "Authorization: Bearer SUA_CHAVE_ANON"


O resultado? O invasor recebe um JSON com todos os dados de todos os clientes, e-mails, faturamentos e notas administrativas. Se o RLS estiver desabilitado, a chave "Anônima" tem poderes de administrador sobre os dados públicos.

A Solução: Ajustando o seu Prompt

A boa notícia é que a IA é obediente. O erro não está na tecnologia, mas na omissão da segurança no prompt inicial. Para garantir que seu app seja seguro desde o "dia zero", você deve incluir instruções explícitas de segurança.

O "Prompt Seguro"

Sempre que iniciar um projeto de Vibe Coding, adicione este parágrafo ao seu comando:

"Habilite o Row Level Security (RLS) em todas as tabelas criadas no Supabase. Crie políticas de segurança para que usuários autenticados possam ler e escrever apenas seus próprios dados, e garanta que dados administrativos não sejam acessíveis via chave anon sem as devidas permissões."

Ao fazer isso, a IA na plataforma (Bolt.new, Lovable, Abacus) gerará o SQL necessário para proteger seu banco, parecido com este:

-- Exemplo do que a IA deve gerar nos bastidores
ALTER TABLE clientes ENABLE ROW LEVEL SECURITY;

CREATE POLICY "Usuários só vêem seus próprios clientes"
ON clientes FOR SELECT

USING (auth.uid() = user_id);

Tabela Comparativa: Sem RLS vs. Com RLS

Recurso	Sem RLS (Padrão Vibe)	Com RLS (Prompt Seguro)
Visibilidade da Chave	Exposta no Browser (Normal)	Exposta no Browser (Normal)
Acesso a dados alheios	Livre (Risco Total)	Bloqueado pelo Banco
Privacidade	Inexistente	Garantida por UID
Escalabilidade	Perigosa	Segura para Produção

Considerações finais

O Vibe Coding é o futuro, mas a segurança não pode ser deixada para depois. Ao entender que o Supabase delega a segurança para o nível da linha (RLS), você assume o controle da integridade dos dados dos seus usuários.

Não deixe que a agilidade de um prompt comprometa a confiança dos seus clientes. Segurança também faz parte da "vibe".

Feito!

Executando o Ollama no ambiente Docker

Executar o Ollama no Docker é a maneira mais prática de executar modelos de linguagem (LLMs) localmente, garantindo isolamento do sistema operacional e fácil gerenciamento.

O presente howto explica passo a passo para configurar o Ollama com Docker e instalar modelos, tanto com CPU quanto com GPU.

1. Pré-requisitos

A premissa é ter o Docker e Docker-Compose instalados, caso ainda não tenha, verifique Instalando Docker e Docker Compose no Linux (qualquer distro) ou Instalando Docker no Windows 10

Nvidia Container Toolkit (Para GPU): Se você tem uma GPU Nvidia e quer aceleração, instale o Nvidia Container Toolkit para o Docker reconhecer sua placa.

2. Executar o Ollama no Docker

Abra o seu terminal e utilize os comandos abaixo:

A. Apenas CPU

-d: Roda o contêiner em segundo plano (detached mode).

-v ollama:/root/.ollama:

Cria um volume chamado ollama para garantir que seus modelos baixados não sejam apagados quando o contêiner for reiniciado.

-p 11434:11434:

Mapeia a porta padrão do Ollama.

B. Com GPU NVIDIA (Aceleração) docker run -d --gpus=all -v ollama:/root/.ollama -p 11434:11434 --name ollama ollama/ollama --gpus=all:

Permite que o contêiner acesse a GPU.

3. Instalar e Rodar Modelos Abertos (Ollama Pull/Run)

Com o contêiner rodando, você pode "entrar" nele e baixar os modelos através da CLI (Interface de Linha de Comando).

Download de um modelo (ex: Llama 3.2):

docker exec -it ollama ollama pull llama3.2

Executar o modelo e interagir:

docker exec -it ollama ollama run llama3.2


Agora você pode conversar com o modelo diretamente no terminal.

Outros modelos populares:

docker exec -it ollama ollama run gemma2

docker exec -it ollama ollama run deepseek-r1

docker exec -it ollama ollama run qwen2.5
4. Como ver os modelos instalados e gerenciar

Para listar os modelos que você já baixou dentro do contêiner Docker, use:

docker exec -it ollama ollama list

Para remover um modelo:

docker exec -it ollama ollama rm nome_do_modelo
5. Dica Pro: Interface Web (Open WebUI)

Para ter uma experiência tipo "ChatGPT" com o Ollama no Docker, a melhor opção é o Open WebUI.

Use o docker-compose para rodar o Ollama e a interface gráfica juntos:

Crie um arquivo docker-compose.yml:

services:
  ollama:
    volumes:
      - ollama:/root/.ollama
    container_name: ollama
    image: ollama/ollama
    ports:
      - "11434:11434"
    networks:
      - ollama-net
    restart: always

  open-webui:
    image: ghcr.io/open-webui/open-webui:main
    container_name: open-webui
    volumes:
      - open-webui:/app/backend/data
    ports:
      - "3000:8080"
    environment:
      - OLLAMA_BASE_URL=http://ollama:11434
    networks:
      - ollama-net
    restart: always

networks:
  ollama-net:

volumes:
  ollama:
  open-webui:

Execute: docker-compose up -d

Acesse http://localhost:3000 no seu navegador.

Feito!

Fazendo o Deploy do site com GitHub Actions

Configurar um site com GitHub Actions para fazer o deploy automático via FTP transforma seu fluxo de trabalho: você faz o git push e o GitHub cuida do resto.

O presente howto explica como fazer o deploy do seu site com GitHub Actions via FTP, comum em hospedagem compartilhada.

Segue os procedimentos:

1. Salve suas credenciais com segurança

Nunca coloque senhas diretamente no código. No seu repositório no GitHub:

Vá em Settings > Secrets and variables > Actions.

Clique em New repository secret e adicione:

FTP_SERVER: O endereço ou nome de domínio do seu servidor.

FTP_USERNAME: Seu usuário de FTP.

FTP_PASSWORD: Sua senha de FTP.

2. Crie o arquivo de Workflow

No seu projeto local, crie a pasta .github/workflows/ e, dentro dela, um arquivo chamado main.yml. Cole o conteúdo abaixo:

Se o site foi desenvolvido apenas com HTML, CSS e JS

No seu projeto local, crie o diretório .github/workflows/ e, dentro dela, um arquivo chamado main.yml. Segue:

.github/workflows/main.yml

Se o site foi desenvolvido com React

Diferente de um site estático simples (HTML/CSS/JS), o navegador não entende diretamente seu código React (JSX). O GitHub Actions precisa rodar o comando de compilação para criar a pasta final com os arquivos otimizados.

No seu arquivo .github/workflows/main.yml, use esta estrutura

.github/workflows/main.yml

3. Suba as alterações

Agora basta commitar e enviar para o GitHub:

git add .

git commit -m "Configurando deploy automático"

git push origin main


Você pode acompanhar o progresso em tempo real na aba Actions do seu repositório. Se tudo estiver certo, seu site será atualizado em poucos segundos!

Pontos importantes para React:

Diretório Local (local-dir): Se você usa Vite (o padrão atual), a pasta de saída é a dist/. Se usa o antigo Create React App, é a build/.

Roteamento (SPA): Se o seu site usa react-router-dom, lembre-se de configurar um arquivo .htaccess no seu servidor para redirecionar todas as rotas para o index.html, caso contrário, você receberá erro 404 ao atualizar a página.

Variáveis de Ambiente: Se o seu React usa .env, você precisará cadastrar essas variáveis nos Secrets do GitHub e injetá-las no passo de build.

Caso criou o projeto React com Vite, precisa adicionar uma configuração.

O segredo aqui é que o GitHub Actions vai criar um "computador virtual", instalar o Node.js, baixar suas bibliotecas e transformar seu código JSX em arquivos que qualquer servidor entende.

Dica de Ouro: O arquivo .htaccess

Para sites React (Single Page Applications), se você não configurar o servidor, as rotas (ex: ://seusite.com) darão erro 404 ao atualizar a página. Crie um arquivo chamado .htaccess na sua pasta public do projeto com este conteúdo:

  RewriteEngine On
  RewriteBase /
  RewriteRule ^index\.html$ - [L]
  RewriteCond %{REQUEST_FILENAME} !-f
  RewriteCond %{REQUEST_FILENAME} !-d
  RewriteRule . /index.html [L]

ATENÇÃO

1. Verifique se o nome da pasta de saída no seu projeto é realmente dist (padrão do Vite) ou build.
2. Certifique-se de que as Secrets (FTP_SERVER, FTP_USERNAME, FTP_PASSWORD) foram adicionadas corretamente no GitHub.
3. Faça o git push e acompanhe a "mágica" na aba Actions.

Feito!

O segredo da escalabilidade no n8n que poucos conhecem

O n8n usa SQLite por padrão em instalações self-hosted, mas isso pode gerar gargalos de desempenho e concorrência em cenários com múltiplos acessos simultâneos. Para ambientes de produção ou workflows de grande escala, a recomendação oficial é migrar para PostgreSQL.

Banco de dados padrão no n8n

Self-hosted: por padrão, utiliza SQLite (leve, embutido, sem necessidade de servidor separado).

n8n Cloud: planos básicos usam SQLite; apenas planos Enterprise usam PostgreSQL.

Limitações do SQLite

Concorrência limitada: não lida bem com múltiplas conexões simultâneas.

Escalabilidade restrita: adequado apenas para testes, ambientes pessoais ou pequenos projetos.

Risco de bloqueios: em workflows com muitos acessos, pode ocorrer lentidão ou falhas de escrita/leitura.

Recomendações para produção

Migrar para PostgreSQL:

Melhor suporte a conexões simultâneas.

Transações robustas e maior confiabilidade.

Ferramentas de backup, replicação e escalabilidade.

Configuração básica:

Definir variáveis do ambiente Docker:

DB_TYPE=postgresdb
DB_POSTGRESDB_DATABASE, DB_POSTGRESDB_HOST, DB_POSTGRESDB_USER, DB_POSTGRESDB_PASSWORD

Criar usuário e banco dedicados para o n8n.

Comparativo Rápido

Critério	SQLite (default)	PostgreSQL (recomendado)
Instalação	Simples, embutido	Requer servidor dedicado
Concorrência	Limitada	Alta, ideal para múltiplos acessos
Escalabilidade	Baixa	Elevada, suporta clusters
Manutenção	Fácil	Mais complexa, mas robusta
Uso ideal	Testes, projetos pequenos	Produção, workflows críticos

Considerações finais

Se você pretende rodar o n8n em produção com múltiplos usuários ou workflows pesados, não use SQLite. Configure PostgreSQL para garantir estabilidade, desempenho e escalabilidade.

Feito!