--- title: "Como migrar de nodes self-hosted para infraestrutura dedicada" description: "Migrar de nodes self-hosted para infraestrutura dedicada é uma troca de endpoint, não uma reconstrução. Por que os times fazem essa mudança, o que ganham com isso e como funciona." --- # Como migrar de nodes self-hosted para infraestrutura dedicada Rodar nós de blockchain internamente traz uma carga de trabalho que só aumenta. Cada chain que você suporta adiciona suas próprias atualizações para acompanhar, armazenamento para expandir e problemas de sincronização para detectar, e os engenheiros que fazem esse trabalho são os mesmos que deveriam estar construindo seu produto. Em algum momento, a manutenção consome mais tempo de engenharia do que retorna. A [infraestrutura dedicada gerenciada](https://www.alchemy.com/dedicated-clusters) é a saída que não sacrifica controle: clusters single-tenant que rodamos para você, com a mesma customização, isolamento e posicionamento regional que você mantém hoje no self-hosting. A migração em si é mais simples do que a maioria das equipes espera. Como um cluster dedicado roda as mesmas APIs que sua aplicação já chama, migrar para ele é basicamente uma troca de endpoint, não uma reconstrução. Este guia aborda por que as equipes deixam de fazer self-hosting, o que elas mantêm, como a troca funciona na prática, e como saber se essa é a decisão certa para você. ## Por que as equipes abandonam nós self-hosted Rodar seus próprios nós raramente é uma grande falha isolada. É um acúmulo constante de pequenas falhas, e cada uma tende a chegar aos seus usuários antes de chegar até você. Três delas motivam a maioria das migrações. A primeira é ficar atrás da ponta da chain. Um nó self-hosted que perde a sincronização continua respondendo requisições, só que com dados desatualizados. Seus usuários veem saldos com minutos de atraso, transações que já foram confirmadas mas não aparecem, e consultas que falham sem motivo sobre o qual eles possam agir. Tickets de suporte surgem, assim como a erosão silenciosa de confiança que vem de um app que está, ocasionalmente e de forma imprevisível, errado. Essa é a falha mais comum em self-hosting e a mais difícil de detectar de dentro, porque o nó parece saudável enquanto entrega respostas ruins. A segunda é acompanhar atualizações de cliente, em todas as chains que você roda. Cada rede define seu próprio ritmo de atualizações e anuncia no seu próprio canal, algumas no GitHub, outras em docs, Discord, Telegram, ou um Slack privado de parceiros, sem um lugar padrão para acompanhar. Manter-se atualizado significa monitorar dezenas de ecossistemas independentes, o que, em uma configuração multi-chain, soma dezenas de atualizações por semana. Perder uma não é uma experiência degradada, é downtime: o nó fica para trás, requisições começam a falhar, e transações de clientes quebram. A [atualização Fusaka do Ethereum](https://www.alchemy.com/blog/ethereum-fusaka-upgrade-dev-guide-to-12-eips) trouxe três mudanças em cerca de cinco semanas no fim de 2025, e isso é para uma única chain. Multiplique isso por todas as chains que sua aplicação suporta e manter a infraestrutura saudável deixa de ser "rodar um nó" e vira um trabalho em tempo integral. A terceira é o armazenamento que nunca para de crescer. Um nó de arquivo do Ethereum já precisa de [múltiplos terabytes de armazenamento NVMe rápido](https://reth.rs/run/system-requirements), e esse volume só aumenta com o tempo. Planejamento de capacidade não é uma configuração única, é uma responsabilidade operacional contínua, e quando o armazenamento se esgota, o nó não consegue mais sincronizar ou servir dados atualizados da chain. Aqui está o mesmo panorama de forma resumida, com a frequência de cada problema e o que muda quando os nós são gerenciados: Nodes fall behind the chain tip

", tooltip: "", icon: "", }, "2": { title: "

The most common self-host failure

", tooltip: "", icon: "", }, "3": { title: "

Users see stale balances and missing transactions; support tickets climb and trust erodes

", tooltip: "", icon: "", }, "4": { title: "

Redundant nodes, routing that sends traffic to healthy nodes, and a consistency manager keep every read block-perfect and prevent stale reads

", tooltip: "", icon: "", }, id: 0, }, { "1": { title: "

A mandatory client upgrade gets missed

", tooltip: "", icon: "", }, "2": { title: "

Dozens of upgrades across chains every week

", tooltip: "", icon: "", }, "3": { title: "

Downtime: the node falls behind and requests start failing

", tooltip: "", icon: "", }, "4": { title: "

We run and upgrade the clients, so the upgrade calendar is never your problem

", tooltip: "", icon: "", }, id: 1, }, { "1": { title: "

Archive storage outgrows the disk

", tooltip: "", icon: "", }, "2": { title: "

Grows continuously unless monitored

", tooltip: "", icon: "", }, "3": { title: "

A full disk crashes the node and takes the app down

", tooltip: "", icon: "", }, "4": { title: "

We provision and scale the hardware for you

", tooltip: "", icon: "", }, id: 2, }, { "1": { title: "

Peers drop, memory leaks, CPU spikes

", tooltip: "", icon: "", }, "2": { title: "

Intermittent, and always at the wrong hour

", tooltip: "", icon: "", }, "3": { title: "

Latency spikes and flaky errors degrade UX, and someone is permanently on call

", tooltip: "", icon: "", }, "4": { title: "

Fully managed and monitored, sized to your workload, automatic failover to shared infrastructure

", tooltip: "", icon: "", }, id: 3, }, ], }} /> ## O que você mantém, e o que você repassa Equipes fazem self-hosting por razões concretas, e um cluster gerenciado só vale a pena se você mantiver essas razões. E você mantém. - **Tracers e binários customizados.** Rode sua própria lógica diretamente nos nós, da mesma forma que equipes de segurança e forense, e qualquer um que faça simulação ou indexação customizada. - **Hardware customizado.** O cluster é dimensionado e configurado para sua carga de trabalho. - **Isolamento single-tenant.** Infraestrutura SOC 2 Type II com isolamento completo de ambiente, o requisito que leva a maioria das equipes regulamentadas e financeiras a rodar seus próprios nós em primeiro lugar. - **Posicionamento regional.** Clusters [são implantados perto da sua stack e dos seus usuários](https://www.alchemy.com/blog/alchemy-edge-proxy), o que faz a diferença que importa para trading sensível à latência e workloads em tempo real. O que você repassa é a operação: redundância, consistência block-perfect em todos os nós, atualizações de cliente, escalonamento de hardware e monitoramento, tudo gerenciado, com dashboards Grafana em tempo real para que você continue vendo tudo sem operar nada disso. Essa é toda a troca: o controle pelo qual você faz self-hosting, sem o plantão que vem junto. ## Como funciona a migração? Como os clusters dedicados expõem as [mesmas APIs do nosso Node RPC compartilhado](https://www.alchemy.com/rpc-api), a migração é majoritariamente configuração, não código. Você aponta sua aplicação para o endpoint do cluster, e os padrões de requisição que você já usa continuam funcionando. Não há SDK para trocar nem formatos de requisição para reescrever. Começa com o dimensionamento. Você compartilha seus números de tráfego e nós provisionamos o cluster para seus picos reais em vez de um palpite. Como nós rodamos os nós, o planejamento de capacidade deixa de ser seu trabalho desde o primeiro dia. A partir daí, a maioria das equipes roda o novo cluster em paralelo com os nós existentes por um curto período, compara os dois, e transfere o tráfego assim que estiverem satisfeitas. Seus próprios nós continuam ativos como fallback até você decidir desligá-los, e o failover automático para nossa frota compartilhada acompanha todo o processo, então nenhum momento específico depende dessa troca. Na prática, isso leva dias de tempo de calendário, não as semanas de esforço em tempo integral que as equipes costumam esperar. Depois, você recupera o hardware, encerra o plantão e para de acompanhar atualizações de cliente. Algumas equipes mantêm um nó rodando como referência independente; a maioria percebe que não precisa disso. Confira este artigo detalhado para entender [como funciona a infraestrutura dedicada de blockchain](https://www.alchemy.com/blog/how-dedicated-blockchain-infrastructure-works). ## Infraestrutura dedicada é o caminho certo para você? Dedicado não é um upgrade que todos deveriam querer. Se sua carga de trabalho roda confortavelmente em um plano compartilhado gerenciado, esse é o melhor lugar para você: é elástico, você paga pelo que usa, e o escalonamento é problema de outra pessoa, sem se comprometer com capacidade provisionada. As equipes que se beneficiam de dedicado são as que têm um motivo específico e duradouro: execução customizada, isolamento single-tenant, uma região que você não consegue alcançar de outra forma, ou volume sustentado que torna a capacidade provisionada a opção mais econômica. Se você não tem certeza de qual descrição se aplica a você, nosso guia sobre [como escolher entre Node RPC e Dedicated Clusters](https://www.alchemy.com/overviews/dedicated-vs-shared-nodes) percorre a decisão de forma honesta. O objetivo é a infraestrutura certa, não a maior. ## Pronto para deixar de usar nós self-hosted? [Dedicated Clusters](https://www.alchemy.com/dedicated-clusters) dão a você controle single-tenant sem a operação: tracers, binários e hardware customizados, consistência block-perfect, e failover automático para a mesma frota compartilhada que entregou [99,99% de uptime durante o maior evento de liquidação da história das criptomoedas](https://www.alchemy.com/blog/best-uptime-biggest-liquidation-event-in-crypto). Confira o [anúncio de lançamento do Dedicated Clusters](https://www.alchemy.com/blog/introducing-dedicated-clusters) para mais informações detalhadas. [Fale com nosso time de Dedicated Clusters](https://www.alchemy.com/dedicated-clusters) sobre sua carga de trabalho, ou traga os números de tráfego da sua configuração atual e nós dimensionamos o cluster para você. Você mantém as APIs com as quais já constrói, nós rodamos os nós, e o failover para infraestrutura compartilhada está lá desde o primeiro dia.