Shuttle.toml

The file Shuttle.toml can be used for project-local configuration. For the current options available, check out Deployment files.

Workspaces

Shuttle supports cargo workspaces, but only one Shuttle service per workspace. The first workspace member found with a shuttle-runtime dependency and a binary target will be targeted for local runs and deployments.

If Shuttle.toml or Secrets are used, those files should be placed in the root of the workspace.

This is an example of a workspace structure with shared code between a backend and frontend crate:

.
ā”œā”€ā”€ .gitignore
ā”œā”€ā”€ Cargo.toml
ā”œā”€ā”€ Secrets.toml      (optional)
ā”œā”€ā”€ Shuttle.toml      (optional)
ā”œā”€ā”€ backend/
ā”‚   ā”œā”€ā”€ Cargo.toml    (depends on shuttle-runtime)
ā”‚   ā””ā”€ā”€ src/
ā”‚       ā””ā”€ā”€ main.rs   (contains #[shuttle_runtime::main])
ā”œā”€ā”€ frontend/
ā”‚   ā”œā”€ā”€ Cargo.toml
ā”‚   ā””ā”€ā”€ src/
ā”‚       ā””ā”€ā”€ main.rs
ā””ā”€ā”€ shared/
    ā”œā”€ā”€ Cargo.toml
    ā””ā”€ā”€ src/
        ā””ā”€ā”€ lib.rs

Cargo feature flags

If the cargo feature shuttle exists, Shuttle activates it and disables default features.

Cargo.toml
# Compiling this package on Shuttle will enable the features
# "shuttle" and "bar". To use default features on Shuttle, add
# "default" to the shuttle array.
[features]
default = ["foo"]
shuttle = ["bar"]
foo = []
bar = []

Multiple binaries

If you want to keep your project structured for allowing both running with and without Shuttle, check out the standalone-binary example. This is great for gradually adding Shuttle into your project.

.shuttle/config.toml

The .shuttle/config.toml is created when linking your project folder to a Shuttle project. It is added to .gitignore by default, and should not be committed.