1. Introduction
  2. What is Shuttle?

A simple cargo command packages up your application, ships it to the Shuttle build cluster where it’s incrementally compiled and automatically served on a unique subdomain.

Shuttle uses simple but powerful annotations to understand your dependencies. Infrastructure dependencies like databases or key-value stores are spun up for you and everything is automatically wired together from the get-go.

It is built for productivity, reliability and performance:

Infrastructure from Code

We’ve already developed an annotation based system that enables Rust apps to be deployed with a one-liner, as well as dependencies like databases being provisioned through static analysis in real-time.

#[shuttle_runtime::main]
async fn rocket(
    // automatic db provisioning + hands you back an authenticated connection pool
    #[shuttle_shared_db::Postgres] pool: PgPool,
) -> ShuttleRocket<...> {
    // application code
}

In this future, infrastructure can be defined directly from code. Not in the “Infrastructure as Code” kind of way though, but in a way that the code that you write implicitly defines infrastructure. What your code actually needs in terms of infrastructure is inferred as you build your application, instead of you having to think upfront about what infrastructure piece is needed and how to wire it up. This liberates you from having to spin up resources, such as a Postgres database, and manage environment variables such as database connection strings.

This setup is also breaking the boundaries that keep containers isolated from each other (and thus make it difficult to orchestrate them), without necessarily getting rid of the paradigm of containers. It does not force you into any specific way of writing applications, but instead becomes an extension of your workflow.