This page describes what Shuttle expects from your project structure, how it handles cargo workspaces, and how to use a custom binary name.
After initializing a basic Shuttle project, the file structure will look like this:
. ├── .gitignore ├── Cargo.toml ├── Shuttle.toml (optional) └── src/ └── main.rs
Shuttle supports cargo workspaces. Simply run
the project and deployment commands in the root of the workspace, and the project name will be taken from the
directory name of the workspace or a
Shuttle.toml with a name key in the root of the workspace.
See Project Name for more info.
This is an example of a workspace structure with shared code between a backend and frontend crate:
. ├── .gitignore ├── Cargo.toml ├── Shuttle.toml (optional) ├── backend │ ├── Cargo.toml │ └── src │ └── main.rs (contains #[shuttle_runtime::main]) ├── frontend │ ├── Cargo.toml │ └── src │ └── main.rs └── shared ├── Cargo.toml └── src └── lib.rs
We currently only support one Shuttle service per workspace, so you can have many crates in a workspace, but only
one crate with a
We intend to allow starting several Shuttle services at the same time, as part of the same project.
The long term plan is to have one central service that routes to the other services in the project, sharing resources amongst them.
Any feedback on what you would like to see in this area is most welcome.
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.