Construindo meu blog, parte 4: imagens no S3 pelo Finder

Mon, 19 Oct 2026 04:15:50 -0300

Selecionar uma imagem, usar o botão direito e receber uma URL pronta para o artigo. Era esse o tipo de facilidade que eu queria trazer para a rotina do blog. A automação da AWS foi a parte mais trabalhosa depois do design.

O caminho começou com um auxiliar de upload e chegou a uma Ação Rápida no Finder. O caso feliz era simples de descrever. O trabalho apareceu nas perguntas seguintes: o que acontece quando a sessão expira, quando eu desisto do login ou quando o envio falha?

Páginas na Hostinger, imagens no S3

O S3 armazena objetos: neste caso, os arquivos das imagens. As páginas continuam na Hostinger. O Markdown guarda a URL pública do arquivo e o navegador busca a imagem nesse endereço.

Isso separa o envio da imagem do build do site. Colocar um arquivo no repositório não executa um upload para a AWS. Também existem assets locais que acompanham o build; o fluxo das novas imagens editoriais usa o S3.

Uma URL de imagem publicada precisa continuar funcionando quando minha sessão termina. Por isso, o endereço usado no artigo não é um link assinado temporário. O prefixo das imagens tem leitura pública configurada, enquanto a escrita exige autenticação. O script de envio não transforma qualquer bucket privado em público.

O que chamo de versões das imagens

Cada envio recebe um nome novo, com ano, mês, nome normalizado e um identificador. Um caminho ilustrativo seria:

images/2026/10/minha-capa-identificador-unico.webp

Se corrigir uma capa, envio outro arquivo e atualizo a referência no artigo. A imagem anterior continua disponível até ser removida. Isso ajuda a evitar que uma URL com cache longo passe a representar outro arquivo sem controle.

Esse mecanismo é diferente do S3 Versioning, que mantém versões de um mesmo objeto dentro do bucket. Aqui estou descrevendo novas chaves e novas URLs. Não basta ter dois arquivos para afirmar que o recurso nativo de versionamento está ativado.

O histórico do Git registra as alterações na referência do artigo. Ele não é, por si só, um backup dos arquivos externos. Preservar e recuperar as imagens exige cuidar também do armazenamento delas.

Um usuário dedicado ao envio

O atalho usa um perfil da AWS CLI com credenciais temporárias de um usuário dedicado. Não depende da sessão root e não guarda uma chave permanente dentro do projeto.

A conta e as permissões são preparadas antes. O auxiliar usa esse destino existente; não provisiona um ambiente AWS inteiro. O login local pelo navegador da AWS CLI permite renovar a autenticação sem colocar senha ou código no artigo, no script ou em uma conversa.

No projeto configurado, a instalação da Ação Rápida parte da raiz:

python3 blog/scripts/install-finder-upload.py

Esse comando pertence ao repositório privado e requer o ambiente descrito acima. Ele não é um instalador público universal para qualquer conta AWS. Para reproduzir a ideia, é preciso adaptar destino, perfil e permissões ao próprio ambiente.

A rotina no Finder

Com a ação instalada, seleciono a imagem e uso Ações Rápidas → Enviar imagem ao S3 — Figueirego. Após o envio, a ação copia a URL e apresenta a notificação de conclusão. Não preciso abrir o Terminal para a rotina normal.

Se a sessão expirou, o atalho abre a autenticação no navegador e aguarda a conclusão. Depois do login autorizado, continua o envio. Foi importante testar o caminho completo pelo Finder: executar o auxiliar no Terminal não demonstraria, sozinho, que o aviso aparecia pela ação do macOS.

Também conferimos a URL pública e a imagem recebida. Uma mensagem de conclusão ajuda, mas não substitui verificar se o arquivo certo está acessível fora da sessão AWS.

A ação instalada no Finder, acessível pelo botão direito sobre a imagem. O menu foi aberto para esta captura, sem executar outro upload.

Ver captura em tamanho original

Cancelar também faz parte da interface

Esperar cinco minutos para descobrir que um login foi abandonado era ruim. A espera ganhou uma janela com Cancelar envio, para encerrar aquela tentativa de forma explícita.

Situação	Comportamento esperado
Sessão válida	Enviar, copiar a URL e avisar a conclusão.
Sessão expirada	Abrir o login e continuar depois de autenticar.
Cancelamento enquanto aguarda login	Avisar, não enviar a imagem e preservar o conteúdo copiado.
Nova tentativa após cancelar	Permitir iniciar o fluxo novamente.

Fechar apenas a aba do navegador não equivale a apertar o botão de cancelamento. E esse botão cancela a espera pela autenticação; ele não promete interromper um upload que já começou.

Testamos a espera primeiro com uma AWS simulada e depois com login real. As duas verificações respondem a perguntas diferentes: a simulação ajuda a controlar o cenário; o teste real confirma a integração que será usada.

Da imagem no Finder à URL copiada. O cancelamento durante o login encerra o fluxo antes do envio.

Abrir diagrama em tamanho original

O que ainda precisa de cuidado

Não removo automaticamente uma imagem antiga só porque enviei outra. Ela pode continuar referenciada por um rascunho, por outro texto ou por um feed já recebido. A limpeza precisa considerar essas referências.

Se o upload concluir, mas a cópia para a área de transferência falhar, isso também não desfaz o objeto enviado. É preciso distinguir falha de envio de falha na última etapa da conveniência, para não repetir uploads sem necessidade.

A automação tornou a rotina mais curta. O aprendizado foi dedicar atenção também aos caminhos de desistência e recuperação: uma ferramenta simples de usar precisa explicar quando terminou, quando falhou e o que aconteceu com o arquivo.