fix: broken external links

docs/local-run.mdx

@@ -108,7 +108,7 @@ if cfg!(debug_assertions) {
 
 ## Docker engines
 
-`cargo-shuttle` uses the [bollard](https://crates.io/crates/bollard) crate to interact with the Docker engine on local runs.
+`cargo-shuttle` uses the [bollard](https://docs.rs/bollard/latest/bollard/index.html) crate to interact with the Docker engine on local runs.
 
 If you are using a non-standard Docker engine, you might get this error:
 

examples/rocket-jwt-authentication.mdx

@@ -5,8 +5,8 @@ description: "Learn how you can secure your Rocket web application by using JWT
 
 ## Description
 
-This example shows how to use [Rocket request guards](https://rocket.rs/v0.5-rc/guide/requests/#request-guards) for authentication with [JSON Web Tokens](https://jwt.io/) (JWT for short).
-The idea is that all requests authenticate first at https://authentication-rocket-app.shuttle.app/login to get a JWT.
+This example shows how to use [Rocket request guards](https://rocket.rs/guide/v0.5/requests/#request-guards) for authentication with [JSON Web Tokens](https://jwt.io/) (JWT for short).
+The idea is that all requests authenticate first at the `/login` route on a given web service to get a JWT.
 Then the JWT is sent with all requests requiring authentication using the HTTP header `Authorization: Bearer <token>`.
 
 This example uses the [`jsonwebtoken`](https://github.com/Keats/jsonwebtoken) which supports symmetric and asymmetric secret encoding, built-in validations, and most JWT algorithms.
@@ -76,7 +76,7 @@ struct PrivateResponse {
 }
 
 // More details on Rocket request guards can be found here
-// https://rocket.rs/v0.5-rc/guide/requests/#request-guards
+// https://rocket.rs/guide/v0.5/requests/#request-guards
 #[get("/private")]
 fn private(user: Claims) -> Json<PrivateResponse> {
     Json(PrivateResponse {

templates/fullstack/saas-template.mdx

@@ -42,7 +42,7 @@ users will be able to view their customers, sales records as well as some analyt
 - **Using `dev` for Development:**
     - Run `npm run dev` to start your application with live reload capabilities. This script uses `turbowatch` to
       monitor changes in both the frontend and backend.
-    - Visit [http://localhost:8000](http://localhost:8000) once the app has built.
+    - Visit `http://localhost:8000` once the app has built.
     - If you prefer using `cargo-watch` instead of `turbowatch`, the watch feature can be disabled in
       the `turbowatch.ts` file.
 - **Frontend-Focused Development with `next-dev`:**

templates/tutorials/authentication.mdx

@@ -37,16 +37,16 @@ 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)); 
+#[shuttle_runtime::main] async fn axum() -> shuttle_axum::ShuttleAxum {
+    let router = Router::new().route("/hello", get(hello_world));
 
     Ok(router.into())
 }
 ```
 
 ### Templates
 
-For generating HTML we will be using [Tera](https://tera.netlify.app/docs), so
+For generating HTML we will be using [Tera](https://keats.github.io/tera/docs/), so
 we can go ahead and add this with `cargo add tera`. We will store all our
 `templates` in a template directory in the project root.
 
@@ -594,7 +594,7 @@ let session_token = req
 ### Auth middleware
 
 In the last post, we went into detail about middleware.
-[You can read more about it in more detail there](https://www.shuttle.dev/blog/2022/08/04/middleware).
+[You can read more about it in more detail there](https://www.shuttle.dev/blog/2022/08/04/middleware-in-rust).
 
 In our middleware, we will get a little fancy and make the user pulling lazy.
 This is so that requests that don't need user data don't have to make a database

templates/tutorials/send-your-logs-to-datadog.mdx

@@ -2,7 +2,7 @@
 title: 'Using Shuttle with Datadog'
 ---
 
-> written by [Roberto Huertas](https://robertohuertas.com/) 
+> written by [Roberto Huertas](https://robertohuertas.com/)
 
 ## Some words about observability
 
@@ -32,7 +32,7 @@ This is great for simple applications, but what if you want to send your logs to
 
 > As a disclaimer, I must say that I'm currently working at [Datadog](https://datadoghq.com), so I'm a bit biased, but I'm also a huge fan of the product and I think it's a great tool for developers 😅.
 
-Most of the time, the easiest way to send anything to the [Datadog platform](https://www.datadoghq.com/observability-platform/) is by using the [Datadog Agent](https://docs.datadoghq.com/agent/), but in this case, as **we cannot install it** in any way, we will use a **small library I created for the occasion** called [dd-tracing-layer](https://crates.io/crates/dd-tracing-layer), which happens to be using the [Datadog HTTP API](https://docs.datadoghq.com/api/latest/logs/) under the hood to send logs to the  [Datadog platform](https://www.datadoghq.com/observability-platform/).
+Most of the time, the easiest way to send anything to the [Datadog platform](https://www.datadoghq.com/observability-platform/) is by using the [Datadog Agent](https://docs.datadoghq.com/agent/), but in this case, as **we cannot install it** in any way, we will use a **small library I created for the occasion** called [dd-tracing-layer](https://docs.rs/dd-tracing-layer/latest/dd_tracing_layer/), which happens to be using the [Datadog HTTP API](https://docs.datadoghq.com/api/latest/logs/) under the hood to send logs to the  [Datadog platform](https://www.datadoghq.com/observability-platform/).
 
 ## How to use tracing with Shuttle
 
@@ -45,7 +45,7 @@ If we check the [Shuttle documentation](https://docs.shuttle.dev/configuration/l
 use tracing::info;
 
 #[shuttle_runtime::main]
-async fn axum(#[shuttle_shared_db::Postgres] pool: PgPool) -> ShuttleAxum { 
+async fn axum(#[shuttle_shared_db::Postgres] pool: PgPool) -> ShuttleAxum {
     info!("Running database migration");
     pool.execute(include_str!("../schema.sql"))
         .await
@@ -85,7 +85,7 @@ As a walkthrough, we are going to create a new [Shuttle](https://www.shuttle.dev
 
 The idea is to build a simple REST API using [Axum](https://docs.rs/axum/latest/axum/) and send our logs to [Datadog](https://datadoghq.com) using the [dd-tracing-layer](https://crates.io/crates/dd-tracing-layer) crate.
 
-Although I'm going to describe all the steps you need to take to make this work, you can see the **final state of the project** in this [GitHub repository](https://github.com/robertohuertasm/shuttle-datadog-logs). 
+Although I'm going to describe all the steps you need to take to make this work, you can see the **final state of the project** in this [GitHub repository](https://github.com/robertohuertasm/shuttle-datadog-logs).
 
 Feel free to use it as a reference.
 

templates/tutorials/serverless-calendar-app.mdx

@@ -129,7 +129,6 @@ Then:
 ```bash
 shuttle deploy
 ```
-
 Now let's head over to the returned project URL:
 
 Hello World! Deploying the first version took less than 5 minutes. Nice! We're

templates/tutorials/websocket-chat-app-js.mdx

@@ -4,8 +4,6 @@ title: "Chat app with React & Rust"
 
 Source code can be found [here](https://github.com/joshua-mo-143/react-websocket-chat-rust).
 
-A live deployment link can be found [here](https://websocket-chat-react-rust-example.shuttle.app/) if you'd like to see the end result before we start.
-
 With Rust going from strength to strength within the web development space, it is clear why many developers and big names are starting to take notice. As one example of this, Meta has recently [recommended Rust](https://engineering.fb.com/2022/07/27/developer-tools/programming-languages-endorsed-for-server-side-use-at-meta/#:~:text=Meta's%20primary%20supported%20server%2Dside,new%20addition%20to%20this%20list.) as a server-side language. If that won't make people sit up and look, then it's hard to know what will - Rust's current offering easily stands on par with most other languages that you could use in a back-end API or microservice, and it will only get better with time.
 
 Let's explore Rust in everyday usage by creating a Typescript React app and combining it with a Rust API that uses WebSockets. While node.js is quick to set up, doesn't require context switching and is easy to use if you already have Javascript knowledge from learning it for writing front-end web apps, you don't need to have a high level of knowledge in Rust to get started writing competent web services that can easily carry out whatever you need.
@@ -277,7 +275,7 @@ Now we can write an npm script to run both our front and back ends in one comman
 ```json
   "scripts": {
     "dev": "concurrently new \"vite\" \"shuttle run --working-directory API\"",
-// ... your other scripts  
+// ... your other scripts
   },
 ```
 
@@ -452,7 +450,7 @@ async fn disconnect_user(
 Now we can easily set up an admin router within the router function that will allow us to disconnect people manually, given a user ID and an authentication secret which you should write like so:
 
 ```rust
-// write this somewhere in your router function 
+// write this somewhere in your router function
 // RequireAuthorizationLayer dictates we must send a Bearer auth token to authorise the kick/remove
     let admin = Router::new()
     .route("/disconnect/:user_id", get(disconnect_user))
@@ -524,7 +522,7 @@ Now if we run `npm run build`, it should build our assets in the API folder in a
 Before we move on, let's re-write the WebSocket URL so that it will dynamically match whatever the URL of our hosted project will be, instead of a fixed string. Let's change our WebSocket connection in the React front-end like so:
 
 ```ts
-// Set up the websocket URL. 
+// Set up the websocket URL.
 const wsUri = ((window.location.protocol == "https:" && "wss://") || "ws://") +
   window.location.host +
   "/ws";