Rust auf Nodion deployen

Rust Schritt für Schritt deployen

1. An 0.0.0.0:$PORT binden Nodion setzt PORT für den Web-Prozess. Lies ihn aus und binde an 0.0.0.0, nicht an 127.0.0.1, sonst erreicht der Health Check die App nicht. Bei Actix Web parst du den Port als u16 und übergibst ("0.0.0.0", port) an 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. Cargo.lock committen, [package] nach oben Mit einer Cargo.lock baut Nodion mit --locked, ein Lockfile, das nicht zur Cargo.toml passt, lässt den Build also scheitern. Den Package-Namen liest Nodion aus der ersten name =-Zeile der Cargo.toml, der Abschnitt [package] gehört deshalb nach oben. Cargo.toml

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

3. Weitere Binaries werden Prozesstypen Jede ausführbare Datei aus target/release landet im Image, zum Beispiel eine aus src/bin/worker.rs. Der Web-Prozess startet das Binary des Packages; jedes weitere Binary wird ein Prozesstyp mit demselben Namen. Für worker legst du auf dem Tab Processes einen Prozess mit diesem Namen ohne Port an und lässt den Befehl leer.
4. App anlegen Lege im Dashboard eine Application aus deinem GitHub-, GitLab-, Bitbucket- oder Gitea-Repository an, wähle Branch und Region EU Central. Lass die Build-Strategie auf Buildpacks; liegt ein Dockerfile im Repository, wählt das Formular stattdessen Dockerfile.
5. PostgreSQL anhängen und Migrationen ausführen Häng auf dem Tab Environment eine Datenbank aus derselben Region an; DATABASE_URL kommt beim nächsten Deploy an, nie während des Builds. Mit SQLx führst du cargo sqlx prepare aus und committest den Ordner .sqlx, damit die query!-Makros ohne Datenbank kompilieren. Migrationen laufen beim Start mit sqlx::migrate!(), oder du baust ein migrate-Binary und lässt es als Release-Schritt laufen, bei jedem Build einmal, bevor die neue Version startet. Procfile

   release: migrate

Gut zu wissen

• Nur das neueste stabile Rustrust-toolchain.toml und rust-version wählen keine ältere Toolchain: Jeder Build nutzt das neueste stabile Rust, das Nodion gebaut hat. Nightly-Toolchains gibt es nicht; Crates, die Nightly-Features brauchen, baust du mit einem Dockerfile.
• WorkspacesNodion führt cargo build --release im Base Directory ohne --workspace aus. In einem virtuellen Workspace (Root-Cargo.toml nur mit [workspace]) baut das alle Member; mit einem Root-Package nur dieses Package, trag also alle Member, die du brauchst, in workspace.default-members ein. Ein virtueller Workspace hat keinen Package-Namen; nenn das Web-Binary deshalb server, api, web oder app.

Was Nodion für dich betreibt

• Deploys ohne Downtime Push auf deinen Branch und Nodion baut ein neues Release. Der Traffic wechselt erst, wenn die neuen Instanzen ihren Health Check bestehen; ein fehlgeschlagenes Release lässt das laufende stehen. Apps mit lokalem Volume starten stattdessen neu, weil die Disk zu einer Instanz gehört.
• Datenbanken neben der App Managed PostgreSQL, pgvector, MySQL, Valkey und ClickHouse in derselben Region. Angehängte Datenbanken kommen als DATABASE_URL, REDIS_URL oder CLICKHOUSE_URL in die App.
• Previews pro Pull Request Schalte Previews ein, und Pull Requests aus deinem Repository bekommen eine eigene App mit eigener URL und frischen, leeren Datenbanken, automatisch oder per Hand angelegt. Forks und Bot-Pull-Requests werden übersprungen.
• Worker, Cron Jobs und Skalierung Worker laufen als weitere Prozesse derselben App, Jobs planst du auf dem Tab Cron, und jeden Prozess skalierst du auf bis zu 16 Instanzen.
• Release-Schritt Mit Buildpacks läuft eine release:-Zeile in der Procfile bei jedem neuen Build. Dockerfile-Apps sowie Redeploys und Rollbacks auf ein früheres Image nutzen einen Release Command, der an der App selbst gesetzt ist; er hat auch Vorrang vor der Procfile-Zeile. Bei statischen Sites läuft ein Release-Schritt in einem Image, das nur die gebauten Dateien enthält.
• Logs und Metriken Build-, Release- und Laufzeit-Logs sowie CPU-, Speicher-, Disk- und Netzwerk-Metriken für jede Instanz im Dashboard.
• Domains und HTTPS Ein Default-Hostname mit HTTPS ab dem ersten Deploy; deine eigenen Domains bekommen automatisch Zertifikate.

Weiterlesen

• Warum wir eigene Buildpacks auf Ubuntu 26.04 gebaut haben Unsere Buildpacks folgen der Cloud-Native-Buildpacks-Spezifikation, aber Stack, Language Packs und Runtime-Versionen sind unsere. Darum.
• Cloud Native Buildpacks erklärt Buildpacks machen aus deinem Quellcode ein Container-Image ohne Dockerfile. Was sie sind und wie sie funktionieren.

Rust auf Nodion: Fragen und Antworten