Substituí o meu agendador de redes sociais por um fluxo de trabalho n8n auto-hospedado

Cinco dólares por canal, por mês. Era esse o número para o qual continuava a olhar no ecrã de renovação, porque decidia em silêncio em quantos sítios eu podia publicar. Quatro canais eram quatro vezes cinco. Acrescentasse eu uma segunda marca mais tarde e a fatura voltava a subir pelas mesmas publicações agendadas que já escrevia sozinho.

Já tinha o n8n a correr num VPS para duas automações sem relação entre si, por isso dei-me um fim de semana para ver se conseguia transformá-lo num agendador de redes sociais n8n para X, LinkedIn, Instagram e Facebook. Está a funcionar há quatro meses. Eis o que a mudança me custou realmente, o que falhou e onde continuo a não a recomendar.

A versão curta

• Consegui publicar no X, LinkedIn, Facebook e Instagram a partir do mesmo fluxo de trabalho, mas os quatro ramos não exigiram a mesma quantidade de trabalho.
• O Instagram foi o problema: a exigência de conta profissional, as regras de media, os limites de publicação e o ciclo de vida dos tokens criaram uma manutenção que eu não tinha com o Buffer.
• Deixei o TikTok de fora porque o catálogo de nós de aplicação integrados do n8n não o inclui, e não estava disposto a tornar uma integração personalizada ou da comunidade parte do meu calendário de publicação.
• A Community Edition eliminou a taxa de software, não o custo. Continuei a pagar o alojamento e a tratar das atualizações, credenciais, cópias de segurança, monitorização e recuperação de publicações falhadas.
• O meu veredicto: a mudança valeu a pena porque queria a redação e a publicação num único pipeline. Se quisesse apenas um calendário visual e filas fiáveis, teria ficado.

O que eu estava a pagar e o que fez pender a balança

Os preços atuais do Buffer indica o Essentials a 5 $ por canal por mês com faturação anual, enquanto o plano gratuito suporta até três canais e dez publicações agendadas por canal. Os meus quatro canais pagos ficavam, portanto, em 20 $ por mês com faturação anual. É uma forma razoável de vender um agendador cuidado, mas cobrava-me exatamente aquilo que eu queria expandir: remodelar uma ideia para vários sítios ao mesmo tempo.

No fim, não foi o preço que me decidiu. Já redigia as publicações com um modelo noutra janela e depois colava-as à mão no agendador. Duas ferramentas faziam um único pipeline evidente. Assim que vi o fluxo de trabalho que queria, pagar uma subscrição para manter a redação e a publicação em duas metades separadas deixou de fazer sentido para mim.

O que faz o meu fluxo de trabalho

O meu fluxo de trabalho é deliberadamente aborrecido. Um Schedule Trigger dispara algumas vezes por dia, lê a próxima linha aprovada da minha Google Sheet, adapta o texto a cada plataforma, envia cada versão pelo seu próprio ramo de publicação e regista o resultado. Mantenho um estado de aprovação humana na folha e só publico as linhas que aprovei. Os ramos que falham disparam um alerta fora do n8n, para que uma credencial partida não desapareça dentro de um registo de execução.

O passo de redação chama a API de um modelo alojado. Ponderei por instantes correr um modelo na mesma máquina, mas com algumas dezenas de publicações por mês, os fatores de custo de auto-hospedar um modelo eram maiores do que a minha fatura de API. O volume de uso, a privacidade ou a latência poderiam mudar essa decisão, mas não tinha motivo para operar infraestrutura extra só para reescrever publicações. O fluxo de trabalho não é engenhoso, e é em parte por isso que confiei nele.

A realidade plataforma a plataforma (o Instagram é o problema)

Três dos meus quatro ramos correram quase sem sobressaltos. O Instagram consumiu mais tempo do que todo o resto do projeto junto e foi a plataforma onde as publicações falhadas me eram mais difíceis de ignorar. A tabela mostra as vias que usei ou avaliei; os detalhes por baixo são as partes que afetaram a minha configuração.

Para o LinkedIn, a documentação do nó LinkedIn cobre a criação de publicações para pessoas e organizações, e o guia de credenciais do LinkedIn do n8n afirma que publicar como organização implica submeter a sua app à Community Management App Review do LinkedIn. Isso cobria aquilo de que eu precisava. A documentação de credenciais do X diz que o X aplica limites de taxa por tempo em cada endpoint, conforme o nível do seu plano de acesso de programador. Com o meu volume de publicação nunca cheguei ao teto, mas continuo a encará-lo como um limite que o X pode mudar, e não como uma promessa do n8n.

O guia de publicação de conteúdo da Meta documenta o JPEG como único formato de imagem suportado e um limite de 100 publicações através da API numa janela móvel de 24 horas para a via documentada. A regra do JPEG custou-me uma noite, porque as minhas exportações eram PNG por predefinição e a falha não era visível de dentro do n8n. Mantenho esse limite de publicação ligado à via e à versão de API atuais, em vez de o dar como permanente.

Falhou duas vezes em quatro meses. Ambas as vezes, o Instagram. Os tokens de acesso de longa duração não são eternos, e a referência da Meta sobre a renovação de tokens diz que um token só pode ser renovado enquanto não estiver expirado e tiver pelo menos 24 horas. Se perder essa janela, a renovação deixa de ser a via de recuperação. O meu erro foi tratar a autenticação como trabalho de instalação em vez de manutenção contínua. Um fluxo de publicação precisa de vigilância dos prazos, de uma renovação antecipada e de um alerta quando a renovação falha.

O TikTok simplesmente não fez parte da minha substituição. O catálogo de nós de aplicação integrados não o inclui. Podia ter usado o nó HTTP Request, um nó próprio ou um da comunidade, mas isso tornar-me-ia responsável por mais gestão de credenciais e mais avarias. Estava a substituir um agendador, não a oferecer-me para manter mais uma integração de plataforma.

As contas do custo, incluindo o meu tempo

Usei o Buffer Essentials com quatro canais como referência. Os preços publicados abaixo referem-se a faturação anual e foram verificados em agosto de 2026; deixei os valores em dólares e em euros nas moedas em que são publicados, em vez de fingir que são diretamente equivalentes.

Os preços de cloud do n8n coloca o Starter mais ou menos na mesma faixa de entrada dos meus quatro canais do Buffer Essentials. Isso matou a opção gerida no meu caso: pagaria um valor mensal parecido por um motor de fluxos de trabalho e perderia a interface de publicação mais agradável. A comparação da Community Edition confirmou que podia ficar com a edição auto-hospedada básica sem taxa de software, mas isso não tornou grátis nem o servidor nem o meu tempo.

Também não transformaria o tamanho da minha máquina num mínimo universal de produção de 4 GB de RAM e 2 vCPU. Os pré-requisitos de implementação do n8n dão um intervalo de recursos largo. A minha carga é pequena, mas outra instalação pode mudar depressa com execuções concorrentes, cargas de media, passos de código, carga na base de dados e um histórico de execuções mais longo. A resposta honesta é partir da carga de trabalho e vigiar memória e CPU.

O SQLite é a base de dados predefinida do n8n e pode chegar para uma instalação de instância única e baixo volume. Ainda assim, prefiro o PostgreSQL assim que o histórico de execuções conta ou se espera que a implementação cresça. O PostgreSQL é também o que uma configuração distribuída em modo de fila precisa, porque o n8n não suporta essa arquitetura sobre SQLite. Prefiro tomar essa decisão na instalação a migrar uma base de dados depois de o fluxo de trabalho se ter tornado importante.

O VPS nunca foi a parte cara. O meu fim de semana foi. Depois veio a noite perdida por causa do JPEG, as falhas de tokens e a verificação recorrente de que as publicações tinham mesmo saído. Se der algum preço às minhas próprias horas, a poupança encolhe depressa e pode ficar negativa. É esse o ponto em que o auto-alojamento deixa de ser barato. Continuo a achar que a mudança valeu a pena, mas na primeira semana não teria dito isso.

LER

A Stack Self-Hosted para Indie Hackers: A melhor forma de substituir a sua enorme fatura SaaS

O que falhou e o que mudei

As duas falhas visíveis foram falhas de token do Instagram, mas o problema de fundo era o silêncio. Um agendador por subscrição dá-me uma superfície de produto pensada para mostrar problemas de conta. O meu primeiro fluxo de trabalho podia falhar dentro do n8n enquanto o sintoma público era apenas um dia sem publicações. Isso ensinou-me que um publicador auto-hospedado tem de falhar em voz alta e recuperar sem duplicados.

• Envio os alertas de falha para um canal fora do n8n, com a resposta da plataforma e o ID de execução do fluxo, para não depender do mesmo sistema para me dizer que está avariado.
• Acompanho as datas de expiração dos tokens e o estado das revisões da app, e testo a renovação com antecedência suficiente para reautorizar antes que uma publicação agendada seja o primeiro aviso.
• Registo um ID de conteúdo único antes de publicar, o que permite a um ramo de plataforma falhado tentar de novo sem republicar nos ramos que já correram bem.
• Faço cópia do volume de dados e da base de dados do n8n, e considero o teste de restauro parte da cópia de segurança em vez de assumir que uns ficheiros copiados me vão salvar.
• Fixo as versões da API onde o fornecedor o permite, leio os registos de alterações e testo cada ramo de plataforma depois de uma mudança do lado do n8n ou do fornecedor.
• Podo o histórico de execuções e os ficheiros de media consoante a retenção de que realmente preciso, porque os materiais para redes sociais podem transformar uma automação minúscula numa cópia de segurança desnecessariamente grande.

Não correria isto a partir de uma máquina lá de casa. Uma publicação agendada para as 9 da manhã exige o fluxo de pé às 9, e a eletricidade doméstica, a ligação, o NAT e as chamadas de retorno acrescentam variáveis que não quero num calendário de conteúdos. Um VPS remove essas variáveis da rede doméstica; não remove a minha responsabilidade sobre TLS, cópias de segurança, monitorização, atualizações ou recuperação.

Quem não deve fazer isto

Fique com o agendador pago se o que quer é um agendador. Isso não é um prémio de consolação. Se um calendário, pré-visualizações, aprovações simples, cobertura ampla de canais e manutenção mínima lhe valem a subscrição, comprá-los é a decisão certa. Sem necessidade de automação à medida, trocar essa interface por uma tela de fluxos é um retrocesso com passos a mais.

Se quer um produto com o formato do Buffer mas que seja seu, eu olharia para o Postiz antes do n8n. A sua versão de código aberto pode correr no seu próprio servidor, e a lista de plataformas inclui o TikTok entre mais de 30 canais suportados. É um calendário de publicação em vez de uma tela de fluxos, o que faz dele um destino mais natural para muita gente que deixa um agendador pago.

Voltaria a fazê-lo apenas porque queria a pesquisa, a redação, a aprovação, a publicação e o registo num único pipeline. Foi essa a troca que aceitei: não agendamento grátis, mas controlo pago com atenção. Se só precisasse de agendar, voltava à subscrição.

Se quiser seguir a mesma via auto-hospedada, a nossa implementação do n8n num clique elimina o passo inicial de instalar o servidor. Não elimina o trabalho que achei mais importante: credenciais do fluxo, aprovações das plataformas, atualizações, cópias de segurança, monitorização e recuperação de publicações falhadas.

Perguntas frequentes

As autorizações do Buffer transitam para o n8n?

Não. As ligações às plataformas que eu tinha concedido ao Buffer pertenciam à app e ao fluxo de autorização do Buffer. O meu fluxo no n8n precisava das suas próprias credenciais, tokens, âmbitos e de qualquer revisão de plataforma exigida para a conta ou a via de publicação.

Cada plataforma social deve ter o seu próprio ramo?

Normalmente sim. Usei ramos separados para poder adaptar o texto, os media, as credenciais e o tratamento de erros a cada plataforma. Isso também permitia que um pedido falhado do Instagram tentasse de novo sem republicar algo que já tinha corrido bem no X ou no LinkedIn.

Pode um único fluxo do n8n publicar para vários clientes?

Sim, mas eu isolaria credenciais, fontes de conteúdo, estados de aprovação e registos por cliente. As permissões e quotas das plataformas continuam a aplicar-se à app e à conta em causa, por isso uma ligação bem-sucedida nunca deve ser tomada como acesso universal.

Como deve um fluxo recuperar publicações falhadas?

Consulto as publicações aprovadas cuja hora agendada já passou e depois publico apenas os registos sem resultado bem-sucedido. Um ID de conteúdo único e a resposta da plataforma guardada impedem que um reinício ou uma nova tentativa dupliquem publicações que já saíram.