Todo ano surge o mesmo desejo de refazer o portfólio, mas desta vez decidi abandonar a busca pela estética das ferramentas “da moda” — Framer, Webflow — pra focar na essência do que acredito depois de quase três décadas de internet: controle sobre a própria infraestrutura; o site foi reconstruído do zero em Hugo, sem tema herdado, priorizando performance e uma arquitetura estática que eu conseguisse entender de ponta a ponta.
arraste pra comparar — v1 (bilíngue, com alternância de tema) ↔ v2 (Editorial, hoje)
Só que “entender de ponta a ponta” não significa que eu escreva cada linha — e é aqui que a primeira versão deste texto errava feio, ao insinuar uma relação com código que nunca foi essa. Comecei como Web Designer e Webmaster ainda nos anos 90, depois fui Técnico e Diretor de TI antes de migrar pra Product e Service Design; é essa vivência de quase três décadas que me deixa dialogar com engenharia e arquitetura de sistema em pé de igualdade e operacionalizar decisão técnica sem depender de escrever cada linha, antecipando erro e ponto de falha onde a maioria nem enxerga risco. Eu mexo no Hugo quando preciso, sei ler e ajustar o que está na minha frente; mas abdico disso na maior parte do tempo, de propósito — entre escrever eu mesmo e dirigir quem escreve mais rápido e com menos erro, escolho a segunda opção: eficiência ganhando de ego técnico. Uso o Claude Desktop pra decidir arquitetura, tom e prioridade — o que construir e por quê — e o Claude Code pra execução, é ele quem escreve o Dockerfile, mexe no hugo.toml, ajusta SCSS; essa divisão de trabalho é o motivo de eu conseguir revisar decisão técnica com propriedade — não é que eu não saiba, é que sei onde vale mais gastar minha atenção.
Enquanto a base técnica mudava por baixo, a superfície também passou por uma segunda leva de mudanças: a versão bilíngue (PT/EN) que ganhou alternância de tema em agosto deu lugar a uma nova direção visual. Troquei a direção anterior por uma linha Editorial — faixas navy e beige alternadas na mesma página, sem alternância de tema (nada de light/dark mode, só o azul como base), Kaisei Tokumin reservado pra títulos e frases de destaque, Inter no corpo e na UI, e JetBrains Mono entrando como terceira fonte pra kickers, rótulos e numeração de seção — duas mudanças, uma motivação só: menos decoração emprestada, mais sistema que eu decido e sustento.
Versão 1: no braço
Essa reconstrução do zero não foi a primeira tentativa. Antes dela, cheguei a manter uma versão inteira em Hugo com tema herdado de terceiro — 61 rodadas de ajuste, entregues manualmente por ZIP, sem Git, sem histórico real, ao longo de três semanas e meia brigando com os mesmos problemas: acessor depreciado numa atualização do Hugo, case duplicado, seletor de idioma saindo da tela. Corrigir, empacotar, subir de novo — repetido 61 vezes. Foi ali que decidi que a próxima versão seria sem tema herdado e sem entrega manual, custasse o que custasse recomeçar do zero.
Pelo histórico do Git, essa primeira versão saiu do zero ao ar em oito dias corridos — cinco pra montar o Hugo com os quatro cases (Truss, Locaweb, Serasa, Cooperguincho) e o deploy funcionando, mais três pra fechar o brand guide; rápido, mas não do nada. Esses oito dias vieram depois de três meses construindo uma apresentação detalhada com os mesmos cases, e a parte difícil — garimpar, estruturar e escrever cada um até virar conteúdo apresentável — já estava resolvida antes de eu abrir o primeiro arquivo do Hugo. Pra quem empurrava a ideia de ter um portfólio havia anos, foram várias sessões até chegar no resultado que eu queria; mas a velocidade da execução final veio de o trabalho pesado já estar feito em outro lugar.
A primeira versão publicada rodava assim: build do Hugo local (hugo) e um script de 10 linhas, deploy.sh, que subia o resultado por rsync direto pra pasta da aplicação no Coolify.
#!/bin/bash
set -e
echo "🔨 Building Hugo..."
hugo
echo "📤 Syncing to server..."
rsync -avz --exclude-from=.gitignore public/ root@panel.benetti.me:/data/coolify/applications/████████████████████████
echo "✅ Deploy complete!"
Funcionava, mas dependia inteiramente de eu lembrar de rodar o script toda vez que mudava algo; sem histórico de deploy, sem vínculo entre commit e publicação, o Git tinha o código, o servidor tinha outra cópia, e a única coisa que os sincronizava era eu digitando um comando.
Versão 2: pipeline de verdade
A mudança que está em andamento agora: o repositório privado no Codeberg (rickbenetti/portfolio) virou a única fonte de verdade, e o Coolify passou a fazer o build a partir dele — Git-based, via Dockerfile multi-stage:
FROM hugomods/hugo:dart-sass-0.165.0 AS builder
WORKDIR /src
COPY . .
RUN hugo --minify
FROM nginx:alpine
COPY --from=builder /src/public /usr/share/nginx/html
EXPOSE 80
CMD ["nginx", "-g", "daemon off;"]
Nove linhas resolvendo o que antes era um script manual — e uma aprendizagem no meio do caminho que vale registrar: a primeira versão do Dockerfile usava klakegg/hugo, a imagem mais indicada nos tutoriais que encontrei; o build quebrou, porque klakegg/hugo está abandonada. Troquei para hugomods/hugo, mantida ativamente, e o pipeline voltou a rodar.
Onde isso está, de verdade
O pipeline novo já builda e publica sozinho a cada commit; uma vantagem que eu não esperava é o Coolify provisionar automaticamente um subdomínio próprio (via sslip.io, resolvendo direto pro IP do servidor) pra cada aplicação, o que dá pra validar o build completo, HTTPS incluído, sem tocar em DNS de produção. É isso que estou usando agora pra confirmar que cada commit gera o site certo antes de qualquer decisão sobre o domínio final; o que ainda falta, sendo direto, é fechar o webhook entre Codeberg e Coolify, pra que o deploy dispare sozinho a cada git push em vez de manual, e depois apontar o domínio de produção (rickbenetti.com.br) pra esse pipeline — isso ainda não aconteceu.
O que isso mostra sobre como eu trabalho
O ponto não é “designer que também programa” versus “designer que não programa” — essa dicotomia é falsa, e forçá-la seria o mesmo erro que cometi ao escrever, na primeira versão deste texto, que o site rodava em Astro (nunca rodou) publicado por sFTP (nunca foi); eu sei escrever o que precisa ser escrito. O que mudou foi uma escolha de alocação: entender profundamente o sistema — do Dockerfile ao DNS — e decidir, linha a linha, onde vale mais gastar minha atenção do que a delegar. Repositório privado, build reproduzível, zero dependência de plataforma de terceiros pra publicar — a soberania de dados que eu já buscava na versão 1 fica mais sólida, não mais frágil, com automação.
Codeberg e Coolify não foram escolha por modismo. Codeberg é uma cooperativa sem fins lucrativos rodando Forgejo — código aberto, sem depender de decisão comercial de Microsoft ou GitLab Inc. sobre o que acontece com repositório privado meu. E o Coolify já não era novidade: é a mesma plataforma que sustenta o resto da minha infraestrutura — e-mail, sites de cliente — rodando num VPS que eu já opero. Trocar de plataforma pra automatizar o portfólio teria sido inflar dependência exatamente onde eu queria reduzir; usar o que já rodava significou pipeline novo sem superfície nova pra manter.
Quer um sistema próprio?
É fácil perder a conta: $10 no e-mail, $10 ou $20 no gerenciador de senhas, mais uma mensalidade pra manter o site em pé em Framer ou Webflow — cada ferramenta com sua própria fatura, seu próprio login, e nenhuma sob seu controle de fato. Some tudo e é comum passar dos $50 por mês espalhados assim, pagando por peças soltas que somem se você parar de pagar. Eu monto o oposto: um VPS seu, com e-mail no seu próprio domínio, gerenciador de senhas, site e o que mais precisar rodando na mesma infraestrutura, deploy automatizado, você no controle de cada peça.