O que o homelab me ensinou sobre escalar infraestrutura não está na tabela do Open WebUI: está em tudo o que parti quando ainda era barato partir

Higgs

Olá a todos!

Prefácio: é a terceira vez em dois meses que pego num artigo do Open WebUI. Em agosto usei-o para falar da Áustria e do AMALIA, na semana passada serviu de pano de fundo aos seis serviços essenciais do homelab. Prometo que é a última. Aviso também que sou parte interessada: corro infraestrutura em casa há muitos anos, trabalho com infraestrutura profissionalmente, e tenho o preconceito assumido de que uma coisa ensina a outra. Leiam com isso em mente.

Há uma frase no artigo “How Your AI Homelab Scales Into National Infrastructure” que me continua a ficar atravessada desde agosto. Vem logo a seguir à tabela com os cinco degraus, da pessoa sozinha com um Mac até à infraestrutura de datacenter de um Estado, e diz, mais coisa menos coisa, que descer a tabela é sobretudo acrescentar hardware e ligar mais coisas que já lá estão.

Para o software, é verdade. O Open WebUI que tenho num Mac mini em cima de uma estante é o mesmo que serve 180 mil funcionários públicos austríacos. Mesmo contentor, mesmas definições, mesmo ecrã de login.

Para as pessoas que o operam, é mentira.

Ou melhor, é uma meia verdade que esconde a parte mais cara da escada: aquilo que tens de já saber para que “acrescentar hardware” não seja apenas a forma mais rápida de multiplicar os teus problemas por mil. O artigo até o reconhece de passagem, quando diz que o que muda com a escala é tudo o que está à volta do software. Depois segue em frente, porque o artigo é sobre o Open WebUI. Eu quero parar precisamente aí.

A minha tese é simples, e sei que vai irritar algumas pessoas: os pré-requisitos para escalar infraestrutura aprendem-se melhor num homelab, ou num on-premise pequeno, do que em quase qualquer outro sítio. O homelab não se parece com um datacenter, e ainda bem. O que o torna uma boa escola é outra coisa: é o único sítio onde és dono de todas as camadas ao mesmo tempo, e onde errar custa um sábado à tarde em vez de uma notícia no jornal.

A coluna que falta na tabela

Relembro a tabela para quem não a leu. Cinco linhas com uma pessoa a experimentar, o utilizador avançado de homelab, a equipa pequena, a organização regulada, a escala nacional. Para cada uma, o hardware típico, o que se corre e os controlos que interessam. É uma boa tabela. Escrevi sobre ela em agosto e mantenho o que disse.

Mas falta-lhe uma coluna, e é a única que não se compra: o que é preciso ter aprendido antes de passar para a linha seguinte.

Passar de “uma pessoa” para “equipa pequena” não exige só uma gráfica partilhada e contas com aprovação. Exige que alguém já tenha percebido o que acontece à memória dessa gráfica quando cinco pessoas fazem perguntas ao mesmo tempo. Passar de “equipa” para “organização regulada” não exige só SSO e registos de auditoria. Exige alguém que já tenha visto uma atualização correr mal e saiba voltar atrás sem perder dados. E passar para a escala nacional exige tudo isto, mais a humildade de saber que um erro raro deixa de ser raro quando se multiplica por 250 mil utilizadores.

Nenhuma destas coisas vem no docker-compose. Aprendem-se a partir coisas.

A pergunta é só onde preferes parti-las.

A cloud esconde as lições, e é para isso que se paga o que se paga.

Antes que me acusem de cruzada contra a cloud – e não estariam totalmente enganados por questões  de privacidade, but i digress – uma concessão honesta. A cloud é excelente precisamente porque te poupa a estas lições. Não precisas de saber quantos watts puxa um servidor, qual a ordem de arranque dos serviços depois de um corte de energia, ou o que acontece quando o disco de sistema enche às quatro da manhã. Alguém sabe por ti, e cobra-te por isso. É um negócio perfeitamente legítimo, e para muitos casos é a decisão certa.

O problema aparece quando a abstração passa a ser a única coisa que conheces. Há engenheiros muito competentes que fizeram a carreira inteira dentro de consolas de fornecedores e que, postos à frente de um servidor físico, de uma UPS e de um switch, não sabem por onde começar. Não é defeito deles. Simplesmente nunca tiveram de pensar no que estava por baixo. Tenho debatido muito isto com amigos em projectos que partilhamos.

Quando a conversa passa a ser IA self-hosted, esconder as camadas deixa de ser opção. Um hospital que não pode mandar processos clínicos para fora, ou um ministério que decide correr modelos de pesos abertos no seu próprio datacenter, está a escolher exatamente as camadas que a cloud lhe escondia: energia, rede, armazenamento, atualizações, identidade, recuperação. Alguém tem de as conhecer.

De preferência, alguém que já as conheceu à escala de uma estante.

Lição um: a física não se virtualiza

A primeira coisa que o homelab te ensina, normalmente pela fatura, é que a infraestrutura consome energia e produz calor. Parece óbvio. Não é, para quem sempre pensou em vCPUs e gigabytes de RAM.

Uma gráfica com 24 GB de VRAM, que o artigo aponta como o patamar onde os modelos locais ficam realmente capazes, puxa várias centenas de watts quando está a gerar tokens. Num escritório pequeno em agosto, isso sente-se na pele. A primeira vez que alguém deixa um modelo a processar um lote de documentos durante a noite, aprende três ou quatro coisas de uma vez: que a ventoinha da gráfica tem um som muito característico, que a divisão acorda dois graus mais quente, que o router ao lado também não gostou, e que a tomada com medição de consumo que comprou por curiosidade afinal foi o melhor investimento do homelab inteiro.

Multiplica isto por uma sala de servidores e a conversa muda de nome, mas não de natureza. Deixas de falar em watts e passas a falar em quilowatts por bastidor, em capacidade de refrigeração, em contratos de potência com o fornecedor de energia. Quem já fez a conta em casa (consumo médio vezes horas vezes o preço do kWh do tarifário) percebe à primeira porque é que um cluster de GPUs não cabe num bastidor que foi dimensionado para servidores de ficheiros. Quem nunca a fez descobre-o quando o disjuntor dispara, ou quando chega a primeira fatura da colocation.

E depois há o reboot. O artigo termina a secção dos custos com uma frase de que gosto muito: quanto maior a instalação, mais daquelas responsabilidades se transforma no trabalho de alguém, a começar por ter um plano para uma coisa tão pequena como reiniciar.

Um corte de energia em casa é o melhor professor de dependências que existe. Volta a luz e descobres que as VMs arrancaram antes de o armazenamento estar disponível, que o Open WebUI subiu antes do DNS e não resolve o nome do servidor de inferência, que o contentor com restart always ficou num ciclo de reinícios porque a base de dados ainda não respondia. Tudo funciona, individualmente. Nada funciona em conjunto.

Isto é um grafo de dependências. Em casa tem dez nós. Num datacenter tem dez mil. A lição é exatamente a mesma: a ordem de arranque é uma decisão de arquitetura, não um acaso, e quem nunca a pensou não a vai pensar pela primeira vez a meio de um incidente com o diretor ao telefone.

O homelab ensina ainda que uma UPS sem software a falar com os servidores serve apenas para desligar tudo de forma desordenada cinco minutos mais tarde. Configurar o NUT para que a UPS diga a cada máquina quando se deve desligar, e por que ordem, é uma tarde de trabalho. À escala certa, é exatamente o mesmo problema que um procedimento de paragem controlada num datacenter, com a diferença de que em casa o podes testar sempre que te apetecer.

Lição dois: medir antes de comprar, e medir a coisa certa

“Compra o hardware em último lugar.” É o conselho mais sensato do artigo e aquele que menos gente segue, em casa e nos concursos públicos.

O homelab ensina-te porque é que o conselho é difícil de seguir: para dimensionar, tens de saber o que medir, e a intuição engana. A intuição diz que um modelo de 8 mil milhões de parâmetros, quantizado, ocupa cinco ou seis gigabytes e portanto cabe folgado numa gráfica de 12. E cabe. Para uma pessoa, com conversas curtas.

Depois alguém cola um PDF de quarenta páginas na conversa, o contexto dispara, e a KV cache (a memória onde o modelo guarda o estado de cada conversa em curso) começa a comer a VRAM que sobrava. Junta-lhe uma segunda e uma terceira pessoa a fazer o mesmo à mesma hora e a gráfica que parecia sobredimensionada passa a pôr pedidos em fila, a empurrar parte do modelo para a RAM do sistema, ou a responder a um ritmo que ninguém tolera.

A lição é que a capacidade não é o tamanho do modelo. É o tamanho do modelo, mais o contexto, vezes a concorrência. Qualquer pessoa consegue ler isto num artigo. Só se interioriza quando se vê acontecer.

No Ollama dá para brincar com isto em casa sem gastar um cêntimo. Há variáveis como a OLLAMA_NUM_PARALLEL, que controla quantos pedidos cada modelo atende em simultâneo. Sobe-se o número, abre-se o nvidia-smi (ou o monitor de atividade, num Mac) noutra janela, e põem-se três ou quatro separadores a fazer perguntas longas ao mesmo tempo. Em meia hora aprende-se mais sobre dimensionamento de inferência do que em qualquer folha de cálculo de fornecedor.

Isto explica também porque é que a tabela do artigo passa a falar em Ollama ou vLLM a partir da equipa pequena. O Ollama foi pensado para a conveniência de quem o usa. O vLLM foi pensado para servir muitos pedidos em paralelo, com batching contínuo e uma gestão de memória desenhada para a concorrência. Quem já viu o Ollama a arrastar-se com cinco utilizadores percebe a diferença sem precisar que lha expliquem. Quem nunca viu tende a escolher o que lhe é familiar e a descobrir o limite em produção.

E há a pergunta que qualquer pessoa que opera serviços partilhados acaba por aprender a fazer: qual é o pico? Não a média. O pico. Numa organização, o pico é às nove e meia da manhã de uma segunda-feira, quando toda a gente abre o browser ao mesmo tempo. Numa casa, é quando os miúdos chegam da escola e ligam tudo o que tem ecrã. Aprender a olhar para percentis em vez de médias começa no gráfico de latência do teu próprio serviço, e é das competências que mais distinguem quem já operou coisas de quem só as desenhou.

O Scotty, na Enterprise, tinha fama de inflacionar as estimativas que dava ao capitão para depois parecer um milagreiro. No dimensionamento, a margem não serve para parecer milagreiro. Serve porque vais estar errado, e convém estar errado do lado certo.

Lição três: os modelos são previsíveis, os dados não o são

Um dos erros da lista do artigo é dimensionar o armazenamento para os modelos e esquecer os dados. Os ficheiros dos modelos são a parte previsível. As conversas, os uploads e os índices de pesquisa criados a partir deles crescem sem pedir licença.

O que o homelab te dá aqui é uma coisa que nenhum documento de arquitetura dá: uma série temporal verdadeira. Se tens o Open WebUI a correr há um ano, com RAG sobre os teus próprios documentos, consegues ver quanto cresceu o volume de dados por mês. Divide pelo número de pessoas que o usam e tens uma taxa de crescimento por utilizador. É um número imperfeito, feito com uma amostra ridícula. Mas é um número teu, medido, e vale mais do que qualquer estimativa tirada do ar numa reunião.

Multiplica essa taxa pelo número de utilizadores do degrau seguinte e ficas com uma primeira aproximação honesta do armazenamento que vais precisar. Ficas também com a prova prática de que a retenção não é um pormenor jurídico que se resolve no fim. É a única variável que controla aquela curva. Sem retenção definida, a curva só sobe.

Há ainda a lição mais dolorosa, que é o disco cheio. Toda a gente que tem homelab há mais de um ano tem uma história com um volume que encheu sem avisar, quase sempre por causa de registos que ninguém rodava ou de imagens de contentores antigas que ninguém limpava. À escala de uma casa, é uma manhã perdida e uma lição sobre logrotate. À escala de uma organização, é um serviço em baixo. O problema de fundo é o mesmo: crescimento que ninguém estava a medir, num sítio para onde ninguém estava a olhar.

Lição quatro: descobrir o que morre quando se corta a internet

O artigo fala, entre os casos do meio da tabela, de equipas cuja rede nunca toca na internet. É meia frase para um problema enorme, e é talvez a lição mais subestimada que o homelab tem para dar.

Faz a experiência. Numa sexta-feira à noite, bloqueia a saída para a internet na firewall (se tiveres um pfSense ou um OPNsense à frente, são dois cliques) e deixa ficar assim até domingo. Depois faz uma lista do que deixou de funcionar.

Vais descobrir coisas curiosas. O contentor que tenta puxar a imagem de cada vez que arranca. O modelo que afinal não estava em cache local. A aplicação que valida uma licença ao arrancar e se recusa a trabalhar sem resposta. A sincronização de relógio que parou e que, uns dias depois, começa a fazer falhar certificados e tokens de autenticação de formas estranhíssimas. O DNS interno que, afinal, só resolvia porque reencaminhava tudo para fora. A documentação de que precisavas para resolver tudo isto, que só existia num site.

Cada item dessa lista é um pré-requisito para uma instalação isolada: um registo local de imagens de contentores, um espelho dos repositórios de pacotes, uma pasta com os pesos dos modelos transferidos e com os checksums verificados, um servidor NTP interno, DNS que se aguenta sozinho, documentação que vive do lado de dentro. Nada disto é difícil. Tudo isto é invisível até ao dia em que falta.

E há uma camada extra, que liga diretamente à soberania de que o artigo fala. Se a tua instalação de IA “local” deixa de funcionar quando se corta a internet, então não é local. É uma instalação com dependências que ainda não descobriste. Isto aplica-se a uma casa e aplica-se a um ministério. A única forma barata de o descobrir é cortar o cabo de propósito, num fim de semana em que não precisas de nada.

Lição cinco: atualizar é uma operação, não um reflexo

Repara no comando que o artigo usa para instalar o Open WebUI. A imagem tem a tag main e o contentor tem restart always. Para uma pessoa a experimentar numa noite, é exatamente o que se quer: pouca fricção, sempre a versão mais recente.

Numa organização, a mesma linha é um problema à espera de acontecer. O Open WebUI mexe-se depressa (a 0.11.0 foi anunciada no fim de julho e a 0.11.1 no fim de agosto, ambas com mudanças consideráveis), e a tag main significa que a versão que corre em produção é decidida pelo dia em que alguém reiniciou o contentor. Ou pelo dia em que a máquina reiniciou sozinha depois de um corte de energia, o que nos leva de volta à lição um.

O homelab ensina isto da forma mais eficaz possível: parte-te alguma coisa numa atualização que não pediste. A partir daí aprendes, mais ou menos por esta ordem, a fixar a versão da imagem, a ler as notas de lançamento antes de mudar, a fazer uma cópia do volume de dados antes de atualizar, e a perceber que há atualizações que não se desfazem trocando a tag. Quando uma versão nova migra o esquema da base de dados, voltar à imagem anterior com a base de dados já migrada é pedir sarilhos. O caminho de volta é o backup de antes, não o contentor de antes.

À escala seguinte, esta sequência ganha nomes: ambiente de testes, janela de manutenção, plano de rollback, gestão de alterações. São nomes que soam a burocracia a quem nunca partiu nada. A quem já partiu, soam a bom senso com processo à volta.

O mesmo vale para as dependências que não escolheste. Escrevi em agosto sobre o LiteLLM envenenado durante quarenta minutos, e a lição que tirei na altura serve aqui na perfeição: numa instalação que cresce, a lista de coisas que corres é sempre maior do que a lista de coisas que decidiste correr. Em casa, fazer esse inventário é um exercício de uma tarde, com um docker image ls e alguma paciência. Numa organização, chama-se SBOM, tem ferramentas próprias, e é cada vez mais um requisito contratual.

Lição seis: estado dentro do contentor não escala

Esta é mais técnica, mas é a que separa o degrau da equipa pequena do degrau da organização.

Em casa, o Open WebUI guarda tudo num volume: base de dados, uploads, configuração. Um contentor, um volume, um backup simples. É uma arquitetura perfeita para uma pessoa e perfeitamente aceitável para dez.

Quando precisas de alta disponibilidade (a expressão aparece na última linha da tabela, e não por acaso), um contentor deixa de chegar. Precisas de duas ou mais réplicas atrás de um balanceador, e isso obriga a tirar o estado de dentro do contentor: uma base de dados externa, tipicamente PostgreSQL em vez da SQLite que vem por omissão, armazenamento partilhado para os ficheiros, e uma forma de as réplicas partilharem sessões e eventos em tempo real. A documentação do projeto cobre isto. O que a documentação não te dá é a experiência de o ver falhar.

Nada disto é exclusivo do Open WebUI. É o mesmo padrão em quase qualquer aplicação web que alguma vez tenhas tentado escalar. E o homelab é um sítio excelente para o praticar, porque podes montar duas réplicas atrás do teu reverse proxy num fim de semana, desligar uma delas a meio de uma conversa e ver o que acontece ao utilizador. Da primeira vez, alguma coisa vai correr mal. Ainda bem que foi em casa, com um único utilizador a reclamar.

Quem, como eu, tem o armazenamento em hosts dedicados e o distribui por iSCSI para os hosts de computação já sentiu esta separação entre estado e processamento na pele. Dá mais trabalho do que ter tudo na mesma caixa, e há dias em que me pergunto porque é que não simplifico. Depois lembro-me de que é a única forma de poder perder uma caixa inteira sem perder os dados, e a pergunta passa.

Lição sete: a identidade é a primeira coisa que não se refaz

Não vou repetir os quatro controlos do artigo, porque já os percorri em agosto. Quero só acrescentar o que o homelab ensina sobre eles e que a lista não diz.

O primeiro utilizador que convidas para a tua instalação muda tudo. Até ali, és administrador, utilizador e suporte ao mesmo tempo, e todas as decisões de acesso são tuas e implícitas. A partir dali passam a ser explícitas, e aprendes duas coisas depressa: que é muito mais fácil dar acesso do que tirá-lo, e que a forma como organizas as contas no primeiro dia é a forma como vais viver com elas durante anos.

Quem montou contas locais em cinco serviços e depois tentou migrar tudo para um fornecedor de identidade central sabe do que falo. Os utilizadores ficam duplicados, os históricos ficam agarrados à conta antiga, as permissões têm de ser refeitas à mão, e há sempre um serviço que não suporta OIDC e fica de fora. À escala de uma casa, é uma tarde aborrecida. À escala de 180 mil pessoas, é o tipo de projeto que dura anos e sobrevive a mais do que um diretor de sistemas de informação.

Por isso, o pré-requisito não é saber configurar OIDC, que se aprende numa tarde com a documentação aberta. É saber que a identidade se decide antes, e que ligar o SSO no dia um custa muito menos do que migrar para ele no dia mil.

Um exercício que recomendo a toda a gente: dá acesso a um amigo à tua instalação e depois retira-lho. Verifica se ele perdeu mesmo o acesso a tudo, incluindo as chaves de API que entretanto criou e as partilhas que fez. A resposta costuma ser instrutiva.

Lição oito: o operador seguinte és tu, daqui a seis meses

Num homelab és o único operador. Isso parece uma vantagem até ao dia em que precisas de mexer numa coisa que configuraste há seis meses e não fazes a menor ideia de porque é que está assim.

O teu eu de daqui a seis meses é o primeiro colega de equipa que vais ter. Não sabe o que sabias, não se lembra do que decidiste, e vai estar a tentar perceber o sistema à pressa, provavelmente porque alguma coisa está em baixo e alguém em casa está a perguntar quando é que volta. Escrever para ele é o treino perfeito para escrever para uma equipa.

Na prática, começa por um README no repositório de configuração com três coisas: o que corre onde, porque é que está assim, e como se recupera cada peça. Quando a instalação cresce, esse ficheiro ganha o nome de runbook. Quando tens uma equipa, ganha revisões, um dono e a data da última verificação.

O teste é simples e cruel. Dá o documento a alguém que não conhece a tua instalação e pede-lhe que recupere um serviço seguindo apenas o que lá está escrito. Tudo o que essa pessoa te perguntar é uma linha que falta.

Em agosto chamei a isto o problema da “experiência do Nuno”: a instalação montada por uma pessoa, que funciona enquanto essa pessoa está presente e contactável. A versão formal é o fator autocarro. O homelab é o sítio mais barato para aprender a baixar esse risco, porque és simultaneamente a pessoa que monta e a pessoa que se vai esquecer.

O que o homelab não te ensina

Seria desonesto terminar sem a lista do outro lado. Há pré-requisitos de escala que nenhuma estante lá de casa ensina, por muito bem montada que esteja.

Não ensina escala a sério. Uma falha que acontece uma vez em cada dez mil pedidos nunca a vais ver em casa. Com 250 mil utilizadores, acontece várias vezes por hora e passa a ser o teu problema principal. Os efeitos de manada, com toda a gente a voltar a ligar-se no mesmo segundo depois de uma falha, também não aparecem numa casa com quatro pessoas e dois gatos.

Não ensina a parte humana da operação. Escalas de prevenção, passagens de turno, comunicação durante um incidente com trezentas pessoas à espera, uma análise pós-incidente em que ninguém é crucificado. Em casa, o incidente acaba quando tu decides que acabou.

Não ensina compras, contratos nem conformidade. O artigo é claro nisto e eu volto a sublinhar: self-hosting não é conformidade. Correr o modelo em casa ensina-te onde estão os dados. Não te diz se a forma como os guardas cumpre o RGPD ou o AI Act, e para isso é preciso gente que não mexe em contentores e que sabe coisas que nós não sabemos.

E há um risco real, que convém nomear sem rodeios: os maus hábitos do homelab. Configurar tudo à mão através de interfaces gráficas sem deixar rasto, correr tudo como root porque dá menos trabalho, a mesma palavra-passe de administrador em todo o lado, o “funciona na minha máquina” como critério de aceitação. Quem leva estes hábitos para um ambiente profissional faz mais estragos do que quem nunca teve homelab nenhum, porque junta confiança a maus reflexos.

O homelab só ensina bem quem o trata como ensaio de produção. Tratado como recreio, ensina sobretudo a ter recreio.

Um plano de estudos para o teu homelab

Se quiseres transformar o homelab numa escola a sério, estes são os exercícios que eu faria, e o que cada um ensina. Nenhum obriga a comprar nada.

  1. Desliga a corrente de propósito, com a UPS configurada, e cronometra quanto tempo tudo demora a voltar sozinho. Ensina dependências e ordem de arranque.
  2. Corta a saída para a internet durante um fim de semana e faz a lista do que morreu. Ensina o que é, de facto, uma instalação isolada.
  3. Põe quatro ou cinco sessões em simultâneo a fazer perguntas longas ao teu modelo local, com o monitor da gráfica aberto. Ensina dimensionamento de inferência.
  4. Mede o crescimento do volume de dados durante três meses e projeta-o para cem utilizadores. Ensina planeamento de capacidade e o peso real da retenção.
  5. Fixa a versão de um serviço, lê as notas da versão seguinte e faz a atualização com um plano de volta escrito antes de começar. Ensina gestão de alterações.
  6. Restaura a instalação inteira noutra máquina, só a partir do backup e do repositório de configuração. Ensina recuperação e mostra, sem piedade, o que falta documentar.
  7. Dá acesso a alguém e depois retira-o por completo. Ensina o ciclo de vida da identidade.
  8. Entrega o teu runbook a outra pessoa e observa-a em silêncio enquanto o segue. Ensina humildade, sobretudo.

Faz um por mês. Ao fim de oito meses tens um conjunto de competências que muita gente com “arquiteto de infraestrutura” no cartão de visita nunca praticou, e tens-no com cicatrizes pequenas, que são as melhores.

Onde é que isto nos deixa

Volto à frase que me ficou atravessada. Descer a escada do artigo é, de facto, sobretudo acrescentar hardware e ligar coisas que já lá estão. O software acompanha. O que não acompanha, por omissão, é a experiência de quem o opera.

A Áustria pôs 180 mil pessoas a usar o Open WebUI em servidores do Estado, com modelos de pesos abertos, e o plano anunciado é chegar às 250 mil até ao fim do ano. Não conheço a equipa do Bundesrechenzentrum. Mas aposto que, algures lá dentro, há gente que já cortou a corrente de propósito, já viu uma gráfica a arrastar-se com utilizadores concorrentes, e já restaurou um backup antes de precisar dele. Não se chega àquela escala sem essa gente, e essa gente não nasceu a saber.

Em Portugal, onde o AMALIA, da última vez que olhei, continuava à espera da sua camada de acesso pública, a pergunta sobre quem vai operar essa camada é tão importante como a pergunta sobre quem a vai financiar. A boa notícia é que a escola já existe e está espalhada pelo país: em estantes, em armários de corredor, em mini PCs em cima do móvel da televisão. A má notícia é que quase ninguém a trata como escola.

Trata a tua. Parte as coisas agora, de propósito e com método, enquanto isso só custa uma tarde de sábado e um bocadinho da paciência de quem vive contigo. É o treino mais barato que alguma vez vais ter para o dia em que aquilo que partir tiver trezentas pessoas à espera do outro lado.

Até à próxima.
Nuno

Documentação:

Artigo de origem

Posts anteriores referidos

Ferramentas referidas

Nota: Este post foi feito com o auxílio de um LLM privado.

Related Posts