Implante sua primeira aplicação em um servidor com o erpc worker

Crie uma pequena API HTTP em Rust com o erpc worker, execute-a na sua máquina e implante-a em um servidor com quatro comandos.
Esta página descreve o ERPC CLI v0.1.0-rc.4, uma versão de pré-lançamento.
O erpc worker (alias erpc w) compila sua aplicação em um binário nativo para Linux e a executa em um ERPC VPS, em um novo VPS por hora ou em um servidor próprio, sob uma unidade systemd com hardening, sem Docker e sem nenhum runtime no meio.
Uma release que não fica saudável volta por rollback à release anterior, e várias aplicações podem compartilhar um servidor, cada uma em uma porta própria. Tudo sobre a aplicação está no erpc.toml na raiz dela, que não contém nenhum segredo e pode ser incluído em um commit.

Pré-requisitos

  • Uma conta ERPC, com login feito nesta máquina com erpc login (Login e chaves).
  • ERPC Credit, para um novo VPS por hora. Um produto por hora é pago com ERPC Credit, comprado antecipadamente, e uma ativação que o crédito não cobre é recusada. Os preços estão em Preços e no ERPC Web Dashboard.
  • Uma chave SSH nesta máquina: ssh-keygen -t ed25519, ou erpc config set ssh_key <path>.pub para uma chave que você já tem.
  • Uma forma de compilar para Linux. A partir de um Mac ou de um Windows: o target Rust do servidor (rustup target add x86_64-unknown-linux-gnu), o zig (brew install zig no macOS) e o cargo-zigbuild (cargo install cargo-zigbuild --locked). A partir de uma máquina Linux do mesmo tipo do servidor (x86-64 em todos os servidores ERPC), nada além do cargo. Sem as ferramentas de compilação cruzada, a aplicação é compilada com a toolchain desta máquina, e o binário passa a precisar da glibc com a qual foi linkado, que o build e o deploy informam. Com elas, a aplicação é compilada para a glibc 2.31 ou superior.

Implantar o HelloWorld

O HelloWorld é uma pequena API HTTP em Rust que não precisa de chave, de segredo nem de linha de dados. Ele responde a GET /, GET /hello/{name} e GET /healthz.
bash
erpc worker init --template helloworld   # makes ./hello-world
erpc worker run hello-world              # here: curl http://127.0.0.1:3000/
erpc worker deploy hello-world           # your VPS, or a new hourly one (price asked first)
erpc worker api / --dir hello-world      # {"message":"Hello, World!",…} from the server
  1. O init cria a aplicação em ./hello-world, com o erpc.toml dela.
  2. O run compila a aplicação e a executa na sua máquina, para que você possa chamá-la primeiro com curl.
  3. O deploy compila a aplicação para o servidor e a implanta. Tudo o que custa dinheiro é mostrado antes, com o preço por hora, o seu saldo e quanto tempo o crédito dura, e, em um terminal, só começa depois de um sim.
  4. O api chama a API da aplicação implantada a partir da sua máquina, com a API ainda no loopback do servidor.
O erpc worker check lista o que falta à aplicação, e o deploy se recusa a prosseguir antes de comprar qualquer coisa quando falta algo. O erpc worker build executa apenas a compilação, que é a forma de ver uma compilação falhar antes de um servidor ser comprado.

Escolher um modelo

O erpc worker init pergunta uma única coisa: o que criar, escolhido com as setas do teclado.
  • HelloWorld é o modelo para começar.
  • HFT e pumpfun-bot são, por enquanto, feitos ambos a partir do modelo pumpfun: um trading bot para pump.fun (PumpSwap) portado de ValidatorsDAO/solana-stream.
O --template hft (ou helloworld, pumpfun-bot ou um id de modelo) pula o seletor, e o --name dá nome à aplicação. Sem um nome, a aplicação recebe o nome da escolha (hello-world, hft-bot, pumpfun-bot). Quando já existe um diretório com esse nome, uma pessoa que está escolhendo recebe -2, -3 e assim por diante, e um script (--yes, --json, sem terminal) recebe um erro. Sem ninguém a quem perguntar e sem --template, o que é criado é o HelloWorld.
Um trading bot precisa de uma chave e de algumas configurações antes de rodar. Esta é a ordem:
bash
erpc login                             # once per machine: the session in 1Password or the keychain
erpc worker init                       # pick with the arrow keys; makes ./<name> with erpc.toml
cd <name>
erpc worker key new                    # the trading key, in 1Password, the keychain or the keystore; prints the public key to fund
erpc worker secret put API_TOKEN --generate          # the bot's own API token, made for you and shown to nobody
erpc worker secret put ERPC_API_KEY --from-account   # the account's RPC key, read from your account (or SOLANA_RPC_ENDPOINT in [vars])
erpc worker check                      # what erpc.toml describes, and what is missing
erpc worker run --grpc --ip <IPV4>     # build and run here, with an hourly gRPC line letting this machine in
erpc worker run --check --grpc --ip <IPV4>   # the same, stopped once healthy
erpc worker deploy --new-vps --grpc    # a new hourly VPS and gRPC line, prices asked first
O init mostra essa ordem para a aplicação que criou. Chaves e segredos explica onde a chave e os segredos ficam guardados.

Escolher o servidor

O deploy usa a primeira destas opções:
  1. o servidor que o [env.<name>] da aplicação já indica;
  2. --vps <id>, um ERPC VPS da sua conta;
  3. --new-vps, o VPS por hora mais barato na região mais próxima desta máquina, de acordo com o fuso horário dela (--region e --plan escolhem outra coisa);
  4. --host <address>, um servidor próprio: Ubuntu ou Debian com systemd, nftables, sudo e Python 3 em /usr/bin/python3, acessado como root ou como um usuário com sudo sem senha;
  5. caso contrário, em um terminal, uma lista dos VPSs em execução da sua conta, com "start a new one" no final.
Em um servidor próprio, o firewall do worker descarta toda conexão de entrada, exceto SSH e a porta da aplicação, então um servidor que serve qualquer outra coisa não é o servidor indicado.

Implantar sem uma pessoa no terminal

Um script, ou um agente como o erpc ai, não tem um terminal em que responder. Duas flags permitem que ele faça o trabalho mesmo assim:
bash
erpc worker deploy hello-world --new-vps --yes                     # no key: all the way, unattended
erpc worker deploy pump-sniper --new-vps --grpc --yes --prepare    # a bot: everything but its key
erpc worker deploy pump-sniper                                     # then you, at a terminal: the key, and the start
  • --yes responde ao preço de cada produto por hora que o comando indica (--new-vps, --grpc, --shreds, --unlimited). Também responde ao primeiro login em um servidor que o erpc ainda não deixou com acesso só por chave, seja um novo ou um indicado com --vps <ID>: o erpc faz login uma vez com a senha do servidor, instala a sua chave e desativa os logins por senha. Sem --yes e sem terminal, uma ativação é recusada antes de qualquer compra, com status de saída 3.
  • Escolher entre os seus servidores ainda exige uma pessoa. Indique o servidor com --new-vps, --vps <ID> ou --host.
  • --prepare faz tudo o que não exige nem a chave de trading nem um segredo, e não inicia, não para e não reinicia nada. O próximo erpc worker deploy em um terminal entrega a chave e os segredos e inicia a aplicação. A chave de trading só é lida para uma pessoa em um terminal.

Conectar sua aplicação a gRPC, Shreds e Unlimited RPC

As linhas por hora da ERPC admitem o servidor pelo endereço dele e não recebem token. Cada linha é ativada para o servidor por uma flag própria no deploy, e a aplicação recebe o endpoint da linha como uma configuração:
FlagLinhaO que a aplicação recebe
--grpcGeyser gRPCGRPC_ENDPOINT
--shredsShreds (Shredstream gRPC)SHREDS_ENDPOINT
--unlimitedUnlimited RPC na região do servidorSOLANA_SEND_RPC_ENDPOINT
  • Cada linha é a mais barata da respectiva família, a menos que --grpc-plan, --shreds-plan ou --unlimited-plan indique outra.
  • O Unlimited RPC roda em um servidor dedicado que leva até 45 minutos para ser configurado. Ele atende sendTransaction e uma lista curta de leituras, não getProgramAccounts nem getTokenAccountsByOwner. O endpoint dele é HTTP simples (sem TLS) e admite apenas o endereço que está na allowlist.

Linhas para uma execução na sua máquina

O erpc worker run também aceita --grpc e --shreds, para testar a aplicação aqui com dados reais antes de ela ir para um servidor.
  • O endereço: as linhas admitem o endereço IPv4 público desta máquina, que você informa com --ip. O erpc não o descobre sozinho.
  • Compra: uma nova linha só é comprada em um terminal, depois que o preço dela é mostrado. O run não tem --yes.
  • Encerramento: quando a execução termina, cada linha por hora é encerrada depois de uma pergunta. --keep-lines as mantém, ainda cobradas. Se a execução terminar de qualquer outra forma (o terminal fechado, um segundo Ctrl-C), as linhas continuam ativas e são cobradas.
  • Os números: o que a aplicação mede aqui inclui a distância desta máquina até a linha, então é mais lento do que a mesma aplicação em um servidor perto da linha.

Próximos passos