How to deploy a Rust Service to Google Cloud Run

September 21, 2020

One of my bad habits is wasting time ontrying out new programming languages, every so often. I guess, in 2020, Rust is the new cool thing, so I had to indulge myself. I will reserve judgement on Rust, for the time being. Suffice it to say, there are aspects of Rust that excite me, other aspects are just plain annoying. You can't deny it's versatility though, that's Rust's main selling point, if you ask me.

As an experiment, I wrote a hello-world Web Service to be deployed as a container. Being the lazy, operations-averse engineer that I am, I use Google Cloud Run (that's a great name) which is based on KNative (what a stupid name).

Here is the simple Web Service:


use std::convert::Infallible;
use std::env;

use hyper::service::{make_service_fn, service_fn};
use hyper::{Body, Request, Response, Server};

async fn hello(_: Request<Body>) -> Result<Response<Body>, Infallible> {
        "hello, world",

pub async fn main() -> Result<(), Box<dyn std::error::Error + Send + Sync>> {

    let make_svc = make_service_fn(|_conn| async { Ok::<_, Infallible>(service_fn(hello)) });

    let port = if let Ok(port_env_var) = env::var("PORT") {
            .unwrap_or_else(|_| panic!("Invalid port env variable (PORT={})", port_env_var))
    } else {

    let addr = ([0, 0, 0, 0], port).into();

    let server = Server::bind(&addr).serve(make_svc);

    println!("Listening on http://{}", addr);



As you can see, I decided to use the Tokio runtime. I believe it will emerge as the winner of the Rust 'async wars'. The fact that it powers the wonderful Deno project is a strong reason to bet on Tokio.

On the other hand, I see no clear winner in the race for the dominant Rust Web Framework (Actix and Rocket look like strong candidates) so I plan to 'wait it out'. Thus, I used the low-level Hyper library for this experiment.

Pay attention to one important detail: You have to listen to, listening to or localhost will not work.

Here is the Dockerfile I used to build the container image:

FROM rust:1.46.0 as builder

ARG SERVICE_NAME=hello_service

RUN USER=root cargo new --bin /usr/src/${SERVICE_NAME}


COPY ./Cargo.toml ./Cargo.toml

RUN cargo build --release \ 
    && rm -rf src

ADD . ./

RUN rm ./target/release/deps/${SERVICE_NAME}* \
    && cargo build --release


ARG SERVICE_NAME=hello_service

COPY --from=builder /usr/src/${SERVICE_NAME}/target/release/${SERVICE_NAME} /usr/local/bin/${SERVICE_NAME}

CMD ["hello_service"]

Following best-practices, this Dockerfile supports a two-stage build and engages in Cargo shenanigans to enable caching a layer of dependencies. Unlike most Dockerfiles for Rust you can find online, it leverages a Distroless base image instead of Alpine Linux. The prospect of messing with musl libc doesn't sound very enticing.

Sweet, let's try this locally:

sudo podman build -t hello_service -f ./Dockerfile .
sudo podman run -p 3000:3000 hello_service

Huh, you still use docker? Sigh:

alias docker=podman

Now you can browse http://localhost:3000 to get your greeting.

Finally, let's deploy to production:

gcloud config set run/platform managed
gcloud config set builds/use_kaniko True
gcloud config set builds/kaniko_cache_ttl 24
gcloud builds submit --tag
gcloud run deploy --image

Please note that I enabled the Kaniko Cache option to leverage the aforementioned cached dependencies layer to speed up the deployment.

Mission accomplished!


Reduced the number of RUN commands, in the Dockerfile, to minimize the generated layers (thanks @mlk0981).

Also, I need to investigate how Docker BuildKit can further optimize the caching of Cargo dependencies (thanks @dkarlovi).


You can discuss this post on this Twitter thread.