Rust · 1.86

Hospedagem Rust 24/7

Suba uma API em axum, um bot em serenity ou um worker de fila e deixe rodando. O cargo build --release acontece na construção da imagem, o binário de target/release sobe em container isolado e a plataforma reinicia o processo sozinha, em qualquer plano, quando ele cai.

Criar conta Ver planos

Origem

Quem desenhou o Rust

Graydon Hoare começou o Rust em 2006 como projeto pessoal; a Mozilla adotou em 2009 para o motor do Firefox. A aposta era o controle de um C sem dangling pointer e sem coletor de lixo: o compilador recusa o alias perigoso. Depois de anos de mudança incompatível, a 1.0 saiu em 2015 com a promessa de estabilidade. Ownership e empréstimo são o mecanismo, não uma biblioteca.

Sistemas sem coletor de lixo

O Rust quer o controle de C e C++ sem dangling pointer e sem pausar o programa para recolher memória. Essa é a aposta — não “mais uma linguagem nova”.

O compilador é o fiscal

Ownership e empréstimo recusam o alias perigoso na compilação. O que outras linguagens deixam para o runtime, o rustc decide antes de gerar o binário.

Nativo, sem VM

Não há máquina virtual no meio. O propósito é o mesmo de um systems language clássico: o que sai é código para o processador, com uma garantia que o C não dá.

O que a plataforma faz por um projeto Rust

O essencial já vem configurado em toda aplicação Rust aqui; os recursos que dependem do plano estão indicados no card.

Build release na imagem

As crates do Cargo.toml são baixadas e compiladas enquanto a imagem é construída, não a cada boot. O container sobe com o binário de target/release pronto, e erro de compilação aparece no log do build em vez de virar crash em produção.

Três versões, uma linha de config

1.86 (recomendada), 1.87 e 1.85 disponíveis. Trocar é mudar VERSION no vertracloud.config e subir de novo — não há imagem para escolher nem Dockerfile para manter.

Teto de RAM no arquivo de config

MEMORY define quanta memória o container pode ocupar, e o painel mostra o uso real ao lado do teto. Se o processo estourar o limite, ele é encerrado por OOM e o evento fica registrado no log.

Auto-restart com freio

Um unwrap que estoura em produção não deixa o serviço fora do ar: o processo é reiniciado sozinho, em qualquer plano. Se ele quebrar 5 vezes em 10 minutos, a plataforma marca crash loop e desliga o auto-restart por 24 horas. Saída com exit code 0 não dispara reinício.

O que as pessoas rodam em Rust aqui

Carga longa e previsível: é onde o custo baixo de memória por requisição aparece na conta do fim do mês.

APIs em axum, actix-web e warp

Publique a aplicação para receber um subdomínio em vertraweb.app com TLS. O binário de release já traz o servidor dentro: ele só precisa escutar em 0.0.0.0:80, porque quem escuta em localhost nunca vê a requisição que chega de fora.

Bots e serviços de background

serenity, twilight e clientes de API rodam como processo sem porta HTTP. O token vai nas variáveis de ambiente do painel, nunca num .env dentro do zip — a plataforma não lê arquivo .env.

Workers e pipelines de dados

Consumidor de fila, indexador, rotina de processamento: cargas longas em que o custo de memória por requisição importa. O painel mostra a RAM real ao lado do teto do MEMORY, e o processo que estoura o limite é encerrado por OOM.

Conector nativo com banco gerenciado

Um PostgreSQL 17 criado no mesmo painel conversa com sqlx ou tokio-postgres pelo host interno. TLS é obrigatório, e o certificado de cliente e a senha saem do painel direto para o seu conector.

Versões de Rust disponíveis

1.86 é a recomendada, 1.87 é a mais recente e 1.85 segue disponível. Sem VERSION no vertracloud.config, a aplicação sobe na recomendada.

Versão	vertracloud.config	Status
1.87	VERSION=1.87	Mais recente
1.86	VERSION=1.86	Recomendada
1.85	VERSION=1.85

A configuração inteira

O vertracloud.config é um arquivo INI opcional na raiz do projeto. MAIN aponta o binário em target/release; VERSION escolhe o Rust; MEMORY define o teto de RAM do container.

vertracloud.config

NAME=meu-worker
MAIN=target/release/app
VERSION=1.86
MEMORY=512

Um plano para cada fase do projeto

A memória e o armazenamento mudam por plano; a linguagem, não. Compare o que cada plano libera e escolha o que cabe no projeto agora.

Comparar planos

Também roda aqui

Mesma plataforma, mesmo deploy, outra stack.

Java

Python

Perguntas frequentes sobre hospedagem Rust

Compilação, MAIN e memória: as dúvidas mais frequentes de quem sobe Rust.

Quais versões de Rust posso usar?

1.86 é a recomendada, 1.87 é a mais recente e 1.85 segue disponível. A escolha é feita pela chave VERSION no vertracloud.config; sem ela, a aplicação sobe na recomendada.

Para onde o MAIN deve apontar?

Para o executável gerado pelo perfil release, normalmente target/release/ com o nome declarado no Cargo.toml. Apontar para o binário de debug funciona, mas ele é maior e mais lento em produção.

Posso subir o binário já compilado em vez do código?

O binário está para outro sistema ou arquitetura. Compile para Linux x86_64, ou — o caminho mais simples — envie o código-fonte com Cargo.toml e Cargo.lock e deixe a compilação acontecer no build da plataforma.

Quanta memória meu serviço precisa?

Depende da carga, e o painel mostra o uso real do container. Se o processo for encerrado por OOM, aumente MEMORY. Publicar na web exige 512 MB de RAM e plano Pro.

Preciso enviar a pasta target no zip?

Não — e não envie. Exclua target do pacote: ela costuma ser a maior pasta do projeto, o limite do zip é 100 MB e o build é refeito no servidor, para Linux.

Suba seu serviço Rust hoje

Crie a conta, envie o código com Cargo.toml e Cargo.lock ou conecte o repositório do GitHub, e acompanhe o cargo build --release no terminal do painel.

Criar conta