Despliega Rust en Nodion

Despliega Rust paso a paso

1. Escucha en 0.0.0.0:$PORT Nodion define PORT para el proceso web. Léela y escucha en 0.0.0.0, no en 127.0.0.1, o el health check no podrá llegar a la app. Con Actix Web, convierte el puerto a u16 y pasa ("0.0.0.0", port) a HttpServer::bind. src/main.rs

   use axum::{routing::get, Router};
   
   #[tokio::main]
   async fn main() {
       let port = std::env::var("PORT").unwrap_or_else(|_| "8080".to_string());
       let app = Router::new().route("/", get(|| async { "ok" }));
       let listener = tokio::net::TcpListener::bind(format!("0.0.0.0:{port}"))
           .await
           .unwrap();
       axum::serve(listener, app).await.unwrap();
   }

2. Haz commit de Cargo.lock y deja [package] al principio Si hay un Cargo.lock, Nodion compila con --locked, así que un lockfile que no coincida con Cargo.toml hace fallar la build. Nodion toma el nombre del paquete de la primera línea name = de Cargo.toml, así que deja la sección [package] al principio. Cargo.toml

   [package]
   name = "myapp"
   version = "0.1.0"
   edition = "2024"
   
   [dependencies]
   axum = "0.8"
   tokio = { version = "1", features = ["full"] }

3. Los binarios adicionales se convierten en tipos de proceso Todos los ejecutables de target/release van en la imagen, por ejemplo uno de src/bin/worker.rs. El proceso web ejecuta el binario del paquete; cada uno de los demás binarios se convierte en un tipo de proceso con el mismo nombre. Para ejecutar worker, añade en la pestaña Processes un proceso con ese nombre y sin puerto, y deja vacío su comando.
4. Crea la app En el dashboard, crea una aplicación desde tu repositorio de GitHub, GitLab, Bitbucket o Gitea y elige la rama y la región EU Central. Deja la estrategia de build en Buildpacks; si el repositorio tiene un Dockerfile, el formulario selecciona Dockerfile en su lugar.
5. Vincula PostgreSQL y ejecuta las migraciones En la pestaña Environment, vincula una base de datos de la misma región; DATABASE_URL llega con el siguiente despliegue, nunca durante la build. Con SQLx, ejecuta cargo sqlx prepare y haz commit de la carpeta .sqlx para que las macros query! compilen sin base de datos. Ejecuta las migraciones al arrancar con sqlx::migrate!(), o compila un binario migrate y ejecútalo como paso de release, una vez por build, antes de que arranque la nueva versión. Procfile

   release: migrate

A tener en cuenta

• Solo el Rust estable más recienterust-toolchain.toml y rust-version no seleccionan una toolchain más antigua: cada build usa el Rust estable más reciente que Nodion ha compilado. Las toolchains nightly no están disponibles, así que los crates que necesitan funcionalidades nightly requieren un Dockerfile.
• WorkspacesNodion ejecuta cargo build --release en el base directory sin --workspace. En un workspace virtual (un Cargo.toml en la raíz con solo [workspace]), eso compila todos los miembros; con un paquete en la raíz, compila solo ese paquete, así que incluye en workspace.default-members todos los miembros que necesites. Un workspace virtual no tiene nombre de paquete, así que llama al binario web server, api, web o app.

Lo que Nodion gestiona por ti

• Despliegues sin downtime Haz push a tu rama y Nodion construye una nueva release. El tráfico pasa a las nuevas instancias cuando superan el health check; si una release falla, la que está en marcha sigue activa. En cambio, las apps con un volumen local se reinician porque el disco pertenece a una sola instancia.
• Bases de datos junto a la app PostgreSQL, pgvector, MySQL, Valkey y ClickHouse gestionados en la misma región. Al vincular una base de datos, sus datos de conexión llegan como DATABASE_URL, REDIS_URL o CLICKHOUSE_URL.
• Previews por pull request Activa las previews: cada pull request de tu repositorio tendrá su propia app, con URL y bases de datos nuevas y vacías. Puedes crearla automáticamente o a mano. Se omiten las pull requests de forks y bots.
• Workers, cron jobs y escalado Ejecuta workers como procesos adicionales de la misma app, programa tareas en la pestaña Cron y escala cada proceso hasta 16 instancias.
• Paso de release Con buildpacks, una línea release: del Procfile se ejecuta con cada nueva build. Las apps con Dockerfile, así como los redeploys o rollbacks a una imagen anterior, usan un comando de release definido en la propia app, que además tiene prioridad sobre la línea del Procfile. En los sitios estáticos, el paso de release se ejecuta en una imagen que solo contiene los archivos generados por la build.
• Logs y métricas Logs de build, release y runtime, además de métricas de CPU, memoria, disco y red de cada instancia, en el dashboard.
• Dominios y HTTPS Un nombre de host predeterminado con HTTPS desde el primer despliegue; tus propios dominios reciben certificados automáticamente.

Para seguir leyendo

• Por qué hemos creado buildpacks propios sobre Ubuntu 26.04 Nuestros buildpacks siguen la especificación de Cloud Native Buildpacks, pero el stack, los buildpacks de lenguaje y las versiones de runtime son nuestros. Te contamos por qué.
• Cloud Native Buildpacks: qué son y cómo funcionan Los buildpacks convierten tu código fuente en una imagen de contenedor sin Dockerfile. Te explicamos qué son y cómo funcionan.

Rust en Nodion: preguntas y respuestas