Skip to content

Releases: shuttle-hq/shuttle

v0.16.0

08 May 10:21
@chesedo chesedo
v0.16.0
62a21c1
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.16.0

shuttle: v0.16.0 update

We're excited to release shuttle v0.16.0! 🚀

First week of Shuttle Batch 2023

This marks the first release since the start of this year’s batch, bringing a lot of new contributors to Shuttle. We’ve already had several pull requests, solving a lot of long-standing issues.

  • @piewhat and @pedromfedricci fixed a bug where panic messages from users services that were owned strings were not captured in the runtime logs in #854
  • @vroussea and @utterstep fixed a bug were some tracing data was lost due to a missing on_new_span impl on our Logger in #864
  • @paulotten and @mikegin refactored our examples to serve “Hello, world!” at / and updated our relevant tests in #863
  • @paulotten fixed our end to end tests in #858
  • @AlphaKeks added an .editorconfig in #855
  • @morlinbrot changed the default port for the provisioner to make contributing easier for contributors with AirPlay receivers in #852
  • @iamwacko improved the efficiency of our CI in #859
  • @jonaro00 cleaned up some dead code in #832

Updated init command

@jonar00, also from the shuttle batch, made a series of improvement to our init command, making it a lot easier to implement for new service implementations. He also made some changes to the API, to initialize with a certain framework you now first need to pass the new --template (or -t) flag.

# before
cargo shuttle init --axum

# now
cargo shuttle init --template axum
# or
cargo shuttle init -t axum

In the future we intend to refactor init to initialize from any template by passing in a URL, for example a link to one of our examples.

Upgrading

To upgrade your shuttle CLI, run: cargo install cargo-shuttle, or if you’re using [cargo-binstall](https://github.com/cargo-bins/cargo-binstall), cargo binstall cargo-shuttle.

If you’d like to upgrade your project container, run the restart project command. This will not delete any databases, and you will keep your project name:

cargo shuttle project restart

Finally, redeploy your shuttle service:

cargo shuttle deploy

All commits for this release

New Contributors

Full Changelog: v0.15.0...v0.16.0

Contributors

utterstep, paulotten, and 10 other contributors
Assets 7
Loading

v0.15.0

27 Apr 15:00
@chesedo chesedo
v0.15.0
b626bf0
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.15.0

shuttle: v0.15.0 update

We're excited to release shuttle v0.15.0! 🚀

Improving our pre-release QA

To prevent regressions we need to do thorough QA of the changes we make for new releases. To prevent this from slowing down releases and development, for this release we have started implementing automated QA in our CI. For this first iteration we will do an end-to-end test of installing cargo-shuttle, doing a local run and a deploy on macOS and Linux (a workflow for windows should be ready for the next release).

Updated CLI command and first bounty 💎

For this release we had our first approved bounty contribution, congratulations to @jonaro00!

To claim the bounty they submitted an implementation of a new flag for the logs command in the CLI:

cargo shuttle logs —latest

This command is a convenient way to get the logs of the last deployment, so you will not need to do a deployment list, get the ID and then a cargo shuttle logs <id> to get the latest one. All the existing functionality of the command remains the same.

Error message improvements

For this release we have addressed some poor or missing error messages:

  • Updated the error messages on commands that 404 when a deployment and/or service is missing with more information and a tip to resolve it.
  • Validate the input in the interactive login from cargo shuttle login, to ensure incorrectly pasted keys will prompt the user to re-submit.

Bug fixes

  • Fixed a bug where cancelling a local run or a local run crashing would not free the port bound by the service, leading to crashes on subsequent runs #805
  • Fixed a bug where we were inadvertently logging secrets in the deployer #814

Contributions

Upgrading

To upgrade your shuttle CLI, run: cargo install cargo-shuttle, or if you’re using [cargo-binstall](https://github.com/cargo-bins/cargo-binstall), cargo binstall cargo-shuttle.

If you’d like to upgrade your project container, run the restart project command. This will not delete any databases, and you will keep your project name:

cargo shuttle project restart

Finally, redeploy your shuttle service:

cargo shuttle deploy

Commits for this release

Full Changelog: v0.14.0...v0.15.0

Contributors

chesedo, jhawkesworth, and 4 other contributors
Assets 7
Loading

v0.14.0

12 Apr 15:07
@chesedo chesedo
v0.14.0
1db4ae7
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.14.0

shuttle: v0.14.0 update

We're excited to release shuttle v0.14.0! 🚀

Workspace support

We now have full support for cargo workspaces! We have had limited support in the past, where only a workspace where the shuttle project was the root crate was deployable. Following this release, you will be able to have a regular workspace. We will search the workspace for shuttle projects, and in this first iteration we will start all of them for local runs, but only the first one we find for deployments.

We intend to allow starting several services in deployment too. 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 people would like to see in this area is most welcome.

Note: When deploying a workspace where the shuttle service uses shuttle-static-folder, the static folder must be placed in the workspace root.

Changes to the project commands

We have a new project command: cargo shuttle project restart. This command will replace the old flow of project rm → project new to restart a project.

In addition to that, the following cargo shuttle project commands have been renamed:

  • new has been renamed to start
  • rm has been renamed to stop

Their functionality remains the same, they will start and stop your project’s container.

Thanks to @jonaro00 for suggesting, implementing and documenting these changes!

Removing the protoc requirement for cargo-shuttle

We have removed the need for protoc to install cargo-shuttle, but protoc will still be required to build, run and deploy shuttle services. We intend to remove the protoc requirement entirely in the next release.

Bug fixes

  • Fixed a bug where a deployment might return an error due to not waiting on the deployment state to update, thanks @jonaro00! #744
  • Fixed a bug on windows where the path to the static folder was incorrect for local runs: #762
  • Fixed a bug where setting the local_uri for databases would cause deployments to fail: #786

Contributions

Upgrading

To upgrade your shuttle CLI, run: cargo install cargo-shuttle, or if you’re using [cargo-binstall](https://github.com/cargo-bins/cargo-binstall), cargo binstall cargo-shuttle.

If you’d like to upgrade your project container, run the restart project command. This will not delete any databases, and you will keep your project name:

cargo shuttle project restart

Finally, redeploy your shuttle service:

cargo shuttle deploy

Commits for this release

Full Changelog: v0.13.0...v0.14.0

Contributors

kierendavies, chesedo, and 6 other contributors
Assets 7
Loading

v0.13.0

27 Mar 15:23
@chesedo chesedo
v0.13.0
99accab
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.13.0

shuttle: v0.13.0 update

We're excited to release shuttle v0.13.0! 🚀

Changes to the cargo-shuttle CLI

We added a new command to list all the provisioned resources for your project, like databases and secrets: cargo shuttle resource list. With the addition of the new resource command, the cargo shuttle status command will no longer list resources.

Note: Due to the changes to the deployer API required for the resource list command, if you do a project rm and project new after this release you will also need to upgrade your CLI.

Upgrading our pinned Rust version

In this release we bump our pinned version of Rust to 1.68, previously 1.65, allowing users to use the new language features introduced in these updates. To be able to take advantage of this, you will need to update your project container by running cargo shuttle project rm followed by cargo shuttle project new.

Contributions

Upgrading

To upgrade your shuttle CLI, run: cargo install cargo-shuttle, or if you’re using [cargo-binstall](https://github.com/cargo-bins/cargo-binstall), cargo binstall cargo-shuttle.

If you’d like to upgrade your project container, run the rm and new project commands. This will not delete any databases, and you will keep your project name:

cargo shuttle project rm
cargo shuttle project new

Finally, redeploy your shuttle service:

cargo shuttle deploy

Commits for this release

Full Changelog: v0.12.0...v0.13.0

Contributors

chesedo, meskill, and 5 other contributors
Assets 7
Loading

v0.12.0

20 Mar 16:24
@chesedo chesedo
v0.12.0
b6d7b6f
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.12.0

shuttle: v0.12.0 update

We're excited to release shuttle v0.12.0! 🚀

Removing our unsafe FFI

As of this release Shuttle will no longer rely on compiling users projects as dynamic libraries, we have refactored the codegen to embed the required code to configure and add resources to a users project binary. This means we can get rid of the unsafe FFI needed to load the dynamic libraries, which was a big source of memory issues (especially for local runs). As a result of the refactor, we’ll be able to:

  • Get rid of the Sync requirement for services.
  • Get rid of the extra tokio::Runtime that is currently required for shuttle resources to be started on the correct side of the FFI (e.g. shuttle_shared_db, shuttle_secrets).
  • Correctly stop deployments.
  • Remove the version pin on tokio (as of writing it is pinned to 1.22).

Shuttle-next framework

Shuttle-next is a brand new WASM web-framework based on axum and hyper. There are many benefits to using WASM for a backend web-framework, but one of the key features is the isolation it offers. Since WASM modules have no notion of a file system, a shuttle-next project can only interact with the host through resources explicitly declared by us. In this first iteration, the only resource available is an HTTP stream to and from a project.

Shuttle-next is very much a work in progress, and we're releasing this iteration without some of the
features that make shuttle a pleasure to use, for example the ability to effortlessly deploy and connect to a database. It's also not currently possible to use any middleware. We're planning to implement this functionality, and more, in the near future. We're also hoping that the feedback we get from this release will help us see which features we should prioritize, and which areas of the framework's design need the most attention going forward.

Below is a small example of shuttle-next, see the example in our docs for more information.

Note: shuttle-next does not currently work on Windows, it only works on unix systems (i.e mac, Linux and Windows Subsystem for Linux). We aim to resolve this in future releases.

// lib.rs
shuttle_next::app! {
    #[shuttle_next::endpoint(method = get, route = "/hello")]
    async fn hello() -> &'static str {
        "Hello, World!"
    }
}

Extracting the service integrations

The service implementations for frameworks like Axum, Rocket, Serenity etc., have now been extracted into separate crates. You will now need to depend on that crate, e.g shuttle_axum = "0.12.0", rather than shuttle-service = { version = "0.12.0", features = ["web-axum"] }.

Bug fixes

  • Fixed a bug where windows users had to do a cargo build before they could cargo shuttle run: #721
  • Fixed a bug where the file contents of static assets in the shuttle_static_files directory were deleted in local runs: #717
  • Fixed a bug where passing a path to cargo shuttle init would return an error: #706

Protoc requirement

Due to new dependencies we can’t go without users will now need to install protoc to install and use cargo-shuttle and our other crates. We tried to find a way around this requirement, but it came at the cost of significantly increased build times. We know this extra step required before being able to use shuttle is far from ideal, and we’ll try to find a good way around it in the future.

Mac and Linux

To install protoc from the distributed binary, you can use this script:

# replace <arch> with your architecture, for example for linux x86_64 replace <arch> with: linux-x86_64
curl -OL https://github.com/protocolbuffers/protobuf/releases/download/v21.9/protoc-21.9-<arch>.zip &&\
        sudo unzip -o protoc-21.9-<arch>.zip -d /usr/local bin/protoc &&\
        sudo unzip -o protoc-21.9-<arch>.zip -d /usr/local 'include/*' &&\
        rm -f protoc-21.9-<arch>.zip

If you'd like to do this yourself without the above script, see instructions here: https://grpc.io/docs/protoc-installation/#install-pre-compiled-binaries-any-os

On mac you can also install protoc with brew: brew install protobuf.

Note: installing protoc on Linux with apt-get install protobuf-compiler will not be enough, since it will install an old version of protoc (v3.12) but it needs to be at least v3.19. Installing on mac using brew works.

Windows

On Windows the simplest way to install protoc is to first install chocolatey, and then simply run: choco install protoc

Upgrading

Due to the nature of these changes, all projects will be stopped and forced to upgrade. Please see instructions here for how to upgrade, as well as our updated examples and updated docs

First, since your project will now be compiled as a binary and no longer a library, you need to convert it to a binary. That means renaming the lib.rs file where your shuttle_service::main function currently is to main.rs, and you’ll also need to remove the [lib] field from your Cargo.toml.

We have also made some changes to the imports, you’ll now need to import shuttle-runtime and tokio, as well as the service integration for your framework. See the example below.

# Before for axum apps
axum = "0.6"
shuttle-service = { version = "0.11.0", features = ["web-axum"] }
sync_wrapper = "0.1.1"

# After for axum apps
axum = "0.6"
shuttle-axum = "0.12.0"
shuttle-runtime = "0.12.0"
tokio = "1.26.0"

# Before for serenity bots
serenity = { version = "0.11.5", default-features = false, features = ["client", "gateway", "rustls_backend", "model"] }
shuttle-secrets = "0.11.0"
shuttle-service = { version = "0.11.0", features = ["bot-serenity"] }

# After for serenity bots
serenity = { version = "0.11.5", default-features = false, features = ["client", "gateway", "rustls_backend", "model"] }
shuttle-runtime = "0.12.0"
shuttle-serenity = "0.12.0"
shuttle-secrets = "0.12.0"
tokio = "1.26.0"

Since the service integrations now live in a different crate from where the Service trait is defined, they need to be wrapped in a new-type for us to be able to implement Service for them. This means you need to wrap the return type from your shuttle_runtime::main function in this type, but he have implemented From from for all the integrations, so you can simply return Ok(router.into()). See an example of upgrading an axum app below, and see our updated examples for other integrations:

// Before in src/lib.rs
use axum::{routing::get, Router};
use sync_wrapper::SyncWrapper;

async fn hello_world() -> &'static str {
    "Hello, world!"
}

#[shuttle_service::main]
async fn axum() -> shuttle_service::ShuttleAxum {
    let router = Router::new().route("/hello", get(hello_world));
    let sync_wrapper = SyncWrapper::new(router);

    Ok(sync_wrapper)
}

// After in src/main.rs
use axum::{routing::get, Router};

async fn hello_world() -> &'static str {
    "Hello, world!"
}

#[shuttle_runtime::main]
async fn axum() -> shuttle_axum::ShuttleAxum {
    let router = Router::new().route("/hello", get(hello_world));

    Ok(router.into())
}

To upgrade your shuttle CLI, run: cargo install cargo-shuttle, or if you’re using cargo-binstall, cargo binstall cargo-shuttle.

If you’d like to upgrade your project container, run the rm and new project commands. This will not delete any databases, and you will keep your project name:

cargo shuttle project rm 
cargo shuttle project new

Finally, redeploy your shuttle service:

cargo shuttle deploy

Contributions

  • @kierendavies made their first contribution to shuttle by fixing a nefarious cyclical dependency bug in #700
  • @blixus made some great improvements to our CLI docs in shuttle-hq/shuttle-docs#48
  • @HexPanda made their first contribution to shuttle by fixing the indentation of the poise init code in #687
  • @stavares843 made their first contribution to shuttle by fixing some typos in our repo in #682

Commits for this release

  • feat: shuttle-serenity initial commit poc by @brokad in #429
  • shuttle next wrapper POC by @oddgrd in #431
  • refactor: create runtimes workspace by @chesedo in #432
  • feat: add --provisioner-address arg to both runtimes by @chesedo in #433
  • feat: create a control plane interface (part 1) by @chesedo in #436
  • refactor: combine runtimes into one by @chesedo in #438
  • feat(deployer): add support for building wasm projects by @akrantz01 in #437
  • feat: move factory to runtime by @oddgrd in #444
  • WIP feat: start runtime from deployer by @oddgrd in #450
  • feat: get logs from runtime by @chesedo in #459
  • [WI...
Read more

Contributors

kierendavies, chesedo, and 6 other contributors
Assets 7
Loading

v0.11.2

02 Mar 20:32
@chesedo chesedo
v0.11.2
262ef1a
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.11.2

shuttle: v0.11.2 update

We're excited to release shuttle v0.11.2! 🚀

Sleeping Idle Projects

Shuttle imposes no restrictions on how many projects a user can create. While we are in alpha this is a win-win, users creating many and varied projects is great for testing both our code and how we handle load. However, this has lead to a sizable amount of idle projects. To remedy this, we will start putting these idle projects to sleep, by default after 30 minutes of no activity.

By activity we mean both:

  • CPU load of the project over a 30 minute window. The load is increased when a project receives traffic (for example, traffic to an API endpoint for an axum server, or calling the commands of a discord bot in a discord server). An HTTP server (eg. axum or rocket), will need about 2 requests per minute over the idle-time period to be considered active, a discord bot will need about 6 calls per minute.
  • User interaction, for example running cargo shuttle status or any other CLI commands except for cargo shuttle project <cmd> commands.

If the project is sleeping, traffic to the project or user interaction will wake it, and in our tests this usually takes around one second. Important: if a discord bot is sleeping due to inactivity, calling the bot commands will not wake it, only developer interaction through the CLI will (but traffic will keep it from going to sleep). See the below instructions for how to increase the idle limit.

Since we don’t really want to restrict active users yet, this limit can be freely modified. You can change it by passing in a flag when creating a project: cargo shuttle project new --idle-minutes 40. If you pass in --idle-minutes 0 the idle timeout will be disabled and your project will never sleep. This is especially useful for discord bots, since they will not be awoken by traffic (people using the bot commands in a discord channel), only by developer interaction through the shuttle CLI.

Due to the nature of these changes, to be able to run cargo shuttle project new, you will need to update your cargo-shuttle CLI (so if you don’t need to run project new you don’t have to update now).

To upgrade your shuttle CLI, run: cargo install cargo-shuttle, or if you’re using cargo-binstall, cargo binstall cargo-shuttle.

If you’d like to upgrade your project container, run the rm and new project commands. This will not delete any databases, and you will keep your project name:

cargo shuttle project rm 
cargo shuttle project new

Finally, redeploy your shuttle service:

cargo shuttle deploy

Note: The versions of dependencies like shuttle-service, shuttle-secrets and the other resource libraries were not incremented for this release, they should stay at 0.11.0.

New Contributors

  • @jonaro00 made their first contribution to shuttle by doing some much needed housekeeping of our various markdown files and docs, as well as cleaning up some redundant dependencies in #666 , #664 and shuttle-hq/shuttle-docs#45

Commits for this release

Full Changelog: v0.11.1...v0.11.2

Contributors

chesedo, brokad, and 2 other contributors
Assets 7
Loading

v0.11.0

27 Feb 23:13
@chesedo chesedo
v0.11.0
d7a5333
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.11.0

shuttle: v0.11.0 update

We're excited to release shuttle v0.11.0! 🚀

Security Refactor

The core of this release is a major security overhaul, introducing the new auth crate to the repository. You should not notice any difference in functionality, but this will ensure complete isolation between users projects, and guarantee that a resource can only be accessed by it’s owner.

This refactor also lays the foundation for the recently announced dashboard to be able to securely interface with the Shuttle API. This means that soon the CLI will not be the only way to manage your projects, though it will take some time for the dashboard to reach feature parity with the CLI.

Due to the nature of these changes all projects will have to manually update, as we will not be able to keep running older versions that don’t support the new authentication system. To upgrade your project, you need to take the following steps:

  1. To upgrade your shuttle CLI, run: cargo install cargo-shuttle, or if you’re using [cargo-binstall](https://github.com/cargo-bins/cargo-binstall), cargo binstall cargo-shuttle.
  2. Update your shuttle dependency(s) to 0.11.0:
shuttle-service = { version = "0.11.0", features = ["web-axum"] }
shuttle-static-folder = "0.11.0"
# ...
  1. Optionally, test locally using:
cargo shuttle run
  1. Upgrade your remote project using the rm and new project commands. This will not delete any databases, and you will keep your project name:
cargo shuttle project rm 
cargo shuttle project new
  1. Deploy your project again:
cargo shuttle deploy

New Contributors

  • @MrCoolTheCucumber made their first contribution in #622, laying down a solid foundation for our upcoming resource deletion feature.
  • @angelorendina made their first contribution in #637, fixing a bug with our upcoming custom domain feature.
  • @sentinel1909 made their first contribution in #636, filling a hole in our contribution docs. They have also made several contributions to our docs repo, thanks!

All contributions for this release

Full Changelog: v0.10.0...v0.11.0

Contributors

chesedo, MrCoolTheCucumber, and 4 other contributors
Assets 7
Loading

v0.10.0

13 Feb 17:55
@chesedo chesedo
v0.10.0
4668291
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.10.0

shuttle: v0.10.0 update

We're excited to release shuttle v0.10.0! 🚀

Here are the highlights in this update.

Local secrets

We now support setting secrets for the local development environment, meaning for cargo shuttle run. To use local secrets, simply create a Secrets.dev.toml file, and this will only be used for local runs. If you want to use some of the same secrets in prod and dev, you'll need to have them in both files. Thanks a lot @joshua-mo-143! #610

Binstall support

For 0.9.0 we published our first pre-built releases, but there was a compatibility issue with cargo-binstall. That has been resolved, and binstall is now supported! We have also added the x86_64-unknown-linux-gnu target. #608

The following targets are supported as of 0.10:

  • x86_64-unknown-linux-musl
  • x86_64-unknown-linux-gnu
  • aarch64-unknown-linux-musl
  • x86_64-pc-windows-msvc
  • x86_64-apple-darwin

And more

  • To improve project creation stability, we have added three new project states that ensure containers that fail to start will automatically retry, and that containers that become unhealthy will attempt to restart. #620
  • Renamed cargo shuttle delete to cargo shuttle stop, to more accurately reflect its purpose, and also fixed the foreign key error it would return. Thanks @jdrouet! #619
  • Added a cargo shuttle logout command that clears the shuttle API-key from your environment, thanks @joshua-mo-143: #595
  • Added a flag to cargo shuttle run that allows running locally in the release profile: cargo shuttle run --release. Thanks @gautamprikshit1! #611
  • Local runs now respect the $PORT environment variable, thanks @canac! #571

Misc

  • Migrated our uses of the tempdir crate to tempfile, thanks @gautamprikshit! #603

How to upgrade

If you had a project on shuttle, then you will need to manually update the version to 0.10.0 in your Cargo.toml. You may also need to update the versions of your shuttle resources to 0.10.0.

To upgrade your project container:

# this will not delete any databases, and you will keep your project name
cargo shuttle project rm # to remove your project
cargo shuttle project new # to recreate your project
cargo shuttle deploy # redeploy your service

To upgrade your shuttle CLI, simply run cargo install cargo-shuttle, or if you’re using [cargo-binstall](https://github.com/cargo-bins/cargo-binstall), cargo binstall cargo-shuttle.

New Contributors

Contributions for this release

Full Changelog: v0.9.0...v0.10.0

Contributors

canac, chesedo, and 4 other contributors
Assets 7
Loading

v0.9.0

27 Jan 18:13
@chesedo chesedo
v0.9.0
79ff57e
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.9.0

shuttle: v0.9.0 update

We're excited to release shuttle v0.9.0! 🚀

Here are the highlights in this update.

Poise support

Shuttle now has a Poise integration for building command-based discord bots with ease. Check out the new example here. Thanks to @Anafabula for their first contribution to shuttle!

Binary distributions

Shuttle will now include pre-built binaries for cargo-shuttle with every release, meaning rather than installing the CLI with cargo install cargo-shuttle you can now simply download the binary for your OS, put it in your .cargo/bin folder and you’re good to go!

If you’d prefer a simple tool for this, you can also install the binary using [cargo-binstall](https://github.com/cargo-bins/cargo-binstall).

Note: The current binary paths are incompatible with cargo-binstall (this will be fixed for the next release), so to install with it you need to add some additional flags: cargo binstall cargo-shuttle --pkg-url="https://github.com/shuttle-hq/shuttle/releases/download/v0.9.0/cargo-shuttle-v0.9.0-8-gf75c2e9-<target>.tar.gz" --bin-dir="shuttle/cargo-shuttle" --pkg-fmt="tgz". Remember to add .exe to the end of bin-dir if you're using the windows binary.

The following targets will be supported as of 0.9:

  • x86_64-unknown-linux-musl
  • aarch64-unknown-linux-musl
  • x86_64-pc-windows-msvc
  • x86_64-apple-darwin

Expose your shuttle app to your local network

You can now pass the --external flag to cargo shuttle run, this will run your app on 0.0.0.0:8000 , exposing your app to your local network. If you’re serving a static website from your app, this makes it easy to open it up on your phone to see that the styling is correct across devices. Thanks to @joshua-mo-143 for this cool new feature!

Override local run database URIs

You can now pass in a local URI as an argument to the shuttle DB resources, allowing you to opt out of the default spawning of a docker container for your local DB. When you set the local_uri, you can also insert secrets from Secrets.toml using string interpolation: #596, #597

#[shuttle_service::main]
async fn axum(
	#[shuttle_shared_db::Postgres(
	local_uri = "postgres://postgres:{secrets.PASSWORD}@localhost:5432/postgres"
)] pool: PgPool) -> ShuttleAxum { ... }

And more

  • Added a cargo shuttle feedback command that opens a browser on the create new issue page of the shuttle repo, thanks @gautamprikshit1: #592

Bug fixes

  • Fixed a bug where using crates with a rust-toolchain override, like dashmap , would lead to errors in deployment: #545
  • Fixed a bug where deployer was persisting incorrect historical states, so when doing cargo shuttle deployment list users would see deployments that appeared to be stuck in the loading or building state: #548

How to upgrade

If you had a project on shuttle, then you will need to manually update the version to 0.9.0 in your Cargo.toml. You may also need to update the versions of your shuttle resources to 0.9.0.

To upgrade your project container:

# this will not delete any databases, and you will keep your project name
cargo shuttle project rm # to remove your project
cargo shuttle project new # to recreate your project
cargo shuttle deploy # redeploy your service

To upgrade your shuttle CLI, simply run cargo install cargo-shuttle or install from the binary releases, see instructions near the top of this release.

New Contributors

Pull requests for this release

Full Changelog: v0.8.1...v0.9.0

Contributors

chesedo, alekspickle, and 5 other contributors
Assets 6
Loading

v0.8.0

16 Dec 09:29
@oddgrd oddgrd
v0.8.0
2956292
This commit was created on GitHub.com and signed with GitHub’s verified signature. The key has expired.
GPG key ID: 4AEE18F83AFDEB23
Expired
Learn about vigilant mode.
Compare
Choose a tag to compare
v0.8.0

We're excited to release shuttle v0.8.0! 🚀

Here are the highlights in this update.

Better scaffolding

The CLI now has a completely interactive starter flow (thanks @Procrat and @guerinoni!)

https://github.com/shuttle-hq/shuttle/raw/main/assets/v0.8.0-interactive-init.gif

Static files

You can now send a local folder from your source files to deployed services.

Just add the shuttle-static-folder crate to your Cargo.toml:

[dependencies]
shuttle-service = { version = "0.8.0" }
shuttle-static-folder = { version = "0.8.0" }

and add the #[shuttle_static_folder::StaticFolder] annotation to a PathBuf argument in your service's main:

use shuttle_static_folder::StaticFolder;

#[shuttle_service::main]
async fn main(
    #[StaticFolder(folder = "/public")] static: PathBuf,
) -> _ { ... }

This will mount a folder in the service's runtime and populate it with the content of the local directory /public. If you don't specify the value of the folder parameter, the default is /static. Head over [to the docs](https://docs.shuttle.rs/resources/shuttle-static-folder) to learn more about this plugin.

Public dependencies

The Cargo.toml file of your shuttle services can now accept any public dependency that can be pulled on deployment - not just [crates.io](http://crates.io/) ones. This means, for example, that you can deploy with git dependencies:

[dependencies]
shuttle-service = { version = "0.8.0" }
strum = { git = "[email protected]:shuttle-hq/strum.git" }

And more!

  • We now support Actix Web, thanks @biryukovmaxim!
  • We have bumped our supported Rust version to 1.65, and our pinned tokio version to 1.22
  • We have bumped all of our dependencies, including our integrations. A few of you will need to upgrade as well, for example Axum users will have to upgrade to 0.6 to use the latest version of shuttle-service with the axum integration.
  • We fixed issues for certain projects that would lead them to not report their readiness state correctly
  • We've added a redeployment strategy that kicks in if projects stop responding, making them more resilient to unexpected panics

How to upgrade

If you had a project on shuttle, then you will need to manually update the version to 0.8.0 in your Cargo.toml. You may also need to update the versions of your shuttle resources to 0.8.0.

To upgrade your project container:

cargo shuttle project rm // to remove your project
cargo shuttle project new // to recreate your project
cargo shuttle deploy // redeploy your service

To upgrade your shuttle CLI, simply run cargo install cargo-shuttle.

New Contributors

Pull Requests for this release

Full Changelog: v0.7.2...v0.8.0

Contributors

Procrat, chesedo, and 6 other contributors
Assets 2
Loading