Frequently Asked Questions

We build and deploy every project in its own container. This gives you safe isolation from other users, and also across all the projects that are owned by your account.

The cargo shuttle project start command starts a Docker container. Read more about the deployment environment here.

Your code is analyzed and built on our servers. The first time you introduce additional resources in your code, like the first time you use a database, we will add that resource to your project and wire it automatically to your deployment. Read about what happens to deployment files here.

See Deployment environment.

Of course! When you deploy a project on Shuttle, your app becomes available at a URL of the form ${project_name}.shuttleapp.rs.

With this, you can build a server that serves pretty much any frontend project. For details on how to serve static files with Shuttle, check out our Deployment files docs.

You can also just use it for an API, and host your frontend on any of the common frontend hosting solutions (Vercel, Netlify, etc), you just have to make your API calls to the URL of your project, and you’re up.

For a tutorial on how to build and deploy a simple full-stack app using Next.js & Rust, check out this tutorial: Deploying a NextJS frontend with Rust, in one go

You can bring your lambda code to Shuttle as is. And we run it on dedicated infrastructure that keeps the state of your services across requests, has no cold-start and can even have long-running threads, all of which is not possible on AWS Lambda.

Absolutely! And it’s quite easy. Check out this section of our docs for the steps to do so: Custom Services

Yes, you can create a SeaORM connection from the sqlx pool Shuttle passes to you when you provision a SQL database. You can take a look at the example here.

Certainly. Just create a Shuttle.toml file in the workspace root directory where your Cargo.toml is and add name = "your-project-name". Read more here.

Currently, all deployments are in the eu-west2 region (London). We do plan to support multiple regions, but we can’t give a precise ETA yet.

There are different ways to interpret “self hosting Shuttle”.

Items (2) and (3) below are not officially supported yet. Item (3) is on the roadmap.

1. Single project local run. If you are mainly using Shuttle for the automation of secrets and database containers, using cargo shuttle run --release on your own server might be sufficient.
2. Running the Shuttle stack on your own server. A similar setup which can give you an experience more similar to the full Shuttle experience.
3. [Advanced] Hosting Shuttle in your own cloud environment. This option lets you run a replica of the Shuttle production environment, under a custom domain.