Rust · 1.86
Hosting Rust 24/7
Sube una API en axum, un bot en serenity o un worker de cola y déjalo funcionando. El cargo build --release ocurre al construir la imagen, el binario de target/release arranca en un contenedor aislado y la plataforma reinicia el proceso sola, en cualquier plan, cuando se cae.
Quién diseñó Rust
Graydon Hoare empezó Rust en 2006 como proyecto personal; Mozilla lo adoptó en 2009 para el motor de Firefox. La apuesta era el control de C sin dangling pointer y sin recolector de basura: el compilador rechaza el alias peligroso. Tras años de cambios incompatibles, la 1.0 salió en 2015 con la promesa de estabilidad. Ownership y préstamo son el mecanismo, no una biblioteca.
Graydon Hoare
Crunchbase
Sistemas sin recolector de basura
Rust quiere el control de C y C++ sin dangling pointer y sin pausar el programa para recoger memoria. Esa es la apuesta — no “otro lenguaje nuevo”.
El compilador es el fiscal
Ownership y préstamo rechazan el alias peligroso al compilar. Lo que otros lenguajes dejan al runtime, rustc lo decide antes de emitir el binario.
Nativo, sin VM
No hay máquina virtual en el medio. El propósito es el mismo de un systems language clásico: lo que sale es código para el procesador, con una garantía que C no da.
Lo que la plataforma hace por un proyecto Rust
Lo esencial ya viene configurado en toda aplicación Rust aquí; las funciones que dependen del plan se indican en la tarjeta.
Build release en la imagen
Las crates del Cargo.toml se descargan y compilan mientras se construye la imagen, no en cada arranque. El contenedor arranca con el binario de target/release listo, y un error de compilación aparece en el log del build en vez de convertirse en un crash en producción.
Tres versiones, una línea de config
1.86 (recomendada), 1.87 y 1.85 disponibles. Cambiar es modificar VERSION en vertracloud.config y volver a desplegar — no hay imagen que elegir ni Dockerfile que mantener.
Techo de RAM en el archivo de config
MEMORY define cuánta memoria puede ocupar el contenedor, y el panel muestra el uso real junto al techo. Si el proceso pasa del límite, se cierra por OOM y el evento queda registrado en el log.
Auto-reinicio con freno
Un unwrap que revienta en producción no deja el servicio caído: el proceso se reinicia solo, en cualquier plan. Si se rompe 5 veces en 10 minutos, la plataforma marca crash loop y apaga el auto-reinicio durante 24 horas. Salir con exit code 0 no dispara reinicio.
Lo que la gente ejecuta en Rust aquí
Carga larga y previsible: es donde el bajo coste de memoria por petición aparece en la factura de fin de mes.
APIs en axum, actix-web y warp
Publica la aplicación para recibir un subdominio en vertraweb.app con TLS. El binario de release ya trae el servidor dentro: solo tiene que escuchar en 0.0.0.0:80, porque lo que escucha en localhost nunca ve la petición que llega de fuera.
Bots y servicios en segundo plano
serenity, twilight y clientes de API corren como proceso sin puerto HTTP. El token va en las variables de entorno del panel, nunca en un .env dentro del zip — la plataforma no lee archivos .env.
Workers y pipelines de datos
Consumidor de cola, indexador, rutina de procesamiento: cargas largas donde el coste de memoria por petición importa. El panel muestra la RAM real junto al techo de MEMORY, y el proceso que pasa del límite se cierra por OOM.
Conector nativo con base gestionada
Un PostgreSQL 17 creado en el mismo panel habla con sqlx o tokio-postgres por el host interno. TLS es obligatorio, y el certificado de cliente y la contraseña salen del panel directo hacia tu conector.
Versiones de Rust disponibles
La 1.86 es la recomendada, la 1.87 es la más reciente y la 1.85 sigue disponible. Sin VERSION en el vertracloud.config, la aplicación arranca en la recomendada.
| Versión | vertracloud.config | Estado |
|---|---|---|
| 1.87 | VERSION=1.87 | Más reciente |
| 1.86 | VERSION=1.86 | Recomendada |
| 1.85 | VERSION=1.85 |
La configuración entera
vertracloud.config es un archivo INI opcional en la raíz del proyecto. MAIN apunta al binario en target/release; VERSION elige el Rust; MEMORY define el techo de RAM del contenedor.
NAME=meu-worker
MAIN=target/release/app
VERSION=1.86
MEMORY=512Un plan para cada etapa del proyecto
La memoria y el almacenamiento cambian según el plan; el lenguaje, no. Compara lo que abre cada plan y elige el que le sirve al proyecto hoy.
Comparar planesTambién corre aquí
Misma plataforma, mismo deploy, otro stack.
Preguntas frecuentes sobre hosting Rust
Compilación, MAIN y memoria: las dudas más frecuentes de quien sube Rust.
¿Qué versiones de Rust puedo usar?
1.86 es la recomendada, 1.87 es la más reciente y 1.85 sigue disponible. La elección se hace con la clave VERSION en vertracloud.config; sin ella, la aplicación arranca en la recomendada.
¿A dónde debe apuntar MAIN?
Al ejecutable generado por el perfil release, normalmente target/release/ con el nombre declarado en Cargo.toml. Apuntar al binario de debug funciona, pero es más grande y más lento en producción.
¿Puedo subir el binario ya compilado en vez del código?
El binario apunta a otro sistema o arquitectura. Compila para Linux x86_64 o, el camino más simple, sube el código fuente con Cargo.toml y Cargo.lock y deja que la compilación ocurra en el build de la plataforma.
¿Cuánta memoria necesita mi servicio?
Depende de la carga, y el panel muestra el uso real del contenedor. Si el proceso se cierra por OOM, sube MEMORY. Publicar en la web exige 512 MB de RAM y plan Pro.
¿Tengo que subir la carpeta target en el zip?
No — y mejor no lo hagas. Deja target fuera del paquete: suele ser la carpeta más grande del proyecto, el límite del zip es 100 MB y el build se rehace en el servidor, para Linux.
Sube tu servicio Rust hoy
Crea la cuenta, sube el código con Cargo.toml y Cargo.lock o conecta el repositorio de GitHub, y sigue el cargo build --release en la terminal del panel.
Crear cuenta