Hospede seu próprio BTCPay Server em um VPS

O discurso de venda geralmente é “sem taxas”, que é a parte menos interessante disso. Quatro coisas mudam, e só uma delas é sobre dinheiro:

• Ninguém segura os seus fundos em trânsito. Um processador hospedado por terceiros recebe o pagamento do cliente na própria carteira dele e só depois credita para você. É nessa brecha que acontecem retenções, revisões e bloqueios. O BTCPay nunca recebe nada: o cliente paga um endereço derivado da sua chave, e as moedas são suas desde a primeira confirmação.
• Ninguém pergunta quem você é. Entrar em um processador é um processo de identidade que termina em um banco. Instalar um software não é. Essa é a diferença inteira, e é por isso que a resposta para “como eu recebo cripto sem KYC” é sempre “rode o processador você mesmo”.
• O custo para de escalar com você. Uma porcentagem é cobrada para sempre e cresce com o sucesso. Um VPS e um domínio custam o mesmo em um mês bom e em um mês ruim.
• Você herda o trabalho operacional. Uptime, atualizações, backups, e ser a pessoa que recebe a mensagem quando um cliente diz que a fatura nunca foi confirmada. Esse é o preço de verdade, e ele é pago em atenção, não em dinheiro.

O que você não ganha é a única coisa em que os processadores são genuinamente bons: transformar moedas em dinheiro de conta bancária em seu nome. O BTCPay guarda o que foi pago, na moeda em que foi pago. Conversão, faturamento em moeda fiduciária, exportações contábeis que uma autoridade fiscal reconheça — problemas totalmente separados, e a maioria das formas de resolvê-los reintroduz exatamente a contraparte identificada que você acabou de remover. Descubra qual metade dessa troca você realmente queria antes de construir qualquer coisa.

O nome engana de um jeito útil. “BTCPay Server” não é um programa só; o deploy padrão é uma pequena frota de contêineres que sobem juntos, e saber qual é qual faz a diferença entre dimensionar isso direito e simplesmente chutar:

• Bitcoin Core. Um nó completo de verdade, validando desde o genesis. Este é o componente que consome seu disco, a maior parte do primeiro dia, e quase toda a memória. Todo o resto é, em comparação, de graça.
• NBXplorer. O indexador entre o Core e o BTCPay. Você entrega a ele chaves públicas estendidas; ele rastreia os endereços derivados e avisa o BTCPay quando o dinheiro chega. É também a peça que se importa com a poda, por motivos que a seção de modos de falha retoma.
• O BTCPay Server em si. A aplicação: lojas, faturas, a página de checkout, o ponto de venda, webhooks, a Greenfield API. Modesto em comparação — algumas centenas de megabytes de memória.
• PostgreSQL. Faturas, lojas, configurações, usuários, chaves de API. Pequeno, e é para isso que os seus backups realmente servem.
• nginx com certificados automáticos. Um proxy reverso mais um companheiro que emite e renova um certificado para o seu hostname. É por isso que as portas 80 e 443 precisam estar genuinamente alcançáveis pela internet.
• Opcionalmente um nó Lightning (Core Lightning ou LND) e um daemon Monero com um RPC de carteira ao lado — cada um trazendo sua própria chain e seu próprio apetite por disco.

Então a pergunta de dimensionamento nunca é “quão grande o BTCPay precisa ser”. É “quanta chain eu estou guardando, e quantas chains”. Responda isso e o plano se escolhe sozinho.

O projeto documenta 2 GB de RAM com swap como mínimo e 4 GB como recomendação, e a diferença entre esses dois números é a diferença entre uma instalação que tecnicamente termina e uma que você está disposto a indicar para clientes. Um runtime de aplicação, o PostgreSQL e um bitcoind sincronizando, dividindo 2 GB, vão terminar — devagar, com o arquivo de swap fazendo um trabalho que não deveria precisar fazer.

O disco é definido por quão forte você poda, e o deploy expõe isso como um fragmento que você passa para o instalador. A família roda aproximadamente o opt-save-storage em cerca de 100 GB de arquivos de blocos, o -s em cerca de 50 GB, o -xs em cerca de 25 GB e o -xxs em cerca de 5 GB. Esse último é uma armadilha para qualquer coisa que precise sobreviver: ele mantém tão pouco histórico que a manutenção comum começa a falhar. Para uma loja, -s ou -xs é a faixa sensata.

Números concretos da grade, porque “depende” não é uma resposta:

• Só Bitcoin, podado, uma loja — Scout, 2 vCPU / 4 GB / 70 GB NVMe, $9.00/mo. O piso honesto, e a resposta certa para a maioria dos leitores.
• Bitcoin e Lightning — Runner, 3 vCPU / 6 GB / 100 GB, $14.00/mo. Um daemon Lightning é leve em disco e insistente em ficar online; a folga é para o nó por baixo dele.
• Bitcoin, Lightning e Monero — Alpha, 6 vCPU / 12 GB / 200 GB, $28.00/mo. Uma chain Monero podada tem sozinha cerca de 85 GB, então duas chains e dois indexadores é onde 8 GB fica apertado. Hunter (4 vCPU / 8 GB / 140 GB, $19.00/mo) cabe só se o Bitcoin ficar podado com força e continuar assim.
• Um nó não podado por trás da loja — um projeto diferente, com uma conta diferente. O guia de nó completo tem esses números, e eles começam no Fenrir.

A CPU importa exatamente uma vez. A verificação de assinaturas durante o download inicial de blocos é paralelizável, então de duas a quatro vCPU transformam a primeira sincronização de dias em cerca de um dia, e depois voltam a ficar ociosas. A banda é um custo único da chain inteira, em uma porta de 1 Gbps com tráfego ilimitado e sem fatura por excedente no fim do mês. Latência é irrelevante para um processador de pagamentos, então escolha o local pela jurisdição, não pelos milissegundos — Amsterdã, Paris, Bucareste e Sófia ficam todas no preço base.

Uma lista curta, e um item dela não é técnico.

• Um domínio, com um registro A já apontando para o servidor. O certificado é emitido via HTTP contra esse hostname, então o DNS precisa resolver antes de o instalador rodar, não durante. Um subdomínio como pay.example.com é o formato normal.
• Portas 80 e 443 abertas para o mundo. A porta 80 não é opcional, mesmo que nada de útil sirva nela depois; o desafio do certificado precisa dela.
• Debian 13 da biblioteca de templates, em uma máquina que já passou pelos dez minutos de hardening. Faça isso primeiro — é bem mais difícil fazer com educação depois que uma stack já está rodando.
• Uma carteira que você já controla, e sua chave pública estendida. Sparrow, Electrum ou uma carteira de hardware. Tenha-a em mãos antes de instalar, para nunca ficar tentado a deixar o servidor gerar uma para você.
• Um endereço de e-mail para a autoridade certificadora. Ele só recebe avisos de expiração, e nada mais.
• Uma decisão sobre poda, tomada agora. Mudar de ideia depois significa ressincronizar a chain do zero, um dia que você não vai gostar de gastar duas vezes.

Quase todo resultado ruim com um processador auto-hospedado remonta a uma única decisão tomada cedo e sem cuidado: deixar o servidor guardar algo capaz de gastar. Vale a pena ser explícito sobre os três casos, porque eles são genuinamente diferentes.

• Bitcoin on-chain: somente observação, sempre. O BTCPay guarda uma chave pública estendida e mais nada. Se a máquina for comprometida, o invasor descobre o que você recebeu e pode mudar para onde as futuras faturas apontam — um ataque real, e o motivo para reconferir a carteira da sua loja depois de qualquer incidente — mas não consegue tocar em uma moeda já recebida.
• Lightning: quente por definição. Os canais são financiados com moedas que o servidor pode gastar, porque é isso que um canal é. Esta é a exceção deliberada, e a seção acima dimensiona ela.
• Monero: somente visualização, estruturalmente. A chave privada de visualização revela todo pagamento que chega e não autoriza nenhum deles. Não existe equivalente do lado do Bitcoin.

A única funcionalidade que quebra esse modelo de propósito é o Payjoin. Ele deixa seu servidor contribuir com uma entrada na transação do cliente, o que degrada de forma significativa a heurística de entrada comum em que a análise de chain se apoia, e é um ganho real de privacidade para as duas partes — mas quem recebe precisa conseguir assinar, então isso exige uma carteira quente dentro do BTCPay. Essa é uma troca real, não uma funcionalidade de graça. Assuma isso conscientemente, e financie-a do mesmo jeito que você financia a carteira do Lightning: com um valor, não com tudo.

E se você deixar o assistente de configuração gerar a carteira da loja porque era o caminho mais rápido: anote a seed que ele mostrou, verifique-a em uma carteira offline, e depois planeje a migração para uma configuração somente observação. Uma seed que já esteve em um servidor exposto à internet é uma seed com uma contagem regressiva correndo.

Organize o estado pelo que seria preciso para recriá-lo, porque as respostas são bem diferentes:

• A chain. Não é um problema de backup. É um dado público e ela ressincroniza, devagar e de graça. Nunca faça backup dela.
• O banco de dados. Faturas, lojas, configurações, usuários, chaves de API. Este é o backup de verdade, é pequeno, e perdê-lo custa o registro contábil de cada venda — não o dinheiro, mas o papelório.
• Sua carteira on-chain. Já está segura, porque a chave nunca esteve aqui. Essa é a recompensa do passo cinco.
• O estado dos canais Lightning. O que morde. Um backup estático de canal deixa você recuperar os fundos dos seus canais depois de uma perda total, forçando o fechamento deles; ele não restaura os canais, e não vale nada se estiver desatualizado. Ele muda toda vez que um canal abre ou fecha, então pertence a uma cópia automatizada fora do local, não a uma pasta que você lembra trimestralmente.
• A carteira Monero somente visualização. Reconstruível a partir do endereço e da chave de visualização que você ainda guarda offline. Faça backup delas e trate os arquivos da carteira como um cache.

O deploy vem com ferramentas auxiliares que fazem isso corretamente:

btcpay-backup.sh    # stops the stack, dumps Postgres, tars the config, restarts
btcpay-restore.sh   # puts one of those archives back

Essa pausa é o ponto principal — uma cópia quente de um banco de dados rodando pode restaurar para algo problemático. Criptografe tudo o que sai da máquina, e lembre-se de que o snapshot semanal incluído em todo plano é uma conveniência, não um backup: um snapshot mora junto com a coisa que ele protege.

Em ordem aproximada de quantas vezes já custaram uma noite de alguém:

• O certificado nunca é emitido. Nove em cada dez vezes o registro A foi criado depois que o instalador rodou, ou a porta 80 está filtrada. Corrija o DNS, confirme que o nome resolve a partir de algum lugar que não seja o seu próprio laptop, e então rode o script de configuração de novo. Tentar de novo às cegas contra a autoridade certificadora rende um rate limit e uma semana de espera, então mude alguma coisa entre as tentativas.
• Uma chave estendida importada com histórico não mostra saldo. Esta é a armadilha da poda. O indexador encontra pagamentos novos observando blocos novos, mas reconstruir o passado de uma carteira já existente significa ler blocos que um nó podado já apagou. Use uma conta nova para a loja e o problema simplesmente não existe; se você precisar importar histórico, vai precisar de um nó não podado e de um rescan.
• “O cliente pagou e a fatura continua aberta.” Geralmente é subpagamento pela taxa da carteira que enviou, uma fatura que expirou enquanto o pagamento ficava sem confirmação, ou uma política de confirmação mais rígida do que você lembra de ter escolhido. As três são configurações, e as três são o motivo de você testar primeiro com o seu próprio dinheiro.
• O nó fica para trás silenciosamente. Um bitcoind travado distribui endereços e perde pagamentos sem reclamar. Compare a sua altura de bloco com qualquer fonte pública em um cronômetro e alerte sobre a diferença; isso não é algo para você aprender através de um cliente.
• Uma atualização no momento errado. O btcpay-update.sh se comporta bem, mas reinicia tudo. Rode-o de forma deliberada, nunca automaticamente, e nunca durante uma venda.
• O endereço ganha uma reputação. Uma página de checkout em um IPv4 na blocklist é uma página de checkout que algumas redes corporativas e filtros de e-mail recusam silenciosamente. Todo plano aqui vem com um endereço dedicado sem histórico, e vale a pena verificar isso antes de imprimir o domínio em qualquer lugar.

O software remove uma contraparte. Ele não remove o resto da superfície, e ser honesto sobre isso é mais útil do que mais uma lista de funcionalidades.

O domínio é o ponto fraco. Ele é registrado em algum lugar, resolve publicamente, e é a primeira coisa que qualquer um olha. Um processador auto-hospedado em um hostname registrado no seu próprio nome, em um registrador no seu próprio país, tirou o dinheiro das mãos de terceiros e deixou a identidade exatamente onde estava. Se isso importa para o que você vende, o registrador merece pelo menos tanta atenção quanto o host.

A jurisdição é uma variável real. Onde a máquina fica decide de quem é a ordem judicial que a alcança e quanto processo fica no caminho. Isso é atrito e distância, não imunidade — um ponto que o verbete de hospedagem offshore explica em detalhes, e vale a pena ler antes de escolher uma bandeira em vez de uma rede.

A conta é o último elo. Alugar o servidor com um endereço de e-mail e pagar em Monero significa que nenhum extrato de cartão liga a página de checkout a um banco — uma coisa estranha de esquecer enquanto você constrói um sistema cujo ponto inteiro é não precisar de um. Todo plano aqui é no-KYC por padrão, e todo local vem com um IPv4 limpo e dedicado com DNS reverso personalizado.

E o limite é declarado, não implícito. Nós, processadores e lojas são infraestrutura comum e são bem-vindos aqui; a política de uso aceitável é curta, pública, e tem um piso embaixo dela. Se você precisa de uma licença para receber pagamentos é uma pergunta sobre o que você vende e onde você está, não sobre o software — e é uma pergunta para alguém qualificado, não para um guia de hospedagem.