diff --git a/README.md b/README.md
index 7484bb70..8cbb0708 100644
--- a/README.md
+++ b/README.md
@@ -11,7 +11,7 @@ Before contributing to our documentation, please read our [style guide](STYLE_GU
 The project includes a Makefile that provides shortcuts for common tasks. You can see all available commands by running:
 
 ```bash
-$ make help
+make help
 ```
 
 This will display a list of all available commands and their descriptions. The Makefile includes commands for installation, starting the development server, creating versions, formatting markdown files, and cleaning build artifacts.
@@ -21,23 +21,23 @@ This will display a list of all available commands and their descriptions. The M
 Make sure that you have Node.js installed on your computer.
 
 ```bash
-$ cd serverpod_docs
+cd serverpod_docs
 
 # Using npm
-$ npm install
+npm install
 
 # Or if you have Make installed, use this make command
-$ make install
+make install
 ```
 
 ### Local Development
 
 ```bash
 # Using npm
-$ npm start
+npm start
 
 # Or if you have Make installed, use this make command
-$ make start
+make start
 ```
 
 This command starts a local development server and opens up a browser window. Most changes are reflected live without having to restart the server.
@@ -50,10 +50,10 @@ Make sure that the documentation is all up-to-date then run:
 
 ```bash
 # Using npm
-$ npm run docusaurus docs:version X.X.X
+npm run docusaurus docs:version X.X.X
 
 # Or if you have Make installed, use this make command
-$ make version VERSION=X.X.X
+make version VERSION=X.X.X
 ```
 
 ### Amend the latest version
@@ -62,10 +62,10 @@ If you need to make changes to the latest version, you can do so by removing the
 
 ```bash
 # Using npm
-$ npm run docusaurus docs:version X.X.X
+npm run docusaurus docs:version X.X.X
 
 # Or if you have Make installed, use this make command
-$ make version VERSION=X.X.X
+make version VERSION=X.X.X
 ```
 
 ### Add redirects
@@ -84,20 +84,20 @@ Install the `markdownlint-cli` globally, by running the following command from y
 
 ```bash
 # Using npm
-$ npm install -g markdownlint-cli
+npm install -g markdownlint-cli
 
 # Or if you have Make installed, use this make command
-$ make install-linter
+make install-linter
 ```
 
 Formatting is only enforced in `/serverpod_docs/docs/` directory so therefore you only need to run the markdownlint-cli in this folder with:
 
 ```bash
 # Using npm
-$ markdownlint './docs/**/*.md'
+markdownlint './docs/**/*.md'
 
 # Or if you have Make installed, use this make command
-$ make format
+make format
 ```
 
 ### Manual build and deploy
@@ -105,5 +105,5 @@ $ make format
 To do this you need access to the Serverpod Github `serverpod.github.io` repository. Clone it next to the `serverpod_web` repo.
 
 ```bash
-$ util/deploy
+util/deploy
 ```
diff --git a/docs/01-installation.md b/docs/01-installation.md
index 171b0273..4416404e 100644
--- a/docs/01-installation.md
+++ b/docs/01-installation.md
@@ -13,7 +13,7 @@ Serverpod is tested on Mac, Windows, and Linux. Before you can install Serverpod
 Check your Flutter installation by running the following command in your terminal:
 
 ```bash
-$ flutter doctor
+flutter doctor
 ```
 
 ::::
@@ -29,7 +29,7 @@ If you want to use Postgres rather than SQLite on your machine, install **[Docke
 Check your Docker installation by running the following command in your terminal:
 
 ```bash
-$ docker info
+docker info
 ```
 
 If you are using Docker Desktop and you get an error, make sure that Docker is running. You can check this by looking for the Docker icon in your system tray or taskbar. If it's not running, start Docker Desktop and try again.
@@ -41,13 +41,13 @@ If you are using Docker Desktop and you get an error, make sure that Docker is r
 Serverpod is installed using the Dart package manager. To install Serverpod, run the following command in your terminal:
 
 ```txt
-$ dart install serverpod_cli 3.5.0-beta.6
+dart install serverpod_cli 3.5.0-beta.6
 ```
 
 This command will install the Serverpod command-line interface (CLI) globally on your machine. You can verify the installation by running:
 
 ```bash
-$ serverpod
+serverpod
 ```
 
 If everything is correctly configured, the help for the `serverpod` command is now displayed.
@@ -57,7 +57,7 @@ If everything is correctly configured, the help for the `serverpod` command is n
 If the Serverpod CLI is already installed globally, deactivate it before installing or upgrading:
 
 ```txt
-$ dart pub global deactivate serverpod_cli
+dart pub global deactivate serverpod_cli
 ```
 
 :::
diff --git a/docs/04-get-started/01-creating-endpoints.md b/docs/04-get-started/01-creating-endpoints.md
index 9eca173a..dbba2387 100644
--- a/docs/04-get-started/01-creating-endpoints.md
+++ b/docs/04-get-started/01-creating-endpoints.md
@@ -38,8 +38,8 @@ development:
 Next, we add the Dartantic AI package as a dependency to our server. This package provides a convenient interface for working with different AI providers, including Google's Gemini API.
 
 ```bash
-$ cd magic_recipe_server
-$ dart pub add dartantic_ai
+cd magic_recipe_server
+dart pub add dartantic_ai
 ```
 
 ## Create a new endpoint
@@ -100,8 +100,8 @@ For methods to be recognized by Serverpod, they need to return a typed `Future`
 Now, you need to generate the code for your new endpoint. You do this by running `serverpod generate` in the server directory of your project:
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 `serverpod generate` will create bindings for the endpoint and register them in the server's `generated/protocol.dart` file. It will also generate the required client code so that you can call your new `generateRecipe` method from your app.
@@ -221,16 +221,16 @@ Before you start your server, ensure no other Serverpod server is running. Also,
 Let's try our new recipe app! First, start the server:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart --apply-migrations
+cd magic_recipe_server
+docker compose up -d
+dart bin/main.dart --apply-migrations
 ```
 
 Now, you can start the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser:
diff --git a/docs/04-get-started/02-models-and-data.md b/docs/04-get-started/02-models-and-data.md
index ebaaa9fe..9c9188e3 100644
--- a/docs/04-get-started/02-models-and-data.md
+++ b/docs/04-get-started/02-models-and-data.md
@@ -34,8 +34,8 @@ You can use most primitive Dart types here or any other models you have specifie
 To generate the code for the model, run the `serverpod generate` command in your server directory:
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 This will generate the code for the model and create a new file called `recipe.dart` in the `lib/src/generated` directory. It will also update the client code in `magic_recipe/magic_recipe_client` so you can use it in your Flutter app.
@@ -133,8 +133,8 @@ class RecipeEndpoint extends Endpoint {
 First, we need to update our generated client by running `serverpod generate`.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 Now that we have created the `Recipe` model we can use it in the app. We will do this in the `_callGenerateRecipe` method of the `magic_recipe_flutter/lib/main.dart` file. Let's update our `RecipeWidget` so that it displays the author and year of the recipe in addition to the recipe itself.
@@ -433,16 +433,16 @@ class ResultDisplay extends StatelessWidget {
 First, start the server:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart
+cd magic_recipe_server
+docker compose up -d
+dart bin/main.dart
 ```
 
 Then, start the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look something like this:
diff --git a/docs/04-get-started/03-working-with-the-database.md b/docs/04-get-started/03-working-with-the-database.md
index 1d056603..a0c48d83 100644
--- a/docs/04-get-started/03-working-with-the-database.md
+++ b/docs/04-get-started/03-working-with-the-database.md
@@ -42,9 +42,9 @@ To create a migration, follow these two steps in order:
 2. Run `serverpod create-migration` to create the necessary database migration.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
-$ serverpod create-migration
+cd magic_recipe_server
+serverpod generate
+serverpod create-migration
 ```
 
 Each time you run `serverpod create-migration`, a new migration file will be created in your _migrations_ folder. These step-by-step migrations provide a history of your database changes and allow you to roll back changes if needed.
@@ -190,8 +190,8 @@ The `insertRow` method is used to insert a new row into the database. The `find`
 Like before, when you change something that has an effect on your client code, you need to run `serverpod generate`. We don't need to run `serverpod create-migrations` again because we already created a migration in the previous step and haven't done any changes that affect the database.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 ## Call the endpoint from the app
@@ -434,9 +434,9 @@ To run the application with database support, follow these steps in order:
 First, start the database and apply migrations:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d                   # Start the database container
-$ dart bin/main.dart --apply-migrations  # Apply any pending migrations
+cd magic_recipe_server
+docker compose up -d                   # Start the database container
+dart bin/main.dart --apply-migrations  # Apply any pending migrations
 ```
 
 :::tip
@@ -446,8 +446,8 @@ The `--apply-migrations` flag is safe to use during development - if no migratio
 Next, launch the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 ## Summary
diff --git a/docs/06-concepts/06-database/01-connection.md b/docs/06-concepts/06-database/01-connection.md
index 0c9ce97a..05bff19a 100644
--- a/docs/06-concepts/06-database/01-connection.md
+++ b/docs/06-concepts/06-database/01-connection.md
@@ -100,19 +100,19 @@ development:
 A newly created Serverpod project has a preconfigured Docker instance with a Postgres database set up. Run the following command from the root of the `server` package to start the database:
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To stop the database run:
 
 ```bash
-$ docker compose stop
+docker compose stop
 ```
 
 To remove the database and __delete__ all associated data, run:
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
 
 ## Connecting to a custom Postgres instance
diff --git a/docs/06-concepts/06-database/11-migrations.md b/docs/06-concepts/06-database/11-migrations.md
index 80bc54c2..ad8f803b 100644
--- a/docs/06-concepts/06-database/11-migrations.md
+++ b/docs/06-concepts/06-database/11-migrations.md
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,7 +47,7 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
@@ -55,7 +55,7 @@ $ serverpod create-migration --force
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,7 +162,7 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
@@ -170,7 +170,7 @@ $ serverpod create-repair-migration --force
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
diff --git a/docs/06-concepts/10-modules.md b/docs/06-concepts/10-modules.md
index 442b0747..1bd1f12f 100644
--- a/docs/06-concepts/10-modules.md
+++ b/docs/06-concepts/10-modules.md
@@ -32,15 +32,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -79,13 +79,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.
diff --git a/docs/06-concepts/11-authentication/11-legacy/01-setup.md b/docs/06-concepts/11-authentication/11-legacy/01-setup.md
index 677ac269..c2769e98 100644
--- a/docs/06-concepts/11-authentication/11-legacy/01-setup.md
+++ b/docs/06-concepts/11-authentication/11-legacy/01-setup.md
@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
 Add the module as a dependency to the server project's `pubspec.yaml`.
 
 ```sh
-$ dart pub add serverpod_auth_server
+dart pub add serverpod_auth_server
 ```
 
 Add the authentication handler to the Serverpod instance.
@@ -46,7 +46,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
@@ -54,19 +54,19 @@ $ serverpod generate
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../../database/migrations).
diff --git a/docs/06-concepts/11-authentication/11-legacy/04-providers/02-google.md b/docs/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
index 7b52c420..8fe10f12 100644
--- a/docs/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
+++ b/docs/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
@@ -119,7 +119,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -136,7 +136,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::
diff --git a/docs/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md b/docs/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
index f5aab8fc..b1a4e0dc 100644
--- a/docs/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
+++ b/docs/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
@@ -31,8 +31,8 @@ To add authentication with Firebase, you must first install and initialize the F
 The short version:
 
 ```bash
-$ flutter pub add firebase_core firebase_auth firebase_ui_auth
-$ flutterfire configure
+flutter pub add firebase_core firebase_auth firebase_ui_auth
+flutterfire configure
 ```
 
 In the Firebase console, configure the different social sign-ins you plan to use, under `Authentication > Sign-in method`.
@@ -67,7 +67,7 @@ void main() async {
 Add the [serverpod_auth_firebase_flutter](https://pub.dev/packages/serverpod_auth_firebase_flutter) package.
 
 ```bash
-$ flutter pub add serverpod_auth_firebase_flutter
+flutter pub add serverpod_auth_firebase_flutter
 ```
 
 The `SignInWithFirebaseButton` is a convenient button that triggers the sign-in flow and can be used like this:
diff --git a/docs/06-concepts/12-file-uploads.md b/docs/06-concepts/12-file-uploads.md
index 8c3b42a0..5b0fa10f 100644
--- a/docs/06-concepts/12-file-uploads.md
+++ b/docs/06-concepts/12-file-uploads.md
@@ -140,7 +140,7 @@ You may also want to add the bucket as a backend for your load balancer to give
 When you have set up your GCP bucket, you need to configure it in Serverpod. Add the GCP package to your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_gcp
+dart pub add serverpod_cloud_storage_gcp
 ```
 
 ```dart
@@ -233,7 +233,7 @@ This section shows how to set up a storage using S3. Before you write your Dart
 When you are all set with the AWS setup, include the S3 package in your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_s3
+dart pub add serverpod_cloud_storage_s3
 ```
 
 ```dart
@@ -271,7 +271,7 @@ Serverpod supports Cloudflare R2 as a cloud storage provider. R2 is S3-compatibl
 Add the R2 package to your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_r2
+dart pub add serverpod_cloud_storage_r2
 ```
 
 ```dart
diff --git a/docs/06-concepts/14-scheduling/01-setup.md b/docs/06-concepts/14-scheduling/01-setup.md
index cdad56cd..5b6847d8 100644
--- a/docs/06-concepts/14-scheduling/01-setup.md
+++ b/docs/06-concepts/14-scheduling/01-setup.md
@@ -31,7 +31,7 @@ It is not valid to override the `invoke` method of the `FutureCall` class. This
 Next, you need to generate the code for your future calls:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 Calling `serverpod generate` will create a type-safe interface for invoking the future calls in the server's `generated/future_calls.dart` file. This interface can be accessed from the Serverpod object.
diff --git a/docs/06-concepts/14-scheduling/02-recurring-task.md b/docs/06-concepts/14-scheduling/02-recurring-task.md
index 0ae25963..ef4444bd 100644
--- a/docs/06-concepts/14-scheduling/02-recurring-task.md
+++ b/docs/06-concepts/14-scheduling/02-recurring-task.md
@@ -20,7 +20,7 @@ class ExampleFutureCall extends FutureCall {
 Next, generate the code for your future call:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 :::info
diff --git a/docs/06-concepts/14-scheduling/04-configuration.md b/docs/06-concepts/14-scheduling/04-configuration.md
index 5db4d347..74f0ead2 100644
--- a/docs/06-concepts/14-scheduling/04-configuration.md
+++ b/docs/06-concepts/14-scheduling/04-configuration.md
@@ -72,7 +72,7 @@ checkBrokenCalls: false
 The future calls check can be used with the maintenance role to programmatically validate that the server can be restarted without breaking future calls. The process will exit normally, but logs can be inspected to verify that no broken future calls were found.
 
 ```bash
-$ dart run bin/main.dart --role maintenance
+dart run bin/main.dart --role maintenance
 ```
 :::
 
diff --git a/docs/06-concepts/20-shared-packages.md b/docs/06-concepts/20-shared-packages.md
index fdd23d23..dd4c8e8c 100644
--- a/docs/06-concepts/20-shared-packages.md
+++ b/docs/06-concepts/20-shared-packages.md
@@ -75,7 +75,7 @@ Paths are relative to the server project directory. You can list multiple shared
 Run `serverpod generate` from your server directory.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 This generates the Dart classes and protocol in the shared package's `lib/src/generated/` directory. After generation, a typical shared package looks like:
diff --git a/docs/06-concepts/22-experimental.md b/docs/06-concepts/22-experimental.md
index 9f053f2e..bf8661fc 100644
--- a/docs/06-concepts/22-experimental.md
+++ b/docs/06-concepts/22-experimental.md
@@ -25,7 +25,7 @@ If possible, the experimental API will remain for some time as `@deprecated`, an
 Some of the experimental features are enabled by including the `--experimental-features` flag when running the serverpod command:
 
 ```bash
-$ serverpod generate --experimental-features=all
+serverpod generate --experimental-features=all
 ```
 
 The current options you can pass are:
diff --git a/docs/08-deployments/02-deploying-to-gce-terraform.md b/docs/08-deployments/02-deploying-to-gce-terraform.md
index 3a2ac487..f55c21bd 100644
--- a/docs/08-deployments/02-deploying-to-gce-terraform.md
+++ b/docs/08-deployments/02-deploying-to-gce-terraform.md
@@ -126,7 +126,7 @@ Depending on your domain name registrar, the process for setting up your domain
 You can test that the domain points to the correct name servers by running `dig` on the command line. It will output the domain name servers.
 
 ```bash
-$ dig +short NS examplepod.com
+dig +short NS examplepod.com
 ```
 
 Should yield an output similar to this:
@@ -228,13 +228,13 @@ If you are deploying a staging server in addition to your production server, you
 Once you have configured Terraform and your Serverpod, you are ready to deploy your infrastructure. Make sure that you have `cd` into your `deploy/gcp/terraform_gce` directory. Now run:
 
 ```bash
-$ terraform init
+terraform init
 ```
 
 This will download the Serverpod module and initialize your Terraform configuration. Now, deploy your infrastructure by running:
 
 ```bash
-$ terraform apply
+terraform apply
 ```
 
 Terraform will ask you for the password to your production and staging database. You will find the passwords in your `config/passwords.yaml` file. If you are not deploying a staging server, you can leave the staging database password blank.
diff --git a/docs/08-deployments/03-deploying-to-gcr-console.md b/docs/08-deployments/03-deploying-to-gcr-console.md
index cdd5991d..b647215c 100644
--- a/docs/08-deployments/03-deploying-to-gcr-console.md
+++ b/docs/08-deployments/03-deploying-to-gcr-console.md
@@ -11,13 +11,13 @@ Before you begin, you will need to install and configure the Google Cloud CLI to
 - To [initialize](https://cloud.google.com/sdk/docs/initializing) the gcloud CLI, run the following command:
 
 ```bash
-$ gcloud init
+gcloud init
 ```
 
 - To set the default project for your Cloud Run service:
 
 ```bash
-$ gcloud config set project <PROJECT_ID>
+gcloud config set project <PROJECT_ID>
 ```
 
 ## Setup the database
@@ -75,8 +75,8 @@ database:
 Your server is now ready to be deployed. When you created your project, Serverpod also created a script for deploying your server. Copy it to the root of your server directory and make it executable. Make sure you are in your server directory (e.g., `myproject_server`). Then run the following command:
 
 ```bash
-$ cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
-$ chmod u+x cloud-run-deploy.sh
+cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
+chmod u+x cloud-run-deploy.sh
 ```
 
 Open up the script in your favorite editor. You will need to fill in your _database instance's connection name_ and the _email of your service account_.
@@ -84,7 +84,7 @@ Open up the script in your favorite editor. You will need to fill in your _datab
 Now, deploy your server by running the following:
 
 ```bash
-$ ./cloud-run-deploy.sh
+./cloud-run-deploy.sh
 ```
 
 The script runs two deployment commands, one for your API and one for the Insights API used by the Serverpod app. While running, it may ask you to enable the Cloud Run and SQL Admin services. Answer yes to all these questions.
diff --git a/docs/08-deployments/04-deploying-to-aws.md b/docs/08-deployments/04-deploying-to-aws.md
index af139474..713e4d4c 100644
--- a/docs/08-deployments/04-deploying-to-aws.md
+++ b/docs/08-deployments/04-deploying-to-aws.md
@@ -202,14 +202,14 @@ database:
 Your Serverpod should now be configured and ready to be deployed. Exciting times! Open up a terminal and `cd` into your server `aws/terraform` directory. First, you need to add an environment variable so that Terraform can correctly set the password for the Postgres database. You will find the production password for the database in your `config/passwords.yaml` file.
 
 ```bash
-$ export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
+export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
 ```
 
 Next, we are ready to initialize Terraform and deploy our server. You will only need to run the `terraform init` command the first time you deploy the configuration.
 
 ```bash
-$ terraform init
-$ terraform apply
+terraform init
+terraform apply
 ```
 
 Terraform will now run some checks and make a plan for the deployment. If everything looks good, it will ask you if you are ready to go ahead with the changes. Type `yes` and hit the return key. Applying the changes can take up to five minutes as AWS creates the different resources needed for your Serverpod.
diff --git a/docs/08-deployments/05-general.md b/docs/08-deployments/05-general.md
index 981bb8d9..fa1f3878 100644
--- a/docs/08-deployments/05-general.md
+++ b/docs/08-deployments/05-general.md
@@ -11,7 +11,7 @@ Serverpod will not run without a link to a Postgres database with the correct ta
 Serverpod has three main configuration files, depending on which mode the server is running; `development`, `staging`, or `production`. The files are located in the `config/` directory. By default, the server will start in development mode. To use another configuration file, use the `--mode` option when starting the server. If you are running multiple servers in a cluster, use the `--server-id` option to specify the id of each server. By default, the server will run as id `default`. For instance, to start the server in production mode with id `2`, run the following command:
 
 ```bash
-$ dart bin/main.dart --mode production --server-id 2
+dart bin/main.dart --mode production --server-id 2
 ```
 
 :::info
@@ -35,7 +35,7 @@ Serverpod can assume different roles depending on your configuration. If you run
 You can specify the role of your server when you launch it by setting the `--role` argument.
 
 ```bash
-$ dart bin/main.dart --role serverless
+dart bin/main.dart --role serverless
 ```
 
 ## Docker container
diff --git a/docs/09-upgrading/03-upgrade-to-pgvector.md b/docs/09-upgrading/03-upgrade-to-pgvector.md
index 24896009..6f94d34c 100644
--- a/docs/09-upgrading/03-upgrade-to-pgvector.md
+++ b/docs/09-upgrading/03-upgrade-to-pgvector.md
@@ -64,8 +64,8 @@ fields:
 4. Generate and apply a migration:
 
 ```bash
-$ serverpod create-migration
-$ dart run bin/main.dart --apply-migrations
+serverpod create-migration
+dart run bin/main.dart --apply-migrations
 ```
 
 For more details on creating and applying migrations, see the [Migrations](../concepts/database/migrations) section.
diff --git a/docs/09-upgrading/04-archive/03-upgrade-to-two.md b/docs/09-upgrading/04-archive/03-upgrade-to-two.md
index 54e3b54d..5ef0d80a 100644
--- a/docs/09-upgrading/04-archive/03-upgrade-to-two.md
+++ b/docs/09-upgrading/04-archive/03-upgrade-to-two.md
@@ -284,7 +284,7 @@ To ensure new databases are created with the new representation, the latest migr
 A new empty migration can be created by running the following command in the terminal:
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 #### Migration of existing tables
diff --git a/docs/10-tools/02-lsp.md b/docs/10-tools/02-lsp.md
index 2374cf57..8da02d1b 100644
--- a/docs/10-tools/02-lsp.md
+++ b/docs/10-tools/02-lsp.md
@@ -5,7 +5,7 @@ The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server
 To start the Serverpod LSP server, use the following command:
 
 ```bash
-$ serverpod language-server
+serverpod language-server
 ```
 
 :::info
diff --git a/docs/10-tools/03-run-scripts.md b/docs/10-tools/03-run-scripts.md
index 699ed8ce..d040adcb 100644
--- a/docs/10-tools/03-run-scripts.md
+++ b/docs/10-tools/03-run-scripts.md
@@ -19,13 +19,13 @@ serverpod:
 To run a script:
 
 ```bash
-$ serverpod run start
+serverpod run start
 ```
 
 To list all available scripts, use the `--list` flag or omit the script name:
 
 ```bash
-$ serverpod run --list
+serverpod run --list
 ```
 
 Scripts run in a shell environment (`bash` on Linux/macOS, `cmd` on Windows), so you can use pipes, conditionals, and environment variables. The CLI forwards signals like `Ctrl+C` to the running script and propagates exit codes.
diff --git a/docs/11-serverpod-mini.md b/docs/11-serverpod-mini.md
index d9a254ca..54883a22 100644
--- a/docs/11-serverpod-mini.md
+++ b/docs/11-serverpod-mini.md
@@ -40,7 +40,7 @@ Serverpod Mini is a lightweight version of Serverpod that is perfect for small p
 Create a mini project by running:
 
 ```bash
-$ serverpod create myminipod --mini
+serverpod create myminipod --mini
 ```
 
 Serverpod will create a new project for you. It contains three Dart packages, but you only need to pay attention to the `myminipod_server` and `myminipod_flutter` directories. The server directory contains your server files, and the flutter directory contains your app. The third package (`myminipod_client`) contains generated code that is used by the Flutter app to communicate with the server.
@@ -48,15 +48,15 @@ Serverpod will create a new project for you. It contains three Dart packages, bu
 Start your server by changing directory into your server directory, and run the `bin/main.dart` file:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ dart bin/main.dart
+cd myminipod/myminipod_server
+dart bin/main.dart
 ```
 
 Your default project comes with a sample Flutter app, all hooked up to talk with your server. Run it with the `flutter` command:
 
 ```bash
-$ cd myminipod/myminipod_flutter
-$ flutter run -d chrome
+cd myminipod/myminipod_flutter
+flutter run -d chrome
 ```
 
 Easy as that. 🥳
@@ -84,8 +84,8 @@ For types, you can use most basic Dart types, such as `String`, `double`, `int`,
 Whenever you add or edit a model file, run `serverpod generate` in your server directory. Then, Serverpod will generate all the updated Dart classes:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Adding methods to your server
@@ -121,8 +121,8 @@ class CompanyEndpoint extends Endpoint {
 After adding or modifying endpoints and endpoint methods, you must run `serverpod generate` to keep your Flutter app up-to-date.
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Calling the server methods from the app
diff --git a/versioned_docs/version-1.1.1/03-tutorials/01-first-app.mdx b/versioned_docs/version-1.1.1/03-tutorials/01-first-app.mdx
index 5cc1d309..d7c180cd 100644
--- a/versioned_docs/version-1.1.1/03-tutorials/01-first-app.mdx
+++ b/versioned_docs/version-1.1.1/03-tutorials/01-first-app.mdx
@@ -29,7 +29,7 @@ Demo of what we will build: ([Full code example](https://github.com/serverpod/no
 Create a new project using the Serverpod CLI. Run the following command in your terminal:
 
 ```bash
-$ serverpod create notes
+serverpod create notes
 ```
 
 To start the server:
@@ -64,7 +64,7 @@ Let's take a closer look at the content of the `notes.yaml` file:
 Use the code generator to generate the code for the `Note` class from the definition in `notes.yaml`. Run the following command from the root of your server project:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 After the code generation process is complete, you can access the generated code for the `Note` class in `lib/src/generated/note.dart` inside your Serverpod project.
@@ -93,7 +93,7 @@ fields:
 Run the code generator again to generate the necessary code for the database table:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 Take a look at the updated `lib/src/generated/note.dart` file. You will notice that the code generator has added new methods for interacting with the database. 
@@ -260,7 +260,7 @@ Congratulations! You have now created all the endpoints needed for the note app.
 Now run the code generator again to generate the client library for our endpoints. This needs to be run from the server directory `notes_server`.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 You can find all the newly generated code in the client directory `notes_client`. You normally don't need to touch this package, but it's good to know where it is located.
diff --git a/versioned_docs/version-1.1.1/05-concepts/09-authentication/01-setup.mdx b/versioned_docs/version-1.1.1/05-concepts/09-authentication/01-setup.mdx
index af3787ea..31d10e8d 100644
--- a/versioned_docs/version-1.1.1/05-concepts/09-authentication/01-setup.mdx
+++ b/versioned_docs/version-1.1.1/05-concepts/09-authentication/01-setup.mdx
@@ -34,7 +34,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
diff --git a/versioned_docs/version-1.2.0/01-get-started.md b/versioned_docs/version-1.2.0/01-get-started.md
index 047228a3..ebc4d885 100644
--- a/versioned_docs/version-1.2.0/01-get-started.md
+++ b/versioned_docs/version-1.2.0/01-get-started.md
@@ -5,7 +5,7 @@ This page should give you an understanding of how a Serverpod project is structu
 Create a new project by running `serverpod create`.
 
 ```bash
-$ serverpod create mypod
+serverpod create mypod
 ```
 
 :::info
@@ -24,9 +24,9 @@ This command will create a new directory called `mypod`, with three dart package
 Make sure that [Docker Desktop](https://www.docker.com/products/docker-desktop/) is running, then start your Docker containers with `docker compose up --build --detach`. It will start Postgres and Redis. Then, run `dart bin/main.dart --apply-migrations` to start your server.
 
 ```bash
-$ cd mypod/mypod_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd mypod/mypod_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 If everything is working, you should see something like this on your terminal:
@@ -54,8 +54,8 @@ In your development environment it can be helpful to always start Serverpod with
 Start the default demo app by changing the directory into the Flutter package that was created and running `flutter run`.
 
 ```bash
-$ cd mypod/mypod_flutter
-$ flutter run -d chrome
+cd mypod/mypod_flutter
+flutter run -d chrome
 ```
 
  The flag `-d chrome` runs the app in Chrome, for other run options please see the Flutter documentation.
@@ -81,8 +81,8 @@ Both the `endpoints` and `models` directories contain sample files that give a q
 Whenever you change your code in either the `endpoints` or `models` directory, you will need to regenerate the classes managed by Serverpod. Do this by running `serverpod generate`.
 
 ```bash
-$ cd mypod/mypod_server
-$ serverpod generate
+cd mypod/mypod_server
+serverpod generate
 ```
 
 ### Working with endpoints
@@ -164,15 +164,15 @@ development:
 With database migrations, Serverpod makes it easy to evolve your database schema. When you make changes to your project that should be reflected in your database, you need to create a migration. A migration is a set of SQL queries that are run to update the database. To create a migration, run `serverpod create-migration` in the home directory of the server. 
 
 ```bash
-$ cd mypod/mypod_server
-$ serverpod create-migration
+cd mypod/mypod_server
+serverpod create-migration
 ```
 
 Migrations are then applied to the database as part of the server startup by adding the `--apply-migrations` flag.
 
 ```bash 
-$ cd mypod/mypod_server
-$ dart bin/main.dart --apply-migrations
+cd mypod/mypod_server
+dart bin/main.dart --apply-migrations
 ```
 
 :::tip
diff --git a/versioned_docs/version-1.2.0/03-tutorials/01-first-app.mdx b/versioned_docs/version-1.2.0/03-tutorials/01-first-app.mdx
index 5f466c17..3ec4c193 100644
--- a/versioned_docs/version-1.2.0/03-tutorials/01-first-app.mdx
+++ b/versioned_docs/version-1.2.0/03-tutorials/01-first-app.mdx
@@ -29,15 +29,15 @@ Demo of what we will build: ([Full code example](https://github.com/serverpod/no
 Create a new project using the Serverpod CLI. Run the following command in your terminal:
 
 ```bash
-$ serverpod create notes
+serverpod create notes
 ```
 
 To start the server:
 
 ```bash
-$ cd notes/notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes/notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 :::info
@@ -69,7 +69,7 @@ Let's take a closer look at the content of the `note.yaml` file:
 Use the code generator to generate the code for the `Note` class from the definition in `note.yaml`. Run the following command from the root of your server project (`notes_server`):
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 After the code generation process is complete, you can access the generated code for the `Note` class in `lib/src/generated/note.dart` inside your Serverpod project.
@@ -98,7 +98,7 @@ fields:
 Run the code generator again to generate the necessary code used to access the database table:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 Take a look at the updated `lib/src/generated/note.dart` file. You will notice that the code generator has added new methods for interacting with the database. 
@@ -107,7 +107,7 @@ Take a look at the updated `lib/src/generated/note.dart` file. You will notice t
 To create the new `note` table in the database we will use the Serverpod migration system. Run the following command to generate a new database migration:
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 This creates a new migration that contains a description of the database schema and SQL code to add the table. These files can be found in the `migrations` directory in your server project (`notes_server`).
@@ -117,7 +117,7 @@ This creates a new migration that contains a description of the database schema
 To apply the database migration, start the server with the `--apply-migrations` command. We can also run the server in maintenance mode which will shut down the server as soon as its tasks are done.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 Once command has executed successfully, the database table for storing the note data will have been created.
@@ -237,7 +237,7 @@ Congratulations! You have now created all the endpoints needed for the notes app
 Now run the code generator again to generate the client library for our endpoints. This needs to be run from the server directory `notes_server`.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 You can find the newly generated code in the client directory `notes_client`. You normally don't need to touch this package, but it's good to know where it is located.
@@ -752,16 +752,16 @@ Start the database and server:
 Make sure you reboot the server if you started it earlier.
 
 ```bash
-$ cd notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 Start the Flutter app in Chrome (or the platform of your choice):
 
 ```bash
-$ cd notes_flutter
-$ flutter run -d chrome
+cd notes_flutter
+flutter run -d chrome
 ```
 
 <ReactPlayer playing={true} loop controls width="960px" height="720px" url='/img/tutorial/note-app/03-note-create.mp4' />
diff --git a/versioned_docs/version-1.2.0/05-concepts/03-serialization.md b/versioned_docs/version-1.2.0/05-concepts/03-serialization.md
index b4e07d9a..5626da95 100644
--- a/versioned_docs/version-1.2.0/05-concepts/03-serialization.md
+++ b/versioned_docs/version-1.2.0/05-concepts/03-serialization.md
@@ -64,8 +64,8 @@ Your folder structure should then look like this:
 Then you need to add the package `serverpod_serialization` to get access to the `SerializationManager` class.
 
 ```bash
-$ cd my_project_shared
-$ dart pub add serverpod_serialization
+cd my_project_shared
+dart pub add serverpod_serialization
 ```
 
 Then you need to update both your `my_project_server/pubspec.yaml` and `my_project_client/pubspec.yaml` and add the new package as a dependency.
diff --git a/versioned_docs/version-1.2.0/05-concepts/06-database/01-connection.md b/versioned_docs/version-1.2.0/05-concepts/06-database/01-connection.md
index 3e1d15b9..d09d8179 100644
--- a/versioned_docs/version-1.2.0/05-concepts/06-database/01-connection.md
+++ b/versioned_docs/version-1.2.0/05-concepts/06-database/01-connection.md
@@ -47,18 +47,18 @@ A newly created Serverpod project comes with a preconfigured docker instance wit
 :::
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To remove the database run (this commands preserve all data).
 
 ```bash
-$ docker compose down
+docker compose down
 ```
 
 To remove the database and __delete__ all data add the `-v` flag.
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
 
diff --git a/versioned_docs/version-1.2.0/05-concepts/06-database/11-migrations.md b/versioned_docs/version-1.2.0/05-concepts/06-database/11-migrations.md
index c4e1891e..e0ededd7 100644
--- a/versioned_docs/version-1.2.0/05-concepts/06-database/11-migrations.md
+++ b/versioned_docs/version-1.2.0/05-concepts/06-database/11-migrations.md
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,7 +47,7 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
@@ -55,7 +55,7 @@ $ serverpod create-migration --force
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,7 +162,7 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
@@ -170,7 +170,7 @@ $ serverpod create-repair-migration --force
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
diff --git a/versioned_docs/version-1.2.0/05-concepts/09-modules.md b/versioned_docs/version-1.2.0/05-concepts/09-modules.md
index eee00e5c..3eb0e1ae 100644
--- a/versioned_docs/version-1.2.0/05-concepts/09-modules.md
+++ b/versioned_docs/version-1.2.0/05-concepts/09-modules.md
@@ -35,15 +35,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -81,13 +81,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.
diff --git a/versioned_docs/version-1.2.0/05-concepts/10-authentication/01-setup.md b/versioned_docs/version-1.2.0/05-concepts/10-authentication/01-setup.md
index 3a32b2ec..66038296 100644
--- a/versioned_docs/version-1.2.0/05-concepts/10-authentication/01-setup.md
+++ b/versioned_docs/version-1.2.0/05-concepts/10-authentication/01-setup.md
@@ -30,7 +30,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
@@ -38,20 +38,20 @@ $ serverpod generate
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../database/migrations).
diff --git a/versioned_docs/version-1.2.0/05-concepts/10-authentication/04-providers/02-google.md b/versioned_docs/version-1.2.0/05-concepts/10-authentication/04-providers/02-google.md
index a78f9bc6..ec168e52 100644
--- a/versioned_docs/version-1.2.0/05-concepts/10-authentication/04-providers/02-google.md
+++ b/versioned_docs/version-1.2.0/05-concepts/10-authentication/04-providers/02-google.md
@@ -117,7 +117,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -134,7 +134,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::
diff --git a/versioned_docs/version-1.2.0/05-concepts/10-authentication/04-providers/05-firebase.md b/versioned_docs/version-1.2.0/05-concepts/10-authentication/04-providers/05-firebase.md
index 0833366a..3b7bfdc5 100644
--- a/versioned_docs/version-1.2.0/05-concepts/10-authentication/04-providers/05-firebase.md
+++ b/versioned_docs/version-1.2.0/05-concepts/10-authentication/04-providers/05-firebase.md
@@ -29,8 +29,8 @@ To add authentication with Firebase, you must first install and initialize the F
 The short version:
 
 ```bash
-$ flutter pub add firebase_core firebase_auth firebase_ui_auth
-$ flutterfire configure
+flutter pub add firebase_core firebase_auth firebase_ui_auth
+flutterfire configure
 ```
 
 In the Firebase console, configure the different social sign-ins you plan to use, under `Authentication > Sign-in method`.
@@ -65,7 +65,7 @@ void main() async {
 Add the [serverpod_auth_firebase_flutter](https://pub.dev/packages/serverpod_auth_firebase_flutter) package.
 
 ```bash
-$ flutter pub add serverpod_auth_firebase_flutter
+flutter pub add serverpod_auth_firebase_flutter
 ```
 
 The `SignInWithFirebaseButton` is a convenient button that triggers the sign-in flow and can be used like this:
diff --git a/versioned_docs/version-1.2.0/06-deployments/02-deploying-to-gce-terraform.md b/versioned_docs/version-1.2.0/06-deployments/02-deploying-to-gce-terraform.md
index 1c7b02f4..0a8cc624 100644
--- a/versioned_docs/version-1.2.0/06-deployments/02-deploying-to-gce-terraform.md
+++ b/versioned_docs/version-1.2.0/06-deployments/02-deploying-to-gce-terraform.md
@@ -117,7 +117,7 @@ Depending on your domain name registrar, the process for setting up your domain
 You can test that the domain points to the correct name servers by running `dig` on the command line. It will output the domain name servers.
 
 ```bash
-$ dig +short NS examplepod.com
+dig +short NS examplepod.com
 ```
 
 Should yield an output similar to this:
@@ -212,13 +212,13 @@ If you are deploying a staging server in addition to your production server, you
 Once you have configured Terraform and your Serverpod, you are ready to deploy your infrastructure. Make sure that you have `cd` into your `deploy/gcp/terraform_gce` directory. Now run:
 
 ```bash
-$ terraform init
+terraform init
 ```
 
 This will download the Serverpod module and initialize your Terraform configuration. Now, deploy your infrastructure by running:
 
 ```bash
-$ terraform apply
+terraform apply
 ```
 
 Terraform will ask you for the password to your production and staging database. You will find the passwords in your `config/passwords.yaml` file. If you are not deploying a staging server, you can leave the staging database password blank.
diff --git a/versioned_docs/version-1.2.0/06-deployments/03-deploying-to-gcr-console.md b/versioned_docs/version-1.2.0/06-deployments/03-deploying-to-gcr-console.md
index 08898b08..8661eb90 100644
--- a/versioned_docs/version-1.2.0/06-deployments/03-deploying-to-gcr-console.md
+++ b/versioned_docs/version-1.2.0/06-deployments/03-deploying-to-gcr-console.md
@@ -8,11 +8,11 @@ Before you begin, you will need to install and configure the Google Cloud CLI to
 - [Install](https://cloud.google.com/sdk/docs/install) the Google Cloud CLI.
 - To [initialize](https://cloud.google.com/sdk/docs/initializing) the gcloud CLI, run the following command:
 ```bash
-$ gcloud init
+gcloud init
 ```
 - To set the default project for your Cloud Run service:
 ```bash
-$ gcloud config set project <PROJECT_ID>
+gcloud config set project <PROJECT_ID>
 ```
 
 ## Setup the database
@@ -64,8 +64,8 @@ database:
 Your server is now ready to be deployed. When you created your project, Serverpod also created a script for deploying your server. Copy it to the root of your server directory and make it executable. Make sure you are in your server directory (e.g., `myproject_server`). Then run the following command:
 
 ```bash
-$ cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
-$ chmod u+x cloud-run-deploy.sh
+cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
+chmod u+x cloud-run-deploy.sh
 ```
 
 Open up the script in your favorite editor. You will need to fill in your _database instance's connection name_ and the _email of your service account_.
@@ -73,7 +73,7 @@ Open up the script in your favorite editor. You will need to fill in your _datab
 Now, deploy your server by running the following:
 
 ```bash
-$ ./cloud-run-deploy.sh
+./cloud-run-deploy.sh
 ```
 
 The script runs two deployment commands, one for your API and one for the Insights API used by the Serverpod app. While running, it may ask you to enable the Cloud Run and SQL Admin services. Answer yes to all these questions.
diff --git a/versioned_docs/version-1.2.0/06-deployments/04-deploying-to-aws.md b/versioned_docs/version-1.2.0/06-deployments/04-deploying-to-aws.md
index 1d1d0c3b..21162581 100644
--- a/versioned_docs/version-1.2.0/06-deployments/04-deploying-to-aws.md
+++ b/versioned_docs/version-1.2.0/06-deployments/04-deploying-to-aws.md
@@ -89,14 +89,14 @@ Finally, to complete your Serverpod configuration, you will need to edit the `co
 Your Serverpod should now be configured and ready to be deployed. Exciting times! Open up a terminal and `cd` into your server `aws/terraform` directory. First, you need to add an environment variable so that Terraform can correctly set the password for the Postgres database. You will find the production password for the database in your `config/passwords.yaml` file.
 
 ```bash
-$ export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
+export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
 ```
 
 Next, we are ready to initialize Terraform and deploy our server. You will only need to run the `terraform init` command the first time you deploy the configuration.
 
 ```bash
-$ terraform init
-$ terraform apply
+terraform init
+terraform apply
 ```
 
 Terraform will now run some checks and make a plan for the deployment. If everything looks good, it will ask you if you are ready to go ahead with the changes. Type `yes` and hit the return key. Applying the changes can take up to five minutes as AWS creates the different resources needed for your Serverpod.
diff --git a/versioned_docs/version-1.2.0/06-deployments/05-general.md b/versioned_docs/version-1.2.0/06-deployments/05-general.md
index 2dab8de7..6fa7330a 100644
--- a/versioned_docs/version-1.2.0/06-deployments/05-general.md
+++ b/versioned_docs/version-1.2.0/06-deployments/05-general.md
@@ -8,7 +8,7 @@ Serverpod will not run without a link to a Postgres database with the correct ta
 Serverpod has three main configuration files, depending on which mode the server is running; `development`, `staging`, or `production`. The files are located in the `config/` directory. By default, the server will start in development mode. To use another configuration file, use the `--mode` option when starting the server. If you are running multiple servers in a cluster, use the `--server-id` option to specify the id of each server. By default, the server will run as id `default`. For instance, to start the server in production mode with id `2`, run the following command:
 
 ```bash
-$ dart bin/main.dart --mode production --server-id 2
+dart bin/main.dart --mode production --server-id 2
 ```
 
 :::info
@@ -31,7 +31,7 @@ Serverpod can assume different roles depending on your configuration. If you run
 You can specify the role of your server when you launch it by setting the `--role` argument.
 
 ```bash
-$ dart bin/main.dart --role serverless
+dart bin/main.dart --role serverless
 ```
 
 ## Docker container
diff --git a/versioned_docs/version-1.2.0/07-cli.md b/versioned_docs/version-1.2.0/07-cli.md
index ef20230a..8a3670f0 100644
--- a/versioned_docs/version-1.2.0/07-cli.md
+++ b/versioned_docs/version-1.2.0/07-cli.md
@@ -5,7 +5,7 @@ The Serverpod Command Line Interface (CLI) provides a suite of tools to facilita
 ## Usage
 
 ```bash
-$ serverpod <command> [arguments]
+serverpod <command> [arguments]
 ```
 
 ## Global Options
diff --git a/versioned_docs/version-1.2.0/09-lsp.md b/versioned_docs/version-1.2.0/09-lsp.md
index 3b075501..e8040157 100644
--- a/versioned_docs/version-1.2.0/09-lsp.md
+++ b/versioned_docs/version-1.2.0/09-lsp.md
@@ -5,7 +5,7 @@ The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server
 To start the Serverpod LSP server, use the following command:
 
 ```bash
-$ serverpod language-server
+serverpod language-server
 ```
 
 :::info
diff --git a/versioned_docs/version-1.2.0/11-contribute.md b/versioned_docs/version-1.2.0/11-contribute.md
index f66583eb..673dcbc6 100644
--- a/versioned_docs/version-1.2.0/11-contribute.md
+++ b/versioned_docs/version-1.2.0/11-contribute.md
@@ -19,7 +19,7 @@ We are very conscious about keeping the Serverpod code base clean. When you writ
 Continuous integration tests are automatically run when sending a pull request to the `main` branch. You can run the tests locally by changing your working directory into the root serverpod directory and running:
 
 ```bash
-$ util/run_tests
+util/run_tests
 ```
 
 :::caution
@@ -39,28 +39,28 @@ Running single individual tests is useful when you are working on a specific fea
 ```
 2. Start the Docker container for the test server.
 ```bash
-$ cd tests/serverpod_test_server/docker-local
-$ docker compose up --build --detach
-$ ./setup-tables
+cd tests/serverpod_test_server/docker-local
+docker compose up --build --detach
+./setup-tables
 ```
 3. Start the test server.
 ```bash
-$ cd tests/serverpod_test_server
-$ dart bin/main.dart
+cd tests/serverpod_test_server
+dart bin/main.dart
 ```
 4. Run an individual test
 ```bash
-$ cd tests/serverpod_test_server
-$ dart test test/connection_test.dart
+cd tests/serverpod_test_server
+dart test test/connection_test.dart
 ```
 
 ### Command line tools
 To run the `serverpod` command from your cloned repository, you will need to:
 
 ```bash
-$ cd tools/serverpod_cli
-$ dart pub get
-$ dart pub global activate --source path .
+cd tools/serverpod_cli
+dart pub get
+dart pub global activate --source path .
 ```
 
 Depending on your Dart version you may need to run the `dart pub global` command above every time you've made changes in the Serverpod tooling.
@@ -79,7 +79,7 @@ First off, we are restrictive about which new packages we include in the Serverp
 Secondly, you shouldn't edit the `pubspec.yaml` files directly. Instead, make changes to the files in the `templates/` directory. When you've made changes, run the `update_pubspecs` command to generate the `pubspec.yaml` files.
 
 ```bash
-$ util/update_pubspecs
+util/update_pubspecs
 ```
 
 ## Submitting your pull request
diff --git a/versioned_docs/version-1.2.0/12-upgrading/01-upgrade-to-one-point-two.md b/versioned_docs/version-1.2.0/12-upgrading/01-upgrade-to-one-point-two.md
index c58b843a..24b29fe1 100644
--- a/versioned_docs/version-1.2.0/12-upgrading/01-upgrade-to-one-point-two.md
+++ b/versioned_docs/version-1.2.0/12-upgrading/01-upgrade-to-one-point-two.md
@@ -179,7 +179,7 @@ If it is not important to preserve the data that is in your database, you can si
 This ensures that the project is up to date with the latest version of Serverpod. Navigate to your project's `server` package directory and run the `generate` command.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 2. Create a migration for your project.
@@ -187,7 +187,7 @@ $ serverpod generate
 The migration system will create a migration as if the database needs to be initialized from scratch. Navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 3. Recreate database.
@@ -195,8 +195,8 @@ $ serverpod create-migration
 In a Serverpod development project, the database is hosted in a docker container. To remove the existing database and start a new one run the following commands:
 
 ```bash
-$ docker compose down -v
-$ docker compose up --build --detach 
+docker compose down -v
+docker compose up --build --detach 
 ```
 
 The command first removes the running container along with its volume and the second command starts a new database from scratch.
@@ -206,7 +206,7 @@ The command first removes the running container along with its volume and the se
 Initialize the database by applying the migration to it using the `--apply-migrations` flag when starting the server.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 ### Data to preserve
@@ -218,7 +218,7 @@ If your project already has data in the database that should be preserved, we ca
 This ensures that the project is up to date with the latest version of Serverpod. Navigate to your project's `server` package directory and run the `generate` command.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 2. Create a migration for your project.
@@ -226,7 +226,7 @@ $ serverpod generate
 The migration system will create a migration as if the database needs to be initialized from scratch. Navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 3. Create a repair migration.
@@ -234,8 +234,8 @@ $ serverpod create-migration
 The repair migration system will create a repair migration that makes your live database schema match the newly created migration. To enable the command to fetch your live database schema it requires a running server. Navigate to your project's `server` package directory and start the server, then run the `create-repair-migration` command.
 
 ```bash
-$ dart run bin/main.dart
-$ serverpod create-repair-migration
+dart run bin/main.dart
+serverpod create-repair-migration
 ```
 
 :::info
@@ -249,7 +249,7 @@ Use the `--mode` option to specify the database source to use. By default, the r
 To apply the repair migration to your database, restart the server using the `--apply-repair-migration` flag.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 ## Closing remarks
diff --git a/versioned_docs/version-1.2.0/index.md b/versioned_docs/version-1.2.0/index.md
index d7139b7a..8d75e701 100644
--- a/versioned_docs/version-1.2.0/index.md
+++ b/versioned_docs/version-1.2.0/index.md
@@ -16,13 +16,13 @@ Serverpod is tested on Mac, Windows, and Linux. Before you can install Serverpod
 Once you have Flutter and Docker installed and configured, open up a terminal and install Serverpod by running:
 
 ```bash
-$ dart pub global activate serverpod_cli
+dart pub global activate serverpod_cli
 ```
 
 Now test the installation by running:
 
 ```bash
-$ serverpod
+serverpod
 ```
 
 If everything is correctly configured, the help for the `serverpod` command is now displayed.
diff --git a/versioned_docs/version-2.0.0/01-get-started.md b/versioned_docs/version-2.0.0/01-get-started.md
index d16ff989..460ec507 100644
--- a/versioned_docs/version-2.0.0/01-get-started.md
+++ b/versioned_docs/version-2.0.0/01-get-started.md
@@ -7,7 +7,7 @@ This page should give you an understanding of how a Serverpod project is structu
 Serverpod Mini is a lightweight version of Serverpod that is perfect for small projects or when you want to try out Serverpod without setting up a full server. To get started with Serverpod Mini, read the [Getting started with Serverpod mini](https://medium.com/serverpod/getting-started-with-serverpod-mini-58c71ffefa54) guide.
 
 ```bash
-$ serverpod create mypod --mini
+serverpod create mypod --mini
 ```
 
 ## Creating a new Serverpod project
@@ -15,7 +15,7 @@ $ serverpod create mypod --mini
 Create a new project by running `serverpod create`.
 
 ```bash
-$ serverpod create mypod
+serverpod create mypod
 ```
 
 :::info
@@ -35,9 +35,9 @@ This command will create a new directory called `mypod`, with three dart package
 Make sure that [Docker Desktop](https://www.docker.com/products/docker-desktop/) is running, then start your Docker containers with `docker compose up --build --detach`. It will start Postgres and Redis. Then, run `dart bin/main.dart --apply-migrations` to start your server.
 
 ```bash
-$ cd mypod/mypod_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd mypod/mypod_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 If everything is working, you should see something like this on your terminal:
@@ -66,8 +66,8 @@ In your development environment it can be helpful to always start Serverpod with
 Start the default demo app by changing the directory into the Flutter package that was created and running `flutter run`.
 
 ```bash
-$ cd mypod/mypod_flutter
-$ flutter run -d chrome
+cd mypod/mypod_flutter
+flutter run -d chrome
 ```
 
  The flag `-d chrome` runs the app in Chrome, for other run options please see the Flutter documentation.
@@ -95,8 +95,8 @@ Both the `endpoints` and `models` directories contain sample files that give a q
 Whenever you change your code in either the `endpoints` or `models` directory, you will need to regenerate the classes managed by Serverpod. Do this by running `serverpod generate`.
 
 ```bash
-$ cd mypod/mypod_server
-$ serverpod generate
+cd mypod/mypod_server
+serverpod generate
 ```
 
 ### Working with endpoints
@@ -184,15 +184,15 @@ development:
 With database migrations, Serverpod makes it easy to evolve your database schema. When you make changes to your project that should be reflected in your database, you need to create a migration. A migration is a set of SQL queries that are run to update the database. To create a migration, run `serverpod create-migration` in the home directory of the server.
 
 ```bash
-$ cd mypod/mypod_server
-$ serverpod create-migration
+cd mypod/mypod_server
+serverpod create-migration
 ```
 
 Migrations are then applied to the database as part of the server startup by adding the `--apply-migrations` flag.
 
 ```bash
-$ cd mypod/mypod_server
-$ dart bin/main.dart --apply-migrations
+cd mypod/mypod_server
+dart bin/main.dart --apply-migrations
 ```
 
 :::tip
diff --git a/versioned_docs/version-2.0.0/03-tutorials/01-first-app.mdx b/versioned_docs/version-2.0.0/03-tutorials/01-first-app.mdx
index 4c10a085..400c8923 100644
--- a/versioned_docs/version-2.0.0/03-tutorials/01-first-app.mdx
+++ b/versioned_docs/version-2.0.0/03-tutorials/01-first-app.mdx
@@ -29,15 +29,15 @@ Demo of what we will build: ([Full code example](https://github.com/serverpod/no
 Create a new project using the Serverpod CLI. Run the following command in your terminal:
 
 ```bash
-$ serverpod create notes
+serverpod create notes
 ```
 
 To start the server:
 
 ```bash
-$ cd notes/notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes/notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 :::info
@@ -69,7 +69,7 @@ Let's take a closer look at the content of the `note.yaml` file:
 Use the code generator to generate the code for the `Note` class from the definition in `note.yaml`. Run the following command from the root of your server project (`notes_server`):
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 After the code generation process is complete, you can access the generated code for the `Note` class in `lib/src/generated/note.dart` inside your Serverpod project.
@@ -98,7 +98,7 @@ fields:
 Run the code generator again to generate the necessary code used to access the database table:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 Take a look at the updated `lib/src/generated/note.dart` file. You will notice that the code generator has added new methods for interacting with the database. 
@@ -107,7 +107,7 @@ Take a look at the updated `lib/src/generated/note.dart` file. You will notice t
 To create the new `note` table in the database we will use the Serverpod migration system. Run the following command to generate a new database migration:
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 This creates a new migration that contains a description of the database schema and SQL code to add the table. These files can be found in the `migrations` directory in your server project (`notes_server`).
@@ -117,7 +117,7 @@ This creates a new migration that contains a description of the database schema
 To apply the database migration, start the server with the `--apply-migrations` command. We can also run the server in maintenance mode which will shut down the server as soon as its tasks are done.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 Once command has executed successfully, the database table for storing the note data will have been created.
@@ -237,7 +237,7 @@ Congratulations! You have now created all the endpoints needed for the notes app
 Now run the code generator again to generate the client library for our endpoints. This needs to be run from the server directory `notes_server`.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 You can find the newly generated code in the client directory `notes_client`. You normally don't need to touch this package, but it's good to know where it is located.
@@ -752,16 +752,16 @@ Start the database and server:
 Make sure you reboot the server if you started it earlier.
 
 ```bash
-$ cd notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 Start the Flutter app in Chrome (or the platform of your choice):
 
 ```bash
-$ cd notes_flutter
-$ flutter run -d chrome
+cd notes_flutter
+flutter run -d chrome
 ```
 
 <ReactPlayer playing={true} loop controls width="960px" height="720px" url='/img/tutorial/note-app/03-note-create.mp4' />
diff --git a/versioned_docs/version-2.0.0/05-concepts/06-database/01-connection.md b/versioned_docs/version-2.0.0/05-concepts/06-database/01-connection.md
index 657d1e0e..40936cc9 100644
--- a/versioned_docs/version-2.0.0/05-concepts/06-database/01-connection.md
+++ b/versioned_docs/version-2.0.0/05-concepts/06-database/01-connection.md
@@ -48,17 +48,17 @@ A newly created Serverpod project comes with a preconfigured docker instance wit
 :::
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To remove the database run (this commands preserve all data).
 
 ```bash
-$ docker compose down
+docker compose down
 ```
 
 To remove the database and __delete__ all data add the `-v` flag.
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
diff --git a/versioned_docs/version-2.0.0/05-concepts/06-database/11-migrations.md b/versioned_docs/version-2.0.0/05-concepts/06-database/11-migrations.md
index c4e1891e..e0ededd7 100644
--- a/versioned_docs/version-2.0.0/05-concepts/06-database/11-migrations.md
+++ b/versioned_docs/version-2.0.0/05-concepts/06-database/11-migrations.md
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,7 +47,7 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
@@ -55,7 +55,7 @@ $ serverpod create-migration --force
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,7 +162,7 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
@@ -170,7 +170,7 @@ $ serverpod create-repair-migration --force
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
diff --git a/versioned_docs/version-2.0.0/05-concepts/09-modules.md b/versioned_docs/version-2.0.0/05-concepts/09-modules.md
index 0d2c1334..a6b0c63a 100644
--- a/versioned_docs/version-2.0.0/05-concepts/09-modules.md
+++ b/versioned_docs/version-2.0.0/05-concepts/09-modules.md
@@ -34,15 +34,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -80,13 +80,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.
diff --git a/versioned_docs/version-2.0.0/05-concepts/10-authentication/01-setup.md b/versioned_docs/version-2.0.0/05-concepts/10-authentication/01-setup.md
index 8101e1c3..f9bcba37 100644
--- a/versioned_docs/version-2.0.0/05-concepts/10-authentication/01-setup.md
+++ b/versioned_docs/version-2.0.0/05-concepts/10-authentication/01-setup.md
@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
 Add the module as a dependency to the server project's `pubspec.yaml`.
 
 ```sh
-$ dart pub add serverpod_auth_server
+dart pub add serverpod_auth_server
 ```
 
 Add the authentication handler to the Serverpod instance.
@@ -45,7 +45,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
@@ -53,19 +53,19 @@ $ serverpod generate
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../database/migrations).
diff --git a/versioned_docs/version-2.0.0/05-concepts/10-authentication/04-providers/02-google.md b/versioned_docs/version-2.0.0/05-concepts/10-authentication/04-providers/02-google.md
index a78f9bc6..ec168e52 100644
--- a/versioned_docs/version-2.0.0/05-concepts/10-authentication/04-providers/02-google.md
+++ b/versioned_docs/version-2.0.0/05-concepts/10-authentication/04-providers/02-google.md
@@ -117,7 +117,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -134,7 +134,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::
diff --git a/versioned_docs/version-2.0.0/05-concepts/10-authentication/04-providers/05-firebase.md b/versioned_docs/version-2.0.0/05-concepts/10-authentication/04-providers/05-firebase.md
index 0833366a..3b7bfdc5 100644
--- a/versioned_docs/version-2.0.0/05-concepts/10-authentication/04-providers/05-firebase.md
+++ b/versioned_docs/version-2.0.0/05-concepts/10-authentication/04-providers/05-firebase.md
@@ -29,8 +29,8 @@ To add authentication with Firebase, you must first install and initialize the F
 The short version:
 
 ```bash
-$ flutter pub add firebase_core firebase_auth firebase_ui_auth
-$ flutterfire configure
+flutter pub add firebase_core firebase_auth firebase_ui_auth
+flutterfire configure
 ```
 
 In the Firebase console, configure the different social sign-ins you plan to use, under `Authentication > Sign-in method`.
@@ -65,7 +65,7 @@ void main() async {
 Add the [serverpod_auth_firebase_flutter](https://pub.dev/packages/serverpod_auth_firebase_flutter) package.
 
 ```bash
-$ flutter pub add serverpod_auth_firebase_flutter
+flutter pub add serverpod_auth_firebase_flutter
 ```
 
 The `SignInWithFirebaseButton` is a convenient button that triggers the sign-in flow and can be used like this:
diff --git a/versioned_docs/version-2.0.0/06-deployments/02-deploying-to-gce-terraform.md b/versioned_docs/version-2.0.0/06-deployments/02-deploying-to-gce-terraform.md
index 3a2ac487..f55c21bd 100644
--- a/versioned_docs/version-2.0.0/06-deployments/02-deploying-to-gce-terraform.md
+++ b/versioned_docs/version-2.0.0/06-deployments/02-deploying-to-gce-terraform.md
@@ -126,7 +126,7 @@ Depending on your domain name registrar, the process for setting up your domain
 You can test that the domain points to the correct name servers by running `dig` on the command line. It will output the domain name servers.
 
 ```bash
-$ dig +short NS examplepod.com
+dig +short NS examplepod.com
 ```
 
 Should yield an output similar to this:
@@ -228,13 +228,13 @@ If you are deploying a staging server in addition to your production server, you
 Once you have configured Terraform and your Serverpod, you are ready to deploy your infrastructure. Make sure that you have `cd` into your `deploy/gcp/terraform_gce` directory. Now run:
 
 ```bash
-$ terraform init
+terraform init
 ```
 
 This will download the Serverpod module and initialize your Terraform configuration. Now, deploy your infrastructure by running:
 
 ```bash
-$ terraform apply
+terraform apply
 ```
 
 Terraform will ask you for the password to your production and staging database. You will find the passwords in your `config/passwords.yaml` file. If you are not deploying a staging server, you can leave the staging database password blank.
diff --git a/versioned_docs/version-2.0.0/06-deployments/03-deploying-to-gcr-console.md b/versioned_docs/version-2.0.0/06-deployments/03-deploying-to-gcr-console.md
index cdd5991d..b647215c 100644
--- a/versioned_docs/version-2.0.0/06-deployments/03-deploying-to-gcr-console.md
+++ b/versioned_docs/version-2.0.0/06-deployments/03-deploying-to-gcr-console.md
@@ -11,13 +11,13 @@ Before you begin, you will need to install and configure the Google Cloud CLI to
 - To [initialize](https://cloud.google.com/sdk/docs/initializing) the gcloud CLI, run the following command:
 
 ```bash
-$ gcloud init
+gcloud init
 ```
 
 - To set the default project for your Cloud Run service:
 
 ```bash
-$ gcloud config set project <PROJECT_ID>
+gcloud config set project <PROJECT_ID>
 ```
 
 ## Setup the database
@@ -75,8 +75,8 @@ database:
 Your server is now ready to be deployed. When you created your project, Serverpod also created a script for deploying your server. Copy it to the root of your server directory and make it executable. Make sure you are in your server directory (e.g., `myproject_server`). Then run the following command:
 
 ```bash
-$ cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
-$ chmod u+x cloud-run-deploy.sh
+cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
+chmod u+x cloud-run-deploy.sh
 ```
 
 Open up the script in your favorite editor. You will need to fill in your _database instance's connection name_ and the _email of your service account_.
@@ -84,7 +84,7 @@ Open up the script in your favorite editor. You will need to fill in your _datab
 Now, deploy your server by running the following:
 
 ```bash
-$ ./cloud-run-deploy.sh
+./cloud-run-deploy.sh
 ```
 
 The script runs two deployment commands, one for your API and one for the Insights API used by the Serverpod app. While running, it may ask you to enable the Cloud Run and SQL Admin services. Answer yes to all these questions.
diff --git a/versioned_docs/version-2.0.0/06-deployments/04-deploying-to-aws.md b/versioned_docs/version-2.0.0/06-deployments/04-deploying-to-aws.md
index af71318a..f41a0973 100644
--- a/versioned_docs/version-2.0.0/06-deployments/04-deploying-to-aws.md
+++ b/versioned_docs/version-2.0.0/06-deployments/04-deploying-to-aws.md
@@ -96,14 +96,14 @@ Finally, to complete your Serverpod configuration, you will need to edit the `co
 Your Serverpod should now be configured and ready to be deployed. Exciting times! Open up a terminal and `cd` into your server `aws/terraform` directory. First, you need to add an environment variable so that Terraform can correctly set the password for the Postgres database. You will find the production password for the database in your `config/passwords.yaml` file.
 
 ```bash
-$ export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
+export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
 ```
 
 Next, we are ready to initialize Terraform and deploy our server. You will only need to run the `terraform init` command the first time you deploy the configuration.
 
 ```bash
-$ terraform init
-$ terraform apply
+terraform init
+terraform apply
 ```
 
 Terraform will now run some checks and make a plan for the deployment. If everything looks good, it will ask you if you are ready to go ahead with the changes. Type `yes` and hit the return key. Applying the changes can take up to five minutes as AWS creates the different resources needed for your Serverpod.
diff --git a/versioned_docs/version-2.0.0/06-deployments/05-general.md b/versioned_docs/version-2.0.0/06-deployments/05-general.md
index bc27776c..bd4cd171 100644
--- a/versioned_docs/version-2.0.0/06-deployments/05-general.md
+++ b/versioned_docs/version-2.0.0/06-deployments/05-general.md
@@ -11,7 +11,7 @@ Serverpod will not run without a link to a Postgres database with the correct ta
 Serverpod has three main configuration files, depending on which mode the server is running; `development`, `staging`, or `production`. The files are located in the `config/` directory. By default, the server will start in development mode. To use another configuration file, use the `--mode` option when starting the server. If you are running multiple servers in a cluster, use the `--server-id` option to specify the id of each server. By default, the server will run as id `default`. For instance, to start the server in production mode with id `2`, run the following command:
 
 ```bash
-$ dart bin/main.dart --mode production --server-id 2
+dart bin/main.dart --mode production --server-id 2
 ```
 
 :::info
@@ -35,7 +35,7 @@ Serverpod can assume different roles depending on your configuration. If you run
 You can specify the role of your server when you launch it by setting the `--role` argument.
 
 ```bash
-$ dart bin/main.dart --role serverless
+dart bin/main.dart --role serverless
 ```
 
 ## Docker container
diff --git a/versioned_docs/version-2.0.0/07-tools/01-cli.md b/versioned_docs/version-2.0.0/07-tools/01-cli.md
index 590561bf..f94612d5 100644
--- a/versioned_docs/version-2.0.0/07-tools/01-cli.md
+++ b/versioned_docs/version-2.0.0/07-tools/01-cli.md
@@ -5,7 +5,7 @@ The Serverpod Command Line Interface (CLI) provides a suite of tools to facilita
 ## Usage
 
 ```bash
-$ serverpod <command> [arguments]
+serverpod <command> [arguments]
 ```
 
 ## Global Options
diff --git a/versioned_docs/version-2.0.0/07-tools/03-lsp.md b/versioned_docs/version-2.0.0/07-tools/03-lsp.md
index 3b075501..e8040157 100644
--- a/versioned_docs/version-2.0.0/07-tools/03-lsp.md
+++ b/versioned_docs/version-2.0.0/07-tools/03-lsp.md
@@ -5,7 +5,7 @@ The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server
 To start the Serverpod LSP server, use the following command:
 
 ```bash
-$ serverpod language-server
+serverpod language-server
 ```
 
 :::info
diff --git a/versioned_docs/version-2.0.0/11-contribute.md b/versioned_docs/version-2.0.0/11-contribute.md
index 7b55cf51..0b54bce8 100644
--- a/versioned_docs/version-2.0.0/11-contribute.md
+++ b/versioned_docs/version-2.0.0/11-contribute.md
@@ -23,7 +23,7 @@ We are very conscious about keeping the Serverpod code base clean. When you writ
 Continuous integration tests are automatically run when sending a pull request to the `main` branch. You can run the tests locally by changing your working directory into the root serverpod directory and running:
 
 ```bash
-$ util/run_tests
+util/run_tests
 ```
 
 :::caution
@@ -71,9 +71,9 @@ Running single individual tests is useful when you are working on a specific fea
 To run the `serverpod` command from your cloned repository, you will need to:
 
 ```bash
-$ cd tools/serverpod_cli
-$ dart pub get
-$ dart pub global activate --source path .
+cd tools/serverpod_cli
+dart pub get
+dart pub global activate --source path .
 ```
 
 Depending on your Dart version you may need to run the `dart pub global` command above every time you've made changes in the Serverpod tooling.
@@ -93,7 +93,7 @@ First off, we are restrictive about which new packages we include in the Serverp
 Secondly, you shouldn't edit the `pubspec.yaml` files directly. Instead, make changes to the files in the `templates/` directory. When you've made changes, run the `update_pubspecs` command to generate the `pubspec.yaml` files.
 
 ```bash
-$ util/update_pubspecs
+util/update_pubspecs
 ```
 
 ## Submitting your pull request
diff --git a/versioned_docs/version-2.0.0/12-upgrading/01-upgrade-to-two.md b/versioned_docs/version-2.0.0/12-upgrading/01-upgrade-to-two.md
index 54e3b54d..5ef0d80a 100644
--- a/versioned_docs/version-2.0.0/12-upgrading/01-upgrade-to-two.md
+++ b/versioned_docs/version-2.0.0/12-upgrading/01-upgrade-to-two.md
@@ -284,7 +284,7 @@ To ensure new databases are created with the new representation, the latest migr
 A new empty migration can be created by running the following command in the terminal:
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 #### Migration of existing tables
diff --git a/versioned_docs/version-2.0.0/index.md b/versioned_docs/version-2.0.0/index.md
index 684c5796..a1e807f5 100644
--- a/versioned_docs/version-2.0.0/index.md
+++ b/versioned_docs/version-2.0.0/index.md
@@ -18,13 +18,13 @@ Serverpod is tested on Mac, Windows, and Linux. Before you can install Serverpod
 Once you have Flutter and Docker installed and configured, open up a terminal and install Serverpod by running:
 
 ```bash
-$ dart pub global activate serverpod_cli
+dart pub global activate serverpod_cli
 ```
 
 Now test the installation by running:
 
 ```bash
-$ serverpod
+serverpod
 ```
 
 If everything is correctly configured, the help for the `serverpod` command is now displayed.
diff --git a/versioned_docs/version-2.1.0/01-get-started.md b/versioned_docs/version-2.1.0/01-get-started.md
index e4d74993..f1f5fbc2 100644
--- a/versioned_docs/version-2.1.0/01-get-started.md
+++ b/versioned_docs/version-2.1.0/01-get-started.md
@@ -40,7 +40,7 @@ The full version of Serverpod needs access to a Postgres database. The easiest w
 Create a new project by running `serverpod create`.
 
 ```bash
-$ serverpod create mypod
+serverpod create mypod
 ```
 
 :::info
@@ -60,9 +60,9 @@ This command will create a new directory called `mypod`, with three dart package
 Make sure that __[Docker Desktop](https://www.docker.com/products/docker-desktop/)__ is running, then start your Docker containers with `docker compose up --build --detach`. It will start Postgres and Redis. Then, run `dart bin/main.dart --apply-migrations` to start your server.
 
 ```bash
-$ cd mypod/mypod_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd mypod/mypod_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 If everything is working, you should see something like this on your terminal:
@@ -91,8 +91,8 @@ In your development environment it can be helpful to always start Serverpod with
 Start the default demo app by changing the directory into the Flutter package that was created and running `flutter run`.
 
 ```bash
-$ cd mypod/mypod_flutter
-$ flutter run -d chrome
+cd mypod/mypod_flutter
+flutter run -d chrome
 ```
 
 The flag `-d chrome` runs the app in Chrome, for other run options please see the Flutter documentation.
@@ -131,8 +131,8 @@ Both the `endpoints` and `models` directories contain sample files that give a q
 Whenever you change your code in either the `endpoints` or `models` directory, you will need to regenerate the classes managed by Serverpod. Do this by running `serverpod generate`.
 
 ```bash
-$ cd mypod/mypod_server
-$ serverpod generate
+cd mypod/mypod_server
+serverpod generate
 ```
 
 ### Working with endpoints
@@ -220,15 +220,15 @@ development:
 With database migrations, Serverpod makes it easy to evolve your database schema. When you make changes to your project that should be reflected in your database, you need to create a migration. A migration is a set of SQL queries that are run to update the database. To create a migration, run `serverpod create-migration` in the home directory of the server.
 
 ```bash
-$ cd mypod/mypod_server
-$ serverpod create-migration
+cd mypod/mypod_server
+serverpod create-migration
 ```
 
 Migrations are then applied to the database as part of the server startup by adding the `--apply-migrations` flag.
 
 ```bash
-$ cd mypod/mypod_server
-$ dart bin/main.dart --apply-migrations
+cd mypod/mypod_server
+dart bin/main.dart --apply-migrations
 ```
 
 :::tip
diff --git a/versioned_docs/version-2.1.0/02-get-started-with-mini.md b/versioned_docs/version-2.1.0/02-get-started-with-mini.md
index 66c56cf4..46caca46 100644
--- a/versioned_docs/version-2.1.0/02-get-started-with-mini.md
+++ b/versioned_docs/version-2.1.0/02-get-started-with-mini.md
@@ -8,7 +8,7 @@ Serverpod Mini is a slimmer version of Serverpod that does not need to be connec
 Create a mini project by running:
 
 ```bash
-$ serverpod create myminipod --mini
+serverpod create myminipod --mini
 ```
 
 Serverpod will create a new project for you. It contains three Dart packages, but you only need to pay attention to the `myminipod_server` and `myminipod_flutter` directories. The server directory contains your server files, and the flutter directory contains your app. The third package (`myminipod_client`) contains generated code that is used by the Flutter app to communicate with the server.
@@ -16,15 +16,15 @@ Serverpod will create a new project for you. It contains three Dart packages, bu
 Start your server by changing directory into your server directory, and run the `bin/main.dart` file:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ dart bin/main.dart
+cd myminipod/myminipod_server
+dart bin/main.dart
 ```
 
 Your default project comes with a sample Flutter app, all hooked up to talk with your server. Run it with the `flutter` command:
 
 ```bash
-$ cd myminipod/myminipod_flutter
-$ flutter run -d chrome
+cd myminipod/myminipod_flutter
+flutter run -d chrome
 ```
 
 Easy as that. 🥳
@@ -51,8 +51,8 @@ For types, you can use most basic Dart types, such as `String`, `double`, `int`,
 Whenever you add or edit a model file, run `serverpod generate` in your server directory. Then, Serverpod will generate all the updated Dart classes:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Adding methods to your server
@@ -87,8 +87,8 @@ class CompanyEndpoint extends Endpoint {
 After adding or modifying endpoints and endpoint methods, you must run `serverpod generate` to keep your Flutter app up-to-date.
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Calling the server methods from the app
diff --git a/versioned_docs/version-2.1.0/05-tutorials/01-first-app.mdx b/versioned_docs/version-2.1.0/05-tutorials/01-first-app.mdx
index 178ddca4..c6127fd1 100644
--- a/versioned_docs/version-2.1.0/05-tutorials/01-first-app.mdx
+++ b/versioned_docs/version-2.1.0/05-tutorials/01-first-app.mdx
@@ -31,15 +31,15 @@ Demo of what we will build: ([Full code example](https://github.com/serverpod/no
 Create a new project using the Serverpod CLI. Run the following command in your terminal:
 
 ```bash
-$ serverpod create notes
+serverpod create notes
 ```
 
 To start the server:
 
 ```bash
-$ cd notes/notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes/notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 :::info
@@ -71,7 +71,7 @@ Let's take a closer look at the content of the `note.yaml` file:
 Use the code generator to generate the code for the `Note` class from the definition in `note.yaml`. Run the following command from the root of your server project (`notes_server`):
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 After the code generation process is complete, you can access the generated code for the `Note` class in `lib/src/generated/note.dart` inside your Serverpod project.
@@ -100,7 +100,7 @@ fields:
 Run the code generator again to generate the necessary code used to access the database table:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 Take a look at the updated `lib/src/generated/note.dart` file. You will notice that the code generator has added new methods for interacting with the database. 
@@ -109,7 +109,7 @@ Take a look at the updated `lib/src/generated/note.dart` file. You will notice t
 To create the new `note` table in the database we will use the Serverpod migration system. Run the following command to generate a new database migration:
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 This creates a new migration that contains a description of the database schema and SQL code to add the table. These files can be found in the `migrations` directory in your server project (`notes_server`).
@@ -119,7 +119,7 @@ This creates a new migration that contains a description of the database schema
 To apply the database migration, start the server with the `--apply-migrations` command. We can also run the server in maintenance mode which will shut down the server as soon as its tasks are done.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 Once command has executed successfully, the database table for storing the note data will have been created.
@@ -239,7 +239,7 @@ Congratulations! You have now created all the endpoints needed for the notes app
 Now run the code generator again to generate the client library for our endpoints. This needs to be run from the server directory `notes_server`.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 You can find the newly generated code in the client directory `notes_client`. You normally don't need to touch this package, but it's good to know where it is located.
@@ -754,16 +754,16 @@ Start the database and server:
 Make sure you reboot the server if you started it earlier.
 
 ```bash
-$ cd notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 Start the Flutter app in Chrome (or the platform of your choice):
 
 ```bash
-$ cd notes_flutter
-$ flutter run -d chrome
+cd notes_flutter
+flutter run -d chrome
 ```
 
 <ReactPlayer playing={true} loop controls width="960px" height="720px" url='/img/tutorial/note-app/03-note-create.mp4' />
diff --git a/versioned_docs/version-2.1.0/06-concepts/06-database/01-connection.md b/versioned_docs/version-2.1.0/06-concepts/06-database/01-connection.md
index 089d29e7..a2916864 100644
--- a/versioned_docs/version-2.1.0/06-concepts/06-database/01-connection.md
+++ b/versioned_docs/version-2.1.0/06-concepts/06-database/01-connection.md
@@ -48,19 +48,19 @@ development:
 A newly created Serverpod project has a preconfigured Docker instance with a Postgres database set up. Run the following command from the root of the `server` package to start the database:
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To stop the database run:
 
 ```bash
-$ docker compose stop
+docker compose stop
 ```
 
 To remove the database and __delete__ all associated data, run:
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
 
 ## Connecting to a custom Postgres instance
diff --git a/versioned_docs/version-2.1.0/06-concepts/06-database/11-migrations.md b/versioned_docs/version-2.1.0/06-concepts/06-database/11-migrations.md
index c4e1891e..e0ededd7 100644
--- a/versioned_docs/version-2.1.0/06-concepts/06-database/11-migrations.md
+++ b/versioned_docs/version-2.1.0/06-concepts/06-database/11-migrations.md
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,7 +47,7 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
@@ -55,7 +55,7 @@ $ serverpod create-migration --force
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,7 +162,7 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
@@ -170,7 +170,7 @@ $ serverpod create-repair-migration --force
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
diff --git a/versioned_docs/version-2.1.0/06-concepts/10-modules.md b/versioned_docs/version-2.1.0/06-concepts/10-modules.md
index 0d2c1334..a6b0c63a 100644
--- a/versioned_docs/version-2.1.0/06-concepts/10-modules.md
+++ b/versioned_docs/version-2.1.0/06-concepts/10-modules.md
@@ -34,15 +34,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -80,13 +80,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.
diff --git a/versioned_docs/version-2.1.0/06-concepts/11-authentication/01-setup.md b/versioned_docs/version-2.1.0/06-concepts/11-authentication/01-setup.md
index 89b49af3..2be7440b 100644
--- a/versioned_docs/version-2.1.0/06-concepts/11-authentication/01-setup.md
+++ b/versioned_docs/version-2.1.0/06-concepts/11-authentication/01-setup.md
@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
 Add the module as a dependency to the server project's `pubspec.yaml`.
 
 ```sh
-$ dart pub add serverpod_auth_server
+dart pub add serverpod_auth_server
 ```
 
 Add the authentication handler to the Serverpod instance.
@@ -45,7 +45,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
@@ -53,19 +53,19 @@ $ serverpod generate
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../database/migrations).
diff --git a/versioned_docs/version-2.1.0/06-concepts/11-authentication/04-providers/02-google.md b/versioned_docs/version-2.1.0/06-concepts/11-authentication/04-providers/02-google.md
index caa8b601..5ea95571 100644
--- a/versioned_docs/version-2.1.0/06-concepts/11-authentication/04-providers/02-google.md
+++ b/versioned_docs/version-2.1.0/06-concepts/11-authentication/04-providers/02-google.md
@@ -117,7 +117,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -134,7 +134,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::
diff --git a/versioned_docs/version-2.1.0/06-concepts/11-authentication/04-providers/05-firebase.md b/versioned_docs/version-2.1.0/06-concepts/11-authentication/04-providers/05-firebase.md
index 1816b20b..9dcb3766 100644
--- a/versioned_docs/version-2.1.0/06-concepts/11-authentication/04-providers/05-firebase.md
+++ b/versioned_docs/version-2.1.0/06-concepts/11-authentication/04-providers/05-firebase.md
@@ -29,8 +29,8 @@ To add authentication with Firebase, you must first install and initialize the F
 The short version:
 
 ```bash
-$ flutter pub add firebase_core firebase_auth firebase_ui_auth
-$ flutterfire configure
+flutter pub add firebase_core firebase_auth firebase_ui_auth
+flutterfire configure
 ```
 
 In the Firebase console, configure the different social sign-ins you plan to use, under `Authentication > Sign-in method`.
@@ -65,7 +65,7 @@ void main() async {
 Add the [serverpod_auth_firebase_flutter](https://pub.dev/packages/serverpod_auth_firebase_flutter) package.
 
 ```bash
-$ flutter pub add serverpod_auth_firebase_flutter
+flutter pub add serverpod_auth_firebase_flutter
 ```
 
 The `SignInWithFirebaseButton` is a convenient button that triggers the sign-in flow and can be used like this:
diff --git a/versioned_docs/version-2.1.0/07-deployments/02-deploying-to-gce-terraform.md b/versioned_docs/version-2.1.0/07-deployments/02-deploying-to-gce-terraform.md
index 3a2ac487..f55c21bd 100644
--- a/versioned_docs/version-2.1.0/07-deployments/02-deploying-to-gce-terraform.md
+++ b/versioned_docs/version-2.1.0/07-deployments/02-deploying-to-gce-terraform.md
@@ -126,7 +126,7 @@ Depending on your domain name registrar, the process for setting up your domain
 You can test that the domain points to the correct name servers by running `dig` on the command line. It will output the domain name servers.
 
 ```bash
-$ dig +short NS examplepod.com
+dig +short NS examplepod.com
 ```
 
 Should yield an output similar to this:
@@ -228,13 +228,13 @@ If you are deploying a staging server in addition to your production server, you
 Once you have configured Terraform and your Serverpod, you are ready to deploy your infrastructure. Make sure that you have `cd` into your `deploy/gcp/terraform_gce` directory. Now run:
 
 ```bash
-$ terraform init
+terraform init
 ```
 
 This will download the Serverpod module and initialize your Terraform configuration. Now, deploy your infrastructure by running:
 
 ```bash
-$ terraform apply
+terraform apply
 ```
 
 Terraform will ask you for the password to your production and staging database. You will find the passwords in your `config/passwords.yaml` file. If you are not deploying a staging server, you can leave the staging database password blank.
diff --git a/versioned_docs/version-2.1.0/07-deployments/03-deploying-to-gcr-console.md b/versioned_docs/version-2.1.0/07-deployments/03-deploying-to-gcr-console.md
index cdd5991d..b647215c 100644
--- a/versioned_docs/version-2.1.0/07-deployments/03-deploying-to-gcr-console.md
+++ b/versioned_docs/version-2.1.0/07-deployments/03-deploying-to-gcr-console.md
@@ -11,13 +11,13 @@ Before you begin, you will need to install and configure the Google Cloud CLI to
 - To [initialize](https://cloud.google.com/sdk/docs/initializing) the gcloud CLI, run the following command:
 
 ```bash
-$ gcloud init
+gcloud init
 ```
 
 - To set the default project for your Cloud Run service:
 
 ```bash
-$ gcloud config set project <PROJECT_ID>
+gcloud config set project <PROJECT_ID>
 ```
 
 ## Setup the database
@@ -75,8 +75,8 @@ database:
 Your server is now ready to be deployed. When you created your project, Serverpod also created a script for deploying your server. Copy it to the root of your server directory and make it executable. Make sure you are in your server directory (e.g., `myproject_server`). Then run the following command:
 
 ```bash
-$ cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
-$ chmod u+x cloud-run-deploy.sh
+cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
+chmod u+x cloud-run-deploy.sh
 ```
 
 Open up the script in your favorite editor. You will need to fill in your _database instance's connection name_ and the _email of your service account_.
@@ -84,7 +84,7 @@ Open up the script in your favorite editor. You will need to fill in your _datab
 Now, deploy your server by running the following:
 
 ```bash
-$ ./cloud-run-deploy.sh
+./cloud-run-deploy.sh
 ```
 
 The script runs two deployment commands, one for your API and one for the Insights API used by the Serverpod app. While running, it may ask you to enable the Cloud Run and SQL Admin services. Answer yes to all these questions.
diff --git a/versioned_docs/version-2.1.0/07-deployments/04-deploying-to-aws.md b/versioned_docs/version-2.1.0/07-deployments/04-deploying-to-aws.md
index f65ca62b..b5169f93 100644
--- a/versioned_docs/version-2.1.0/07-deployments/04-deploying-to-aws.md
+++ b/versioned_docs/version-2.1.0/07-deployments/04-deploying-to-aws.md
@@ -202,14 +202,14 @@ database:
 Your Serverpod should now be configured and ready to be deployed. Exciting times! Open up a terminal and `cd` into your server `aws/terraform` directory. First, you need to add an environment variable so that Terraform can correctly set the password for the Postgres database. You will find the production password for the database in your `config/passwords.yaml` file.
 
 ```bash
-$ export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
+export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
 ```
 
 Next, we are ready to initialize Terraform and deploy our server. You will only need to run the `terraform init` command the first time you deploy the configuration.
 
 ```bash
-$ terraform init
-$ terraform apply
+terraform init
+terraform apply
 ```
 
 Terraform will now run some checks and make a plan for the deployment. If everything looks good, it will ask you if you are ready to go ahead with the changes. Type `yes` and hit the return key. Applying the changes can take up to five minutes as AWS creates the different resources needed for your Serverpod.
diff --git a/versioned_docs/version-2.1.0/07-deployments/05-general.md b/versioned_docs/version-2.1.0/07-deployments/05-general.md
index bc27776c..bd4cd171 100644
--- a/versioned_docs/version-2.1.0/07-deployments/05-general.md
+++ b/versioned_docs/version-2.1.0/07-deployments/05-general.md
@@ -11,7 +11,7 @@ Serverpod will not run without a link to a Postgres database with the correct ta
 Serverpod has three main configuration files, depending on which mode the server is running; `development`, `staging`, or `production`. The files are located in the `config/` directory. By default, the server will start in development mode. To use another configuration file, use the `--mode` option when starting the server. If you are running multiple servers in a cluster, use the `--server-id` option to specify the id of each server. By default, the server will run as id `default`. For instance, to start the server in production mode with id `2`, run the following command:
 
 ```bash
-$ dart bin/main.dart --mode production --server-id 2
+dart bin/main.dart --mode production --server-id 2
 ```
 
 :::info
@@ -35,7 +35,7 @@ Serverpod can assume different roles depending on your configuration. If you run
 You can specify the role of your server when you launch it by setting the `--role` argument.
 
 ```bash
-$ dart bin/main.dart --role serverless
+dart bin/main.dart --role serverless
 ```
 
 ## Docker container
diff --git a/versioned_docs/version-2.1.0/08-upgrading/03-upgrade-to-two.md b/versioned_docs/version-2.1.0/08-upgrading/03-upgrade-to-two.md
index 54e3b54d..5ef0d80a 100644
--- a/versioned_docs/version-2.1.0/08-upgrading/03-upgrade-to-two.md
+++ b/versioned_docs/version-2.1.0/08-upgrading/03-upgrade-to-two.md
@@ -284,7 +284,7 @@ To ensure new databases are created with the new representation, the latest migr
 A new empty migration can be created by running the following command in the terminal:
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 #### Migration of existing tables
diff --git a/versioned_docs/version-2.1.0/09-tools/02-lsp.md b/versioned_docs/version-2.1.0/09-tools/02-lsp.md
index 2374cf57..8da02d1b 100644
--- a/versioned_docs/version-2.1.0/09-tools/02-lsp.md
+++ b/versioned_docs/version-2.1.0/09-tools/02-lsp.md
@@ -5,7 +5,7 @@ The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server
 To start the Serverpod LSP server, use the following command:
 
 ```bash
-$ serverpod language-server
+serverpod language-server
 ```
 
 :::info
diff --git a/versioned_docs/version-2.1.0/10-contribute.md b/versioned_docs/version-2.1.0/10-contribute.md
index 262f3d10..ed67d758 100644
--- a/versioned_docs/version-2.1.0/10-contribute.md
+++ b/versioned_docs/version-2.1.0/10-contribute.md
@@ -26,7 +26,7 @@ We are very conscious about keeping the Serverpod code base clean. When you writ
 Continuous integration tests are automatically run when sending a pull request to the `main` branch. You can run the tests locally by changing your working directory into the root serverpod directory and running:
 
 ```bash
-$ util/run_tests
+util/run_tests
 ```
 
 :::caution
@@ -74,9 +74,9 @@ Running single individual tests is useful when you are working on a specific fea
 To run the `serverpod` command from your cloned repository, you will need to:
 
 ```bash
-$ cd tools/serverpod_cli
-$ dart pub get
-$ dart pub global activate --source path .
+cd tools/serverpod_cli
+dart pub get
+dart pub global activate --source path .
 ```
 
 Depending on your Dart version you may need to run the `dart pub global` command above every time you've made changes in the Serverpod tooling.
@@ -96,7 +96,7 @@ First off, we are restrictive about which new packages we include in the Serverp
 Secondly, you shouldn't edit the `pubspec.yaml` files directly. Instead, make changes to the files in the `templates/` directory. When you've made changes, run the `update_pubspecs` command to generate the `pubspec.yaml` files.
 
 ```bash
-$ util/update_pubspecs
+util/update_pubspecs
 ```
 
 ## Submitting your pull request
diff --git a/versioned_docs/version-2.1.0/index.md b/versioned_docs/version-2.1.0/index.md
index e825cbee..16d80e7d 100644
--- a/versioned_docs/version-2.1.0/index.md
+++ b/versioned_docs/version-2.1.0/index.md
@@ -16,13 +16,13 @@ Serverpod is tested on Mac, Windows, and Linux. Before you can install Serverpod
 Install Serverpod by running:
 
 ```bash
-$ dart pub global activate serverpod_cli
+dart pub global activate serverpod_cli
 ```
 
 Now test the installation by running:
 
 ```bash
-$ serverpod
+serverpod
 ```
 
 If everything is correctly configured, the help for the `serverpod` command is now displayed.
diff --git a/versioned_docs/version-2.2.0/01-get-started.md b/versioned_docs/version-2.2.0/01-get-started.md
index e4d74993..f1f5fbc2 100644
--- a/versioned_docs/version-2.2.0/01-get-started.md
+++ b/versioned_docs/version-2.2.0/01-get-started.md
@@ -40,7 +40,7 @@ The full version of Serverpod needs access to a Postgres database. The easiest w
 Create a new project by running `serverpod create`.
 
 ```bash
-$ serverpod create mypod
+serverpod create mypod
 ```
 
 :::info
@@ -60,9 +60,9 @@ This command will create a new directory called `mypod`, with three dart package
 Make sure that __[Docker Desktop](https://www.docker.com/products/docker-desktop/)__ is running, then start your Docker containers with `docker compose up --build --detach`. It will start Postgres and Redis. Then, run `dart bin/main.dart --apply-migrations` to start your server.
 
 ```bash
-$ cd mypod/mypod_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd mypod/mypod_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 If everything is working, you should see something like this on your terminal:
@@ -91,8 +91,8 @@ In your development environment it can be helpful to always start Serverpod with
 Start the default demo app by changing the directory into the Flutter package that was created and running `flutter run`.
 
 ```bash
-$ cd mypod/mypod_flutter
-$ flutter run -d chrome
+cd mypod/mypod_flutter
+flutter run -d chrome
 ```
 
 The flag `-d chrome` runs the app in Chrome, for other run options please see the Flutter documentation.
@@ -131,8 +131,8 @@ Both the `endpoints` and `models` directories contain sample files that give a q
 Whenever you change your code in either the `endpoints` or `models` directory, you will need to regenerate the classes managed by Serverpod. Do this by running `serverpod generate`.
 
 ```bash
-$ cd mypod/mypod_server
-$ serverpod generate
+cd mypod/mypod_server
+serverpod generate
 ```
 
 ### Working with endpoints
@@ -220,15 +220,15 @@ development:
 With database migrations, Serverpod makes it easy to evolve your database schema. When you make changes to your project that should be reflected in your database, you need to create a migration. A migration is a set of SQL queries that are run to update the database. To create a migration, run `serverpod create-migration` in the home directory of the server.
 
 ```bash
-$ cd mypod/mypod_server
-$ serverpod create-migration
+cd mypod/mypod_server
+serverpod create-migration
 ```
 
 Migrations are then applied to the database as part of the server startup by adding the `--apply-migrations` flag.
 
 ```bash
-$ cd mypod/mypod_server
-$ dart bin/main.dart --apply-migrations
+cd mypod/mypod_server
+dart bin/main.dart --apply-migrations
 ```
 
 :::tip
diff --git a/versioned_docs/version-2.2.0/02-get-started-with-mini.md b/versioned_docs/version-2.2.0/02-get-started-with-mini.md
index 66c56cf4..46caca46 100644
--- a/versioned_docs/version-2.2.0/02-get-started-with-mini.md
+++ b/versioned_docs/version-2.2.0/02-get-started-with-mini.md
@@ -8,7 +8,7 @@ Serverpod Mini is a slimmer version of Serverpod that does not need to be connec
 Create a mini project by running:
 
 ```bash
-$ serverpod create myminipod --mini
+serverpod create myminipod --mini
 ```
 
 Serverpod will create a new project for you. It contains three Dart packages, but you only need to pay attention to the `myminipod_server` and `myminipod_flutter` directories. The server directory contains your server files, and the flutter directory contains your app. The third package (`myminipod_client`) contains generated code that is used by the Flutter app to communicate with the server.
@@ -16,15 +16,15 @@ Serverpod will create a new project for you. It contains three Dart packages, bu
 Start your server by changing directory into your server directory, and run the `bin/main.dart` file:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ dart bin/main.dart
+cd myminipod/myminipod_server
+dart bin/main.dart
 ```
 
 Your default project comes with a sample Flutter app, all hooked up to talk with your server. Run it with the `flutter` command:
 
 ```bash
-$ cd myminipod/myminipod_flutter
-$ flutter run -d chrome
+cd myminipod/myminipod_flutter
+flutter run -d chrome
 ```
 
 Easy as that. 🥳
@@ -51,8 +51,8 @@ For types, you can use most basic Dart types, such as `String`, `double`, `int`,
 Whenever you add or edit a model file, run `serverpod generate` in your server directory. Then, Serverpod will generate all the updated Dart classes:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Adding methods to your server
@@ -87,8 +87,8 @@ class CompanyEndpoint extends Endpoint {
 After adding or modifying endpoints and endpoint methods, you must run `serverpod generate` to keep your Flutter app up-to-date.
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Calling the server methods from the app
diff --git a/versioned_docs/version-2.2.0/05-tutorials/01-first-app.mdx b/versioned_docs/version-2.2.0/05-tutorials/01-first-app.mdx
index 178ddca4..c6127fd1 100644
--- a/versioned_docs/version-2.2.0/05-tutorials/01-first-app.mdx
+++ b/versioned_docs/version-2.2.0/05-tutorials/01-first-app.mdx
@@ -31,15 +31,15 @@ Demo of what we will build: ([Full code example](https://github.com/serverpod/no
 Create a new project using the Serverpod CLI. Run the following command in your terminal:
 
 ```bash
-$ serverpod create notes
+serverpod create notes
 ```
 
 To start the server:
 
 ```bash
-$ cd notes/notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes/notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 :::info
@@ -71,7 +71,7 @@ Let's take a closer look at the content of the `note.yaml` file:
 Use the code generator to generate the code for the `Note` class from the definition in `note.yaml`. Run the following command from the root of your server project (`notes_server`):
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 After the code generation process is complete, you can access the generated code for the `Note` class in `lib/src/generated/note.dart` inside your Serverpod project.
@@ -100,7 +100,7 @@ fields:
 Run the code generator again to generate the necessary code used to access the database table:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 Take a look at the updated `lib/src/generated/note.dart` file. You will notice that the code generator has added new methods for interacting with the database. 
@@ -109,7 +109,7 @@ Take a look at the updated `lib/src/generated/note.dart` file. You will notice t
 To create the new `note` table in the database we will use the Serverpod migration system. Run the following command to generate a new database migration:
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 This creates a new migration that contains a description of the database schema and SQL code to add the table. These files can be found in the `migrations` directory in your server project (`notes_server`).
@@ -119,7 +119,7 @@ This creates a new migration that contains a description of the database schema
 To apply the database migration, start the server with the `--apply-migrations` command. We can also run the server in maintenance mode which will shut down the server as soon as its tasks are done.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 Once command has executed successfully, the database table for storing the note data will have been created.
@@ -239,7 +239,7 @@ Congratulations! You have now created all the endpoints needed for the notes app
 Now run the code generator again to generate the client library for our endpoints. This needs to be run from the server directory `notes_server`.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 You can find the newly generated code in the client directory `notes_client`. You normally don't need to touch this package, but it's good to know where it is located.
@@ -754,16 +754,16 @@ Start the database and server:
 Make sure you reboot the server if you started it earlier.
 
 ```bash
-$ cd notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 Start the Flutter app in Chrome (or the platform of your choice):
 
 ```bash
-$ cd notes_flutter
-$ flutter run -d chrome
+cd notes_flutter
+flutter run -d chrome
 ```
 
 <ReactPlayer playing={true} loop controls width="960px" height="720px" url='/img/tutorial/note-app/03-note-create.mp4' />
diff --git a/versioned_docs/version-2.2.0/06-concepts/06-database/01-connection.md b/versioned_docs/version-2.2.0/06-concepts/06-database/01-connection.md
index 089d29e7..a2916864 100644
--- a/versioned_docs/version-2.2.0/06-concepts/06-database/01-connection.md
+++ b/versioned_docs/version-2.2.0/06-concepts/06-database/01-connection.md
@@ -48,19 +48,19 @@ development:
 A newly created Serverpod project has a preconfigured Docker instance with a Postgres database set up. Run the following command from the root of the `server` package to start the database:
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To stop the database run:
 
 ```bash
-$ docker compose stop
+docker compose stop
 ```
 
 To remove the database and __delete__ all associated data, run:
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
 
 ## Connecting to a custom Postgres instance
diff --git a/versioned_docs/version-2.2.0/06-concepts/06-database/11-migrations.md b/versioned_docs/version-2.2.0/06-concepts/06-database/11-migrations.md
index c4e1891e..e0ededd7 100644
--- a/versioned_docs/version-2.2.0/06-concepts/06-database/11-migrations.md
+++ b/versioned_docs/version-2.2.0/06-concepts/06-database/11-migrations.md
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,7 +47,7 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
@@ -55,7 +55,7 @@ $ serverpod create-migration --force
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,7 +162,7 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
@@ -170,7 +170,7 @@ $ serverpod create-repair-migration --force
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
diff --git a/versioned_docs/version-2.2.0/06-concepts/10-modules.md b/versioned_docs/version-2.2.0/06-concepts/10-modules.md
index 0d2c1334..a6b0c63a 100644
--- a/versioned_docs/version-2.2.0/06-concepts/10-modules.md
+++ b/versioned_docs/version-2.2.0/06-concepts/10-modules.md
@@ -34,15 +34,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -80,13 +80,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.
diff --git a/versioned_docs/version-2.2.0/06-concepts/11-authentication/01-setup.md b/versioned_docs/version-2.2.0/06-concepts/11-authentication/01-setup.md
index 66c10d7d..2f54d7e2 100644
--- a/versioned_docs/version-2.2.0/06-concepts/11-authentication/01-setup.md
+++ b/versioned_docs/version-2.2.0/06-concepts/11-authentication/01-setup.md
@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
 Add the module as a dependency to the server project's `pubspec.yaml`.
 
 ```sh
-$ dart pub add serverpod_auth_server
+dart pub add serverpod_auth_server
 ```
 
 Add the authentication handler to the Serverpod instance.
@@ -45,7 +45,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
@@ -53,19 +53,19 @@ $ serverpod generate
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../database/migrations).
diff --git a/versioned_docs/version-2.2.0/06-concepts/11-authentication/04-providers/02-google.md b/versioned_docs/version-2.2.0/06-concepts/11-authentication/04-providers/02-google.md
index caa8b601..5ea95571 100644
--- a/versioned_docs/version-2.2.0/06-concepts/11-authentication/04-providers/02-google.md
+++ b/versioned_docs/version-2.2.0/06-concepts/11-authentication/04-providers/02-google.md
@@ -117,7 +117,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -134,7 +134,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::
diff --git a/versioned_docs/version-2.2.0/06-concepts/11-authentication/04-providers/05-firebase.md b/versioned_docs/version-2.2.0/06-concepts/11-authentication/04-providers/05-firebase.md
index 1816b20b..9dcb3766 100644
--- a/versioned_docs/version-2.2.0/06-concepts/11-authentication/04-providers/05-firebase.md
+++ b/versioned_docs/version-2.2.0/06-concepts/11-authentication/04-providers/05-firebase.md
@@ -29,8 +29,8 @@ To add authentication with Firebase, you must first install and initialize the F
 The short version:
 
 ```bash
-$ flutter pub add firebase_core firebase_auth firebase_ui_auth
-$ flutterfire configure
+flutter pub add firebase_core firebase_auth firebase_ui_auth
+flutterfire configure
 ```
 
 In the Firebase console, configure the different social sign-ins you plan to use, under `Authentication > Sign-in method`.
@@ -65,7 +65,7 @@ void main() async {
 Add the [serverpod_auth_firebase_flutter](https://pub.dev/packages/serverpod_auth_firebase_flutter) package.
 
 ```bash
-$ flutter pub add serverpod_auth_firebase_flutter
+flutter pub add serverpod_auth_firebase_flutter
 ```
 
 The `SignInWithFirebaseButton` is a convenient button that triggers the sign-in flow and can be used like this:
diff --git a/versioned_docs/version-2.2.0/06-concepts/20-experimental.md b/versioned_docs/version-2.2.0/06-concepts/20-experimental.md
index f17e7f81..9a28dca4 100644
--- a/versioned_docs/version-2.2.0/06-concepts/20-experimental.md
+++ b/versioned_docs/version-2.2.0/06-concepts/20-experimental.md
@@ -9,7 +9,7 @@ Experimental features should not be used in production environments, as their st
 By default, experimental features are disabled. To opt into using them, include the `--experimental-features` flag when running the serverpod command:
 
 ```bash
-$ serverpod generate --experimental-features=all
+serverpod generate --experimental-features=all
 ```
 
 The current options you can pass are:
diff --git a/versioned_docs/version-2.2.0/07-deployments/02-deploying-to-gce-terraform.md b/versioned_docs/version-2.2.0/07-deployments/02-deploying-to-gce-terraform.md
index 3a2ac487..f55c21bd 100644
--- a/versioned_docs/version-2.2.0/07-deployments/02-deploying-to-gce-terraform.md
+++ b/versioned_docs/version-2.2.0/07-deployments/02-deploying-to-gce-terraform.md
@@ -126,7 +126,7 @@ Depending on your domain name registrar, the process for setting up your domain
 You can test that the domain points to the correct name servers by running `dig` on the command line. It will output the domain name servers.
 
 ```bash
-$ dig +short NS examplepod.com
+dig +short NS examplepod.com
 ```
 
 Should yield an output similar to this:
@@ -228,13 +228,13 @@ If you are deploying a staging server in addition to your production server, you
 Once you have configured Terraform and your Serverpod, you are ready to deploy your infrastructure. Make sure that you have `cd` into your `deploy/gcp/terraform_gce` directory. Now run:
 
 ```bash
-$ terraform init
+terraform init
 ```
 
 This will download the Serverpod module and initialize your Terraform configuration. Now, deploy your infrastructure by running:
 
 ```bash
-$ terraform apply
+terraform apply
 ```
 
 Terraform will ask you for the password to your production and staging database. You will find the passwords in your `config/passwords.yaml` file. If you are not deploying a staging server, you can leave the staging database password blank.
diff --git a/versioned_docs/version-2.2.0/07-deployments/03-deploying-to-gcr-console.md b/versioned_docs/version-2.2.0/07-deployments/03-deploying-to-gcr-console.md
index cdd5991d..b647215c 100644
--- a/versioned_docs/version-2.2.0/07-deployments/03-deploying-to-gcr-console.md
+++ b/versioned_docs/version-2.2.0/07-deployments/03-deploying-to-gcr-console.md
@@ -11,13 +11,13 @@ Before you begin, you will need to install and configure the Google Cloud CLI to
 - To [initialize](https://cloud.google.com/sdk/docs/initializing) the gcloud CLI, run the following command:
 
 ```bash
-$ gcloud init
+gcloud init
 ```
 
 - To set the default project for your Cloud Run service:
 
 ```bash
-$ gcloud config set project <PROJECT_ID>
+gcloud config set project <PROJECT_ID>
 ```
 
 ## Setup the database
@@ -75,8 +75,8 @@ database:
 Your server is now ready to be deployed. When you created your project, Serverpod also created a script for deploying your server. Copy it to the root of your server directory and make it executable. Make sure you are in your server directory (e.g., `myproject_server`). Then run the following command:
 
 ```bash
-$ cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
-$ chmod u+x cloud-run-deploy.sh
+cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
+chmod u+x cloud-run-deploy.sh
 ```
 
 Open up the script in your favorite editor. You will need to fill in your _database instance's connection name_ and the _email of your service account_.
@@ -84,7 +84,7 @@ Open up the script in your favorite editor. You will need to fill in your _datab
 Now, deploy your server by running the following:
 
 ```bash
-$ ./cloud-run-deploy.sh
+./cloud-run-deploy.sh
 ```
 
 The script runs two deployment commands, one for your API and one for the Insights API used by the Serverpod app. While running, it may ask you to enable the Cloud Run and SQL Admin services. Answer yes to all these questions.
diff --git a/versioned_docs/version-2.2.0/07-deployments/04-deploying-to-aws.md b/versioned_docs/version-2.2.0/07-deployments/04-deploying-to-aws.md
index f65ca62b..b5169f93 100644
--- a/versioned_docs/version-2.2.0/07-deployments/04-deploying-to-aws.md
+++ b/versioned_docs/version-2.2.0/07-deployments/04-deploying-to-aws.md
@@ -202,14 +202,14 @@ database:
 Your Serverpod should now be configured and ready to be deployed. Exciting times! Open up a terminal and `cd` into your server `aws/terraform` directory. First, you need to add an environment variable so that Terraform can correctly set the password for the Postgres database. You will find the production password for the database in your `config/passwords.yaml` file.
 
 ```bash
-$ export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
+export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
 ```
 
 Next, we are ready to initialize Terraform and deploy our server. You will only need to run the `terraform init` command the first time you deploy the configuration.
 
 ```bash
-$ terraform init
-$ terraform apply
+terraform init
+terraform apply
 ```
 
 Terraform will now run some checks and make a plan for the deployment. If everything looks good, it will ask you if you are ready to go ahead with the changes. Type `yes` and hit the return key. Applying the changes can take up to five minutes as AWS creates the different resources needed for your Serverpod.
diff --git a/versioned_docs/version-2.2.0/07-deployments/05-general.md b/versioned_docs/version-2.2.0/07-deployments/05-general.md
index bc27776c..bd4cd171 100644
--- a/versioned_docs/version-2.2.0/07-deployments/05-general.md
+++ b/versioned_docs/version-2.2.0/07-deployments/05-general.md
@@ -11,7 +11,7 @@ Serverpod will not run without a link to a Postgres database with the correct ta
 Serverpod has three main configuration files, depending on which mode the server is running; `development`, `staging`, or `production`. The files are located in the `config/` directory. By default, the server will start in development mode. To use another configuration file, use the `--mode` option when starting the server. If you are running multiple servers in a cluster, use the `--server-id` option to specify the id of each server. By default, the server will run as id `default`. For instance, to start the server in production mode with id `2`, run the following command:
 
 ```bash
-$ dart bin/main.dart --mode production --server-id 2
+dart bin/main.dart --mode production --server-id 2
 ```
 
 :::info
@@ -35,7 +35,7 @@ Serverpod can assume different roles depending on your configuration. If you run
 You can specify the role of your server when you launch it by setting the `--role` argument.
 
 ```bash
-$ dart bin/main.dart --role serverless
+dart bin/main.dart --role serverless
 ```
 
 ## Docker container
diff --git a/versioned_docs/version-2.2.0/08-upgrading/03-upgrade-to-two.md b/versioned_docs/version-2.2.0/08-upgrading/03-upgrade-to-two.md
index 54e3b54d..5ef0d80a 100644
--- a/versioned_docs/version-2.2.0/08-upgrading/03-upgrade-to-two.md
+++ b/versioned_docs/version-2.2.0/08-upgrading/03-upgrade-to-two.md
@@ -284,7 +284,7 @@ To ensure new databases are created with the new representation, the latest migr
 A new empty migration can be created by running the following command in the terminal:
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 #### Migration of existing tables
diff --git a/versioned_docs/version-2.2.0/09-tools/02-lsp.md b/versioned_docs/version-2.2.0/09-tools/02-lsp.md
index 2374cf57..8da02d1b 100644
--- a/versioned_docs/version-2.2.0/09-tools/02-lsp.md
+++ b/versioned_docs/version-2.2.0/09-tools/02-lsp.md
@@ -5,7 +5,7 @@ The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server
 To start the Serverpod LSP server, use the following command:
 
 ```bash
-$ serverpod language-server
+serverpod language-server
 ```
 
 :::info
diff --git a/versioned_docs/version-2.2.0/10-contribute.md b/versioned_docs/version-2.2.0/10-contribute.md
index 262f3d10..ed67d758 100644
--- a/versioned_docs/version-2.2.0/10-contribute.md
+++ b/versioned_docs/version-2.2.0/10-contribute.md
@@ -26,7 +26,7 @@ We are very conscious about keeping the Serverpod code base clean. When you writ
 Continuous integration tests are automatically run when sending a pull request to the `main` branch. You can run the tests locally by changing your working directory into the root serverpod directory and running:
 
 ```bash
-$ util/run_tests
+util/run_tests
 ```
 
 :::caution
@@ -74,9 +74,9 @@ Running single individual tests is useful when you are working on a specific fea
 To run the `serverpod` command from your cloned repository, you will need to:
 
 ```bash
-$ cd tools/serverpod_cli
-$ dart pub get
-$ dart pub global activate --source path .
+cd tools/serverpod_cli
+dart pub get
+dart pub global activate --source path .
 ```
 
 Depending on your Dart version you may need to run the `dart pub global` command above every time you've made changes in the Serverpod tooling.
@@ -96,7 +96,7 @@ First off, we are restrictive about which new packages we include in the Serverp
 Secondly, you shouldn't edit the `pubspec.yaml` files directly. Instead, make changes to the files in the `templates/` directory. When you've made changes, run the `update_pubspecs` command to generate the `pubspec.yaml` files.
 
 ```bash
-$ util/update_pubspecs
+util/update_pubspecs
 ```
 
 ## Submitting your pull request
diff --git a/versioned_docs/version-2.2.0/index.md b/versioned_docs/version-2.2.0/index.md
index e825cbee..16d80e7d 100644
--- a/versioned_docs/version-2.2.0/index.md
+++ b/versioned_docs/version-2.2.0/index.md
@@ -16,13 +16,13 @@ Serverpod is tested on Mac, Windows, and Linux. Before you can install Serverpod
 Install Serverpod by running:
 
 ```bash
-$ dart pub global activate serverpod_cli
+dart pub global activate serverpod_cli
 ```
 
 Now test the installation by running:
 
 ```bash
-$ serverpod
+serverpod
 ```
 
 If everything is correctly configured, the help for the `serverpod` command is now displayed.
diff --git a/versioned_docs/version-2.3.0/01-get-started.md b/versioned_docs/version-2.3.0/01-get-started.md
index 95a2d73b..86ecc2c2 100644
--- a/versioned_docs/version-2.3.0/01-get-started.md
+++ b/versioned_docs/version-2.3.0/01-get-started.md
@@ -40,7 +40,7 @@ The full version of Serverpod needs access to a Postgres database. The easiest w
 Create a new project by running `serverpod create`.
 
 ```bash
-$ serverpod create mypod
+serverpod create mypod
 ```
 
 :::info
@@ -60,9 +60,9 @@ This command will create a new directory called `mypod`, with three dart package
 Make sure that __[Docker Desktop](https://www.docker.com/products/docker-desktop/)__ is running, then start your Docker containers with `docker compose up --build --detach`. It will start Postgres and Redis. Then, run `dart bin/main.dart --apply-migrations` to start your server.
 
 ```bash
-$ cd mypod/mypod_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd mypod/mypod_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 If everything is working, you should see something like this on your terminal:
@@ -91,8 +91,8 @@ In your development environment it can be helpful to always start Serverpod with
 Start the default demo app by changing the directory into the Flutter package that was created and running `flutter run`.
 
 ```bash
-$ cd mypod/mypod_flutter
-$ flutter run -d chrome
+cd mypod/mypod_flutter
+flutter run -d chrome
 ```
 
 The flag `-d chrome` runs the app in Chrome, for other run options please see the Flutter documentation.
@@ -131,8 +131,8 @@ Both the `endpoints` and `models` directories contain sample files that give a q
 Whenever you change your code in either the `endpoints` or `models` directory, you will need to regenerate the classes managed by Serverpod. Do this by running `serverpod generate`.
 
 ```bash
-$ cd mypod/mypod_server
-$ serverpod generate
+cd mypod/mypod_server
+serverpod generate
 ```
 
 ### Working with endpoints
@@ -220,15 +220,15 @@ development:
 With database migrations, Serverpod makes it easy to evolve your database schema. When you make changes to your project that should be reflected in your database, you need to create a migration. A migration is a set of SQL queries that are run to update the database. To create a migration, run `serverpod create-migration` in the home directory of the server.
 
 ```bash
-$ cd mypod/mypod_server
-$ serverpod create-migration
+cd mypod/mypod_server
+serverpod create-migration
 ```
 
 Migrations are then applied to the database as part of the server startup by adding the `--apply-migrations` flag.
 
 ```bash
-$ cd mypod/mypod_server
-$ dart bin/main.dart --apply-migrations
+cd mypod/mypod_server
+dart bin/main.dart --apply-migrations
 ```
 
 :::tip
diff --git a/versioned_docs/version-2.3.0/02-get-started-with-mini.md b/versioned_docs/version-2.3.0/02-get-started-with-mini.md
index b85c171f..4849a1c9 100644
--- a/versioned_docs/version-2.3.0/02-get-started-with-mini.md
+++ b/versioned_docs/version-2.3.0/02-get-started-with-mini.md
@@ -8,7 +8,7 @@ Serverpod Mini is a slimmer version of Serverpod that does not need to be connec
 Create a mini project by running:
 
 ```bash
-$ serverpod create myminipod --mini
+serverpod create myminipod --mini
 ```
 
 Serverpod will create a new project for you. It contains three Dart packages, but you only need to pay attention to the `myminipod_server` and `myminipod_flutter` directories. The server directory contains your server files, and the flutter directory contains your app. The third package (`myminipod_client`) contains generated code that is used by the Flutter app to communicate with the server.
@@ -16,15 +16,15 @@ Serverpod will create a new project for you. It contains three Dart packages, bu
 Start your server by changing directory into your server directory, and run the `bin/main.dart` file:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ dart bin/main.dart
+cd myminipod/myminipod_server
+dart bin/main.dart
 ```
 
 Your default project comes with a sample Flutter app, all hooked up to talk with your server. Run it with the `flutter` command:
 
 ```bash
-$ cd myminipod/myminipod_flutter
-$ flutter run -d chrome
+cd myminipod/myminipod_flutter
+flutter run -d chrome
 ```
 
 Easy as that. 🥳
@@ -51,8 +51,8 @@ For types, you can use most basic Dart types, such as `String`, `double`, `int`,
 Whenever you add or edit a model file, run `serverpod generate` in your server directory. Then, Serverpod will generate all the updated Dart classes:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Adding methods to your server
@@ -87,8 +87,8 @@ class CompanyEndpoint extends Endpoint {
 After adding or modifying endpoints and endpoint methods, you must run `serverpod generate` to keep your Flutter app up-to-date.
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Calling the server methods from the app
diff --git a/versioned_docs/version-2.3.0/05-tutorials/01-first-app.mdx b/versioned_docs/version-2.3.0/05-tutorials/01-first-app.mdx
index 178ddca4..c6127fd1 100644
--- a/versioned_docs/version-2.3.0/05-tutorials/01-first-app.mdx
+++ b/versioned_docs/version-2.3.0/05-tutorials/01-first-app.mdx
@@ -31,15 +31,15 @@ Demo of what we will build: ([Full code example](https://github.com/serverpod/no
 Create a new project using the Serverpod CLI. Run the following command in your terminal:
 
 ```bash
-$ serverpod create notes
+serverpod create notes
 ```
 
 To start the server:
 
 ```bash
-$ cd notes/notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes/notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 :::info
@@ -71,7 +71,7 @@ Let's take a closer look at the content of the `note.yaml` file:
 Use the code generator to generate the code for the `Note` class from the definition in `note.yaml`. Run the following command from the root of your server project (`notes_server`):
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 After the code generation process is complete, you can access the generated code for the `Note` class in `lib/src/generated/note.dart` inside your Serverpod project.
@@ -100,7 +100,7 @@ fields:
 Run the code generator again to generate the necessary code used to access the database table:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 Take a look at the updated `lib/src/generated/note.dart` file. You will notice that the code generator has added new methods for interacting with the database. 
@@ -109,7 +109,7 @@ Take a look at the updated `lib/src/generated/note.dart` file. You will notice t
 To create the new `note` table in the database we will use the Serverpod migration system. Run the following command to generate a new database migration:
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 This creates a new migration that contains a description of the database schema and SQL code to add the table. These files can be found in the `migrations` directory in your server project (`notes_server`).
@@ -119,7 +119,7 @@ This creates a new migration that contains a description of the database schema
 To apply the database migration, start the server with the `--apply-migrations` command. We can also run the server in maintenance mode which will shut down the server as soon as its tasks are done.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 Once command has executed successfully, the database table for storing the note data will have been created.
@@ -239,7 +239,7 @@ Congratulations! You have now created all the endpoints needed for the notes app
 Now run the code generator again to generate the client library for our endpoints. This needs to be run from the server directory `notes_server`.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 You can find the newly generated code in the client directory `notes_client`. You normally don't need to touch this package, but it's good to know where it is located.
@@ -754,16 +754,16 @@ Start the database and server:
 Make sure you reboot the server if you started it earlier.
 
 ```bash
-$ cd notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 Start the Flutter app in Chrome (or the platform of your choice):
 
 ```bash
-$ cd notes_flutter
-$ flutter run -d chrome
+cd notes_flutter
+flutter run -d chrome
 ```
 
 <ReactPlayer playing={true} loop controls width="960px" height="720px" url='/img/tutorial/note-app/03-note-create.mp4' />
diff --git a/versioned_docs/version-2.3.0/06-concepts/06-database/01-connection.md b/versioned_docs/version-2.3.0/06-concepts/06-database/01-connection.md
index 089d29e7..a2916864 100644
--- a/versioned_docs/version-2.3.0/06-concepts/06-database/01-connection.md
+++ b/versioned_docs/version-2.3.0/06-concepts/06-database/01-connection.md
@@ -48,19 +48,19 @@ development:
 A newly created Serverpod project has a preconfigured Docker instance with a Postgres database set up. Run the following command from the root of the `server` package to start the database:
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To stop the database run:
 
 ```bash
-$ docker compose stop
+docker compose stop
 ```
 
 To remove the database and __delete__ all associated data, run:
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
 
 ## Connecting to a custom Postgres instance
diff --git a/versioned_docs/version-2.3.0/06-concepts/06-database/11-migrations.md b/versioned_docs/version-2.3.0/06-concepts/06-database/11-migrations.md
index c4e1891e..e0ededd7 100644
--- a/versioned_docs/version-2.3.0/06-concepts/06-database/11-migrations.md
+++ b/versioned_docs/version-2.3.0/06-concepts/06-database/11-migrations.md
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,7 +47,7 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
@@ -55,7 +55,7 @@ $ serverpod create-migration --force
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,7 +162,7 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
@@ -170,7 +170,7 @@ $ serverpod create-repair-migration --force
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
diff --git a/versioned_docs/version-2.3.0/06-concepts/10-modules.md b/versioned_docs/version-2.3.0/06-concepts/10-modules.md
index 3e4db07a..26732597 100644
--- a/versioned_docs/version-2.3.0/06-concepts/10-modules.md
+++ b/versioned_docs/version-2.3.0/06-concepts/10-modules.md
@@ -34,15 +34,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -80,13 +80,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.
diff --git a/versioned_docs/version-2.3.0/06-concepts/11-authentication/01-setup.md b/versioned_docs/version-2.3.0/06-concepts/11-authentication/01-setup.md
index 66c10d7d..2f54d7e2 100644
--- a/versioned_docs/version-2.3.0/06-concepts/11-authentication/01-setup.md
+++ b/versioned_docs/version-2.3.0/06-concepts/11-authentication/01-setup.md
@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
 Add the module as a dependency to the server project's `pubspec.yaml`.
 
 ```sh
-$ dart pub add serverpod_auth_server
+dart pub add serverpod_auth_server
 ```
 
 Add the authentication handler to the Serverpod instance.
@@ -45,7 +45,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
@@ -53,19 +53,19 @@ $ serverpod generate
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../database/migrations).
diff --git a/versioned_docs/version-2.3.0/06-concepts/11-authentication/04-providers/02-google.md b/versioned_docs/version-2.3.0/06-concepts/11-authentication/04-providers/02-google.md
index caa8b601..5ea95571 100644
--- a/versioned_docs/version-2.3.0/06-concepts/11-authentication/04-providers/02-google.md
+++ b/versioned_docs/version-2.3.0/06-concepts/11-authentication/04-providers/02-google.md
@@ -117,7 +117,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -134,7 +134,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::
diff --git a/versioned_docs/version-2.3.0/06-concepts/11-authentication/04-providers/05-firebase.md b/versioned_docs/version-2.3.0/06-concepts/11-authentication/04-providers/05-firebase.md
index 1816b20b..9dcb3766 100644
--- a/versioned_docs/version-2.3.0/06-concepts/11-authentication/04-providers/05-firebase.md
+++ b/versioned_docs/version-2.3.0/06-concepts/11-authentication/04-providers/05-firebase.md
@@ -29,8 +29,8 @@ To add authentication with Firebase, you must first install and initialize the F
 The short version:
 
 ```bash
-$ flutter pub add firebase_core firebase_auth firebase_ui_auth
-$ flutterfire configure
+flutter pub add firebase_core firebase_auth firebase_ui_auth
+flutterfire configure
 ```
 
 In the Firebase console, configure the different social sign-ins you plan to use, under `Authentication > Sign-in method`.
@@ -65,7 +65,7 @@ void main() async {
 Add the [serverpod_auth_firebase_flutter](https://pub.dev/packages/serverpod_auth_firebase_flutter) package.
 
 ```bash
-$ flutter pub add serverpod_auth_firebase_flutter
+flutter pub add serverpod_auth_firebase_flutter
 ```
 
 The `SignInWithFirebaseButton` is a convenient button that triggers the sign-in flow and can be used like this:
diff --git a/versioned_docs/version-2.3.0/06-concepts/20-experimental.md b/versioned_docs/version-2.3.0/06-concepts/20-experimental.md
index f17e7f81..9a28dca4 100644
--- a/versioned_docs/version-2.3.0/06-concepts/20-experimental.md
+++ b/versioned_docs/version-2.3.0/06-concepts/20-experimental.md
@@ -9,7 +9,7 @@ Experimental features should not be used in production environments, as their st
 By default, experimental features are disabled. To opt into using them, include the `--experimental-features` flag when running the serverpod command:
 
 ```bash
-$ serverpod generate --experimental-features=all
+serverpod generate --experimental-features=all
 ```
 
 The current options you can pass are:
diff --git a/versioned_docs/version-2.3.0/07-deployments/02-deploying-to-gce-terraform.md b/versioned_docs/version-2.3.0/07-deployments/02-deploying-to-gce-terraform.md
index 3a2ac487..f55c21bd 100644
--- a/versioned_docs/version-2.3.0/07-deployments/02-deploying-to-gce-terraform.md
+++ b/versioned_docs/version-2.3.0/07-deployments/02-deploying-to-gce-terraform.md
@@ -126,7 +126,7 @@ Depending on your domain name registrar, the process for setting up your domain
 You can test that the domain points to the correct name servers by running `dig` on the command line. It will output the domain name servers.
 
 ```bash
-$ dig +short NS examplepod.com
+dig +short NS examplepod.com
 ```
 
 Should yield an output similar to this:
@@ -228,13 +228,13 @@ If you are deploying a staging server in addition to your production server, you
 Once you have configured Terraform and your Serverpod, you are ready to deploy your infrastructure. Make sure that you have `cd` into your `deploy/gcp/terraform_gce` directory. Now run:
 
 ```bash
-$ terraform init
+terraform init
 ```
 
 This will download the Serverpod module and initialize your Terraform configuration. Now, deploy your infrastructure by running:
 
 ```bash
-$ terraform apply
+terraform apply
 ```
 
 Terraform will ask you for the password to your production and staging database. You will find the passwords in your `config/passwords.yaml` file. If you are not deploying a staging server, you can leave the staging database password blank.
diff --git a/versioned_docs/version-2.3.0/07-deployments/03-deploying-to-gcr-console.md b/versioned_docs/version-2.3.0/07-deployments/03-deploying-to-gcr-console.md
index cdd5991d..b647215c 100644
--- a/versioned_docs/version-2.3.0/07-deployments/03-deploying-to-gcr-console.md
+++ b/versioned_docs/version-2.3.0/07-deployments/03-deploying-to-gcr-console.md
@@ -11,13 +11,13 @@ Before you begin, you will need to install and configure the Google Cloud CLI to
 - To [initialize](https://cloud.google.com/sdk/docs/initializing) the gcloud CLI, run the following command:
 
 ```bash
-$ gcloud init
+gcloud init
 ```
 
 - To set the default project for your Cloud Run service:
 
 ```bash
-$ gcloud config set project <PROJECT_ID>
+gcloud config set project <PROJECT_ID>
 ```
 
 ## Setup the database
@@ -75,8 +75,8 @@ database:
 Your server is now ready to be deployed. When you created your project, Serverpod also created a script for deploying your server. Copy it to the root of your server directory and make it executable. Make sure you are in your server directory (e.g., `myproject_server`). Then run the following command:
 
 ```bash
-$ cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
-$ chmod u+x cloud-run-deploy.sh
+cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
+chmod u+x cloud-run-deploy.sh
 ```
 
 Open up the script in your favorite editor. You will need to fill in your _database instance's connection name_ and the _email of your service account_.
@@ -84,7 +84,7 @@ Open up the script in your favorite editor. You will need to fill in your _datab
 Now, deploy your server by running the following:
 
 ```bash
-$ ./cloud-run-deploy.sh
+./cloud-run-deploy.sh
 ```
 
 The script runs two deployment commands, one for your API and one for the Insights API used by the Serverpod app. While running, it may ask you to enable the Cloud Run and SQL Admin services. Answer yes to all these questions.
diff --git a/versioned_docs/version-2.3.0/07-deployments/04-deploying-to-aws.md b/versioned_docs/version-2.3.0/07-deployments/04-deploying-to-aws.md
index af139474..713e4d4c 100644
--- a/versioned_docs/version-2.3.0/07-deployments/04-deploying-to-aws.md
+++ b/versioned_docs/version-2.3.0/07-deployments/04-deploying-to-aws.md
@@ -202,14 +202,14 @@ database:
 Your Serverpod should now be configured and ready to be deployed. Exciting times! Open up a terminal and `cd` into your server `aws/terraform` directory. First, you need to add an environment variable so that Terraform can correctly set the password for the Postgres database. You will find the production password for the database in your `config/passwords.yaml` file.
 
 ```bash
-$ export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
+export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
 ```
 
 Next, we are ready to initialize Terraform and deploy our server. You will only need to run the `terraform init` command the first time you deploy the configuration.
 
 ```bash
-$ terraform init
-$ terraform apply
+terraform init
+terraform apply
 ```
 
 Terraform will now run some checks and make a plan for the deployment. If everything looks good, it will ask you if you are ready to go ahead with the changes. Type `yes` and hit the return key. Applying the changes can take up to five minutes as AWS creates the different resources needed for your Serverpod.
diff --git a/versioned_docs/version-2.3.0/07-deployments/05-general.md b/versioned_docs/version-2.3.0/07-deployments/05-general.md
index bc27776c..bd4cd171 100644
--- a/versioned_docs/version-2.3.0/07-deployments/05-general.md
+++ b/versioned_docs/version-2.3.0/07-deployments/05-general.md
@@ -11,7 +11,7 @@ Serverpod will not run without a link to a Postgres database with the correct ta
 Serverpod has three main configuration files, depending on which mode the server is running; `development`, `staging`, or `production`. The files are located in the `config/` directory. By default, the server will start in development mode. To use another configuration file, use the `--mode` option when starting the server. If you are running multiple servers in a cluster, use the `--server-id` option to specify the id of each server. By default, the server will run as id `default`. For instance, to start the server in production mode with id `2`, run the following command:
 
 ```bash
-$ dart bin/main.dart --mode production --server-id 2
+dart bin/main.dart --mode production --server-id 2
 ```
 
 :::info
@@ -35,7 +35,7 @@ Serverpod can assume different roles depending on your configuration. If you run
 You can specify the role of your server when you launch it by setting the `--role` argument.
 
 ```bash
-$ dart bin/main.dart --role serverless
+dart bin/main.dart --role serverless
 ```
 
 ## Docker container
diff --git a/versioned_docs/version-2.3.0/08-upgrading/03-upgrade-to-two.md b/versioned_docs/version-2.3.0/08-upgrading/03-upgrade-to-two.md
index 54e3b54d..5ef0d80a 100644
--- a/versioned_docs/version-2.3.0/08-upgrading/03-upgrade-to-two.md
+++ b/versioned_docs/version-2.3.0/08-upgrading/03-upgrade-to-two.md
@@ -284,7 +284,7 @@ To ensure new databases are created with the new representation, the latest migr
 A new empty migration can be created by running the following command in the terminal:
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 #### Migration of existing tables
diff --git a/versioned_docs/version-2.3.0/09-tools/02-lsp.md b/versioned_docs/version-2.3.0/09-tools/02-lsp.md
index 2374cf57..8da02d1b 100644
--- a/versioned_docs/version-2.3.0/09-tools/02-lsp.md
+++ b/versioned_docs/version-2.3.0/09-tools/02-lsp.md
@@ -5,7 +5,7 @@ The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server
 To start the Serverpod LSP server, use the following command:
 
 ```bash
-$ serverpod language-server
+serverpod language-server
 ```
 
 :::info
diff --git a/versioned_docs/version-2.3.0/index.md b/versioned_docs/version-2.3.0/index.md
index e825cbee..16d80e7d 100644
--- a/versioned_docs/version-2.3.0/index.md
+++ b/versioned_docs/version-2.3.0/index.md
@@ -16,13 +16,13 @@ Serverpod is tested on Mac, Windows, and Linux. Before you can install Serverpod
 Install Serverpod by running:
 
 ```bash
-$ dart pub global activate serverpod_cli
+dart pub global activate serverpod_cli
 ```
 
 Now test the installation by running:
 
 ```bash
-$ serverpod
+serverpod
 ```
 
 If everything is correctly configured, the help for the `serverpod` command is now displayed.
diff --git a/versioned_docs/version-2.4.0/01-get-started.md b/versioned_docs/version-2.4.0/01-get-started.md
index 95a2d73b..86ecc2c2 100644
--- a/versioned_docs/version-2.4.0/01-get-started.md
+++ b/versioned_docs/version-2.4.0/01-get-started.md
@@ -40,7 +40,7 @@ The full version of Serverpod needs access to a Postgres database. The easiest w
 Create a new project by running `serverpod create`.
 
 ```bash
-$ serverpod create mypod
+serverpod create mypod
 ```
 
 :::info
@@ -60,9 +60,9 @@ This command will create a new directory called `mypod`, with three dart package
 Make sure that __[Docker Desktop](https://www.docker.com/products/docker-desktop/)__ is running, then start your Docker containers with `docker compose up --build --detach`. It will start Postgres and Redis. Then, run `dart bin/main.dart --apply-migrations` to start your server.
 
 ```bash
-$ cd mypod/mypod_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd mypod/mypod_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 If everything is working, you should see something like this on your terminal:
@@ -91,8 +91,8 @@ In your development environment it can be helpful to always start Serverpod with
 Start the default demo app by changing the directory into the Flutter package that was created and running `flutter run`.
 
 ```bash
-$ cd mypod/mypod_flutter
-$ flutter run -d chrome
+cd mypod/mypod_flutter
+flutter run -d chrome
 ```
 
 The flag `-d chrome` runs the app in Chrome, for other run options please see the Flutter documentation.
@@ -131,8 +131,8 @@ Both the `endpoints` and `models` directories contain sample files that give a q
 Whenever you change your code in either the `endpoints` or `models` directory, you will need to regenerate the classes managed by Serverpod. Do this by running `serverpod generate`.
 
 ```bash
-$ cd mypod/mypod_server
-$ serverpod generate
+cd mypod/mypod_server
+serverpod generate
 ```
 
 ### Working with endpoints
@@ -220,15 +220,15 @@ development:
 With database migrations, Serverpod makes it easy to evolve your database schema. When you make changes to your project that should be reflected in your database, you need to create a migration. A migration is a set of SQL queries that are run to update the database. To create a migration, run `serverpod create-migration` in the home directory of the server.
 
 ```bash
-$ cd mypod/mypod_server
-$ serverpod create-migration
+cd mypod/mypod_server
+serverpod create-migration
 ```
 
 Migrations are then applied to the database as part of the server startup by adding the `--apply-migrations` flag.
 
 ```bash
-$ cd mypod/mypod_server
-$ dart bin/main.dart --apply-migrations
+cd mypod/mypod_server
+dart bin/main.dart --apply-migrations
 ```
 
 :::tip
diff --git a/versioned_docs/version-2.4.0/02-get-started-with-mini.md b/versioned_docs/version-2.4.0/02-get-started-with-mini.md
index b85c171f..4849a1c9 100644
--- a/versioned_docs/version-2.4.0/02-get-started-with-mini.md
+++ b/versioned_docs/version-2.4.0/02-get-started-with-mini.md
@@ -8,7 +8,7 @@ Serverpod Mini is a slimmer version of Serverpod that does not need to be connec
 Create a mini project by running:
 
 ```bash
-$ serverpod create myminipod --mini
+serverpod create myminipod --mini
 ```
 
 Serverpod will create a new project for you. It contains three Dart packages, but you only need to pay attention to the `myminipod_server` and `myminipod_flutter` directories. The server directory contains your server files, and the flutter directory contains your app. The third package (`myminipod_client`) contains generated code that is used by the Flutter app to communicate with the server.
@@ -16,15 +16,15 @@ Serverpod will create a new project for you. It contains three Dart packages, bu
 Start your server by changing directory into your server directory, and run the `bin/main.dart` file:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ dart bin/main.dart
+cd myminipod/myminipod_server
+dart bin/main.dart
 ```
 
 Your default project comes with a sample Flutter app, all hooked up to talk with your server. Run it with the `flutter` command:
 
 ```bash
-$ cd myminipod/myminipod_flutter
-$ flutter run -d chrome
+cd myminipod/myminipod_flutter
+flutter run -d chrome
 ```
 
 Easy as that. 🥳
@@ -51,8 +51,8 @@ For types, you can use most basic Dart types, such as `String`, `double`, `int`,
 Whenever you add or edit a model file, run `serverpod generate` in your server directory. Then, Serverpod will generate all the updated Dart classes:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Adding methods to your server
@@ -87,8 +87,8 @@ class CompanyEndpoint extends Endpoint {
 After adding or modifying endpoints and endpoint methods, you must run `serverpod generate` to keep your Flutter app up-to-date.
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Calling the server methods from the app
diff --git a/versioned_docs/version-2.4.0/05-tutorials/01-first-app.mdx b/versioned_docs/version-2.4.0/05-tutorials/01-first-app.mdx
index 178ddca4..c6127fd1 100644
--- a/versioned_docs/version-2.4.0/05-tutorials/01-first-app.mdx
+++ b/versioned_docs/version-2.4.0/05-tutorials/01-first-app.mdx
@@ -31,15 +31,15 @@ Demo of what we will build: ([Full code example](https://github.com/serverpod/no
 Create a new project using the Serverpod CLI. Run the following command in your terminal:
 
 ```bash
-$ serverpod create notes
+serverpod create notes
 ```
 
 To start the server:
 
 ```bash
-$ cd notes/notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes/notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 :::info
@@ -71,7 +71,7 @@ Let's take a closer look at the content of the `note.yaml` file:
 Use the code generator to generate the code for the `Note` class from the definition in `note.yaml`. Run the following command from the root of your server project (`notes_server`):
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 After the code generation process is complete, you can access the generated code for the `Note` class in `lib/src/generated/note.dart` inside your Serverpod project.
@@ -100,7 +100,7 @@ fields:
 Run the code generator again to generate the necessary code used to access the database table:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 Take a look at the updated `lib/src/generated/note.dart` file. You will notice that the code generator has added new methods for interacting with the database. 
@@ -109,7 +109,7 @@ Take a look at the updated `lib/src/generated/note.dart` file. You will notice t
 To create the new `note` table in the database we will use the Serverpod migration system. Run the following command to generate a new database migration:
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 This creates a new migration that contains a description of the database schema and SQL code to add the table. These files can be found in the `migrations` directory in your server project (`notes_server`).
@@ -119,7 +119,7 @@ This creates a new migration that contains a description of the database schema
 To apply the database migration, start the server with the `--apply-migrations` command. We can also run the server in maintenance mode which will shut down the server as soon as its tasks are done.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 Once command has executed successfully, the database table for storing the note data will have been created.
@@ -239,7 +239,7 @@ Congratulations! You have now created all the endpoints needed for the notes app
 Now run the code generator again to generate the client library for our endpoints. This needs to be run from the server directory `notes_server`.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 You can find the newly generated code in the client directory `notes_client`. You normally don't need to touch this package, but it's good to know where it is located.
@@ -754,16 +754,16 @@ Start the database and server:
 Make sure you reboot the server if you started it earlier.
 
 ```bash
-$ cd notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 Start the Flutter app in Chrome (or the platform of your choice):
 
 ```bash
-$ cd notes_flutter
-$ flutter run -d chrome
+cd notes_flutter
+flutter run -d chrome
 ```
 
 <ReactPlayer playing={true} loop controls width="960px" height="720px" url='/img/tutorial/note-app/03-note-create.mp4' />
diff --git a/versioned_docs/version-2.4.0/06-concepts/06-database/01-connection.md b/versioned_docs/version-2.4.0/06-concepts/06-database/01-connection.md
index 089d29e7..a2916864 100644
--- a/versioned_docs/version-2.4.0/06-concepts/06-database/01-connection.md
+++ b/versioned_docs/version-2.4.0/06-concepts/06-database/01-connection.md
@@ -48,19 +48,19 @@ development:
 A newly created Serverpod project has a preconfigured Docker instance with a Postgres database set up. Run the following command from the root of the `server` package to start the database:
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To stop the database run:
 
 ```bash
-$ docker compose stop
+docker compose stop
 ```
 
 To remove the database and __delete__ all associated data, run:
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
 
 ## Connecting to a custom Postgres instance
diff --git a/versioned_docs/version-2.4.0/06-concepts/06-database/11-migrations.md b/versioned_docs/version-2.4.0/06-concepts/06-database/11-migrations.md
index c4e1891e..e0ededd7 100644
--- a/versioned_docs/version-2.4.0/06-concepts/06-database/11-migrations.md
+++ b/versioned_docs/version-2.4.0/06-concepts/06-database/11-migrations.md
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,7 +47,7 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
@@ -55,7 +55,7 @@ $ serverpod create-migration --force
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,7 +162,7 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
@@ -170,7 +170,7 @@ $ serverpod create-repair-migration --force
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
diff --git a/versioned_docs/version-2.4.0/06-concepts/10-modules.md b/versioned_docs/version-2.4.0/06-concepts/10-modules.md
index 3e4db07a..26732597 100644
--- a/versioned_docs/version-2.4.0/06-concepts/10-modules.md
+++ b/versioned_docs/version-2.4.0/06-concepts/10-modules.md
@@ -34,15 +34,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -80,13 +80,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.
diff --git a/versioned_docs/version-2.4.0/06-concepts/11-authentication/01-setup.md b/versioned_docs/version-2.4.0/06-concepts/11-authentication/01-setup.md
index 66c10d7d..2f54d7e2 100644
--- a/versioned_docs/version-2.4.0/06-concepts/11-authentication/01-setup.md
+++ b/versioned_docs/version-2.4.0/06-concepts/11-authentication/01-setup.md
@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
 Add the module as a dependency to the server project's `pubspec.yaml`.
 
 ```sh
-$ dart pub add serverpod_auth_server
+dart pub add serverpod_auth_server
 ```
 
 Add the authentication handler to the Serverpod instance.
@@ -45,7 +45,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
@@ -53,19 +53,19 @@ $ serverpod generate
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../database/migrations).
diff --git a/versioned_docs/version-2.4.0/06-concepts/11-authentication/04-providers/02-google.md b/versioned_docs/version-2.4.0/06-concepts/11-authentication/04-providers/02-google.md
index caa8b601..5ea95571 100644
--- a/versioned_docs/version-2.4.0/06-concepts/11-authentication/04-providers/02-google.md
+++ b/versioned_docs/version-2.4.0/06-concepts/11-authentication/04-providers/02-google.md
@@ -117,7 +117,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -134,7 +134,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::
diff --git a/versioned_docs/version-2.4.0/06-concepts/11-authentication/04-providers/05-firebase.md b/versioned_docs/version-2.4.0/06-concepts/11-authentication/04-providers/05-firebase.md
index 1816b20b..9dcb3766 100644
--- a/versioned_docs/version-2.4.0/06-concepts/11-authentication/04-providers/05-firebase.md
+++ b/versioned_docs/version-2.4.0/06-concepts/11-authentication/04-providers/05-firebase.md
@@ -29,8 +29,8 @@ To add authentication with Firebase, you must first install and initialize the F
 The short version:
 
 ```bash
-$ flutter pub add firebase_core firebase_auth firebase_ui_auth
-$ flutterfire configure
+flutter pub add firebase_core firebase_auth firebase_ui_auth
+flutterfire configure
 ```
 
 In the Firebase console, configure the different social sign-ins you plan to use, under `Authentication > Sign-in method`.
@@ -65,7 +65,7 @@ void main() async {
 Add the [serverpod_auth_firebase_flutter](https://pub.dev/packages/serverpod_auth_firebase_flutter) package.
 
 ```bash
-$ flutter pub add serverpod_auth_firebase_flutter
+flutter pub add serverpod_auth_firebase_flutter
 ```
 
 The `SignInWithFirebaseButton` is a convenient button that triggers the sign-in flow and can be used like this:
diff --git a/versioned_docs/version-2.4.0/06-concepts/20-experimental.md b/versioned_docs/version-2.4.0/06-concepts/20-experimental.md
index a90eeca2..a3433ac8 100644
--- a/versioned_docs/version-2.4.0/06-concepts/20-experimental.md
+++ b/versioned_docs/version-2.4.0/06-concepts/20-experimental.md
@@ -21,7 +21,7 @@ If possible, the experimental API will remain for some time as `@deprecated`, an
 Some of the experimental features are enabled by including the `--experimental-features` flag when running the serverpod command:
 
 ```bash
-$ serverpod generate --experimental-features=all
+serverpod generate --experimental-features=all
 ```
 
 The current options you can pass are:
diff --git a/versioned_docs/version-2.4.0/07-deployments/02-deploying-to-gce-terraform.md b/versioned_docs/version-2.4.0/07-deployments/02-deploying-to-gce-terraform.md
index 3a2ac487..f55c21bd 100644
--- a/versioned_docs/version-2.4.0/07-deployments/02-deploying-to-gce-terraform.md
+++ b/versioned_docs/version-2.4.0/07-deployments/02-deploying-to-gce-terraform.md
@@ -126,7 +126,7 @@ Depending on your domain name registrar, the process for setting up your domain
 You can test that the domain points to the correct name servers by running `dig` on the command line. It will output the domain name servers.
 
 ```bash
-$ dig +short NS examplepod.com
+dig +short NS examplepod.com
 ```
 
 Should yield an output similar to this:
@@ -228,13 +228,13 @@ If you are deploying a staging server in addition to your production server, you
 Once you have configured Terraform and your Serverpod, you are ready to deploy your infrastructure. Make sure that you have `cd` into your `deploy/gcp/terraform_gce` directory. Now run:
 
 ```bash
-$ terraform init
+terraform init
 ```
 
 This will download the Serverpod module and initialize your Terraform configuration. Now, deploy your infrastructure by running:
 
 ```bash
-$ terraform apply
+terraform apply
 ```
 
 Terraform will ask you for the password to your production and staging database. You will find the passwords in your `config/passwords.yaml` file. If you are not deploying a staging server, you can leave the staging database password blank.
diff --git a/versioned_docs/version-2.4.0/07-deployments/03-deploying-to-gcr-console.md b/versioned_docs/version-2.4.0/07-deployments/03-deploying-to-gcr-console.md
index cdd5991d..b647215c 100644
--- a/versioned_docs/version-2.4.0/07-deployments/03-deploying-to-gcr-console.md
+++ b/versioned_docs/version-2.4.0/07-deployments/03-deploying-to-gcr-console.md
@@ -11,13 +11,13 @@ Before you begin, you will need to install and configure the Google Cloud CLI to
 - To [initialize](https://cloud.google.com/sdk/docs/initializing) the gcloud CLI, run the following command:
 
 ```bash
-$ gcloud init
+gcloud init
 ```
 
 - To set the default project for your Cloud Run service:
 
 ```bash
-$ gcloud config set project <PROJECT_ID>
+gcloud config set project <PROJECT_ID>
 ```
 
 ## Setup the database
@@ -75,8 +75,8 @@ database:
 Your server is now ready to be deployed. When you created your project, Serverpod also created a script for deploying your server. Copy it to the root of your server directory and make it executable. Make sure you are in your server directory (e.g., `myproject_server`). Then run the following command:
 
 ```bash
-$ cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
-$ chmod u+x cloud-run-deploy.sh
+cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
+chmod u+x cloud-run-deploy.sh
 ```
 
 Open up the script in your favorite editor. You will need to fill in your _database instance's connection name_ and the _email of your service account_.
@@ -84,7 +84,7 @@ Open up the script in your favorite editor. You will need to fill in your _datab
 Now, deploy your server by running the following:
 
 ```bash
-$ ./cloud-run-deploy.sh
+./cloud-run-deploy.sh
 ```
 
 The script runs two deployment commands, one for your API and one for the Insights API used by the Serverpod app. While running, it may ask you to enable the Cloud Run and SQL Admin services. Answer yes to all these questions.
diff --git a/versioned_docs/version-2.4.0/07-deployments/04-deploying-to-aws.md b/versioned_docs/version-2.4.0/07-deployments/04-deploying-to-aws.md
index af139474..713e4d4c 100644
--- a/versioned_docs/version-2.4.0/07-deployments/04-deploying-to-aws.md
+++ b/versioned_docs/version-2.4.0/07-deployments/04-deploying-to-aws.md
@@ -202,14 +202,14 @@ database:
 Your Serverpod should now be configured and ready to be deployed. Exciting times! Open up a terminal and `cd` into your server `aws/terraform` directory. First, you need to add an environment variable so that Terraform can correctly set the password for the Postgres database. You will find the production password for the database in your `config/passwords.yaml` file.
 
 ```bash
-$ export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
+export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
 ```
 
 Next, we are ready to initialize Terraform and deploy our server. You will only need to run the `terraform init` command the first time you deploy the configuration.
 
 ```bash
-$ terraform init
-$ terraform apply
+terraform init
+terraform apply
 ```
 
 Terraform will now run some checks and make a plan for the deployment. If everything looks good, it will ask you if you are ready to go ahead with the changes. Type `yes` and hit the return key. Applying the changes can take up to five minutes as AWS creates the different resources needed for your Serverpod.
diff --git a/versioned_docs/version-2.4.0/07-deployments/05-general.md b/versioned_docs/version-2.4.0/07-deployments/05-general.md
index bc27776c..bd4cd171 100644
--- a/versioned_docs/version-2.4.0/07-deployments/05-general.md
+++ b/versioned_docs/version-2.4.0/07-deployments/05-general.md
@@ -11,7 +11,7 @@ Serverpod will not run without a link to a Postgres database with the correct ta
 Serverpod has three main configuration files, depending on which mode the server is running; `development`, `staging`, or `production`. The files are located in the `config/` directory. By default, the server will start in development mode. To use another configuration file, use the `--mode` option when starting the server. If you are running multiple servers in a cluster, use the `--server-id` option to specify the id of each server. By default, the server will run as id `default`. For instance, to start the server in production mode with id `2`, run the following command:
 
 ```bash
-$ dart bin/main.dart --mode production --server-id 2
+dart bin/main.dart --mode production --server-id 2
 ```
 
 :::info
@@ -35,7 +35,7 @@ Serverpod can assume different roles depending on your configuration. If you run
 You can specify the role of your server when you launch it by setting the `--role` argument.
 
 ```bash
-$ dart bin/main.dart --role serverless
+dart bin/main.dart --role serverless
 ```
 
 ## Docker container
diff --git a/versioned_docs/version-2.4.0/08-upgrading/03-upgrade-to-two.md b/versioned_docs/version-2.4.0/08-upgrading/03-upgrade-to-two.md
index 54e3b54d..5ef0d80a 100644
--- a/versioned_docs/version-2.4.0/08-upgrading/03-upgrade-to-two.md
+++ b/versioned_docs/version-2.4.0/08-upgrading/03-upgrade-to-two.md
@@ -284,7 +284,7 @@ To ensure new databases are created with the new representation, the latest migr
 A new empty migration can be created by running the following command in the terminal:
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 #### Migration of existing tables
diff --git a/versioned_docs/version-2.4.0/09-tools/02-lsp.md b/versioned_docs/version-2.4.0/09-tools/02-lsp.md
index 2374cf57..8da02d1b 100644
--- a/versioned_docs/version-2.4.0/09-tools/02-lsp.md
+++ b/versioned_docs/version-2.4.0/09-tools/02-lsp.md
@@ -5,7 +5,7 @@ The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server
 To start the Serverpod LSP server, use the following command:
 
 ```bash
-$ serverpod language-server
+serverpod language-server
 ```
 
 :::info
diff --git a/versioned_docs/version-2.4.0/index.md b/versioned_docs/version-2.4.0/index.md
index e825cbee..16d80e7d 100644
--- a/versioned_docs/version-2.4.0/index.md
+++ b/versioned_docs/version-2.4.0/index.md
@@ -16,13 +16,13 @@ Serverpod is tested on Mac, Windows, and Linux. Before you can install Serverpod
 Install Serverpod by running:
 
 ```bash
-$ dart pub global activate serverpod_cli
+dart pub global activate serverpod_cli
 ```
 
 Now test the installation by running:
 
 ```bash
-$ serverpod
+serverpod
 ```
 
 If everything is correctly configured, the help for the `serverpod` command is now displayed.
diff --git a/versioned_docs/version-2.5.0/01-get-started/03-creating-project.md b/versioned_docs/version-2.5.0/01-get-started/03-creating-project.md
index 8ea77153..390224ce 100644
--- a/versioned_docs/version-2.5.0/01-get-started/03-creating-project.md
+++ b/versioned_docs/version-2.5.0/01-get-started/03-creating-project.md
@@ -5,7 +5,7 @@ The full version of Serverpod needs access to a Postgres database. The easiest w
 Create a new project by running `serverpod create`.
 
 ```bash
-$ serverpod create mypod
+serverpod create mypod
 ```
 
 :::info
@@ -25,9 +25,9 @@ This command will create a new directory called `mypod`, with three dart package
 Make sure that **[Docker Desktop](https://www.docker.com/products/docker-desktop/)** is running, then start your Docker containers with `docker compose up --build --detach`. It will start Postgres and Redis. Then, run `dart bin/main.dart --apply-migrations` to start your server.
 
 ```bash
-$ cd mypod/mypod_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd mypod/mypod_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 If everything is working, you should see something like this on your terminal:
@@ -56,8 +56,8 @@ In your development environment it can be helpful to always start Serverpod with
 Start the default demo app by changing the directory into the Flutter package that was created and running `flutter run`.
 
 ```bash
-$ cd mypod/mypod_flutter
-$ flutter run -d chrome
+cd mypod/mypod_flutter
+flutter run -d chrome
 ```
 
 The flag `-d chrome` runs the app in Chrome, for other run options please see the Flutter documentation.
diff --git a/versioned_docs/version-2.5.0/01-get-started/04-get-started-with-mini.md b/versioned_docs/version-2.5.0/01-get-started/04-get-started-with-mini.md
index 26948eca..e1518bbb 100644
--- a/versioned_docs/version-2.5.0/01-get-started/04-get-started-with-mini.md
+++ b/versioned_docs/version-2.5.0/01-get-started/04-get-started-with-mini.md
@@ -9,7 +9,7 @@ Serverpod Mini is a slimmer version of Serverpod that does not need to be connec
 Create a mini project by running:
 
 ```bash
-$ serverpod create myminipod --mini
+serverpod create myminipod --mini
 ```
 
 Serverpod will create a new project for you. It contains three Dart packages, but you only need to pay attention to the `myminipod_server` and `myminipod_flutter` directories. The server directory contains your server files, and the flutter directory contains your app. The third package (`myminipod_client`) contains generated code that is used by the Flutter app to communicate with the server.
@@ -17,15 +17,15 @@ Serverpod will create a new project for you. It contains three Dart packages, bu
 Start your server by changing directory into your server directory, and run the `bin/main.dart` file:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ dart bin/main.dart
+cd myminipod/myminipod_server
+dart bin/main.dart
 ```
 
 Your default project comes with a sample Flutter app, all hooked up to talk with your server. Run it with the `flutter` command:
 
 ```bash
-$ cd myminipod/myminipod_flutter
-$ flutter run -d chrome
+cd myminipod/myminipod_flutter
+flutter run -d chrome
 ```
 
 Easy as that. 🥳
@@ -53,8 +53,8 @@ For types, you can use most basic Dart types, such as `String`, `double`, `int`,
 Whenever you add or edit a model file, run `serverpod generate` in your server directory. Then, Serverpod will generate all the updated Dart classes:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Adding methods to your server
@@ -90,8 +90,8 @@ class CompanyEndpoint extends Endpoint {
 After adding or modifying endpoints and endpoint methods, you must run `serverpod generate` to keep your Flutter app up-to-date.
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Calling the server methods from the app
diff --git a/versioned_docs/version-2.5.0/01-get-started/05-server-overview.md b/versioned_docs/version-2.5.0/01-get-started/05-server-overview.md
index 2c068b7e..df7982b6 100644
--- a/versioned_docs/version-2.5.0/01-get-started/05-server-overview.md
+++ b/versioned_docs/version-2.5.0/01-get-started/05-server-overview.md
@@ -15,6 +15,6 @@ Both the `endpoints` and `models` directories contain sample files that give a q
 Whenever you change your code in either the `endpoints` or `models` directory, you will need to regenerate the classes managed by Serverpod. Do this by running `serverpod generate`.
 
 ```bash
-$ cd mypod/mypod_server
-$ serverpod generate
+cd mypod/mypod_server
+serverpod generate
 ```
diff --git a/versioned_docs/version-2.5.0/01-get-started/08-working-with-database.md b/versioned_docs/version-2.5.0/01-get-started/08-working-with-database.md
index 8bcbead1..7d4a6128 100644
--- a/versioned_docs/version-2.5.0/01-get-started/08-working-with-database.md
+++ b/versioned_docs/version-2.5.0/01-get-started/08-working-with-database.md
@@ -28,15 +28,15 @@ development:
 With database migrations, Serverpod makes it easy to evolve your database schema. When you make changes to your project that should be reflected in your database, you need to create a migration. A migration is a set of SQL queries that are run to update the database. To create a migration, run `serverpod create-migration` in the home directory of the server.
 
 ```bash
-$ cd mypod/mypod_server
-$ serverpod create-migration
+cd mypod/mypod_server
+serverpod create-migration
 ```
 
 Migrations are then applied to the database as part of the server startup by adding the `--apply-migrations` flag.
 
 ```bash
-$ cd mypod/mypod_server
-$ dart bin/main.dart --apply-migrations
+cd mypod/mypod_server
+dart bin/main.dart --apply-migrations
 ```
 
 :::tip
diff --git a/versioned_docs/version-2.5.0/05-tutorials/01-first-app.mdx b/versioned_docs/version-2.5.0/05-tutorials/01-first-app.mdx
index 178ddca4..c6127fd1 100644
--- a/versioned_docs/version-2.5.0/05-tutorials/01-first-app.mdx
+++ b/versioned_docs/version-2.5.0/05-tutorials/01-first-app.mdx
@@ -31,15 +31,15 @@ Demo of what we will build: ([Full code example](https://github.com/serverpod/no
 Create a new project using the Serverpod CLI. Run the following command in your terminal:
 
 ```bash
-$ serverpod create notes
+serverpod create notes
 ```
 
 To start the server:
 
 ```bash
-$ cd notes/notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes/notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 :::info
@@ -71,7 +71,7 @@ Let's take a closer look at the content of the `note.yaml` file:
 Use the code generator to generate the code for the `Note` class from the definition in `note.yaml`. Run the following command from the root of your server project (`notes_server`):
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 After the code generation process is complete, you can access the generated code for the `Note` class in `lib/src/generated/note.dart` inside your Serverpod project.
@@ -100,7 +100,7 @@ fields:
 Run the code generator again to generate the necessary code used to access the database table:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 Take a look at the updated `lib/src/generated/note.dart` file. You will notice that the code generator has added new methods for interacting with the database. 
@@ -109,7 +109,7 @@ Take a look at the updated `lib/src/generated/note.dart` file. You will notice t
 To create the new `note` table in the database we will use the Serverpod migration system. Run the following command to generate a new database migration:
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 This creates a new migration that contains a description of the database schema and SQL code to add the table. These files can be found in the `migrations` directory in your server project (`notes_server`).
@@ -119,7 +119,7 @@ This creates a new migration that contains a description of the database schema
 To apply the database migration, start the server with the `--apply-migrations` command. We can also run the server in maintenance mode which will shut down the server as soon as its tasks are done.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 Once command has executed successfully, the database table for storing the note data will have been created.
@@ -239,7 +239,7 @@ Congratulations! You have now created all the endpoints needed for the notes app
 Now run the code generator again to generate the client library for our endpoints. This needs to be run from the server directory `notes_server`.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 You can find the newly generated code in the client directory `notes_client`. You normally don't need to touch this package, but it's good to know where it is located.
@@ -754,16 +754,16 @@ Start the database and server:
 Make sure you reboot the server if you started it earlier.
 
 ```bash
-$ cd notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 Start the Flutter app in Chrome (or the platform of your choice):
 
 ```bash
-$ cd notes_flutter
-$ flutter run -d chrome
+cd notes_flutter
+flutter run -d chrome
 ```
 
 <ReactPlayer playing={true} loop controls width="960px" height="720px" url='/img/tutorial/note-app/03-note-create.mp4' />
diff --git a/versioned_docs/version-2.5.0/06-concepts/06-database/01-connection.md b/versioned_docs/version-2.5.0/06-concepts/06-database/01-connection.md
index 089d29e7..a2916864 100644
--- a/versioned_docs/version-2.5.0/06-concepts/06-database/01-connection.md
+++ b/versioned_docs/version-2.5.0/06-concepts/06-database/01-connection.md
@@ -48,19 +48,19 @@ development:
 A newly created Serverpod project has a preconfigured Docker instance with a Postgres database set up. Run the following command from the root of the `server` package to start the database:
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To stop the database run:
 
 ```bash
-$ docker compose stop
+docker compose stop
 ```
 
 To remove the database and __delete__ all associated data, run:
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
 
 ## Connecting to a custom Postgres instance
diff --git a/versioned_docs/version-2.5.0/06-concepts/06-database/11-migrations.md b/versioned_docs/version-2.5.0/06-concepts/06-database/11-migrations.md
index c4e1891e..e0ededd7 100644
--- a/versioned_docs/version-2.5.0/06-concepts/06-database/11-migrations.md
+++ b/versioned_docs/version-2.5.0/06-concepts/06-database/11-migrations.md
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,7 +47,7 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
@@ -55,7 +55,7 @@ $ serverpod create-migration --force
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,7 +162,7 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
@@ -170,7 +170,7 @@ $ serverpod create-repair-migration --force
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
diff --git a/versioned_docs/version-2.5.0/06-concepts/10-modules.md b/versioned_docs/version-2.5.0/06-concepts/10-modules.md
index 3e4db07a..26732597 100644
--- a/versioned_docs/version-2.5.0/06-concepts/10-modules.md
+++ b/versioned_docs/version-2.5.0/06-concepts/10-modules.md
@@ -34,15 +34,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -80,13 +80,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.
diff --git a/versioned_docs/version-2.5.0/06-concepts/11-authentication/01-setup.md b/versioned_docs/version-2.5.0/06-concepts/11-authentication/01-setup.md
index 66c10d7d..2f54d7e2 100644
--- a/versioned_docs/version-2.5.0/06-concepts/11-authentication/01-setup.md
+++ b/versioned_docs/version-2.5.0/06-concepts/11-authentication/01-setup.md
@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
 Add the module as a dependency to the server project's `pubspec.yaml`.
 
 ```sh
-$ dart pub add serverpod_auth_server
+dart pub add serverpod_auth_server
 ```
 
 Add the authentication handler to the Serverpod instance.
@@ -45,7 +45,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
@@ -53,19 +53,19 @@ $ serverpod generate
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../database/migrations).
diff --git a/versioned_docs/version-2.5.0/06-concepts/11-authentication/04-providers/02-google.md b/versioned_docs/version-2.5.0/06-concepts/11-authentication/04-providers/02-google.md
index caa8b601..5ea95571 100644
--- a/versioned_docs/version-2.5.0/06-concepts/11-authentication/04-providers/02-google.md
+++ b/versioned_docs/version-2.5.0/06-concepts/11-authentication/04-providers/02-google.md
@@ -117,7 +117,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -134,7 +134,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::
diff --git a/versioned_docs/version-2.5.0/06-concepts/11-authentication/04-providers/05-firebase.md b/versioned_docs/version-2.5.0/06-concepts/11-authentication/04-providers/05-firebase.md
index 1816b20b..9dcb3766 100644
--- a/versioned_docs/version-2.5.0/06-concepts/11-authentication/04-providers/05-firebase.md
+++ b/versioned_docs/version-2.5.0/06-concepts/11-authentication/04-providers/05-firebase.md
@@ -29,8 +29,8 @@ To add authentication with Firebase, you must first install and initialize the F
 The short version:
 
 ```bash
-$ flutter pub add firebase_core firebase_auth firebase_ui_auth
-$ flutterfire configure
+flutter pub add firebase_core firebase_auth firebase_ui_auth
+flutterfire configure
 ```
 
 In the Firebase console, configure the different social sign-ins you plan to use, under `Authentication > Sign-in method`.
@@ -65,7 +65,7 @@ void main() async {
 Add the [serverpod_auth_firebase_flutter](https://pub.dev/packages/serverpod_auth_firebase_flutter) package.
 
 ```bash
-$ flutter pub add serverpod_auth_firebase_flutter
+flutter pub add serverpod_auth_firebase_flutter
 ```
 
 The `SignInWithFirebaseButton` is a convenient button that triggers the sign-in flow and can be used like this:
diff --git a/versioned_docs/version-2.5.0/06-concepts/20-experimental.md b/versioned_docs/version-2.5.0/06-concepts/20-experimental.md
index a90eeca2..a3433ac8 100644
--- a/versioned_docs/version-2.5.0/06-concepts/20-experimental.md
+++ b/versioned_docs/version-2.5.0/06-concepts/20-experimental.md
@@ -21,7 +21,7 @@ If possible, the experimental API will remain for some time as `@deprecated`, an
 Some of the experimental features are enabled by including the `--experimental-features` flag when running the serverpod command:
 
 ```bash
-$ serverpod generate --experimental-features=all
+serverpod generate --experimental-features=all
 ```
 
 The current options you can pass are:
diff --git a/versioned_docs/version-2.5.0/07-deployments/02-deploying-to-gce-terraform.md b/versioned_docs/version-2.5.0/07-deployments/02-deploying-to-gce-terraform.md
index 3a2ac487..f55c21bd 100644
--- a/versioned_docs/version-2.5.0/07-deployments/02-deploying-to-gce-terraform.md
+++ b/versioned_docs/version-2.5.0/07-deployments/02-deploying-to-gce-terraform.md
@@ -126,7 +126,7 @@ Depending on your domain name registrar, the process for setting up your domain
 You can test that the domain points to the correct name servers by running `dig` on the command line. It will output the domain name servers.
 
 ```bash
-$ dig +short NS examplepod.com
+dig +short NS examplepod.com
 ```
 
 Should yield an output similar to this:
@@ -228,13 +228,13 @@ If you are deploying a staging server in addition to your production server, you
 Once you have configured Terraform and your Serverpod, you are ready to deploy your infrastructure. Make sure that you have `cd` into your `deploy/gcp/terraform_gce` directory. Now run:
 
 ```bash
-$ terraform init
+terraform init
 ```
 
 This will download the Serverpod module and initialize your Terraform configuration. Now, deploy your infrastructure by running:
 
 ```bash
-$ terraform apply
+terraform apply
 ```
 
 Terraform will ask you for the password to your production and staging database. You will find the passwords in your `config/passwords.yaml` file. If you are not deploying a staging server, you can leave the staging database password blank.
diff --git a/versioned_docs/version-2.5.0/07-deployments/03-deploying-to-gcr-console.md b/versioned_docs/version-2.5.0/07-deployments/03-deploying-to-gcr-console.md
index cdd5991d..b647215c 100644
--- a/versioned_docs/version-2.5.0/07-deployments/03-deploying-to-gcr-console.md
+++ b/versioned_docs/version-2.5.0/07-deployments/03-deploying-to-gcr-console.md
@@ -11,13 +11,13 @@ Before you begin, you will need to install and configure the Google Cloud CLI to
 - To [initialize](https://cloud.google.com/sdk/docs/initializing) the gcloud CLI, run the following command:
 
 ```bash
-$ gcloud init
+gcloud init
 ```
 
 - To set the default project for your Cloud Run service:
 
 ```bash
-$ gcloud config set project <PROJECT_ID>
+gcloud config set project <PROJECT_ID>
 ```
 
 ## Setup the database
@@ -75,8 +75,8 @@ database:
 Your server is now ready to be deployed. When you created your project, Serverpod also created a script for deploying your server. Copy it to the root of your server directory and make it executable. Make sure you are in your server directory (e.g., `myproject_server`). Then run the following command:
 
 ```bash
-$ cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
-$ chmod u+x cloud-run-deploy.sh
+cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
+chmod u+x cloud-run-deploy.sh
 ```
 
 Open up the script in your favorite editor. You will need to fill in your _database instance's connection name_ and the _email of your service account_.
@@ -84,7 +84,7 @@ Open up the script in your favorite editor. You will need to fill in your _datab
 Now, deploy your server by running the following:
 
 ```bash
-$ ./cloud-run-deploy.sh
+./cloud-run-deploy.sh
 ```
 
 The script runs two deployment commands, one for your API and one for the Insights API used by the Serverpod app. While running, it may ask you to enable the Cloud Run and SQL Admin services. Answer yes to all these questions.
diff --git a/versioned_docs/version-2.5.0/07-deployments/04-deploying-to-aws.md b/versioned_docs/version-2.5.0/07-deployments/04-deploying-to-aws.md
index af139474..713e4d4c 100644
--- a/versioned_docs/version-2.5.0/07-deployments/04-deploying-to-aws.md
+++ b/versioned_docs/version-2.5.0/07-deployments/04-deploying-to-aws.md
@@ -202,14 +202,14 @@ database:
 Your Serverpod should now be configured and ready to be deployed. Exciting times! Open up a terminal and `cd` into your server `aws/terraform` directory. First, you need to add an environment variable so that Terraform can correctly set the password for the Postgres database. You will find the production password for the database in your `config/passwords.yaml` file.
 
 ```bash
-$ export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
+export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
 ```
 
 Next, we are ready to initialize Terraform and deploy our server. You will only need to run the `terraform init` command the first time you deploy the configuration.
 
 ```bash
-$ terraform init
-$ terraform apply
+terraform init
+terraform apply
 ```
 
 Terraform will now run some checks and make a plan for the deployment. If everything looks good, it will ask you if you are ready to go ahead with the changes. Type `yes` and hit the return key. Applying the changes can take up to five minutes as AWS creates the different resources needed for your Serverpod.
diff --git a/versioned_docs/version-2.5.0/07-deployments/05-general.md b/versioned_docs/version-2.5.0/07-deployments/05-general.md
index bc27776c..bd4cd171 100644
--- a/versioned_docs/version-2.5.0/07-deployments/05-general.md
+++ b/versioned_docs/version-2.5.0/07-deployments/05-general.md
@@ -11,7 +11,7 @@ Serverpod will not run without a link to a Postgres database with the correct ta
 Serverpod has three main configuration files, depending on which mode the server is running; `development`, `staging`, or `production`. The files are located in the `config/` directory. By default, the server will start in development mode. To use another configuration file, use the `--mode` option when starting the server. If you are running multiple servers in a cluster, use the `--server-id` option to specify the id of each server. By default, the server will run as id `default`. For instance, to start the server in production mode with id `2`, run the following command:
 
 ```bash
-$ dart bin/main.dart --mode production --server-id 2
+dart bin/main.dart --mode production --server-id 2
 ```
 
 :::info
@@ -35,7 +35,7 @@ Serverpod can assume different roles depending on your configuration. If you run
 You can specify the role of your server when you launch it by setting the `--role` argument.
 
 ```bash
-$ dart bin/main.dart --role serverless
+dart bin/main.dart --role serverless
 ```
 
 ## Docker container
diff --git a/versioned_docs/version-2.5.0/08-upgrading/03-upgrade-to-two.md b/versioned_docs/version-2.5.0/08-upgrading/03-upgrade-to-two.md
index 54e3b54d..5ef0d80a 100644
--- a/versioned_docs/version-2.5.0/08-upgrading/03-upgrade-to-two.md
+++ b/versioned_docs/version-2.5.0/08-upgrading/03-upgrade-to-two.md
@@ -284,7 +284,7 @@ To ensure new databases are created with the new representation, the latest migr
 A new empty migration can be created by running the following command in the terminal:
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 #### Migration of existing tables
diff --git a/versioned_docs/version-2.5.0/09-tools/02-lsp.md b/versioned_docs/version-2.5.0/09-tools/02-lsp.md
index 2374cf57..8da02d1b 100644
--- a/versioned_docs/version-2.5.0/09-tools/02-lsp.md
+++ b/versioned_docs/version-2.5.0/09-tools/02-lsp.md
@@ -5,7 +5,7 @@ The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server
 To start the Serverpod LSP server, use the following command:
 
 ```bash
-$ serverpod language-server
+serverpod language-server
 ```
 
 :::info
diff --git a/versioned_docs/version-2.5.0/index.md b/versioned_docs/version-2.5.0/index.md
index e825cbee..16d80e7d 100644
--- a/versioned_docs/version-2.5.0/index.md
+++ b/versioned_docs/version-2.5.0/index.md
@@ -16,13 +16,13 @@ Serverpod is tested on Mac, Windows, and Linux. Before you can install Serverpod
 Install Serverpod by running:
 
 ```bash
-$ dart pub global activate serverpod_cli
+dart pub global activate serverpod_cli
 ```
 
 Now test the installation by running:
 
 ```bash
-$ serverpod
+serverpod
 ```
 
 If everything is correctly configured, the help for the `serverpod` command is now displayed.
diff --git a/versioned_docs/version-2.6.0/01-get-started/03-creating-project.md b/versioned_docs/version-2.6.0/01-get-started/03-creating-project.md
index 8ea77153..390224ce 100644
--- a/versioned_docs/version-2.6.0/01-get-started/03-creating-project.md
+++ b/versioned_docs/version-2.6.0/01-get-started/03-creating-project.md
@@ -5,7 +5,7 @@ The full version of Serverpod needs access to a Postgres database. The easiest w
 Create a new project by running `serverpod create`.
 
 ```bash
-$ serverpod create mypod
+serverpod create mypod
 ```
 
 :::info
@@ -25,9 +25,9 @@ This command will create a new directory called `mypod`, with three dart package
 Make sure that **[Docker Desktop](https://www.docker.com/products/docker-desktop/)** is running, then start your Docker containers with `docker compose up --build --detach`. It will start Postgres and Redis. Then, run `dart bin/main.dart --apply-migrations` to start your server.
 
 ```bash
-$ cd mypod/mypod_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd mypod/mypod_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 If everything is working, you should see something like this on your terminal:
@@ -56,8 +56,8 @@ In your development environment it can be helpful to always start Serverpod with
 Start the default demo app by changing the directory into the Flutter package that was created and running `flutter run`.
 
 ```bash
-$ cd mypod/mypod_flutter
-$ flutter run -d chrome
+cd mypod/mypod_flutter
+flutter run -d chrome
 ```
 
 The flag `-d chrome` runs the app in Chrome, for other run options please see the Flutter documentation.
diff --git a/versioned_docs/version-2.6.0/01-get-started/04-get-started-with-mini.md b/versioned_docs/version-2.6.0/01-get-started/04-get-started-with-mini.md
index 26948eca..e1518bbb 100644
--- a/versioned_docs/version-2.6.0/01-get-started/04-get-started-with-mini.md
+++ b/versioned_docs/version-2.6.0/01-get-started/04-get-started-with-mini.md
@@ -9,7 +9,7 @@ Serverpod Mini is a slimmer version of Serverpod that does not need to be connec
 Create a mini project by running:
 
 ```bash
-$ serverpod create myminipod --mini
+serverpod create myminipod --mini
 ```
 
 Serverpod will create a new project for you. It contains three Dart packages, but you only need to pay attention to the `myminipod_server` and `myminipod_flutter` directories. The server directory contains your server files, and the flutter directory contains your app. The third package (`myminipod_client`) contains generated code that is used by the Flutter app to communicate with the server.
@@ -17,15 +17,15 @@ Serverpod will create a new project for you. It contains three Dart packages, bu
 Start your server by changing directory into your server directory, and run the `bin/main.dart` file:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ dart bin/main.dart
+cd myminipod/myminipod_server
+dart bin/main.dart
 ```
 
 Your default project comes with a sample Flutter app, all hooked up to talk with your server. Run it with the `flutter` command:
 
 ```bash
-$ cd myminipod/myminipod_flutter
-$ flutter run -d chrome
+cd myminipod/myminipod_flutter
+flutter run -d chrome
 ```
 
 Easy as that. 🥳
@@ -53,8 +53,8 @@ For types, you can use most basic Dart types, such as `String`, `double`, `int`,
 Whenever you add or edit a model file, run `serverpod generate` in your server directory. Then, Serverpod will generate all the updated Dart classes:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Adding methods to your server
@@ -90,8 +90,8 @@ class CompanyEndpoint extends Endpoint {
 After adding or modifying endpoints and endpoint methods, you must run `serverpod generate` to keep your Flutter app up-to-date.
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Calling the server methods from the app
diff --git a/versioned_docs/version-2.6.0/01-get-started/05-server-overview.md b/versioned_docs/version-2.6.0/01-get-started/05-server-overview.md
index 2c068b7e..df7982b6 100644
--- a/versioned_docs/version-2.6.0/01-get-started/05-server-overview.md
+++ b/versioned_docs/version-2.6.0/01-get-started/05-server-overview.md
@@ -15,6 +15,6 @@ Both the `endpoints` and `models` directories contain sample files that give a q
 Whenever you change your code in either the `endpoints` or `models` directory, you will need to regenerate the classes managed by Serverpod. Do this by running `serverpod generate`.
 
 ```bash
-$ cd mypod/mypod_server
-$ serverpod generate
+cd mypod/mypod_server
+serverpod generate
 ```
diff --git a/versioned_docs/version-2.6.0/01-get-started/08-working-with-database.md b/versioned_docs/version-2.6.0/01-get-started/08-working-with-database.md
index 8bcbead1..7d4a6128 100644
--- a/versioned_docs/version-2.6.0/01-get-started/08-working-with-database.md
+++ b/versioned_docs/version-2.6.0/01-get-started/08-working-with-database.md
@@ -28,15 +28,15 @@ development:
 With database migrations, Serverpod makes it easy to evolve your database schema. When you make changes to your project that should be reflected in your database, you need to create a migration. A migration is a set of SQL queries that are run to update the database. To create a migration, run `serverpod create-migration` in the home directory of the server.
 
 ```bash
-$ cd mypod/mypod_server
-$ serverpod create-migration
+cd mypod/mypod_server
+serverpod create-migration
 ```
 
 Migrations are then applied to the database as part of the server startup by adding the `--apply-migrations` flag.
 
 ```bash
-$ cd mypod/mypod_server
-$ dart bin/main.dart --apply-migrations
+cd mypod/mypod_server
+dart bin/main.dart --apply-migrations
 ```
 
 :::tip
diff --git a/versioned_docs/version-2.6.0/05-tutorials/01-first-app.mdx b/versioned_docs/version-2.6.0/05-tutorials/01-first-app.mdx
index 178ddca4..c6127fd1 100644
--- a/versioned_docs/version-2.6.0/05-tutorials/01-first-app.mdx
+++ b/versioned_docs/version-2.6.0/05-tutorials/01-first-app.mdx
@@ -31,15 +31,15 @@ Demo of what we will build: ([Full code example](https://github.com/serverpod/no
 Create a new project using the Serverpod CLI. Run the following command in your terminal:
 
 ```bash
-$ serverpod create notes
+serverpod create notes
 ```
 
 To start the server:
 
 ```bash
-$ cd notes/notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes/notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 :::info
@@ -71,7 +71,7 @@ Let's take a closer look at the content of the `note.yaml` file:
 Use the code generator to generate the code for the `Note` class from the definition in `note.yaml`. Run the following command from the root of your server project (`notes_server`):
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 After the code generation process is complete, you can access the generated code for the `Note` class in `lib/src/generated/note.dart` inside your Serverpod project.
@@ -100,7 +100,7 @@ fields:
 Run the code generator again to generate the necessary code used to access the database table:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 Take a look at the updated `lib/src/generated/note.dart` file. You will notice that the code generator has added new methods for interacting with the database. 
@@ -109,7 +109,7 @@ Take a look at the updated `lib/src/generated/note.dart` file. You will notice t
 To create the new `note` table in the database we will use the Serverpod migration system. Run the following command to generate a new database migration:
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 This creates a new migration that contains a description of the database schema and SQL code to add the table. These files can be found in the `migrations` directory in your server project (`notes_server`).
@@ -119,7 +119,7 @@ This creates a new migration that contains a description of the database schema
 To apply the database migration, start the server with the `--apply-migrations` command. We can also run the server in maintenance mode which will shut down the server as soon as its tasks are done.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 Once command has executed successfully, the database table for storing the note data will have been created.
@@ -239,7 +239,7 @@ Congratulations! You have now created all the endpoints needed for the notes app
 Now run the code generator again to generate the client library for our endpoints. This needs to be run from the server directory `notes_server`.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 You can find the newly generated code in the client directory `notes_client`. You normally don't need to touch this package, but it's good to know where it is located.
@@ -754,16 +754,16 @@ Start the database and server:
 Make sure you reboot the server if you started it earlier.
 
 ```bash
-$ cd notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 Start the Flutter app in Chrome (or the platform of your choice):
 
 ```bash
-$ cd notes_flutter
-$ flutter run -d chrome
+cd notes_flutter
+flutter run -d chrome
 ```
 
 <ReactPlayer playing={true} loop controls width="960px" height="720px" url='/img/tutorial/note-app/03-note-create.mp4' />
diff --git a/versioned_docs/version-2.6.0/06-concepts/06-database/01-connection.md b/versioned_docs/version-2.6.0/06-concepts/06-database/01-connection.md
index d19361fc..eef6182f 100644
--- a/versioned_docs/version-2.6.0/06-concepts/06-database/01-connection.md
+++ b/versioned_docs/version-2.6.0/06-concepts/06-database/01-connection.md
@@ -68,19 +68,19 @@ development:
 A newly created Serverpod project has a preconfigured Docker instance with a Postgres database set up. Run the following command from the root of the `server` package to start the database:
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To stop the database run:
 
 ```bash
-$ docker compose stop
+docker compose stop
 ```
 
 To remove the database and __delete__ all associated data, run:
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
 
 ## Connecting to a custom Postgres instance
diff --git a/versioned_docs/version-2.6.0/06-concepts/06-database/11-migrations.md b/versioned_docs/version-2.6.0/06-concepts/06-database/11-migrations.md
index c4e1891e..e0ededd7 100644
--- a/versioned_docs/version-2.6.0/06-concepts/06-database/11-migrations.md
+++ b/versioned_docs/version-2.6.0/06-concepts/06-database/11-migrations.md
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,7 +47,7 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
@@ -55,7 +55,7 @@ $ serverpod create-migration --force
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,7 +162,7 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
@@ -170,7 +170,7 @@ $ serverpod create-repair-migration --force
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
diff --git a/versioned_docs/version-2.6.0/06-concepts/10-modules.md b/versioned_docs/version-2.6.0/06-concepts/10-modules.md
index 3e4db07a..26732597 100644
--- a/versioned_docs/version-2.6.0/06-concepts/10-modules.md
+++ b/versioned_docs/version-2.6.0/06-concepts/10-modules.md
@@ -34,15 +34,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -80,13 +80,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.
diff --git a/versioned_docs/version-2.6.0/06-concepts/11-authentication/01-setup.md b/versioned_docs/version-2.6.0/06-concepts/11-authentication/01-setup.md
index 66c10d7d..2f54d7e2 100644
--- a/versioned_docs/version-2.6.0/06-concepts/11-authentication/01-setup.md
+++ b/versioned_docs/version-2.6.0/06-concepts/11-authentication/01-setup.md
@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
 Add the module as a dependency to the server project's `pubspec.yaml`.
 
 ```sh
-$ dart pub add serverpod_auth_server
+dart pub add serverpod_auth_server
 ```
 
 Add the authentication handler to the Serverpod instance.
@@ -45,7 +45,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
@@ -53,19 +53,19 @@ $ serverpod generate
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../database/migrations).
diff --git a/versioned_docs/version-2.6.0/06-concepts/11-authentication/04-providers/02-google.md b/versioned_docs/version-2.6.0/06-concepts/11-authentication/04-providers/02-google.md
index caa8b601..5ea95571 100644
--- a/versioned_docs/version-2.6.0/06-concepts/11-authentication/04-providers/02-google.md
+++ b/versioned_docs/version-2.6.0/06-concepts/11-authentication/04-providers/02-google.md
@@ -117,7 +117,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -134,7 +134,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::
diff --git a/versioned_docs/version-2.6.0/06-concepts/11-authentication/04-providers/05-firebase.md b/versioned_docs/version-2.6.0/06-concepts/11-authentication/04-providers/05-firebase.md
index 1816b20b..9dcb3766 100644
--- a/versioned_docs/version-2.6.0/06-concepts/11-authentication/04-providers/05-firebase.md
+++ b/versioned_docs/version-2.6.0/06-concepts/11-authentication/04-providers/05-firebase.md
@@ -29,8 +29,8 @@ To add authentication with Firebase, you must first install and initialize the F
 The short version:
 
 ```bash
-$ flutter pub add firebase_core firebase_auth firebase_ui_auth
-$ flutterfire configure
+flutter pub add firebase_core firebase_auth firebase_ui_auth
+flutterfire configure
 ```
 
 In the Firebase console, configure the different social sign-ins you plan to use, under `Authentication > Sign-in method`.
@@ -65,7 +65,7 @@ void main() async {
 Add the [serverpod_auth_firebase_flutter](https://pub.dev/packages/serverpod_auth_firebase_flutter) package.
 
 ```bash
-$ flutter pub add serverpod_auth_firebase_flutter
+flutter pub add serverpod_auth_firebase_flutter
 ```
 
 The `SignInWithFirebaseButton` is a convenient button that triggers the sign-in flow and can be used like this:
diff --git a/versioned_docs/version-2.6.0/06-concepts/12-file-uploads.md b/versioned_docs/version-2.6.0/06-concepts/12-file-uploads.md
index bbb788ab..b3439eba 100644
--- a/versioned_docs/version-2.6.0/06-concepts/12-file-uploads.md
+++ b/versioned_docs/version-2.6.0/06-concepts/12-file-uploads.md
@@ -98,7 +98,7 @@ You may also want to add the bucket as a backend for your load balancer to give
 When you have set up your GCP bucket, you need to configure it in Serverpod. Add the GCP package to your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_gcp
+dart pub add serverpod_cloud_storage_gcp
 ```
 
 ```dart
@@ -126,7 +126,7 @@ This section shows how to set up a storage using S3. Before you write your Dart
 When you are all set with the AWS setup, include the S3 package in your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_s3
+dart pub add serverpod_cloud_storage_s3
 ```
 
 ```dart
diff --git a/versioned_docs/version-2.6.0/06-concepts/21-experimental.md b/versioned_docs/version-2.6.0/06-concepts/21-experimental.md
index 6d1099bd..a5868a1f 100644
--- a/versioned_docs/version-2.6.0/06-concepts/21-experimental.md
+++ b/versioned_docs/version-2.6.0/06-concepts/21-experimental.md
@@ -21,7 +21,7 @@ If possible, the experimental API will remain for some time as `@deprecated`, an
 Some of the experimental features are enabled by including the `--experimental-features` flag when running the serverpod command:
 
 ```bash
-$ serverpod generate --experimental-features=all
+serverpod generate --experimental-features=all
 ```
 
 The current options you can pass are:
diff --git a/versioned_docs/version-2.6.0/07-deployments/02-deploying-to-gce-terraform.md b/versioned_docs/version-2.6.0/07-deployments/02-deploying-to-gce-terraform.md
index 3a2ac487..f55c21bd 100644
--- a/versioned_docs/version-2.6.0/07-deployments/02-deploying-to-gce-terraform.md
+++ b/versioned_docs/version-2.6.0/07-deployments/02-deploying-to-gce-terraform.md
@@ -126,7 +126,7 @@ Depending on your domain name registrar, the process for setting up your domain
 You can test that the domain points to the correct name servers by running `dig` on the command line. It will output the domain name servers.
 
 ```bash
-$ dig +short NS examplepod.com
+dig +short NS examplepod.com
 ```
 
 Should yield an output similar to this:
@@ -228,13 +228,13 @@ If you are deploying a staging server in addition to your production server, you
 Once you have configured Terraform and your Serverpod, you are ready to deploy your infrastructure. Make sure that you have `cd` into your `deploy/gcp/terraform_gce` directory. Now run:
 
 ```bash
-$ terraform init
+terraform init
 ```
 
 This will download the Serverpod module and initialize your Terraform configuration. Now, deploy your infrastructure by running:
 
 ```bash
-$ terraform apply
+terraform apply
 ```
 
 Terraform will ask you for the password to your production and staging database. You will find the passwords in your `config/passwords.yaml` file. If you are not deploying a staging server, you can leave the staging database password blank.
diff --git a/versioned_docs/version-2.6.0/07-deployments/03-deploying-to-gcr-console.md b/versioned_docs/version-2.6.0/07-deployments/03-deploying-to-gcr-console.md
index cdd5991d..b647215c 100644
--- a/versioned_docs/version-2.6.0/07-deployments/03-deploying-to-gcr-console.md
+++ b/versioned_docs/version-2.6.0/07-deployments/03-deploying-to-gcr-console.md
@@ -11,13 +11,13 @@ Before you begin, you will need to install and configure the Google Cloud CLI to
 - To [initialize](https://cloud.google.com/sdk/docs/initializing) the gcloud CLI, run the following command:
 
 ```bash
-$ gcloud init
+gcloud init
 ```
 
 - To set the default project for your Cloud Run service:
 
 ```bash
-$ gcloud config set project <PROJECT_ID>
+gcloud config set project <PROJECT_ID>
 ```
 
 ## Setup the database
@@ -75,8 +75,8 @@ database:
 Your server is now ready to be deployed. When you created your project, Serverpod also created a script for deploying your server. Copy it to the root of your server directory and make it executable. Make sure you are in your server directory (e.g., `myproject_server`). Then run the following command:
 
 ```bash
-$ cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
-$ chmod u+x cloud-run-deploy.sh
+cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
+chmod u+x cloud-run-deploy.sh
 ```
 
 Open up the script in your favorite editor. You will need to fill in your _database instance's connection name_ and the _email of your service account_.
@@ -84,7 +84,7 @@ Open up the script in your favorite editor. You will need to fill in your _datab
 Now, deploy your server by running the following:
 
 ```bash
-$ ./cloud-run-deploy.sh
+./cloud-run-deploy.sh
 ```
 
 The script runs two deployment commands, one for your API and one for the Insights API used by the Serverpod app. While running, it may ask you to enable the Cloud Run and SQL Admin services. Answer yes to all these questions.
diff --git a/versioned_docs/version-2.6.0/07-deployments/04-deploying-to-aws.md b/versioned_docs/version-2.6.0/07-deployments/04-deploying-to-aws.md
index af139474..713e4d4c 100644
--- a/versioned_docs/version-2.6.0/07-deployments/04-deploying-to-aws.md
+++ b/versioned_docs/version-2.6.0/07-deployments/04-deploying-to-aws.md
@@ -202,14 +202,14 @@ database:
 Your Serverpod should now be configured and ready to be deployed. Exciting times! Open up a terminal and `cd` into your server `aws/terraform` directory. First, you need to add an environment variable so that Terraform can correctly set the password for the Postgres database. You will find the production password for the database in your `config/passwords.yaml` file.
 
 ```bash
-$ export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
+export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
 ```
 
 Next, we are ready to initialize Terraform and deploy our server. You will only need to run the `terraform init` command the first time you deploy the configuration.
 
 ```bash
-$ terraform init
-$ terraform apply
+terraform init
+terraform apply
 ```
 
 Terraform will now run some checks and make a plan for the deployment. If everything looks good, it will ask you if you are ready to go ahead with the changes. Type `yes` and hit the return key. Applying the changes can take up to five minutes as AWS creates the different resources needed for your Serverpod.
diff --git a/versioned_docs/version-2.6.0/07-deployments/05-general.md b/versioned_docs/version-2.6.0/07-deployments/05-general.md
index bc27776c..bd4cd171 100644
--- a/versioned_docs/version-2.6.0/07-deployments/05-general.md
+++ b/versioned_docs/version-2.6.0/07-deployments/05-general.md
@@ -11,7 +11,7 @@ Serverpod will not run without a link to a Postgres database with the correct ta
 Serverpod has three main configuration files, depending on which mode the server is running; `development`, `staging`, or `production`. The files are located in the `config/` directory. By default, the server will start in development mode. To use another configuration file, use the `--mode` option when starting the server. If you are running multiple servers in a cluster, use the `--server-id` option to specify the id of each server. By default, the server will run as id `default`. For instance, to start the server in production mode with id `2`, run the following command:
 
 ```bash
-$ dart bin/main.dart --mode production --server-id 2
+dart bin/main.dart --mode production --server-id 2
 ```
 
 :::info
@@ -35,7 +35,7 @@ Serverpod can assume different roles depending on your configuration. If you run
 You can specify the role of your server when you launch it by setting the `--role` argument.
 
 ```bash
-$ dart bin/main.dart --role serverless
+dart bin/main.dart --role serverless
 ```
 
 ## Docker container
diff --git a/versioned_docs/version-2.6.0/08-upgrading/03-upgrade-to-two.md b/versioned_docs/version-2.6.0/08-upgrading/03-upgrade-to-two.md
index 54e3b54d..5ef0d80a 100644
--- a/versioned_docs/version-2.6.0/08-upgrading/03-upgrade-to-two.md
+++ b/versioned_docs/version-2.6.0/08-upgrading/03-upgrade-to-two.md
@@ -284,7 +284,7 @@ To ensure new databases are created with the new representation, the latest migr
 A new empty migration can be created by running the following command in the terminal:
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 #### Migration of existing tables
diff --git a/versioned_docs/version-2.6.0/09-tools/02-lsp.md b/versioned_docs/version-2.6.0/09-tools/02-lsp.md
index 2374cf57..8da02d1b 100644
--- a/versioned_docs/version-2.6.0/09-tools/02-lsp.md
+++ b/versioned_docs/version-2.6.0/09-tools/02-lsp.md
@@ -5,7 +5,7 @@ The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server
 To start the Serverpod LSP server, use the following command:
 
 ```bash
-$ serverpod language-server
+serverpod language-server
 ```
 
 :::info
diff --git a/versioned_docs/version-2.6.0/index.md b/versioned_docs/version-2.6.0/index.md
index e825cbee..16d80e7d 100644
--- a/versioned_docs/version-2.6.0/index.md
+++ b/versioned_docs/version-2.6.0/index.md
@@ -16,13 +16,13 @@ Serverpod is tested on Mac, Windows, and Linux. Before you can install Serverpod
 Install Serverpod by running:
 
 ```bash
-$ dart pub global activate serverpod_cli
+dart pub global activate serverpod_cli
 ```
 
 Now test the installation by running:
 
 ```bash
-$ serverpod
+serverpod
 ```
 
 If everything is correctly configured, the help for the `serverpod` command is now displayed.
diff --git a/versioned_docs/version-2.7.0/01-get-started/01-creating-endpoints.md b/versioned_docs/version-2.7.0/01-get-started/01-creating-endpoints.md
index 78f18f3d..4e3815e5 100644
--- a/versioned_docs/version-2.7.0/01-get-started/01-creating-endpoints.md
+++ b/versioned_docs/version-2.7.0/01-get-started/01-creating-endpoints.md
@@ -38,8 +38,8 @@ development:
 Next, we add Google's Gemini package as a dependency to our server.
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ dart pub add google_generative_ai
+cd magic_recipe/magic_recipe_server
+dart pub add google_generative_ai
 ```
 
 ## Create a new endpoint
@@ -98,8 +98,8 @@ For methods to be generated, they need to return a typed `Future`, where the typ
 Now, you need to generate the code for your new endpoint. You do this by running `serverpod generate` in the server directory of your project:
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ serverpod generate
+cd magic_recipe/magic_recipe_server
+serverpod generate
 ```
 
 `serverpod generate` will create bindings for the endpoint and register them in the server's `generated/protocol.dart` file. It will also generate the required client code so that you can call your new `generateRecipe` method from your app.
@@ -203,16 +203,16 @@ Before you start your server, ensure no other Serverpod server is running. Also,
 Let's try our new recipe app! First, start the server:
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart --apply-migrations
+cd magic_recipe/magic_recipe_server
+docker compose up -d
+dart bin/main.dart --apply-migrations
 ```
 
 Now, you can start the Flutter app:
 
 ```bash
-$ cd magic_recipe/magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe/magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser:
diff --git a/versioned_docs/version-2.7.0/01-get-started/02-models-and-data.md b/versioned_docs/version-2.7.0/01-get-started/02-models-and-data.md
index 792f1e24..b363a0d3 100644
--- a/versioned_docs/version-2.7.0/01-get-started/02-models-and-data.md
+++ b/versioned_docs/version-2.7.0/01-get-started/02-models-and-data.md
@@ -33,8 +33,8 @@ You can use most primitive Dart types here or any other models you have specifie
 To generate the code for the model, run the `serverpod generate` command in your server directory:
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ serverpod generate
+cd magic_recipe/magic_recipe_server
+serverpod generate
 ```
 
 This will generate the code for the model and create a new file called `recipe.dart` in the `lib/src/generated` directory. It will also update the client code in `magic_recipe/magic_recipe_client` so you can use it in your Flutter app.
@@ -131,8 +131,8 @@ class RecipeEndpoint extends Endpoint {
 First, we need to update our generated client by running `serverpod generate`.
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ serverpod generate
+cd magic_recipe/magic_recipe_server
+serverpod generate
 ```
 
 Now that we have created the `Recipe` model we can use it in the client. We will do this in the `magic_recipe/magic_recipe_flutter/lib/main.dart` file. Let's update our `RecipeWidget` so that it displays the author and year of the recipe in addition to the recipe itself.
@@ -290,16 +290,16 @@ class MyHomePageState extends State<MyHomePage> {
 First, start the server:
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart
+cd magic_recipe/magic_recipe_server
+docker compose up -d
+dart bin/main.dart
 ```
 
 Then, start the Flutter app:
 
 ```bash
-$ cd magic_recipe/magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe/magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look something like this:
diff --git a/versioned_docs/version-2.7.0/01-get-started/03-working-with-the-database.md b/versioned_docs/version-2.7.0/01-get-started/03-working-with-the-database.md
index 5a1f38d4..ba1d1e11 100644
--- a/versioned_docs/version-2.7.0/01-get-started/03-working-with-the-database.md
+++ b/versioned_docs/version-2.7.0/01-get-started/03-working-with-the-database.md
@@ -36,9 +36,9 @@ Check out the reference for [database models](../06-concepts/02-models.md#keywor
 With database migrations, Serverpod makes it easy to evolve your database schema. When you make changes to your project that should be reflected in your database, you need to create a migration. A migration is a set of SQL queries that are run to update the database. To create a migration, run `serverpod create-migration` in the home directory of the server. Since we modified one of our models, make sure to also run `serverpod generate`, to update the generated code in our server.
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ serverpod generate
-$ serverpod create-migration
+cd magic_recipe/magic_recipe_server
+serverpod generate
+serverpod create-migration
 ```
 
 You will notice that there will be a new entry in your _migrations_ folder - serverpod creates these migrations "step by step" - each time you have changes which are relevant to the database and run `serverpod create-migrations` a new migration file will be created. This is a good way to keep track of the changes you make to the database and to be able to roll back changes if needed.
@@ -180,8 +180,8 @@ The `insertRow` method is used to insert a new row in the database. The `find` m
 Like before, when you change something that has an effect on the client code, you need to run `serverpod generate`. We don't need to run `serverpod create-migrations` again because we already created a migration in the previous step and haven't done any changes that affect the database.
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ serverpod generate
+cd magic_recipe/magic_recipe_server
+serverpod generate
 ```
 
 ## Call the endpoint from the app
@@ -421,9 +421,9 @@ class ResultDisplay extends StatelessWidget {
 First, we need to start the server and apply the migrations by adding the `--apply-migrations` flag:
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart --apply-migrations
+cd magic_recipe/magic_recipe_server
+docker compose up -d
+dart bin/main.dart --apply-migrations
 ```
 
 :::tip
@@ -432,8 +432,8 @@ When developing your server, it's always safe to pass the `--apply-migrations` f
 Now, start the Flutter app:
 
 ```bash
-$ cd magic_recipe/magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe/magic_recipe_flutter
+flutter run -d chrome
 ```
 
 ## Summary
diff --git a/versioned_docs/version-2.7.0/05-tutorials/01-first-app.mdx b/versioned_docs/version-2.7.0/05-tutorials/01-first-app.mdx
index 4ef0407b..c97b444d 100644
--- a/versioned_docs/version-2.7.0/05-tutorials/01-first-app.mdx
+++ b/versioned_docs/version-2.7.0/05-tutorials/01-first-app.mdx
@@ -31,15 +31,15 @@ Demo of what we will build: ([Full code example](https://github.com/serverpod/no
 Create a new project using the Serverpod CLI. Run the following command in your terminal:
 
 ```bash
-$ serverpod create notes
+serverpod create notes
 ```
 
 To start the server:
 
 ```bash
-$ cd notes/notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes/notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 :::info
@@ -71,7 +71,7 @@ Let's take a closer look at the content of the `note.yaml` file:
 Use the code generator to generate the code for the `Note` class from the definition in `note.yaml`. Run the following command from the root of your server project (`notes_server`):
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 After the code generation process is complete, you can access the generated code for the `Note` class in `lib/src/generated/note.dart` inside your Serverpod project.
@@ -100,7 +100,7 @@ fields:
 Run the code generator again to generate the necessary code used to access the database table:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 Take a look at the updated `lib/src/generated/note.dart` file. You will notice that the code generator has added new methods for interacting with the database. 
@@ -109,7 +109,7 @@ Take a look at the updated `lib/src/generated/note.dart` file. You will notice t
 To create the new `note` table in the database we will use the Serverpod migration system. Run the following command to generate a new database migration:
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 This creates a new migration that contains a description of the database schema and SQL code to add the table. These files can be found in the `migrations` directory in your server project (`notes_server`).
@@ -119,7 +119,7 @@ This creates a new migration that contains a description of the database schema
 To apply the database migration, start the server with the `--apply-migrations` command. We can also run the server in maintenance mode which will shut down the server as soon as its tasks are done.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 Once command has executed successfully, the database table for storing the note data will have been created.
@@ -239,7 +239,7 @@ Congratulations! You have now created all the endpoints needed for the notes app
 Now run the code generator again to generate the client library for our endpoints. This needs to be run from the server directory `notes_server`.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 You can find the newly generated code in the client directory `notes_client`. You normally don't need to touch this package, but it's good to know where it is located.
@@ -754,16 +754,16 @@ Start the database and server:
 Make sure you reboot the server if you started it earlier.
 
 ```bash
-$ cd notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 Start the Flutter app in Chrome (or the platform of your choice):
 
 ```bash
-$ cd notes_flutter
-$ flutter run -d chrome
+cd notes_flutter
+flutter run -d chrome
 ```
 
 <ReactPlayer playing={true} loop controls width="960px" height="720px" url='/img/tutorial/note-app/03-note-create.mp4' />
diff --git a/versioned_docs/version-2.7.0/06-concepts/06-database/01-connection.md b/versioned_docs/version-2.7.0/06-concepts/06-database/01-connection.md
index d19361fc..eef6182f 100644
--- a/versioned_docs/version-2.7.0/06-concepts/06-database/01-connection.md
+++ b/versioned_docs/version-2.7.0/06-concepts/06-database/01-connection.md
@@ -68,19 +68,19 @@ development:
 A newly created Serverpod project has a preconfigured Docker instance with a Postgres database set up. Run the following command from the root of the `server` package to start the database:
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To stop the database run:
 
 ```bash
-$ docker compose stop
+docker compose stop
 ```
 
 To remove the database and __delete__ all associated data, run:
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
 
 ## Connecting to a custom Postgres instance
diff --git a/versioned_docs/version-2.7.0/06-concepts/06-database/11-migrations.md b/versioned_docs/version-2.7.0/06-concepts/06-database/11-migrations.md
index c4e1891e..e0ededd7 100644
--- a/versioned_docs/version-2.7.0/06-concepts/06-database/11-migrations.md
+++ b/versioned_docs/version-2.7.0/06-concepts/06-database/11-migrations.md
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,7 +47,7 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
@@ -55,7 +55,7 @@ $ serverpod create-migration --force
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,7 +162,7 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
@@ -170,7 +170,7 @@ $ serverpod create-repair-migration --force
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
diff --git a/versioned_docs/version-2.7.0/06-concepts/10-modules.md b/versioned_docs/version-2.7.0/06-concepts/10-modules.md
index 3e4db07a..26732597 100644
--- a/versioned_docs/version-2.7.0/06-concepts/10-modules.md
+++ b/versioned_docs/version-2.7.0/06-concepts/10-modules.md
@@ -34,15 +34,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -80,13 +80,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.
diff --git a/versioned_docs/version-2.7.0/06-concepts/11-authentication/01-setup.md b/versioned_docs/version-2.7.0/06-concepts/11-authentication/01-setup.md
index 66c10d7d..2f54d7e2 100644
--- a/versioned_docs/version-2.7.0/06-concepts/11-authentication/01-setup.md
+++ b/versioned_docs/version-2.7.0/06-concepts/11-authentication/01-setup.md
@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
 Add the module as a dependency to the server project's `pubspec.yaml`.
 
 ```sh
-$ dart pub add serverpod_auth_server
+dart pub add serverpod_auth_server
 ```
 
 Add the authentication handler to the Serverpod instance.
@@ -45,7 +45,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
@@ -53,19 +53,19 @@ $ serverpod generate
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../database/migrations).
diff --git a/versioned_docs/version-2.7.0/06-concepts/11-authentication/04-providers/02-google.md b/versioned_docs/version-2.7.0/06-concepts/11-authentication/04-providers/02-google.md
index caa8b601..5ea95571 100644
--- a/versioned_docs/version-2.7.0/06-concepts/11-authentication/04-providers/02-google.md
+++ b/versioned_docs/version-2.7.0/06-concepts/11-authentication/04-providers/02-google.md
@@ -117,7 +117,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -134,7 +134,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::
diff --git a/versioned_docs/version-2.7.0/06-concepts/11-authentication/04-providers/05-firebase.md b/versioned_docs/version-2.7.0/06-concepts/11-authentication/04-providers/05-firebase.md
index 1816b20b..9dcb3766 100644
--- a/versioned_docs/version-2.7.0/06-concepts/11-authentication/04-providers/05-firebase.md
+++ b/versioned_docs/version-2.7.0/06-concepts/11-authentication/04-providers/05-firebase.md
@@ -29,8 +29,8 @@ To add authentication with Firebase, you must first install and initialize the F
 The short version:
 
 ```bash
-$ flutter pub add firebase_core firebase_auth firebase_ui_auth
-$ flutterfire configure
+flutter pub add firebase_core firebase_auth firebase_ui_auth
+flutterfire configure
 ```
 
 In the Firebase console, configure the different social sign-ins you plan to use, under `Authentication > Sign-in method`.
@@ -65,7 +65,7 @@ void main() async {
 Add the [serverpod_auth_firebase_flutter](https://pub.dev/packages/serverpod_auth_firebase_flutter) package.
 
 ```bash
-$ flutter pub add serverpod_auth_firebase_flutter
+flutter pub add serverpod_auth_firebase_flutter
 ```
 
 The `SignInWithFirebaseButton` is a convenient button that triggers the sign-in flow and can be used like this:
diff --git a/versioned_docs/version-2.7.0/06-concepts/12-file-uploads.md b/versioned_docs/version-2.7.0/06-concepts/12-file-uploads.md
index bbb788ab..b3439eba 100644
--- a/versioned_docs/version-2.7.0/06-concepts/12-file-uploads.md
+++ b/versioned_docs/version-2.7.0/06-concepts/12-file-uploads.md
@@ -98,7 +98,7 @@ You may also want to add the bucket as a backend for your load balancer to give
 When you have set up your GCP bucket, you need to configure it in Serverpod. Add the GCP package to your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_gcp
+dart pub add serverpod_cloud_storage_gcp
 ```
 
 ```dart
@@ -126,7 +126,7 @@ This section shows how to set up a storage using S3. Before you write your Dart
 When you are all set with the AWS setup, include the S3 package in your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_s3
+dart pub add serverpod_cloud_storage_s3
 ```
 
 ```dart
diff --git a/versioned_docs/version-2.7.0/06-concepts/21-experimental.md b/versioned_docs/version-2.7.0/06-concepts/21-experimental.md
index 6d1099bd..a5868a1f 100644
--- a/versioned_docs/version-2.7.0/06-concepts/21-experimental.md
+++ b/versioned_docs/version-2.7.0/06-concepts/21-experimental.md
@@ -21,7 +21,7 @@ If possible, the experimental API will remain for some time as `@deprecated`, an
 Some of the experimental features are enabled by including the `--experimental-features` flag when running the serverpod command:
 
 ```bash
-$ serverpod generate --experimental-features=all
+serverpod generate --experimental-features=all
 ```
 
 The current options you can pass are:
diff --git a/versioned_docs/version-2.7.0/07-deployments/02-deploying-to-gce-terraform.md b/versioned_docs/version-2.7.0/07-deployments/02-deploying-to-gce-terraform.md
index 3a2ac487..f55c21bd 100644
--- a/versioned_docs/version-2.7.0/07-deployments/02-deploying-to-gce-terraform.md
+++ b/versioned_docs/version-2.7.0/07-deployments/02-deploying-to-gce-terraform.md
@@ -126,7 +126,7 @@ Depending on your domain name registrar, the process for setting up your domain
 You can test that the domain points to the correct name servers by running `dig` on the command line. It will output the domain name servers.
 
 ```bash
-$ dig +short NS examplepod.com
+dig +short NS examplepod.com
 ```
 
 Should yield an output similar to this:
@@ -228,13 +228,13 @@ If you are deploying a staging server in addition to your production server, you
 Once you have configured Terraform and your Serverpod, you are ready to deploy your infrastructure. Make sure that you have `cd` into your `deploy/gcp/terraform_gce` directory. Now run:
 
 ```bash
-$ terraform init
+terraform init
 ```
 
 This will download the Serverpod module and initialize your Terraform configuration. Now, deploy your infrastructure by running:
 
 ```bash
-$ terraform apply
+terraform apply
 ```
 
 Terraform will ask you for the password to your production and staging database. You will find the passwords in your `config/passwords.yaml` file. If you are not deploying a staging server, you can leave the staging database password blank.
diff --git a/versioned_docs/version-2.7.0/07-deployments/03-deploying-to-gcr-console.md b/versioned_docs/version-2.7.0/07-deployments/03-deploying-to-gcr-console.md
index cdd5991d..b647215c 100644
--- a/versioned_docs/version-2.7.0/07-deployments/03-deploying-to-gcr-console.md
+++ b/versioned_docs/version-2.7.0/07-deployments/03-deploying-to-gcr-console.md
@@ -11,13 +11,13 @@ Before you begin, you will need to install and configure the Google Cloud CLI to
 - To [initialize](https://cloud.google.com/sdk/docs/initializing) the gcloud CLI, run the following command:
 
 ```bash
-$ gcloud init
+gcloud init
 ```
 
 - To set the default project for your Cloud Run service:
 
 ```bash
-$ gcloud config set project <PROJECT_ID>
+gcloud config set project <PROJECT_ID>
 ```
 
 ## Setup the database
@@ -75,8 +75,8 @@ database:
 Your server is now ready to be deployed. When you created your project, Serverpod also created a script for deploying your server. Copy it to the root of your server directory and make it executable. Make sure you are in your server directory (e.g., `myproject_server`). Then run the following command:
 
 ```bash
-$ cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
-$ chmod u+x cloud-run-deploy.sh
+cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
+chmod u+x cloud-run-deploy.sh
 ```
 
 Open up the script in your favorite editor. You will need to fill in your _database instance's connection name_ and the _email of your service account_.
@@ -84,7 +84,7 @@ Open up the script in your favorite editor. You will need to fill in your _datab
 Now, deploy your server by running the following:
 
 ```bash
-$ ./cloud-run-deploy.sh
+./cloud-run-deploy.sh
 ```
 
 The script runs two deployment commands, one for your API and one for the Insights API used by the Serverpod app. While running, it may ask you to enable the Cloud Run and SQL Admin services. Answer yes to all these questions.
diff --git a/versioned_docs/version-2.7.0/07-deployments/04-deploying-to-aws.md b/versioned_docs/version-2.7.0/07-deployments/04-deploying-to-aws.md
index af139474..713e4d4c 100644
--- a/versioned_docs/version-2.7.0/07-deployments/04-deploying-to-aws.md
+++ b/versioned_docs/version-2.7.0/07-deployments/04-deploying-to-aws.md
@@ -202,14 +202,14 @@ database:
 Your Serverpod should now be configured and ready to be deployed. Exciting times! Open up a terminal and `cd` into your server `aws/terraform` directory. First, you need to add an environment variable so that Terraform can correctly set the password for the Postgres database. You will find the production password for the database in your `config/passwords.yaml` file.
 
 ```bash
-$ export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
+export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
 ```
 
 Next, we are ready to initialize Terraform and deploy our server. You will only need to run the `terraform init` command the first time you deploy the configuration.
 
 ```bash
-$ terraform init
-$ terraform apply
+terraform init
+terraform apply
 ```
 
 Terraform will now run some checks and make a plan for the deployment. If everything looks good, it will ask you if you are ready to go ahead with the changes. Type `yes` and hit the return key. Applying the changes can take up to five minutes as AWS creates the different resources needed for your Serverpod.
diff --git a/versioned_docs/version-2.7.0/07-deployments/05-general.md b/versioned_docs/version-2.7.0/07-deployments/05-general.md
index bc27776c..bd4cd171 100644
--- a/versioned_docs/version-2.7.0/07-deployments/05-general.md
+++ b/versioned_docs/version-2.7.0/07-deployments/05-general.md
@@ -11,7 +11,7 @@ Serverpod will not run without a link to a Postgres database with the correct ta
 Serverpod has three main configuration files, depending on which mode the server is running; `development`, `staging`, or `production`. The files are located in the `config/` directory. By default, the server will start in development mode. To use another configuration file, use the `--mode` option when starting the server. If you are running multiple servers in a cluster, use the `--server-id` option to specify the id of each server. By default, the server will run as id `default`. For instance, to start the server in production mode with id `2`, run the following command:
 
 ```bash
-$ dart bin/main.dart --mode production --server-id 2
+dart bin/main.dart --mode production --server-id 2
 ```
 
 :::info
@@ -35,7 +35,7 @@ Serverpod can assume different roles depending on your configuration. If you run
 You can specify the role of your server when you launch it by setting the `--role` argument.
 
 ```bash
-$ dart bin/main.dart --role serverless
+dart bin/main.dart --role serverless
 ```
 
 ## Docker container
diff --git a/versioned_docs/version-2.7.0/08-upgrading/03-upgrade-to-two.md b/versioned_docs/version-2.7.0/08-upgrading/03-upgrade-to-two.md
index 54e3b54d..5ef0d80a 100644
--- a/versioned_docs/version-2.7.0/08-upgrading/03-upgrade-to-two.md
+++ b/versioned_docs/version-2.7.0/08-upgrading/03-upgrade-to-two.md
@@ -284,7 +284,7 @@ To ensure new databases are created with the new representation, the latest migr
 A new empty migration can be created by running the following command in the terminal:
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 #### Migration of existing tables
diff --git a/versioned_docs/version-2.7.0/09-tools/02-lsp.md b/versioned_docs/version-2.7.0/09-tools/02-lsp.md
index 2374cf57..8da02d1b 100644
--- a/versioned_docs/version-2.7.0/09-tools/02-lsp.md
+++ b/versioned_docs/version-2.7.0/09-tools/02-lsp.md
@@ -5,7 +5,7 @@ The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server
 To start the Serverpod LSP server, use the following command:
 
 ```bash
-$ serverpod language-server
+serverpod language-server
 ```
 
 :::info
diff --git a/versioned_docs/version-2.7.0/index.md b/versioned_docs/version-2.7.0/index.md
index 629426bf..ea2956fd 100644
--- a/versioned_docs/version-2.7.0/index.md
+++ b/versioned_docs/version-2.7.0/index.md
@@ -61,7 +61,7 @@ Serverpod is tested on Mac, Windows, and Linux. Before you can install Serverpod
 Check your Flutter installation by running the following command in your terminal:
 
 ```bash
-$ flutter doctor
+flutter doctor
 ```
 
 :::
@@ -72,7 +72,7 @@ To make use of Serverpod's database connectivity, you need to have access to a P
 Check your Docker installation by running the following command in your terminal:
 
 ```bash
-$ docker info
+docker info
 ```
 
 If you are using Docker Desktop and you are getting an error, make sure that Docker is running. You can check this by looking for the Docker icon in your system tray or taskbar. If it's not running, start Docker Desktop and try again.
@@ -83,13 +83,13 @@ If you are using Docker Desktop and you are getting an error, make sure that Doc
 Serverpod is installed using the Dart package manager. To install Serverpod, run the following command in your terminal:
 
 ```bash
-$ dart pub global activate serverpod_cli
+dart pub global activate serverpod_cli
 ```
 
 This command will install the Serverpod command-line interface (CLI) globally on your machine. You can verify the installation by running:
 
 ```bash
-$ serverpod
+serverpod
 ```
 
 If everything is correctly configured, the help for the `serverpod` command is now displayed.
@@ -112,7 +112,7 @@ To create a new Serverpod project, use the `serverpod create` command. It will s
 The project will be created in a new directory with the name you specify. For example, to create a new project called `my_project`, run the following command:
 
 ```bash
-$ serverpod create my_project
+serverpod create my_project
 ```
 
 :::tip
@@ -122,20 +122,20 @@ The name of the project must be a valid Dart package name. It should start with
 To run your new project you must first start the database from the Docker file that is included with the project. Do this by running the `docker compose up` command in the server directory:
 
 ```bash
-$ cd my_project/my_project_server
-$ docker compose up
+cd my_project/my_project_server
+docker compose up
 ```
 
 This will start the PostgreSQL database. You can stop the database server by pressing `Ctrl+C` in the terminal. If you want to run the servers in the background, you can use the `-d` flag:
 
 ```bash
-$ docker compose up -d
+docker compose up -d
 ```
 
 This will start the database server in detached mode, meaning it will run in the background and you can safely close the terminal window without stopping it. Stop the database container by running the following command from the server directory:
 
 ```bash
-$ docker compose down
+docker compose down
 ```
 
 :::tip
@@ -145,8 +145,8 @@ If you are using Docker Desktop, you can see and manage all your installed Docke
 Now that the database is up and running we can start the Serverpod server. Because we are running the project for the first time, we need create the database tables used by Serverpod. This is done through a [database migration](./06-concepts/06-database/11-migrations.md). An initial migration is already created for us, so all we need to do is to pass the `--apply-migrations` flag to our server when we start it:
 
 ```bash
-$ cd my_project/my_project_server
-$ dart run bin/main.dart --apply-migrations
+cd my_project/my_project_server
+dart run bin/main.dart --apply-migrations
 ```
 
 This will start the server and set up the initial database tables. You can now access the server at `http://localhost:8080` and the web server is available at `http://localhost:8082`. It should look like this:
@@ -156,8 +156,8 @@ This will start the server and set up the initial database tables. You can now a
 Now let's run our Flutter app. You can do this by running `flutter run -d chrome` in the flutter directory:
 
 ```bash
-$ cd my_project/my_project_flutter
-$ flutter run -d chrome
+cd my_project/my_project_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look like this:
diff --git a/versioned_docs/version-2.7.0/serverpod-mini.md b/versioned_docs/version-2.7.0/serverpod-mini.md
index 6d591460..f9279171 100644
--- a/versioned_docs/version-2.7.0/serverpod-mini.md
+++ b/versioned_docs/version-2.7.0/serverpod-mini.md
@@ -35,7 +35,7 @@ Serverpod Mini is a lightweight version of Serverpod that is perfect for small p
 Create a mini project by running:
 
 ```bash
-$ serverpod create myminipod --mini
+serverpod create myminipod --mini
 ```
 
 Serverpod will create a new project for you. It contains three Dart packages, but you only need to pay attention to the `myminipod_server` and `myminipod_flutter` directories. The server directory contains your server files, and the flutter directory contains your app. The third package (`myminipod_client`) contains generated code that is used by the Flutter app to communicate with the server.
@@ -43,15 +43,15 @@ Serverpod will create a new project for you. It contains three Dart packages, bu
 Start your server by changing directory into your server directory, and run the `bin/main.dart` file:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ dart bin/main.dart
+cd myminipod/myminipod_server
+dart bin/main.dart
 ```
 
 Your default project comes with a sample Flutter app, all hooked up to talk with your server. Run it with the `flutter` command:
 
 ```bash
-$ cd myminipod/myminipod_flutter
-$ flutter run -d chrome
+cd myminipod/myminipod_flutter
+flutter run -d chrome
 ```
 
 Easy as that. 🥳
@@ -79,8 +79,8 @@ For types, you can use most basic Dart types, such as `String`, `double`, `int`,
 Whenever you add or edit a model file, run `serverpod generate` in your server directory. Then, Serverpod will generate all the updated Dart classes:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Adding methods to your server
@@ -116,8 +116,8 @@ class CompanyEndpoint extends Endpoint {
 After adding or modifying endpoints and endpoint methods, you must run `serverpod generate` to keep your Flutter app up-to-date.
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Calling the server methods from the app
diff --git a/versioned_docs/version-2.8.0/01-get-started/01-creating-endpoints.md b/versioned_docs/version-2.8.0/01-get-started/01-creating-endpoints.md
index 78f18f3d..4e3815e5 100644
--- a/versioned_docs/version-2.8.0/01-get-started/01-creating-endpoints.md
+++ b/versioned_docs/version-2.8.0/01-get-started/01-creating-endpoints.md
@@ -38,8 +38,8 @@ development:
 Next, we add Google's Gemini package as a dependency to our server.
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ dart pub add google_generative_ai
+cd magic_recipe/magic_recipe_server
+dart pub add google_generative_ai
 ```
 
 ## Create a new endpoint
@@ -98,8 +98,8 @@ For methods to be generated, they need to return a typed `Future`, where the typ
 Now, you need to generate the code for your new endpoint. You do this by running `serverpod generate` in the server directory of your project:
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ serverpod generate
+cd magic_recipe/magic_recipe_server
+serverpod generate
 ```
 
 `serverpod generate` will create bindings for the endpoint and register them in the server's `generated/protocol.dart` file. It will also generate the required client code so that you can call your new `generateRecipe` method from your app.
@@ -203,16 +203,16 @@ Before you start your server, ensure no other Serverpod server is running. Also,
 Let's try our new recipe app! First, start the server:
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart --apply-migrations
+cd magic_recipe/magic_recipe_server
+docker compose up -d
+dart bin/main.dart --apply-migrations
 ```
 
 Now, you can start the Flutter app:
 
 ```bash
-$ cd magic_recipe/magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe/magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser:
diff --git a/versioned_docs/version-2.8.0/01-get-started/02-models-and-data.md b/versioned_docs/version-2.8.0/01-get-started/02-models-and-data.md
index 792f1e24..b363a0d3 100644
--- a/versioned_docs/version-2.8.0/01-get-started/02-models-and-data.md
+++ b/versioned_docs/version-2.8.0/01-get-started/02-models-and-data.md
@@ -33,8 +33,8 @@ You can use most primitive Dart types here or any other models you have specifie
 To generate the code for the model, run the `serverpod generate` command in your server directory:
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ serverpod generate
+cd magic_recipe/magic_recipe_server
+serverpod generate
 ```
 
 This will generate the code for the model and create a new file called `recipe.dart` in the `lib/src/generated` directory. It will also update the client code in `magic_recipe/magic_recipe_client` so you can use it in your Flutter app.
@@ -131,8 +131,8 @@ class RecipeEndpoint extends Endpoint {
 First, we need to update our generated client by running `serverpod generate`.
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ serverpod generate
+cd magic_recipe/magic_recipe_server
+serverpod generate
 ```
 
 Now that we have created the `Recipe` model we can use it in the client. We will do this in the `magic_recipe/magic_recipe_flutter/lib/main.dart` file. Let's update our `RecipeWidget` so that it displays the author and year of the recipe in addition to the recipe itself.
@@ -290,16 +290,16 @@ class MyHomePageState extends State<MyHomePage> {
 First, start the server:
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart
+cd magic_recipe/magic_recipe_server
+docker compose up -d
+dart bin/main.dart
 ```
 
 Then, start the Flutter app:
 
 ```bash
-$ cd magic_recipe/magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe/magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look something like this:
diff --git a/versioned_docs/version-2.8.0/01-get-started/03-working-with-the-database.md b/versioned_docs/version-2.8.0/01-get-started/03-working-with-the-database.md
index 5a1f38d4..ba1d1e11 100644
--- a/versioned_docs/version-2.8.0/01-get-started/03-working-with-the-database.md
+++ b/versioned_docs/version-2.8.0/01-get-started/03-working-with-the-database.md
@@ -36,9 +36,9 @@ Check out the reference for [database models](../06-concepts/02-models.md#keywor
 With database migrations, Serverpod makes it easy to evolve your database schema. When you make changes to your project that should be reflected in your database, you need to create a migration. A migration is a set of SQL queries that are run to update the database. To create a migration, run `serverpod create-migration` in the home directory of the server. Since we modified one of our models, make sure to also run `serverpod generate`, to update the generated code in our server.
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ serverpod generate
-$ serverpod create-migration
+cd magic_recipe/magic_recipe_server
+serverpod generate
+serverpod create-migration
 ```
 
 You will notice that there will be a new entry in your _migrations_ folder - serverpod creates these migrations "step by step" - each time you have changes which are relevant to the database and run `serverpod create-migrations` a new migration file will be created. This is a good way to keep track of the changes you make to the database and to be able to roll back changes if needed.
@@ -180,8 +180,8 @@ The `insertRow` method is used to insert a new row in the database. The `find` m
 Like before, when you change something that has an effect on the client code, you need to run `serverpod generate`. We don't need to run `serverpod create-migrations` again because we already created a migration in the previous step and haven't done any changes that affect the database.
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ serverpod generate
+cd magic_recipe/magic_recipe_server
+serverpod generate
 ```
 
 ## Call the endpoint from the app
@@ -421,9 +421,9 @@ class ResultDisplay extends StatelessWidget {
 First, we need to start the server and apply the migrations by adding the `--apply-migrations` flag:
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart --apply-migrations
+cd magic_recipe/magic_recipe_server
+docker compose up -d
+dart bin/main.dart --apply-migrations
 ```
 
 :::tip
@@ -432,8 +432,8 @@ When developing your server, it's always safe to pass the `--apply-migrations` f
 Now, start the Flutter app:
 
 ```bash
-$ cd magic_recipe/magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe/magic_recipe_flutter
+flutter run -d chrome
 ```
 
 ## Summary
diff --git a/versioned_docs/version-2.8.0/05-tutorials/01-first-app.mdx b/versioned_docs/version-2.8.0/05-tutorials/01-first-app.mdx
index 4ef0407b..c97b444d 100644
--- a/versioned_docs/version-2.8.0/05-tutorials/01-first-app.mdx
+++ b/versioned_docs/version-2.8.0/05-tutorials/01-first-app.mdx
@@ -31,15 +31,15 @@ Demo of what we will build: ([Full code example](https://github.com/serverpod/no
 Create a new project using the Serverpod CLI. Run the following command in your terminal:
 
 ```bash
-$ serverpod create notes
+serverpod create notes
 ```
 
 To start the server:
 
 ```bash
-$ cd notes/notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes/notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 :::info
@@ -71,7 +71,7 @@ Let's take a closer look at the content of the `note.yaml` file:
 Use the code generator to generate the code for the `Note` class from the definition in `note.yaml`. Run the following command from the root of your server project (`notes_server`):
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 After the code generation process is complete, you can access the generated code for the `Note` class in `lib/src/generated/note.dart` inside your Serverpod project.
@@ -100,7 +100,7 @@ fields:
 Run the code generator again to generate the necessary code used to access the database table:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 Take a look at the updated `lib/src/generated/note.dart` file. You will notice that the code generator has added new methods for interacting with the database. 
@@ -109,7 +109,7 @@ Take a look at the updated `lib/src/generated/note.dart` file. You will notice t
 To create the new `note` table in the database we will use the Serverpod migration system. Run the following command to generate a new database migration:
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 This creates a new migration that contains a description of the database schema and SQL code to add the table. These files can be found in the `migrations` directory in your server project (`notes_server`).
@@ -119,7 +119,7 @@ This creates a new migration that contains a description of the database schema
 To apply the database migration, start the server with the `--apply-migrations` command. We can also run the server in maintenance mode which will shut down the server as soon as its tasks are done.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 Once command has executed successfully, the database table for storing the note data will have been created.
@@ -239,7 +239,7 @@ Congratulations! You have now created all the endpoints needed for the notes app
 Now run the code generator again to generate the client library for our endpoints. This needs to be run from the server directory `notes_server`.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 You can find the newly generated code in the client directory `notes_client`. You normally don't need to touch this package, but it's good to know where it is located.
@@ -754,16 +754,16 @@ Start the database and server:
 Make sure you reboot the server if you started it earlier.
 
 ```bash
-$ cd notes_server
-$ docker compose up --build --detach
-$ dart bin/main.dart --apply-migrations
+cd notes_server
+docker compose up --build --detach
+dart bin/main.dart --apply-migrations
 ```
 
 Start the Flutter app in Chrome (or the platform of your choice):
 
 ```bash
-$ cd notes_flutter
-$ flutter run -d chrome
+cd notes_flutter
+flutter run -d chrome
 ```
 
 <ReactPlayer playing={true} loop controls width="960px" height="720px" url='/img/tutorial/note-app/03-note-create.mp4' />
diff --git a/versioned_docs/version-2.8.0/06-concepts/06-database/01-connection.md b/versioned_docs/version-2.8.0/06-concepts/06-database/01-connection.md
index ad472d54..fb9be125 100644
--- a/versioned_docs/version-2.8.0/06-concepts/06-database/01-connection.md
+++ b/versioned_docs/version-2.8.0/06-concepts/06-database/01-connection.md
@@ -66,19 +66,19 @@ development:
 A newly created Serverpod project has a preconfigured Docker instance with a Postgres database set up. Run the following command from the root of the `server` package to start the database:
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To stop the database run:
 
 ```bash
-$ docker compose stop
+docker compose stop
 ```
 
 To remove the database and __delete__ all associated data, run:
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
 
 ## Connecting to a custom Postgres instance
diff --git a/versioned_docs/version-2.8.0/06-concepts/06-database/11-migrations.md b/versioned_docs/version-2.8.0/06-concepts/06-database/11-migrations.md
index c4e1891e..e0ededd7 100644
--- a/versioned_docs/version-2.8.0/06-concepts/06-database/11-migrations.md
+++ b/versioned_docs/version-2.8.0/06-concepts/06-database/11-migrations.md
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,7 +47,7 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
@@ -55,7 +55,7 @@ $ serverpod create-migration --force
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,7 +162,7 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
@@ -170,7 +170,7 @@ $ serverpod create-repair-migration --force
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
diff --git a/versioned_docs/version-2.8.0/06-concepts/10-modules.md b/versioned_docs/version-2.8.0/06-concepts/10-modules.md
index 3e4db07a..26732597 100644
--- a/versioned_docs/version-2.8.0/06-concepts/10-modules.md
+++ b/versioned_docs/version-2.8.0/06-concepts/10-modules.md
@@ -34,15 +34,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -80,13 +80,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.
diff --git a/versioned_docs/version-2.8.0/06-concepts/11-authentication/01-setup.md b/versioned_docs/version-2.8.0/06-concepts/11-authentication/01-setup.md
index 4a04e210..21f54c9d 100644
--- a/versioned_docs/version-2.8.0/06-concepts/11-authentication/01-setup.md
+++ b/versioned_docs/version-2.8.0/06-concepts/11-authentication/01-setup.md
@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
 Add the module as a dependency to the server project's `pubspec.yaml`.
 
 ```sh
-$ dart pub add serverpod_auth_server
+dart pub add serverpod_auth_server
 ```
 
 Add the authentication handler to the Serverpod instance.
@@ -46,7 +46,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
@@ -54,19 +54,19 @@ $ serverpod generate
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../database/migrations).
diff --git a/versioned_docs/version-2.8.0/06-concepts/11-authentication/04-providers/02-google.md b/versioned_docs/version-2.8.0/06-concepts/11-authentication/04-providers/02-google.md
index caa8b601..5ea95571 100644
--- a/versioned_docs/version-2.8.0/06-concepts/11-authentication/04-providers/02-google.md
+++ b/versioned_docs/version-2.8.0/06-concepts/11-authentication/04-providers/02-google.md
@@ -117,7 +117,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -134,7 +134,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::
diff --git a/versioned_docs/version-2.8.0/06-concepts/11-authentication/04-providers/05-firebase.md b/versioned_docs/version-2.8.0/06-concepts/11-authentication/04-providers/05-firebase.md
index 1816b20b..9dcb3766 100644
--- a/versioned_docs/version-2.8.0/06-concepts/11-authentication/04-providers/05-firebase.md
+++ b/versioned_docs/version-2.8.0/06-concepts/11-authentication/04-providers/05-firebase.md
@@ -29,8 +29,8 @@ To add authentication with Firebase, you must first install and initialize the F
 The short version:
 
 ```bash
-$ flutter pub add firebase_core firebase_auth firebase_ui_auth
-$ flutterfire configure
+flutter pub add firebase_core firebase_auth firebase_ui_auth
+flutterfire configure
 ```
 
 In the Firebase console, configure the different social sign-ins you plan to use, under `Authentication > Sign-in method`.
@@ -65,7 +65,7 @@ void main() async {
 Add the [serverpod_auth_firebase_flutter](https://pub.dev/packages/serverpod_auth_firebase_flutter) package.
 
 ```bash
-$ flutter pub add serverpod_auth_firebase_flutter
+flutter pub add serverpod_auth_firebase_flutter
 ```
 
 The `SignInWithFirebaseButton` is a convenient button that triggers the sign-in flow and can be used like this:
diff --git a/versioned_docs/version-2.8.0/06-concepts/12-file-uploads.md b/versioned_docs/version-2.8.0/06-concepts/12-file-uploads.md
index bbb788ab..b3439eba 100644
--- a/versioned_docs/version-2.8.0/06-concepts/12-file-uploads.md
+++ b/versioned_docs/version-2.8.0/06-concepts/12-file-uploads.md
@@ -98,7 +98,7 @@ You may also want to add the bucket as a backend for your load balancer to give
 When you have set up your GCP bucket, you need to configure it in Serverpod. Add the GCP package to your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_gcp
+dart pub add serverpod_cloud_storage_gcp
 ```
 
 ```dart
@@ -126,7 +126,7 @@ This section shows how to set up a storage using S3. Before you write your Dart
 When you are all set with the AWS setup, include the S3 package in your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_s3
+dart pub add serverpod_cloud_storage_s3
 ```
 
 ```dart
diff --git a/versioned_docs/version-2.8.0/06-concepts/21-experimental.md b/versioned_docs/version-2.8.0/06-concepts/21-experimental.md
index 6d1099bd..a5868a1f 100644
--- a/versioned_docs/version-2.8.0/06-concepts/21-experimental.md
+++ b/versioned_docs/version-2.8.0/06-concepts/21-experimental.md
@@ -21,7 +21,7 @@ If possible, the experimental API will remain for some time as `@deprecated`, an
 Some of the experimental features are enabled by including the `--experimental-features` flag when running the serverpod command:
 
 ```bash
-$ serverpod generate --experimental-features=all
+serverpod generate --experimental-features=all
 ```
 
 The current options you can pass are:
diff --git a/versioned_docs/version-2.8.0/07-deployments/02-deploying-to-gce-terraform.md b/versioned_docs/version-2.8.0/07-deployments/02-deploying-to-gce-terraform.md
index 3a2ac487..f55c21bd 100644
--- a/versioned_docs/version-2.8.0/07-deployments/02-deploying-to-gce-terraform.md
+++ b/versioned_docs/version-2.8.0/07-deployments/02-deploying-to-gce-terraform.md
@@ -126,7 +126,7 @@ Depending on your domain name registrar, the process for setting up your domain
 You can test that the domain points to the correct name servers by running `dig` on the command line. It will output the domain name servers.
 
 ```bash
-$ dig +short NS examplepod.com
+dig +short NS examplepod.com
 ```
 
 Should yield an output similar to this:
@@ -228,13 +228,13 @@ If you are deploying a staging server in addition to your production server, you
 Once you have configured Terraform and your Serverpod, you are ready to deploy your infrastructure. Make sure that you have `cd` into your `deploy/gcp/terraform_gce` directory. Now run:
 
 ```bash
-$ terraform init
+terraform init
 ```
 
 This will download the Serverpod module and initialize your Terraform configuration. Now, deploy your infrastructure by running:
 
 ```bash
-$ terraform apply
+terraform apply
 ```
 
 Terraform will ask you for the password to your production and staging database. You will find the passwords in your `config/passwords.yaml` file. If you are not deploying a staging server, you can leave the staging database password blank.
diff --git a/versioned_docs/version-2.8.0/07-deployments/03-deploying-to-gcr-console.md b/versioned_docs/version-2.8.0/07-deployments/03-deploying-to-gcr-console.md
index cdd5991d..b647215c 100644
--- a/versioned_docs/version-2.8.0/07-deployments/03-deploying-to-gcr-console.md
+++ b/versioned_docs/version-2.8.0/07-deployments/03-deploying-to-gcr-console.md
@@ -11,13 +11,13 @@ Before you begin, you will need to install and configure the Google Cloud CLI to
 - To [initialize](https://cloud.google.com/sdk/docs/initializing) the gcloud CLI, run the following command:
 
 ```bash
-$ gcloud init
+gcloud init
 ```
 
 - To set the default project for your Cloud Run service:
 
 ```bash
-$ gcloud config set project <PROJECT_ID>
+gcloud config set project <PROJECT_ID>
 ```
 
 ## Setup the database
@@ -75,8 +75,8 @@ database:
 Your server is now ready to be deployed. When you created your project, Serverpod also created a script for deploying your server. Copy it to the root of your server directory and make it executable. Make sure you are in your server directory (e.g., `myproject_server`). Then run the following command:
 
 ```bash
-$ cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
-$ chmod u+x cloud-run-deploy.sh
+cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
+chmod u+x cloud-run-deploy.sh
 ```
 
 Open up the script in your favorite editor. You will need to fill in your _database instance's connection name_ and the _email of your service account_.
@@ -84,7 +84,7 @@ Open up the script in your favorite editor. You will need to fill in your _datab
 Now, deploy your server by running the following:
 
 ```bash
-$ ./cloud-run-deploy.sh
+./cloud-run-deploy.sh
 ```
 
 The script runs two deployment commands, one for your API and one for the Insights API used by the Serverpod app. While running, it may ask you to enable the Cloud Run and SQL Admin services. Answer yes to all these questions.
diff --git a/versioned_docs/version-2.8.0/07-deployments/04-deploying-to-aws.md b/versioned_docs/version-2.8.0/07-deployments/04-deploying-to-aws.md
index af139474..713e4d4c 100644
--- a/versioned_docs/version-2.8.0/07-deployments/04-deploying-to-aws.md
+++ b/versioned_docs/version-2.8.0/07-deployments/04-deploying-to-aws.md
@@ -202,14 +202,14 @@ database:
 Your Serverpod should now be configured and ready to be deployed. Exciting times! Open up a terminal and `cd` into your server `aws/terraform` directory. First, you need to add an environment variable so that Terraform can correctly set the password for the Postgres database. You will find the production password for the database in your `config/passwords.yaml` file.
 
 ```bash
-$ export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
+export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
 ```
 
 Next, we are ready to initialize Terraform and deploy our server. You will only need to run the `terraform init` command the first time you deploy the configuration.
 
 ```bash
-$ terraform init
-$ terraform apply
+terraform init
+terraform apply
 ```
 
 Terraform will now run some checks and make a plan for the deployment. If everything looks good, it will ask you if you are ready to go ahead with the changes. Type `yes` and hit the return key. Applying the changes can take up to five minutes as AWS creates the different resources needed for your Serverpod.
diff --git a/versioned_docs/version-2.8.0/07-deployments/05-general.md b/versioned_docs/version-2.8.0/07-deployments/05-general.md
index bc27776c..bd4cd171 100644
--- a/versioned_docs/version-2.8.0/07-deployments/05-general.md
+++ b/versioned_docs/version-2.8.0/07-deployments/05-general.md
@@ -11,7 +11,7 @@ Serverpod will not run without a link to a Postgres database with the correct ta
 Serverpod has three main configuration files, depending on which mode the server is running; `development`, `staging`, or `production`. The files are located in the `config/` directory. By default, the server will start in development mode. To use another configuration file, use the `--mode` option when starting the server. If you are running multiple servers in a cluster, use the `--server-id` option to specify the id of each server. By default, the server will run as id `default`. For instance, to start the server in production mode with id `2`, run the following command:
 
 ```bash
-$ dart bin/main.dart --mode production --server-id 2
+dart bin/main.dart --mode production --server-id 2
 ```
 
 :::info
@@ -35,7 +35,7 @@ Serverpod can assume different roles depending on your configuration. If you run
 You can specify the role of your server when you launch it by setting the `--role` argument.
 
 ```bash
-$ dart bin/main.dart --role serverless
+dart bin/main.dart --role serverless
 ```
 
 ## Docker container
diff --git a/versioned_docs/version-2.8.0/08-upgrading/03-upgrade-to-two.md b/versioned_docs/version-2.8.0/08-upgrading/03-upgrade-to-two.md
index 54e3b54d..5ef0d80a 100644
--- a/versioned_docs/version-2.8.0/08-upgrading/03-upgrade-to-two.md
+++ b/versioned_docs/version-2.8.0/08-upgrading/03-upgrade-to-two.md
@@ -284,7 +284,7 @@ To ensure new databases are created with the new representation, the latest migr
 A new empty migration can be created by running the following command in the terminal:
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 #### Migration of existing tables
diff --git a/versioned_docs/version-2.8.0/08-upgrading/05-upgrade-to-pgvector.md b/versioned_docs/version-2.8.0/08-upgrading/05-upgrade-to-pgvector.md
index 24896009..6f94d34c 100644
--- a/versioned_docs/version-2.8.0/08-upgrading/05-upgrade-to-pgvector.md
+++ b/versioned_docs/version-2.8.0/08-upgrading/05-upgrade-to-pgvector.md
@@ -64,8 +64,8 @@ fields:
 4. Generate and apply a migration:
 
 ```bash
-$ serverpod create-migration
-$ dart run bin/main.dart --apply-migrations
+serverpod create-migration
+dart run bin/main.dart --apply-migrations
 ```
 
 For more details on creating and applying migrations, see the [Migrations](../concepts/database/migrations) section.
diff --git a/versioned_docs/version-2.8.0/09-tools/02-lsp.md b/versioned_docs/version-2.8.0/09-tools/02-lsp.md
index 2374cf57..8da02d1b 100644
--- a/versioned_docs/version-2.8.0/09-tools/02-lsp.md
+++ b/versioned_docs/version-2.8.0/09-tools/02-lsp.md
@@ -5,7 +5,7 @@ The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server
 To start the Serverpod LSP server, use the following command:
 
 ```bash
-$ serverpod language-server
+serverpod language-server
 ```
 
 :::info
diff --git a/versioned_docs/version-2.8.0/index.md b/versioned_docs/version-2.8.0/index.md
index 75de6f1f..e62755bb 100644
--- a/versioned_docs/version-2.8.0/index.md
+++ b/versioned_docs/version-2.8.0/index.md
@@ -61,7 +61,7 @@ Serverpod is tested on Mac, Windows, and Linux. Before you can install Serverpod
 Check your Flutter installation by running the following command in your terminal:
 
 ```bash
-$ flutter doctor
+flutter doctor
 ```
 
 :::
@@ -72,7 +72,7 @@ To make use of Serverpod's database connectivity, you need to have access to a P
 Check your Docker installation by running the following command in your terminal:
 
 ```bash
-$ docker info
+docker info
 ```
 
 If you are using Docker Desktop and you are getting an error, make sure that Docker is running. You can check this by looking for the Docker icon in your system tray or taskbar. If it's not running, start Docker Desktop and try again.
@@ -83,13 +83,13 @@ If you are using Docker Desktop and you are getting an error, make sure that Doc
 Serverpod is installed using the Dart package manager. To install Serverpod, run the following command in your terminal:
 
 ```bash
-$ dart pub global activate serverpod_cli
+dart pub global activate serverpod_cli
 ```
 
 This command will install the Serverpod command-line interface (CLI) globally on your machine. You can verify the installation by running:
 
 ```bash
-$ serverpod
+serverpod
 ```
 
 If everything is correctly configured, the help for the `serverpod` command is now displayed.
@@ -112,7 +112,7 @@ To create a new Serverpod project, use the `serverpod create` command. It will s
 The project will be created in a new directory with the name you specify. For example, to create a new project called `my_project`, run the following command:
 
 ```bash
-$ serverpod create my_project
+serverpod create my_project
 ```
 
 :::tip
@@ -122,20 +122,20 @@ The name of the project must be a valid Dart package name. It should start with
 To run your new project you must first start the database from the Docker file that is included with the project. Do this by running the `docker compose up` command in the server directory:
 
 ```bash
-$ cd my_project/my_project_server
-$ docker compose up
+cd my_project/my_project_server
+docker compose up
 ```
 
 This will start the PostgreSQL database. You can stop the database server by pressing `Ctrl+C` in the terminal. If you want to run the servers in the background, you can use the `-d` flag:
 
 ```bash
-$ docker compose up -d
+docker compose up -d
 ```
 
 This will start the database server in detached mode, meaning it will run in the background and you can safely close the terminal window without stopping it. Stop the database container by running the following command from the server directory:
 
 ```bash
-$ docker compose down
+docker compose down
 ```
 
 :::tip
@@ -145,8 +145,8 @@ If you are using Docker Desktop, you can see and manage all your installed Docke
 Now that the database is up and running we can start the Serverpod server. Because we are running the project for the first time, we need create the database tables used by Serverpod. This is done through a [database migration](./06-concepts/06-database/11-migrations.md). An initial migration is already created for us, so all we need to do is to pass the `--apply-migrations` flag to our server when we start it:
 
 ```bash
-$ cd my_project/my_project_server
-$ dart run bin/main.dart --apply-migrations
+cd my_project/my_project_server
+dart run bin/main.dart --apply-migrations
 ```
 
 This will start the server and set up the initial database tables. You can now access the server at `http://localhost:8080` and the web server is available at `http://localhost:8082`. It should look like this:
@@ -156,8 +156,8 @@ This will start the server and set up the initial database tables. You can now a
 Now let's run our Flutter app. You can do this by running `flutter run -d chrome` in the flutter directory:
 
 ```bash
-$ cd my_project/my_project_flutter
-$ flutter run -d chrome
+cd my_project/my_project_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look like this:
diff --git a/versioned_docs/version-2.8.0/serverpod-mini.md b/versioned_docs/version-2.8.0/serverpod-mini.md
index 6d591460..f9279171 100644
--- a/versioned_docs/version-2.8.0/serverpod-mini.md
+++ b/versioned_docs/version-2.8.0/serverpod-mini.md
@@ -35,7 +35,7 @@ Serverpod Mini is a lightweight version of Serverpod that is perfect for small p
 Create a mini project by running:
 
 ```bash
-$ serverpod create myminipod --mini
+serverpod create myminipod --mini
 ```
 
 Serverpod will create a new project for you. It contains three Dart packages, but you only need to pay attention to the `myminipod_server` and `myminipod_flutter` directories. The server directory contains your server files, and the flutter directory contains your app. The third package (`myminipod_client`) contains generated code that is used by the Flutter app to communicate with the server.
@@ -43,15 +43,15 @@ Serverpod will create a new project for you. It contains three Dart packages, bu
 Start your server by changing directory into your server directory, and run the `bin/main.dart` file:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ dart bin/main.dart
+cd myminipod/myminipod_server
+dart bin/main.dart
 ```
 
 Your default project comes with a sample Flutter app, all hooked up to talk with your server. Run it with the `flutter` command:
 
 ```bash
-$ cd myminipod/myminipod_flutter
-$ flutter run -d chrome
+cd myminipod/myminipod_flutter
+flutter run -d chrome
 ```
 
 Easy as that. 🥳
@@ -79,8 +79,8 @@ For types, you can use most basic Dart types, such as `String`, `double`, `int`,
 Whenever you add or edit a model file, run `serverpod generate` in your server directory. Then, Serverpod will generate all the updated Dart classes:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Adding methods to your server
@@ -116,8 +116,8 @@ class CompanyEndpoint extends Endpoint {
 After adding or modifying endpoints and endpoint methods, you must run `serverpod generate` to keep your Flutter app up-to-date.
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Calling the server methods from the app
diff --git a/versioned_docs/version-2.9.0/01-get-started/01-creating-endpoints.md b/versioned_docs/version-2.9.0/01-get-started/01-creating-endpoints.md
index 68ce7c25..c4f269cd 100644
--- a/versioned_docs/version-2.9.0/01-get-started/01-creating-endpoints.md
+++ b/versioned_docs/version-2.9.0/01-get-started/01-creating-endpoints.md
@@ -37,8 +37,8 @@ development:
 Next, we add Google's Gemini package as a dependency to our server.
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ dart pub add google_generative_ai
+cd magic_recipe/magic_recipe_server
+dart pub add google_generative_ai
 ```
 
 ## Create a new endpoint
@@ -97,8 +97,8 @@ For methods to be generated, they need to return a typed `Future`, where the typ
 Now, you need to generate the code for your new endpoint. You do this by running `serverpod generate` in the server directory of your project:
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ serverpod generate
+cd magic_recipe/magic_recipe_server
+serverpod generate
 ```
 
 `serverpod generate` will create bindings for the endpoint and register them in the server's `generated/protocol.dart` file. It will also generate the required client code so that you can call your new `generateRecipe` method from your app.
@@ -202,16 +202,16 @@ Before you start your server, ensure no other Serverpod server is running. Also,
 Let's try our new recipe app! First, start the server:
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart --apply-migrations
+cd magic_recipe/magic_recipe_server
+docker compose up -d
+dart bin/main.dart --apply-migrations
 ```
 
 Now, you can start the Flutter app:
 
 ```bash
-$ cd magic_recipe/magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe/magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser:
diff --git a/versioned_docs/version-2.9.0/01-get-started/02-models-and-data.md b/versioned_docs/version-2.9.0/01-get-started/02-models-and-data.md
index 969cb6e7..64994e8c 100644
--- a/versioned_docs/version-2.9.0/01-get-started/02-models-and-data.md
+++ b/versioned_docs/version-2.9.0/01-get-started/02-models-and-data.md
@@ -33,8 +33,8 @@ You can use most primitive Dart types here or any other models you have specifie
 To generate the code for the model, run the `serverpod generate` command in your server directory:
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ serverpod generate
+cd magic_recipe/magic_recipe_server
+serverpod generate
 ```
 
 This will generate the code for the model and create a new file called `recipe.dart` in the `lib/src/generated` directory. It will also update the client code in `magic_recipe/magic_recipe_client` so you can use it in your Flutter app.
@@ -131,8 +131,8 @@ class RecipeEndpoint extends Endpoint {
 First, we need to update our generated client by running `serverpod generate`.
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ serverpod generate
+cd magic_recipe/magic_recipe_server
+serverpod generate
 ```
 
 Now that we have created the `Recipe` model we can use it in the client. We will do this in the `magic_recipe/magic_recipe_flutter/lib/main.dart` file. Let's update our `RecipeWidget` so that it displays the author and year of the recipe in addition to the recipe itself.
@@ -290,16 +290,16 @@ class MyHomePageState extends State<MyHomePage> {
 First, start the server:
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart
+cd magic_recipe/magic_recipe_server
+docker compose up -d
+dart bin/main.dart
 ```
 
 Then, start the Flutter app:
 
 ```bash
-$ cd magic_recipe/magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe/magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look something like this:
diff --git a/versioned_docs/version-2.9.0/01-get-started/03-working-with-the-database.md b/versioned_docs/version-2.9.0/01-get-started/03-working-with-the-database.md
index 38da95e4..a3c6cbb1 100644
--- a/versioned_docs/version-2.9.0/01-get-started/03-working-with-the-database.md
+++ b/versioned_docs/version-2.9.0/01-get-started/03-working-with-the-database.md
@@ -41,9 +41,9 @@ To create a migration, follow these two steps in order:
 2. Run `serverpod create-migration` to create the necessary database migration.
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ serverpod generate
-$ serverpod create-migration
+cd magic_recipe/magic_recipe_server
+serverpod generate
+serverpod create-migration
 ```
 
 Each time you run `serverpod create-migration`, a new migration file will be created in your _migrations_ folder. These step-by-step migrations provide a history of your database changes and allow you to roll back changes if needed.
@@ -185,8 +185,8 @@ The `insertRow` method is used to insert a new row in the database. The `find` m
 Like before, when you change something that has an effect on the client code, you need to run `serverpod generate`. We don't need to run `serverpod create-migrations` again because we already created a migration in the previous step and haven't done any changes that affect the database.
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ serverpod generate
+cd magic_recipe/magic_recipe_server
+serverpod generate
 ```
 
 ## Call the endpoint from the app
@@ -428,9 +428,9 @@ To run the application with database support, follow these steps in order:
 First, start the database and apply migrations:
 
 ```bash
-$ cd magic_recipe/magic_recipe_server
-$ docker compose up -d                   # Start the database container
-$ dart bin/main.dart --apply-migrations  # Apply any pending migrations
+cd magic_recipe/magic_recipe_server
+docker compose up -d                   # Start the database container
+dart bin/main.dart --apply-migrations  # Apply any pending migrations
 ```
 
 :::tip
@@ -440,8 +440,8 @@ The `--apply-migrations` flag is safe to use during development - if no migratio
 Next, launch the Flutter app:
 
 ```bash
-$ cd magic_recipe/magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe/magic_recipe_flutter
+flutter run -d chrome
 ```
 
 ## Summary
diff --git a/versioned_docs/version-2.9.0/06-concepts/06-database/01-connection.md b/versioned_docs/version-2.9.0/06-concepts/06-database/01-connection.md
index 5170f1e1..8c1919ca 100644
--- a/versioned_docs/version-2.9.0/06-concepts/06-database/01-connection.md
+++ b/versioned_docs/version-2.9.0/06-concepts/06-database/01-connection.md
@@ -70,19 +70,19 @@ development:
 A newly created Serverpod project has a preconfigured Docker instance with a Postgres database set up. Run the following command from the root of the `server` package to start the database:
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To stop the database run:
 
 ```bash
-$ docker compose stop
+docker compose stop
 ```
 
 To remove the database and __delete__ all associated data, run:
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
 
 ## Connecting to a custom Postgres instance
diff --git a/versioned_docs/version-2.9.0/06-concepts/06-database/11-migrations.md b/versioned_docs/version-2.9.0/06-concepts/06-database/11-migrations.md
index c4e1891e..e0ededd7 100644
--- a/versioned_docs/version-2.9.0/06-concepts/06-database/11-migrations.md
+++ b/versioned_docs/version-2.9.0/06-concepts/06-database/11-migrations.md
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,7 +47,7 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
@@ -55,7 +55,7 @@ $ serverpod create-migration --force
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,7 +162,7 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
@@ -170,7 +170,7 @@ $ serverpod create-repair-migration --force
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
diff --git a/versioned_docs/version-2.9.0/06-concepts/10-modules.md b/versioned_docs/version-2.9.0/06-concepts/10-modules.md
index 3e4db07a..26732597 100644
--- a/versioned_docs/version-2.9.0/06-concepts/10-modules.md
+++ b/versioned_docs/version-2.9.0/06-concepts/10-modules.md
@@ -34,15 +34,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -80,13 +80,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.
diff --git a/versioned_docs/version-2.9.0/06-concepts/11-authentication/01-setup.md b/versioned_docs/version-2.9.0/06-concepts/11-authentication/01-setup.md
index 4a04e210..21f54c9d 100644
--- a/versioned_docs/version-2.9.0/06-concepts/11-authentication/01-setup.md
+++ b/versioned_docs/version-2.9.0/06-concepts/11-authentication/01-setup.md
@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
 Add the module as a dependency to the server project's `pubspec.yaml`.
 
 ```sh
-$ dart pub add serverpod_auth_server
+dart pub add serverpod_auth_server
 ```
 
 Add the authentication handler to the Serverpod instance.
@@ -46,7 +46,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
@@ -54,19 +54,19 @@ $ serverpod generate
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../database/migrations).
diff --git a/versioned_docs/version-2.9.0/06-concepts/11-authentication/04-providers/02-google.md b/versioned_docs/version-2.9.0/06-concepts/11-authentication/04-providers/02-google.md
index 7b52c420..8fe10f12 100644
--- a/versioned_docs/version-2.9.0/06-concepts/11-authentication/04-providers/02-google.md
+++ b/versioned_docs/version-2.9.0/06-concepts/11-authentication/04-providers/02-google.md
@@ -119,7 +119,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -136,7 +136,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::
diff --git a/versioned_docs/version-2.9.0/06-concepts/11-authentication/04-providers/05-firebase.md b/versioned_docs/version-2.9.0/06-concepts/11-authentication/04-providers/05-firebase.md
index f5aab8fc..b1a4e0dc 100644
--- a/versioned_docs/version-2.9.0/06-concepts/11-authentication/04-providers/05-firebase.md
+++ b/versioned_docs/version-2.9.0/06-concepts/11-authentication/04-providers/05-firebase.md
@@ -31,8 +31,8 @@ To add authentication with Firebase, you must first install and initialize the F
 The short version:
 
 ```bash
-$ flutter pub add firebase_core firebase_auth firebase_ui_auth
-$ flutterfire configure
+flutter pub add firebase_core firebase_auth firebase_ui_auth
+flutterfire configure
 ```
 
 In the Firebase console, configure the different social sign-ins you plan to use, under `Authentication > Sign-in method`.
@@ -67,7 +67,7 @@ void main() async {
 Add the [serverpod_auth_firebase_flutter](https://pub.dev/packages/serverpod_auth_firebase_flutter) package.
 
 ```bash
-$ flutter pub add serverpod_auth_firebase_flutter
+flutter pub add serverpod_auth_firebase_flutter
 ```
 
 The `SignInWithFirebaseButton` is a convenient button that triggers the sign-in flow and can be used like this:
diff --git a/versioned_docs/version-2.9.0/06-concepts/12-file-uploads.md b/versioned_docs/version-2.9.0/06-concepts/12-file-uploads.md
index bbb788ab..b3439eba 100644
--- a/versioned_docs/version-2.9.0/06-concepts/12-file-uploads.md
+++ b/versioned_docs/version-2.9.0/06-concepts/12-file-uploads.md
@@ -98,7 +98,7 @@ You may also want to add the bucket as a backend for your load balancer to give
 When you have set up your GCP bucket, you need to configure it in Serverpod. Add the GCP package to your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_gcp
+dart pub add serverpod_cloud_storage_gcp
 ```
 
 ```dart
@@ -126,7 +126,7 @@ This section shows how to set up a storage using S3. Before you write your Dart
 When you are all set with the AWS setup, include the S3 package in your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_s3
+dart pub add serverpod_cloud_storage_s3
 ```
 
 ```dart
diff --git a/versioned_docs/version-2.9.0/06-concepts/21-experimental.md b/versioned_docs/version-2.9.0/06-concepts/21-experimental.md
index f5e6d296..7be095d9 100644
--- a/versioned_docs/version-2.9.0/06-concepts/21-experimental.md
+++ b/versioned_docs/version-2.9.0/06-concepts/21-experimental.md
@@ -25,7 +25,7 @@ If possible, the experimental API will remain for some time as `@deprecated`, an
 Some of the experimental features are enabled by including the `--experimental-features` flag when running the serverpod command:
 
 ```bash
-$ serverpod generate --experimental-features=all
+serverpod generate --experimental-features=all
 ```
 
 The current options you can pass are:
diff --git a/versioned_docs/version-2.9.0/07-deployments/02-deploying-to-gce-terraform.md b/versioned_docs/version-2.9.0/07-deployments/02-deploying-to-gce-terraform.md
index 3a2ac487..f55c21bd 100644
--- a/versioned_docs/version-2.9.0/07-deployments/02-deploying-to-gce-terraform.md
+++ b/versioned_docs/version-2.9.0/07-deployments/02-deploying-to-gce-terraform.md
@@ -126,7 +126,7 @@ Depending on your domain name registrar, the process for setting up your domain
 You can test that the domain points to the correct name servers by running `dig` on the command line. It will output the domain name servers.
 
 ```bash
-$ dig +short NS examplepod.com
+dig +short NS examplepod.com
 ```
 
 Should yield an output similar to this:
@@ -228,13 +228,13 @@ If you are deploying a staging server in addition to your production server, you
 Once you have configured Terraform and your Serverpod, you are ready to deploy your infrastructure. Make sure that you have `cd` into your `deploy/gcp/terraform_gce` directory. Now run:
 
 ```bash
-$ terraform init
+terraform init
 ```
 
 This will download the Serverpod module and initialize your Terraform configuration. Now, deploy your infrastructure by running:
 
 ```bash
-$ terraform apply
+terraform apply
 ```
 
 Terraform will ask you for the password to your production and staging database. You will find the passwords in your `config/passwords.yaml` file. If you are not deploying a staging server, you can leave the staging database password blank.
diff --git a/versioned_docs/version-2.9.0/07-deployments/03-deploying-to-gcr-console.md b/versioned_docs/version-2.9.0/07-deployments/03-deploying-to-gcr-console.md
index cdd5991d..b647215c 100644
--- a/versioned_docs/version-2.9.0/07-deployments/03-deploying-to-gcr-console.md
+++ b/versioned_docs/version-2.9.0/07-deployments/03-deploying-to-gcr-console.md
@@ -11,13 +11,13 @@ Before you begin, you will need to install and configure the Google Cloud CLI to
 - To [initialize](https://cloud.google.com/sdk/docs/initializing) the gcloud CLI, run the following command:
 
 ```bash
-$ gcloud init
+gcloud init
 ```
 
 - To set the default project for your Cloud Run service:
 
 ```bash
-$ gcloud config set project <PROJECT_ID>
+gcloud config set project <PROJECT_ID>
 ```
 
 ## Setup the database
@@ -75,8 +75,8 @@ database:
 Your server is now ready to be deployed. When you created your project, Serverpod also created a script for deploying your server. Copy it to the root of your server directory and make it executable. Make sure you are in your server directory (e.g., `myproject_server`). Then run the following command:
 
 ```bash
-$ cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
-$ chmod u+x cloud-run-deploy.sh
+cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
+chmod u+x cloud-run-deploy.sh
 ```
 
 Open up the script in your favorite editor. You will need to fill in your _database instance's connection name_ and the _email of your service account_.
@@ -84,7 +84,7 @@ Open up the script in your favorite editor. You will need to fill in your _datab
 Now, deploy your server by running the following:
 
 ```bash
-$ ./cloud-run-deploy.sh
+./cloud-run-deploy.sh
 ```
 
 The script runs two deployment commands, one for your API and one for the Insights API used by the Serverpod app. While running, it may ask you to enable the Cloud Run and SQL Admin services. Answer yes to all these questions.
diff --git a/versioned_docs/version-2.9.0/07-deployments/04-deploying-to-aws.md b/versioned_docs/version-2.9.0/07-deployments/04-deploying-to-aws.md
index af139474..713e4d4c 100644
--- a/versioned_docs/version-2.9.0/07-deployments/04-deploying-to-aws.md
+++ b/versioned_docs/version-2.9.0/07-deployments/04-deploying-to-aws.md
@@ -202,14 +202,14 @@ database:
 Your Serverpod should now be configured and ready to be deployed. Exciting times! Open up a terminal and `cd` into your server `aws/terraform` directory. First, you need to add an environment variable so that Terraform can correctly set the password for the Postgres database. You will find the production password for the database in your `config/passwords.yaml` file.
 
 ```bash
-$ export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
+export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
 ```
 
 Next, we are ready to initialize Terraform and deploy our server. You will only need to run the `terraform init` command the first time you deploy the configuration.
 
 ```bash
-$ terraform init
-$ terraform apply
+terraform init
+terraform apply
 ```
 
 Terraform will now run some checks and make a plan for the deployment. If everything looks good, it will ask you if you are ready to go ahead with the changes. Type `yes` and hit the return key. Applying the changes can take up to five minutes as AWS creates the different resources needed for your Serverpod.
diff --git a/versioned_docs/version-2.9.0/07-deployments/05-general.md b/versioned_docs/version-2.9.0/07-deployments/05-general.md
index bc27776c..bd4cd171 100644
--- a/versioned_docs/version-2.9.0/07-deployments/05-general.md
+++ b/versioned_docs/version-2.9.0/07-deployments/05-general.md
@@ -11,7 +11,7 @@ Serverpod will not run without a link to a Postgres database with the correct ta
 Serverpod has three main configuration files, depending on which mode the server is running; `development`, `staging`, or `production`. The files are located in the `config/` directory. By default, the server will start in development mode. To use another configuration file, use the `--mode` option when starting the server. If you are running multiple servers in a cluster, use the `--server-id` option to specify the id of each server. By default, the server will run as id `default`. For instance, to start the server in production mode with id `2`, run the following command:
 
 ```bash
-$ dart bin/main.dart --mode production --server-id 2
+dart bin/main.dart --mode production --server-id 2
 ```
 
 :::info
@@ -35,7 +35,7 @@ Serverpod can assume different roles depending on your configuration. If you run
 You can specify the role of your server when you launch it by setting the `--role` argument.
 
 ```bash
-$ dart bin/main.dart --role serverless
+dart bin/main.dart --role serverless
 ```
 
 ## Docker container
diff --git a/versioned_docs/version-2.9.0/08-upgrading/03-upgrade-to-two.md b/versioned_docs/version-2.9.0/08-upgrading/03-upgrade-to-two.md
index 54e3b54d..5ef0d80a 100644
--- a/versioned_docs/version-2.9.0/08-upgrading/03-upgrade-to-two.md
+++ b/versioned_docs/version-2.9.0/08-upgrading/03-upgrade-to-two.md
@@ -284,7 +284,7 @@ To ensure new databases are created with the new representation, the latest migr
 A new empty migration can be created by running the following command in the terminal:
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 #### Migration of existing tables
diff --git a/versioned_docs/version-2.9.0/08-upgrading/05-upgrade-to-pgvector.md b/versioned_docs/version-2.9.0/08-upgrading/05-upgrade-to-pgvector.md
index 24896009..6f94d34c 100644
--- a/versioned_docs/version-2.9.0/08-upgrading/05-upgrade-to-pgvector.md
+++ b/versioned_docs/version-2.9.0/08-upgrading/05-upgrade-to-pgvector.md
@@ -64,8 +64,8 @@ fields:
 4. Generate and apply a migration:
 
 ```bash
-$ serverpod create-migration
-$ dart run bin/main.dart --apply-migrations
+serverpod create-migration
+dart run bin/main.dart --apply-migrations
 ```
 
 For more details on creating and applying migrations, see the [Migrations](../concepts/database/migrations) section.
diff --git a/versioned_docs/version-2.9.0/09-tools/02-lsp.md b/versioned_docs/version-2.9.0/09-tools/02-lsp.md
index 2374cf57..8da02d1b 100644
--- a/versioned_docs/version-2.9.0/09-tools/02-lsp.md
+++ b/versioned_docs/version-2.9.0/09-tools/02-lsp.md
@@ -5,7 +5,7 @@ The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server
 To start the Serverpod LSP server, use the following command:
 
 ```bash
-$ serverpod language-server
+serverpod language-server
 ```
 
 :::info
diff --git a/versioned_docs/version-2.9.0/index.md b/versioned_docs/version-2.9.0/index.md
index 98651371..acb61a6d 100644
--- a/versioned_docs/version-2.9.0/index.md
+++ b/versioned_docs/version-2.9.0/index.md
@@ -64,7 +64,7 @@ Serverpod is tested on Mac, Windows, and Linux. Before you can install Serverpod
 Check your Flutter installation by running the following command in your terminal:
 
 ```bash
-$ flutter doctor
+flutter doctor
 ```
 
 :::
@@ -75,7 +75,7 @@ To make use of Serverpod's database connectivity, you need to have access to a P
 Check your Docker installation by running the following command in your terminal:
 
 ```bash
-$ docker info
+docker info
 ```
 
 If you are using Docker Desktop and you get an error, make sure that Docker is running. You can check this by looking for the Docker icon in your system tray or taskbar. If it's not running, start Docker Desktop and try again.
@@ -86,13 +86,13 @@ If you are using Docker Desktop and you get an error, make sure that Docker is r
 Serverpod is installed using the Dart package manager. To install Serverpod, run the following command in your terminal:
 
 ```bash
-$ dart pub global activate serverpod_cli
+dart pub global activate serverpod_cli
 ```
 
 This command will install the Serverpod command-line interface (CLI) globally on your machine. You can verify the installation by running:
 
 ```bash
-$ serverpod
+serverpod
 ```
 
 If everything is correctly configured, the help for the `serverpod` command is now displayed.
@@ -115,7 +115,7 @@ To create a new Serverpod project, use the `serverpod create` command. It will s
 The project will be created in a new directory with the name you specify. For example, to create a new project called `my_project`, run the following command:
 
 ```bash
-$ serverpod create my_project
+serverpod create my_project
 ```
 
 :::tip
@@ -125,20 +125,20 @@ The name of the project must be a valid Dart package name. It should start with
 To run your new project you must first start the database from the Docker file that is included with the project. Do this by running the `docker compose up` command in the server directory:
 
 ```bash
-$ cd my_project/my_project_server
-$ docker compose up
+cd my_project/my_project_server
+docker compose up
 ```
 
 This will start the PostgreSQL database. You can stop the database server by pressing `Ctrl+C` in the terminal. If you want to run the servers in the background, you can use the `-d` flag:
 
 ```bash
-$ docker compose up -d
+docker compose up -d
 ```
 
 This will start the database server in detached mode, meaning it will run in the background and you can safely close the terminal window without stopping it. Stop the database container by running the following command from the server directory:
 
 ```bash
-$ docker compose down
+docker compose down
 ```
 
 :::tip
@@ -148,8 +148,8 @@ If you are using Docker Desktop, you can see and manage all your installed Docke
 Now that the database is up and running we can start the Serverpod server. Because we are running the project for the first time, we need to create the database tables used by Serverpod. This is done through a [database migration](./06-concepts/06-database/11-migrations.md). An initial migration is already created for us, so all we need to do is pass the `--apply-migrations` flag when starting the server:
 
 ```bash
-$ cd my_project/my_project_server
-$ dart run bin/main.dart --apply-migrations
+cd my_project/my_project_server
+dart run bin/main.dart --apply-migrations
 ```
 
 This will start the server and set up the initial database tables. You can now access the server at `http://localhost:8080` and the web server is available at `http://localhost:8082`. It should look like this:
@@ -159,8 +159,8 @@ This will start the server and set up the initial database tables. You can now a
 Now let's run our Flutter app. You can do this by running `flutter run -d chrome` in the flutter directory:
 
 ```bash
-$ cd my_project/my_project_flutter
-$ flutter run -d chrome
+cd my_project/my_project_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look like this:
diff --git a/versioned_docs/version-2.9.0/serverpod-mini.md b/versioned_docs/version-2.9.0/serverpod-mini.md
index 62516c16..2ee7d247 100644
--- a/versioned_docs/version-2.9.0/serverpod-mini.md
+++ b/versioned_docs/version-2.9.0/serverpod-mini.md
@@ -39,7 +39,7 @@ Serverpod Mini is a lightweight version of Serverpod that is perfect for small p
 Create a mini project by running:
 
 ```bash
-$ serverpod create myminipod --mini
+serverpod create myminipod --mini
 ```
 
 Serverpod will create a new project for you. It contains three Dart packages, but you only need to pay attention to the `myminipod_server` and `myminipod_flutter` directories. The server directory contains your server files, and the flutter directory contains your app. The third package (`myminipod_client`) contains generated code that is used by the Flutter app to communicate with the server.
@@ -47,15 +47,15 @@ Serverpod will create a new project for you. It contains three Dart packages, bu
 Start your server by changing directory into your server directory, and run the `bin/main.dart` file:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ dart bin/main.dart
+cd myminipod/myminipod_server
+dart bin/main.dart
 ```
 
 Your default project comes with a sample Flutter app, all hooked up to talk with your server. Run it with the `flutter` command:
 
 ```bash
-$ cd myminipod/myminipod_flutter
-$ flutter run -d chrome
+cd myminipod/myminipod_flutter
+flutter run -d chrome
 ```
 
 Easy as that. 🥳
@@ -83,8 +83,8 @@ For types, you can use most basic Dart types, such as `String`, `double`, `int`,
 Whenever you add or edit a model file, run `serverpod generate` in your server directory. Then, Serverpod will generate all the updated Dart classes:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Adding methods to your server
@@ -120,8 +120,8 @@ class CompanyEndpoint extends Endpoint {
 After adding or modifying endpoints and endpoint methods, you must run `serverpod generate` to keep your Flutter app up-to-date.
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Calling the server methods from the app
diff --git a/versioned_docs/version-3.0.0/01-get-started/01-creating-endpoints.md b/versioned_docs/version-3.0.0/01-get-started/01-creating-endpoints.md
index 934784aa..24b5c09d 100644
--- a/versioned_docs/version-3.0.0/01-get-started/01-creating-endpoints.md
+++ b/versioned_docs/version-3.0.0/01-get-started/01-creating-endpoints.md
@@ -37,8 +37,8 @@ development:
 Next, we add the Dartantic AI package as a dependency to our server. This package provides a convenient interface for working with different AI providers, including Google's Gemini API.
 
 ```bash
-$ cd magic_recipe_server
-$ dart pub add dartantic_ai
+cd magic_recipe_server
+dart pub add dartantic_ai
 ```
 
 ## Create a new endpoint
@@ -99,8 +99,8 @@ For methods to be recognized by Serverpod, they need to return a typed `Future`
 Now, you need to generate the code for your new endpoint. You do this by running `serverpod generate` in the server directory of your project:
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 `serverpod generate` will create bindings for the endpoint and register them in the server's `generated/protocol.dart` file. It will also generate the required client code so that you can call your new `generateRecipe` method from your app.
@@ -211,16 +211,16 @@ Before you start your server, ensure no other Serverpod server is running. Also,
 Let's try our new recipe app! First, start the server:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart --apply-migrations
+cd magic_recipe_server
+docker compose up -d
+dart bin/main.dart --apply-migrations
 ```
 
 Now, you can start the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser:
diff --git a/versioned_docs/version-3.0.0/01-get-started/02-models-and-data.md b/versioned_docs/version-3.0.0/01-get-started/02-models-and-data.md
index bd2ed418..1b25a289 100644
--- a/versioned_docs/version-3.0.0/01-get-started/02-models-and-data.md
+++ b/versioned_docs/version-3.0.0/01-get-started/02-models-and-data.md
@@ -33,8 +33,8 @@ You can use most primitive Dart types here or any other models you have specifie
 To generate the code for the model, run the `serverpod generate` command in your server directory:
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 This will generate the code for the model and create a new file called `recipe.dart` in the `lib/src/generated` directory. It will also update the client code in `magic_recipe/magic_recipe_client` so you can use it in your Flutter app.
@@ -132,8 +132,8 @@ class RecipeEndpoint extends Endpoint {
 First, we need to update our generated client by running `serverpod generate`.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 Now that we have created the `Recipe` model we can use it in the app. We will do this in the `_callGenerateRecipe` method of the `magic_recipe_flutter/lib/main.dart` file. Let's update our `RecipeWidget` so that it displays the author and year of the recipe in addition to the recipe itself.
@@ -432,16 +432,16 @@ class ResultDisplay extends StatelessWidget {
 First, start the server:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart
+cd magic_recipe_server
+docker compose up -d
+dart bin/main.dart
 ```
 
 Then, start the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look something like this:
diff --git a/versioned_docs/version-3.0.0/01-get-started/03-working-with-the-database.md b/versioned_docs/version-3.0.0/01-get-started/03-working-with-the-database.md
index 51034f07..9ce74949 100644
--- a/versioned_docs/version-3.0.0/01-get-started/03-working-with-the-database.md
+++ b/versioned_docs/version-3.0.0/01-get-started/03-working-with-the-database.md
@@ -41,9 +41,9 @@ To create a migration, follow these two steps in order:
 2. Run `serverpod create-migration` to create the necessary database migration.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
-$ serverpod create-migration
+cd magic_recipe_server
+serverpod generate
+serverpod create-migration
 ```
 
 Each time you run `serverpod create-migration`, a new migration file will be created in your _migrations_ folder. These step-by-step migrations provide a history of your database changes and allow you to roll back changes if needed.
@@ -189,8 +189,8 @@ The `insertRow` method is used to insert a new row into the database. The `find`
 Like before, when you change something that has an effect on your client code, you need to run `serverpod generate`. We don't need to run `serverpod create-migrations` again because we already created a migration in the previous step and haven't done any changes that affect the database.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 ## Call the endpoint from the app
@@ -433,9 +433,9 @@ To run the application with database support, follow these steps in order:
 First, start the database and apply migrations:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d                   # Start the database container
-$ dart bin/main.dart --apply-migrations  # Apply any pending migrations
+cd magic_recipe_server
+docker compose up -d                   # Start the database container
+dart bin/main.dart --apply-migrations  # Apply any pending migrations
 ```
 
 :::tip
@@ -445,8 +445,8 @@ The `--apply-migrations` flag is safe to use during development - if no migratio
 Next, launch the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 ## Summary
diff --git a/versioned_docs/version-3.0.0/06-concepts/06-database/01-connection.md b/versioned_docs/version-3.0.0/06-concepts/06-database/01-connection.md
index 0c9ce97a..05bff19a 100644
--- a/versioned_docs/version-3.0.0/06-concepts/06-database/01-connection.md
+++ b/versioned_docs/version-3.0.0/06-concepts/06-database/01-connection.md
@@ -100,19 +100,19 @@ development:
 A newly created Serverpod project has a preconfigured Docker instance with a Postgres database set up. Run the following command from the root of the `server` package to start the database:
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To stop the database run:
 
 ```bash
-$ docker compose stop
+docker compose stop
 ```
 
 To remove the database and __delete__ all associated data, run:
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
 
 ## Connecting to a custom Postgres instance
diff --git a/versioned_docs/version-3.0.0/06-concepts/06-database/11-migrations.md b/versioned_docs/version-3.0.0/06-concepts/06-database/11-migrations.md
index 80bc54c2..ad8f803b 100644
--- a/versioned_docs/version-3.0.0/06-concepts/06-database/11-migrations.md
+++ b/versioned_docs/version-3.0.0/06-concepts/06-database/11-migrations.md
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,7 +47,7 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
@@ -55,7 +55,7 @@ $ serverpod create-migration --force
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,7 +162,7 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
@@ -170,7 +170,7 @@ $ serverpod create-repair-migration --force
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
diff --git a/versioned_docs/version-3.0.0/06-concepts/10-modules.md b/versioned_docs/version-3.0.0/06-concepts/10-modules.md
index 442b0747..1bd1f12f 100644
--- a/versioned_docs/version-3.0.0/06-concepts/10-modules.md
+++ b/versioned_docs/version-3.0.0/06-concepts/10-modules.md
@@ -32,15 +32,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -79,13 +79,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.
diff --git a/versioned_docs/version-3.0.0/06-concepts/11-authentication/04-providers/02-google/01-setup.md b/versioned_docs/version-3.0.0/06-concepts/11-authentication/04-providers/02-google/01-setup.md
index d5d72451..14f09004 100644
--- a/versioned_docs/version-3.0.0/06-concepts/11-authentication/04-providers/02-google/01-setup.md
+++ b/versioned_docs/version-3.0.0/06-concepts/11-authentication/04-providers/02-google/01-setup.md
@@ -190,7 +190,7 @@ If your `google-services.json` does not include a web OAuth client entry, you ma
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 :::
 
@@ -208,7 +208,7 @@ Navigate to _Clients_ and select the server credentials (the one configured as a
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 :::
 
diff --git a/versioned_docs/version-3.0.0/06-concepts/11-authentication/11-legacy/01-setup.md b/versioned_docs/version-3.0.0/06-concepts/11-authentication/11-legacy/01-setup.md
index 677ac269..c2769e98 100644
--- a/versioned_docs/version-3.0.0/06-concepts/11-authentication/11-legacy/01-setup.md
+++ b/versioned_docs/version-3.0.0/06-concepts/11-authentication/11-legacy/01-setup.md
@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
 Add the module as a dependency to the server project's `pubspec.yaml`.
 
 ```sh
-$ dart pub add serverpod_auth_server
+dart pub add serverpod_auth_server
 ```
 
 Add the authentication handler to the Serverpod instance.
@@ -46,7 +46,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
@@ -54,19 +54,19 @@ $ serverpod generate
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../../database/migrations).
diff --git a/versioned_docs/version-3.0.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md b/versioned_docs/version-3.0.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
index 7b52c420..8fe10f12 100644
--- a/versioned_docs/version-3.0.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
+++ b/versioned_docs/version-3.0.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
@@ -119,7 +119,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -136,7 +136,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::
diff --git a/versioned_docs/version-3.0.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md b/versioned_docs/version-3.0.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
index f5aab8fc..b1a4e0dc 100644
--- a/versioned_docs/version-3.0.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
+++ b/versioned_docs/version-3.0.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
@@ -31,8 +31,8 @@ To add authentication with Firebase, you must first install and initialize the F
 The short version:
 
 ```bash
-$ flutter pub add firebase_core firebase_auth firebase_ui_auth
-$ flutterfire configure
+flutter pub add firebase_core firebase_auth firebase_ui_auth
+flutterfire configure
 ```
 
 In the Firebase console, configure the different social sign-ins you plan to use, under `Authentication > Sign-in method`.
@@ -67,7 +67,7 @@ void main() async {
 Add the [serverpod_auth_firebase_flutter](https://pub.dev/packages/serverpod_auth_firebase_flutter) package.
 
 ```bash
-$ flutter pub add serverpod_auth_firebase_flutter
+flutter pub add serverpod_auth_firebase_flutter
 ```
 
 The `SignInWithFirebaseButton` is a convenient button that triggers the sign-in flow and can be used like this:
diff --git a/versioned_docs/version-3.0.0/06-concepts/12-file-uploads.md b/versioned_docs/version-3.0.0/06-concepts/12-file-uploads.md
index bbb788ab..b3439eba 100644
--- a/versioned_docs/version-3.0.0/06-concepts/12-file-uploads.md
+++ b/versioned_docs/version-3.0.0/06-concepts/12-file-uploads.md
@@ -98,7 +98,7 @@ You may also want to add the bucket as a backend for your load balancer to give
 When you have set up your GCP bucket, you need to configure it in Serverpod. Add the GCP package to your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_gcp
+dart pub add serverpod_cloud_storage_gcp
 ```
 
 ```dart
@@ -126,7 +126,7 @@ This section shows how to set up a storage using S3. Before you write your Dart
 When you are all set with the AWS setup, include the S3 package in your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_s3
+dart pub add serverpod_cloud_storage_s3
 ```
 
 ```dart
diff --git a/versioned_docs/version-3.0.0/06-concepts/21-experimental.md b/versioned_docs/version-3.0.0/06-concepts/21-experimental.md
index 89565cb6..b11d970f 100644
--- a/versioned_docs/version-3.0.0/06-concepts/21-experimental.md
+++ b/versioned_docs/version-3.0.0/06-concepts/21-experimental.md
@@ -25,7 +25,7 @@ If possible, the experimental API will remain for some time as `@deprecated`, an
 Some of the experimental features are enabled by including the `--experimental-features` flag when running the serverpod command:
 
 ```bash
-$ serverpod generate --experimental-features=all
+serverpod generate --experimental-features=all
 ```
 
 The current options you can pass are:
diff --git a/versioned_docs/version-3.0.0/07-deployments/02-deploying-to-gce-terraform.md b/versioned_docs/version-3.0.0/07-deployments/02-deploying-to-gce-terraform.md
index 3a2ac487..f55c21bd 100644
--- a/versioned_docs/version-3.0.0/07-deployments/02-deploying-to-gce-terraform.md
+++ b/versioned_docs/version-3.0.0/07-deployments/02-deploying-to-gce-terraform.md
@@ -126,7 +126,7 @@ Depending on your domain name registrar, the process for setting up your domain
 You can test that the domain points to the correct name servers by running `dig` on the command line. It will output the domain name servers.
 
 ```bash
-$ dig +short NS examplepod.com
+dig +short NS examplepod.com
 ```
 
 Should yield an output similar to this:
@@ -228,13 +228,13 @@ If you are deploying a staging server in addition to your production server, you
 Once you have configured Terraform and your Serverpod, you are ready to deploy your infrastructure. Make sure that you have `cd` into your `deploy/gcp/terraform_gce` directory. Now run:
 
 ```bash
-$ terraform init
+terraform init
 ```
 
 This will download the Serverpod module and initialize your Terraform configuration. Now, deploy your infrastructure by running:
 
 ```bash
-$ terraform apply
+terraform apply
 ```
 
 Terraform will ask you for the password to your production and staging database. You will find the passwords in your `config/passwords.yaml` file. If you are not deploying a staging server, you can leave the staging database password blank.
diff --git a/versioned_docs/version-3.0.0/07-deployments/03-deploying-to-gcr-console.md b/versioned_docs/version-3.0.0/07-deployments/03-deploying-to-gcr-console.md
index cdd5991d..b647215c 100644
--- a/versioned_docs/version-3.0.0/07-deployments/03-deploying-to-gcr-console.md
+++ b/versioned_docs/version-3.0.0/07-deployments/03-deploying-to-gcr-console.md
@@ -11,13 +11,13 @@ Before you begin, you will need to install and configure the Google Cloud CLI to
 - To [initialize](https://cloud.google.com/sdk/docs/initializing) the gcloud CLI, run the following command:
 
 ```bash
-$ gcloud init
+gcloud init
 ```
 
 - To set the default project for your Cloud Run service:
 
 ```bash
-$ gcloud config set project <PROJECT_ID>
+gcloud config set project <PROJECT_ID>
 ```
 
 ## Setup the database
@@ -75,8 +75,8 @@ database:
 Your server is now ready to be deployed. When you created your project, Serverpod also created a script for deploying your server. Copy it to the root of your server directory and make it executable. Make sure you are in your server directory (e.g., `myproject_server`). Then run the following command:
 
 ```bash
-$ cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
-$ chmod u+x cloud-run-deploy.sh
+cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
+chmod u+x cloud-run-deploy.sh
 ```
 
 Open up the script in your favorite editor. You will need to fill in your _database instance's connection name_ and the _email of your service account_.
@@ -84,7 +84,7 @@ Open up the script in your favorite editor. You will need to fill in your _datab
 Now, deploy your server by running the following:
 
 ```bash
-$ ./cloud-run-deploy.sh
+./cloud-run-deploy.sh
 ```
 
 The script runs two deployment commands, one for your API and one for the Insights API used by the Serverpod app. While running, it may ask you to enable the Cloud Run and SQL Admin services. Answer yes to all these questions.
diff --git a/versioned_docs/version-3.0.0/07-deployments/04-deploying-to-aws.md b/versioned_docs/version-3.0.0/07-deployments/04-deploying-to-aws.md
index af139474..713e4d4c 100644
--- a/versioned_docs/version-3.0.0/07-deployments/04-deploying-to-aws.md
+++ b/versioned_docs/version-3.0.0/07-deployments/04-deploying-to-aws.md
@@ -202,14 +202,14 @@ database:
 Your Serverpod should now be configured and ready to be deployed. Exciting times! Open up a terminal and `cd` into your server `aws/terraform` directory. First, you need to add an environment variable so that Terraform can correctly set the password for the Postgres database. You will find the production password for the database in your `config/passwords.yaml` file.
 
 ```bash
-$ export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
+export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
 ```
 
 Next, we are ready to initialize Terraform and deploy our server. You will only need to run the `terraform init` command the first time you deploy the configuration.
 
 ```bash
-$ terraform init
-$ terraform apply
+terraform init
+terraform apply
 ```
 
 Terraform will now run some checks and make a plan for the deployment. If everything looks good, it will ask you if you are ready to go ahead with the changes. Type `yes` and hit the return key. Applying the changes can take up to five minutes as AWS creates the different resources needed for your Serverpod.
diff --git a/versioned_docs/version-3.0.0/07-deployments/05-general.md b/versioned_docs/version-3.0.0/07-deployments/05-general.md
index 981bb8d9..fa1f3878 100644
--- a/versioned_docs/version-3.0.0/07-deployments/05-general.md
+++ b/versioned_docs/version-3.0.0/07-deployments/05-general.md
@@ -11,7 +11,7 @@ Serverpod will not run without a link to a Postgres database with the correct ta
 Serverpod has three main configuration files, depending on which mode the server is running; `development`, `staging`, or `production`. The files are located in the `config/` directory. By default, the server will start in development mode. To use another configuration file, use the `--mode` option when starting the server. If you are running multiple servers in a cluster, use the `--server-id` option to specify the id of each server. By default, the server will run as id `default`. For instance, to start the server in production mode with id `2`, run the following command:
 
 ```bash
-$ dart bin/main.dart --mode production --server-id 2
+dart bin/main.dart --mode production --server-id 2
 ```
 
 :::info
@@ -35,7 +35,7 @@ Serverpod can assume different roles depending on your configuration. If you run
 You can specify the role of your server when you launch it by setting the `--role` argument.
 
 ```bash
-$ dart bin/main.dart --role serverless
+dart bin/main.dart --role serverless
 ```
 
 ## Docker container
diff --git a/versioned_docs/version-3.0.0/08-upgrading/03-upgrade-to-pgvector.md b/versioned_docs/version-3.0.0/08-upgrading/03-upgrade-to-pgvector.md
index 24896009..6f94d34c 100644
--- a/versioned_docs/version-3.0.0/08-upgrading/03-upgrade-to-pgvector.md
+++ b/versioned_docs/version-3.0.0/08-upgrading/03-upgrade-to-pgvector.md
@@ -64,8 +64,8 @@ fields:
 4. Generate and apply a migration:
 
 ```bash
-$ serverpod create-migration
-$ dart run bin/main.dart --apply-migrations
+serverpod create-migration
+dart run bin/main.dart --apply-migrations
 ```
 
 For more details on creating and applying migrations, see the [Migrations](../concepts/database/migrations) section.
diff --git a/versioned_docs/version-3.0.0/08-upgrading/04-archive/03-upgrade-to-two.md b/versioned_docs/version-3.0.0/08-upgrading/04-archive/03-upgrade-to-two.md
index 54e3b54d..5ef0d80a 100644
--- a/versioned_docs/version-3.0.0/08-upgrading/04-archive/03-upgrade-to-two.md
+++ b/versioned_docs/version-3.0.0/08-upgrading/04-archive/03-upgrade-to-two.md
@@ -284,7 +284,7 @@ To ensure new databases are created with the new representation, the latest migr
 A new empty migration can be created by running the following command in the terminal:
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 #### Migration of existing tables
diff --git a/versioned_docs/version-3.0.0/09-tools/02-lsp.md b/versioned_docs/version-3.0.0/09-tools/02-lsp.md
index 2374cf57..8da02d1b 100644
--- a/versioned_docs/version-3.0.0/09-tools/02-lsp.md
+++ b/versioned_docs/version-3.0.0/09-tools/02-lsp.md
@@ -5,7 +5,7 @@ The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server
 To start the Serverpod LSP server, use the following command:
 
 ```bash
-$ serverpod language-server
+serverpod language-server
 ```
 
 :::info
diff --git a/versioned_docs/version-3.0.0/index.md b/versioned_docs/version-3.0.0/index.md
index 98651371..acb61a6d 100644
--- a/versioned_docs/version-3.0.0/index.md
+++ b/versioned_docs/version-3.0.0/index.md
@@ -64,7 +64,7 @@ Serverpod is tested on Mac, Windows, and Linux. Before you can install Serverpod
 Check your Flutter installation by running the following command in your terminal:
 
 ```bash
-$ flutter doctor
+flutter doctor
 ```
 
 :::
@@ -75,7 +75,7 @@ To make use of Serverpod's database connectivity, you need to have access to a P
 Check your Docker installation by running the following command in your terminal:
 
 ```bash
-$ docker info
+docker info
 ```
 
 If you are using Docker Desktop and you get an error, make sure that Docker is running. You can check this by looking for the Docker icon in your system tray or taskbar. If it's not running, start Docker Desktop and try again.
@@ -86,13 +86,13 @@ If you are using Docker Desktop and you get an error, make sure that Docker is r
 Serverpod is installed using the Dart package manager. To install Serverpod, run the following command in your terminal:
 
 ```bash
-$ dart pub global activate serverpod_cli
+dart pub global activate serverpod_cli
 ```
 
 This command will install the Serverpod command-line interface (CLI) globally on your machine. You can verify the installation by running:
 
 ```bash
-$ serverpod
+serverpod
 ```
 
 If everything is correctly configured, the help for the `serverpod` command is now displayed.
@@ -115,7 +115,7 @@ To create a new Serverpod project, use the `serverpod create` command. It will s
 The project will be created in a new directory with the name you specify. For example, to create a new project called `my_project`, run the following command:
 
 ```bash
-$ serverpod create my_project
+serverpod create my_project
 ```
 
 :::tip
@@ -125,20 +125,20 @@ The name of the project must be a valid Dart package name. It should start with
 To run your new project you must first start the database from the Docker file that is included with the project. Do this by running the `docker compose up` command in the server directory:
 
 ```bash
-$ cd my_project/my_project_server
-$ docker compose up
+cd my_project/my_project_server
+docker compose up
 ```
 
 This will start the PostgreSQL database. You can stop the database server by pressing `Ctrl+C` in the terminal. If you want to run the servers in the background, you can use the `-d` flag:
 
 ```bash
-$ docker compose up -d
+docker compose up -d
 ```
 
 This will start the database server in detached mode, meaning it will run in the background and you can safely close the terminal window without stopping it. Stop the database container by running the following command from the server directory:
 
 ```bash
-$ docker compose down
+docker compose down
 ```
 
 :::tip
@@ -148,8 +148,8 @@ If you are using Docker Desktop, you can see and manage all your installed Docke
 Now that the database is up and running we can start the Serverpod server. Because we are running the project for the first time, we need to create the database tables used by Serverpod. This is done through a [database migration](./06-concepts/06-database/11-migrations.md). An initial migration is already created for us, so all we need to do is pass the `--apply-migrations` flag when starting the server:
 
 ```bash
-$ cd my_project/my_project_server
-$ dart run bin/main.dart --apply-migrations
+cd my_project/my_project_server
+dart run bin/main.dart --apply-migrations
 ```
 
 This will start the server and set up the initial database tables. You can now access the server at `http://localhost:8080` and the web server is available at `http://localhost:8082`. It should look like this:
@@ -159,8 +159,8 @@ This will start the server and set up the initial database tables. You can now a
 Now let's run our Flutter app. You can do this by running `flutter run -d chrome` in the flutter directory:
 
 ```bash
-$ cd my_project/my_project_flutter
-$ flutter run -d chrome
+cd my_project/my_project_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look like this:
diff --git a/versioned_docs/version-3.0.0/serverpod-mini.md b/versioned_docs/version-3.0.0/serverpod-mini.md
index 62516c16..2ee7d247 100644
--- a/versioned_docs/version-3.0.0/serverpod-mini.md
+++ b/versioned_docs/version-3.0.0/serverpod-mini.md
@@ -39,7 +39,7 @@ Serverpod Mini is a lightweight version of Serverpod that is perfect for small p
 Create a mini project by running:
 
 ```bash
-$ serverpod create myminipod --mini
+serverpod create myminipod --mini
 ```
 
 Serverpod will create a new project for you. It contains three Dart packages, but you only need to pay attention to the `myminipod_server` and `myminipod_flutter` directories. The server directory contains your server files, and the flutter directory contains your app. The third package (`myminipod_client`) contains generated code that is used by the Flutter app to communicate with the server.
@@ -47,15 +47,15 @@ Serverpod will create a new project for you. It contains three Dart packages, bu
 Start your server by changing directory into your server directory, and run the `bin/main.dart` file:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ dart bin/main.dart
+cd myminipod/myminipod_server
+dart bin/main.dart
 ```
 
 Your default project comes with a sample Flutter app, all hooked up to talk with your server. Run it with the `flutter` command:
 
 ```bash
-$ cd myminipod/myminipod_flutter
-$ flutter run -d chrome
+cd myminipod/myminipod_flutter
+flutter run -d chrome
 ```
 
 Easy as that. 🥳
@@ -83,8 +83,8 @@ For types, you can use most basic Dart types, such as `String`, `double`, `int`,
 Whenever you add or edit a model file, run `serverpod generate` in your server directory. Then, Serverpod will generate all the updated Dart classes:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Adding methods to your server
@@ -120,8 +120,8 @@ class CompanyEndpoint extends Endpoint {
 After adding or modifying endpoints and endpoint methods, you must run `serverpod generate` to keep your Flutter app up-to-date.
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Calling the server methods from the app
diff --git a/versioned_docs/version-3.1.0/01-get-started/01-creating-endpoints.md b/versioned_docs/version-3.1.0/01-get-started/01-creating-endpoints.md
index ebfb16da..6a5402af 100644
--- a/versioned_docs/version-3.1.0/01-get-started/01-creating-endpoints.md
+++ b/versioned_docs/version-3.1.0/01-get-started/01-creating-endpoints.md
@@ -37,8 +37,8 @@ development:
 Next, we add the Dartantic AI package as a dependency to our server. This package provides a convenient interface for working with different AI providers, including Google's Gemini API.
 
 ```bash
-$ cd magic_recipe_server
-$ dart pub add dartantic_ai
+cd magic_recipe_server
+dart pub add dartantic_ai
 ```
 
 ## Create a new endpoint
@@ -99,8 +99,8 @@ For methods to be recognized by Serverpod, they need to return a typed `Future`
 Now, you need to generate the code for your new endpoint. You do this by running `serverpod generate` in the server directory of your project:
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 `serverpod generate` will create bindings for the endpoint and register them in the server's `generated/protocol.dart` file. It will also generate the required client code so that you can call your new `generateRecipe` method from your app.
@@ -220,16 +220,16 @@ Before you start your server, ensure no other Serverpod server is running. Also,
 Let's try our new recipe app! First, start the server:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart --apply-migrations
+cd magic_recipe_server
+docker compose up -d
+dart bin/main.dart --apply-migrations
 ```
 
 Now, you can start the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser:
diff --git a/versioned_docs/version-3.1.0/01-get-started/02-models-and-data.md b/versioned_docs/version-3.1.0/01-get-started/02-models-and-data.md
index bd2ed418..1b25a289 100644
--- a/versioned_docs/version-3.1.0/01-get-started/02-models-and-data.md
+++ b/versioned_docs/version-3.1.0/01-get-started/02-models-and-data.md
@@ -33,8 +33,8 @@ You can use most primitive Dart types here or any other models you have specifie
 To generate the code for the model, run the `serverpod generate` command in your server directory:
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 This will generate the code for the model and create a new file called `recipe.dart` in the `lib/src/generated` directory. It will also update the client code in `magic_recipe/magic_recipe_client` so you can use it in your Flutter app.
@@ -132,8 +132,8 @@ class RecipeEndpoint extends Endpoint {
 First, we need to update our generated client by running `serverpod generate`.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 Now that we have created the `Recipe` model we can use it in the app. We will do this in the `_callGenerateRecipe` method of the `magic_recipe_flutter/lib/main.dart` file. Let's update our `RecipeWidget` so that it displays the author and year of the recipe in addition to the recipe itself.
@@ -432,16 +432,16 @@ class ResultDisplay extends StatelessWidget {
 First, start the server:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart
+cd magic_recipe_server
+docker compose up -d
+dart bin/main.dart
 ```
 
 Then, start the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look something like this:
diff --git a/versioned_docs/version-3.1.0/01-get-started/03-working-with-the-database.md b/versioned_docs/version-3.1.0/01-get-started/03-working-with-the-database.md
index 51034f07..9ce74949 100644
--- a/versioned_docs/version-3.1.0/01-get-started/03-working-with-the-database.md
+++ b/versioned_docs/version-3.1.0/01-get-started/03-working-with-the-database.md
@@ -41,9 +41,9 @@ To create a migration, follow these two steps in order:
 2. Run `serverpod create-migration` to create the necessary database migration.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
-$ serverpod create-migration
+cd magic_recipe_server
+serverpod generate
+serverpod create-migration
 ```
 
 Each time you run `serverpod create-migration`, a new migration file will be created in your _migrations_ folder. These step-by-step migrations provide a history of your database changes and allow you to roll back changes if needed.
@@ -189,8 +189,8 @@ The `insertRow` method is used to insert a new row into the database. The `find`
 Like before, when you change something that has an effect on your client code, you need to run `serverpod generate`. We don't need to run `serverpod create-migrations` again because we already created a migration in the previous step and haven't done any changes that affect the database.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 ## Call the endpoint from the app
@@ -433,9 +433,9 @@ To run the application with database support, follow these steps in order:
 First, start the database and apply migrations:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d                   # Start the database container
-$ dart bin/main.dart --apply-migrations  # Apply any pending migrations
+cd magic_recipe_server
+docker compose up -d                   # Start the database container
+dart bin/main.dart --apply-migrations  # Apply any pending migrations
 ```
 
 :::tip
@@ -445,8 +445,8 @@ The `--apply-migrations` flag is safe to use during development - if no migratio
 Next, launch the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 ## Summary
diff --git a/versioned_docs/version-3.1.0/06-concepts/06-database/01-connection.md b/versioned_docs/version-3.1.0/06-concepts/06-database/01-connection.md
index 0c9ce97a..05bff19a 100644
--- a/versioned_docs/version-3.1.0/06-concepts/06-database/01-connection.md
+++ b/versioned_docs/version-3.1.0/06-concepts/06-database/01-connection.md
@@ -100,19 +100,19 @@ development:
 A newly created Serverpod project has a preconfigured Docker instance with a Postgres database set up. Run the following command from the root of the `server` package to start the database:
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To stop the database run:
 
 ```bash
-$ docker compose stop
+docker compose stop
 ```
 
 To remove the database and __delete__ all associated data, run:
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
 
 ## Connecting to a custom Postgres instance
diff --git a/versioned_docs/version-3.1.0/06-concepts/06-database/11-migrations.md b/versioned_docs/version-3.1.0/06-concepts/06-database/11-migrations.md
index 80bc54c2..ad8f803b 100644
--- a/versioned_docs/version-3.1.0/06-concepts/06-database/11-migrations.md
+++ b/versioned_docs/version-3.1.0/06-concepts/06-database/11-migrations.md
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,7 +47,7 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
@@ -55,7 +55,7 @@ $ serverpod create-migration --force
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,7 +162,7 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
@@ -170,7 +170,7 @@ $ serverpod create-repair-migration --force
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
diff --git a/versioned_docs/version-3.1.0/06-concepts/10-modules.md b/versioned_docs/version-3.1.0/06-concepts/10-modules.md
index 442b0747..1bd1f12f 100644
--- a/versioned_docs/version-3.1.0/06-concepts/10-modules.md
+++ b/versioned_docs/version-3.1.0/06-concepts/10-modules.md
@@ -32,15 +32,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -79,13 +79,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.
diff --git a/versioned_docs/version-3.1.0/06-concepts/11-authentication/04-providers/02-google/01-setup.md b/versioned_docs/version-3.1.0/06-concepts/11-authentication/04-providers/02-google/01-setup.md
index d5d72451..14f09004 100644
--- a/versioned_docs/version-3.1.0/06-concepts/11-authentication/04-providers/02-google/01-setup.md
+++ b/versioned_docs/version-3.1.0/06-concepts/11-authentication/04-providers/02-google/01-setup.md
@@ -190,7 +190,7 @@ If your `google-services.json` does not include a web OAuth client entry, you ma
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 :::
 
@@ -208,7 +208,7 @@ Navigate to _Clients_ and select the server credentials (the one configured as a
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 :::
 
diff --git a/versioned_docs/version-3.1.0/06-concepts/11-authentication/11-legacy/01-setup.md b/versioned_docs/version-3.1.0/06-concepts/11-authentication/11-legacy/01-setup.md
index 677ac269..c2769e98 100644
--- a/versioned_docs/version-3.1.0/06-concepts/11-authentication/11-legacy/01-setup.md
+++ b/versioned_docs/version-3.1.0/06-concepts/11-authentication/11-legacy/01-setup.md
@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
 Add the module as a dependency to the server project's `pubspec.yaml`.
 
 ```sh
-$ dart pub add serverpod_auth_server
+dart pub add serverpod_auth_server
 ```
 
 Add the authentication handler to the Serverpod instance.
@@ -46,7 +46,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
@@ -54,19 +54,19 @@ $ serverpod generate
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../../database/migrations).
diff --git a/versioned_docs/version-3.1.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md b/versioned_docs/version-3.1.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
index 7b52c420..8fe10f12 100644
--- a/versioned_docs/version-3.1.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
+++ b/versioned_docs/version-3.1.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
@@ -119,7 +119,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -136,7 +136,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::
diff --git a/versioned_docs/version-3.1.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md b/versioned_docs/version-3.1.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
index f5aab8fc..b1a4e0dc 100644
--- a/versioned_docs/version-3.1.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
+++ b/versioned_docs/version-3.1.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
@@ -31,8 +31,8 @@ To add authentication with Firebase, you must first install and initialize the F
 The short version:
 
 ```bash
-$ flutter pub add firebase_core firebase_auth firebase_ui_auth
-$ flutterfire configure
+flutter pub add firebase_core firebase_auth firebase_ui_auth
+flutterfire configure
 ```
 
 In the Firebase console, configure the different social sign-ins you plan to use, under `Authentication > Sign-in method`.
@@ -67,7 +67,7 @@ void main() async {
 Add the [serverpod_auth_firebase_flutter](https://pub.dev/packages/serverpod_auth_firebase_flutter) package.
 
 ```bash
-$ flutter pub add serverpod_auth_firebase_flutter
+flutter pub add serverpod_auth_firebase_flutter
 ```
 
 The `SignInWithFirebaseButton` is a convenient button that triggers the sign-in flow and can be used like this:
diff --git a/versioned_docs/version-3.1.0/06-concepts/12-file-uploads.md b/versioned_docs/version-3.1.0/06-concepts/12-file-uploads.md
index bbb788ab..b3439eba 100644
--- a/versioned_docs/version-3.1.0/06-concepts/12-file-uploads.md
+++ b/versioned_docs/version-3.1.0/06-concepts/12-file-uploads.md
@@ -98,7 +98,7 @@ You may also want to add the bucket as a backend for your load balancer to give
 When you have set up your GCP bucket, you need to configure it in Serverpod. Add the GCP package to your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_gcp
+dart pub add serverpod_cloud_storage_gcp
 ```
 
 ```dart
@@ -126,7 +126,7 @@ This section shows how to set up a storage using S3. Before you write your Dart
 When you are all set with the AWS setup, include the S3 package in your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_s3
+dart pub add serverpod_cloud_storage_s3
 ```
 
 ```dart
diff --git a/versioned_docs/version-3.1.0/06-concepts/21-experimental.md b/versioned_docs/version-3.1.0/06-concepts/21-experimental.md
index 075877af..6f87ca22 100644
--- a/versioned_docs/version-3.1.0/06-concepts/21-experimental.md
+++ b/versioned_docs/version-3.1.0/06-concepts/21-experimental.md
@@ -25,7 +25,7 @@ If possible, the experimental API will remain for some time as `@deprecated`, an
 Some of the experimental features are enabled by including the `--experimental-features` flag when running the serverpod command:
 
 ```bash
-$ serverpod generate --experimental-features=all
+serverpod generate --experimental-features=all
 ```
 
 The current options you can pass are:
diff --git a/versioned_docs/version-3.1.0/07-deployments/02-deploying-to-gce-terraform.md b/versioned_docs/version-3.1.0/07-deployments/02-deploying-to-gce-terraform.md
index 3a2ac487..f55c21bd 100644
--- a/versioned_docs/version-3.1.0/07-deployments/02-deploying-to-gce-terraform.md
+++ b/versioned_docs/version-3.1.0/07-deployments/02-deploying-to-gce-terraform.md
@@ -126,7 +126,7 @@ Depending on your domain name registrar, the process for setting up your domain
 You can test that the domain points to the correct name servers by running `dig` on the command line. It will output the domain name servers.
 
 ```bash
-$ dig +short NS examplepod.com
+dig +short NS examplepod.com
 ```
 
 Should yield an output similar to this:
@@ -228,13 +228,13 @@ If you are deploying a staging server in addition to your production server, you
 Once you have configured Terraform and your Serverpod, you are ready to deploy your infrastructure. Make sure that you have `cd` into your `deploy/gcp/terraform_gce` directory. Now run:
 
 ```bash
-$ terraform init
+terraform init
 ```
 
 This will download the Serverpod module and initialize your Terraform configuration. Now, deploy your infrastructure by running:
 
 ```bash
-$ terraform apply
+terraform apply
 ```
 
 Terraform will ask you for the password to your production and staging database. You will find the passwords in your `config/passwords.yaml` file. If you are not deploying a staging server, you can leave the staging database password blank.
diff --git a/versioned_docs/version-3.1.0/07-deployments/03-deploying-to-gcr-console.md b/versioned_docs/version-3.1.0/07-deployments/03-deploying-to-gcr-console.md
index cdd5991d..b647215c 100644
--- a/versioned_docs/version-3.1.0/07-deployments/03-deploying-to-gcr-console.md
+++ b/versioned_docs/version-3.1.0/07-deployments/03-deploying-to-gcr-console.md
@@ -11,13 +11,13 @@ Before you begin, you will need to install and configure the Google Cloud CLI to
 - To [initialize](https://cloud.google.com/sdk/docs/initializing) the gcloud CLI, run the following command:
 
 ```bash
-$ gcloud init
+gcloud init
 ```
 
 - To set the default project for your Cloud Run service:
 
 ```bash
-$ gcloud config set project <PROJECT_ID>
+gcloud config set project <PROJECT_ID>
 ```
 
 ## Setup the database
@@ -75,8 +75,8 @@ database:
 Your server is now ready to be deployed. When you created your project, Serverpod also created a script for deploying your server. Copy it to the root of your server directory and make it executable. Make sure you are in your server directory (e.g., `myproject_server`). Then run the following command:
 
 ```bash
-$ cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
-$ chmod u+x cloud-run-deploy.sh
+cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
+chmod u+x cloud-run-deploy.sh
 ```
 
 Open up the script in your favorite editor. You will need to fill in your _database instance's connection name_ and the _email of your service account_.
@@ -84,7 +84,7 @@ Open up the script in your favorite editor. You will need to fill in your _datab
 Now, deploy your server by running the following:
 
 ```bash
-$ ./cloud-run-deploy.sh
+./cloud-run-deploy.sh
 ```
 
 The script runs two deployment commands, one for your API and one for the Insights API used by the Serverpod app. While running, it may ask you to enable the Cloud Run and SQL Admin services. Answer yes to all these questions.
diff --git a/versioned_docs/version-3.1.0/07-deployments/04-deploying-to-aws.md b/versioned_docs/version-3.1.0/07-deployments/04-deploying-to-aws.md
index af139474..713e4d4c 100644
--- a/versioned_docs/version-3.1.0/07-deployments/04-deploying-to-aws.md
+++ b/versioned_docs/version-3.1.0/07-deployments/04-deploying-to-aws.md
@@ -202,14 +202,14 @@ database:
 Your Serverpod should now be configured and ready to be deployed. Exciting times! Open up a terminal and `cd` into your server `aws/terraform` directory. First, you need to add an environment variable so that Terraform can correctly set the password for the Postgres database. You will find the production password for the database in your `config/passwords.yaml` file.
 
 ```bash
-$ export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
+export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
 ```
 
 Next, we are ready to initialize Terraform and deploy our server. You will only need to run the `terraform init` command the first time you deploy the configuration.
 
 ```bash
-$ terraform init
-$ terraform apply
+terraform init
+terraform apply
 ```
 
 Terraform will now run some checks and make a plan for the deployment. If everything looks good, it will ask you if you are ready to go ahead with the changes. Type `yes` and hit the return key. Applying the changes can take up to five minutes as AWS creates the different resources needed for your Serverpod.
diff --git a/versioned_docs/version-3.1.0/07-deployments/05-general.md b/versioned_docs/version-3.1.0/07-deployments/05-general.md
index 981bb8d9..fa1f3878 100644
--- a/versioned_docs/version-3.1.0/07-deployments/05-general.md
+++ b/versioned_docs/version-3.1.0/07-deployments/05-general.md
@@ -11,7 +11,7 @@ Serverpod will not run without a link to a Postgres database with the correct ta
 Serverpod has three main configuration files, depending on which mode the server is running; `development`, `staging`, or `production`. The files are located in the `config/` directory. By default, the server will start in development mode. To use another configuration file, use the `--mode` option when starting the server. If you are running multiple servers in a cluster, use the `--server-id` option to specify the id of each server. By default, the server will run as id `default`. For instance, to start the server in production mode with id `2`, run the following command:
 
 ```bash
-$ dart bin/main.dart --mode production --server-id 2
+dart bin/main.dart --mode production --server-id 2
 ```
 
 :::info
@@ -35,7 +35,7 @@ Serverpod can assume different roles depending on your configuration. If you run
 You can specify the role of your server when you launch it by setting the `--role` argument.
 
 ```bash
-$ dart bin/main.dart --role serverless
+dart bin/main.dart --role serverless
 ```
 
 ## Docker container
diff --git a/versioned_docs/version-3.1.0/08-upgrading/03-upgrade-to-pgvector.md b/versioned_docs/version-3.1.0/08-upgrading/03-upgrade-to-pgvector.md
index 24896009..6f94d34c 100644
--- a/versioned_docs/version-3.1.0/08-upgrading/03-upgrade-to-pgvector.md
+++ b/versioned_docs/version-3.1.0/08-upgrading/03-upgrade-to-pgvector.md
@@ -64,8 +64,8 @@ fields:
 4. Generate and apply a migration:
 
 ```bash
-$ serverpod create-migration
-$ dart run bin/main.dart --apply-migrations
+serverpod create-migration
+dart run bin/main.dart --apply-migrations
 ```
 
 For more details on creating and applying migrations, see the [Migrations](../concepts/database/migrations) section.
diff --git a/versioned_docs/version-3.1.0/08-upgrading/04-archive/03-upgrade-to-two.md b/versioned_docs/version-3.1.0/08-upgrading/04-archive/03-upgrade-to-two.md
index 54e3b54d..5ef0d80a 100644
--- a/versioned_docs/version-3.1.0/08-upgrading/04-archive/03-upgrade-to-two.md
+++ b/versioned_docs/version-3.1.0/08-upgrading/04-archive/03-upgrade-to-two.md
@@ -284,7 +284,7 @@ To ensure new databases are created with the new representation, the latest migr
 A new empty migration can be created by running the following command in the terminal:
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 #### Migration of existing tables
diff --git a/versioned_docs/version-3.1.0/09-tools/02-lsp.md b/versioned_docs/version-3.1.0/09-tools/02-lsp.md
index 2374cf57..8da02d1b 100644
--- a/versioned_docs/version-3.1.0/09-tools/02-lsp.md
+++ b/versioned_docs/version-3.1.0/09-tools/02-lsp.md
@@ -5,7 +5,7 @@ The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server
 To start the Serverpod LSP server, use the following command:
 
 ```bash
-$ serverpod language-server
+serverpod language-server
 ```
 
 :::info
diff --git a/versioned_docs/version-3.1.0/09-tools/03-run-scripts.md b/versioned_docs/version-3.1.0/09-tools/03-run-scripts.md
index 699ed8ce..d040adcb 100644
--- a/versioned_docs/version-3.1.0/09-tools/03-run-scripts.md
+++ b/versioned_docs/version-3.1.0/09-tools/03-run-scripts.md
@@ -19,13 +19,13 @@ serverpod:
 To run a script:
 
 ```bash
-$ serverpod run start
+serverpod run start
 ```
 
 To list all available scripts, use the `--list` flag or omit the script name:
 
 ```bash
-$ serverpod run --list
+serverpod run --list
 ```
 
 Scripts run in a shell environment (`bash` on Linux/macOS, `cmd` on Windows), so you can use pipes, conditionals, and environment variables. The CLI forwards signals like `Ctrl+C` to the running script and propagates exit codes.
diff --git a/versioned_docs/version-3.1.0/index.md b/versioned_docs/version-3.1.0/index.md
index 98651371..acb61a6d 100644
--- a/versioned_docs/version-3.1.0/index.md
+++ b/versioned_docs/version-3.1.0/index.md
@@ -64,7 +64,7 @@ Serverpod is tested on Mac, Windows, and Linux. Before you can install Serverpod
 Check your Flutter installation by running the following command in your terminal:
 
 ```bash
-$ flutter doctor
+flutter doctor
 ```
 
 :::
@@ -75,7 +75,7 @@ To make use of Serverpod's database connectivity, you need to have access to a P
 Check your Docker installation by running the following command in your terminal:
 
 ```bash
-$ docker info
+docker info
 ```
 
 If you are using Docker Desktop and you get an error, make sure that Docker is running. You can check this by looking for the Docker icon in your system tray or taskbar. If it's not running, start Docker Desktop and try again.
@@ -86,13 +86,13 @@ If you are using Docker Desktop and you get an error, make sure that Docker is r
 Serverpod is installed using the Dart package manager. To install Serverpod, run the following command in your terminal:
 
 ```bash
-$ dart pub global activate serverpod_cli
+dart pub global activate serverpod_cli
 ```
 
 This command will install the Serverpod command-line interface (CLI) globally on your machine. You can verify the installation by running:
 
 ```bash
-$ serverpod
+serverpod
 ```
 
 If everything is correctly configured, the help for the `serverpod` command is now displayed.
@@ -115,7 +115,7 @@ To create a new Serverpod project, use the `serverpod create` command. It will s
 The project will be created in a new directory with the name you specify. For example, to create a new project called `my_project`, run the following command:
 
 ```bash
-$ serverpod create my_project
+serverpod create my_project
 ```
 
 :::tip
@@ -125,20 +125,20 @@ The name of the project must be a valid Dart package name. It should start with
 To run your new project you must first start the database from the Docker file that is included with the project. Do this by running the `docker compose up` command in the server directory:
 
 ```bash
-$ cd my_project/my_project_server
-$ docker compose up
+cd my_project/my_project_server
+docker compose up
 ```
 
 This will start the PostgreSQL database. You can stop the database server by pressing `Ctrl+C` in the terminal. If you want to run the servers in the background, you can use the `-d` flag:
 
 ```bash
-$ docker compose up -d
+docker compose up -d
 ```
 
 This will start the database server in detached mode, meaning it will run in the background and you can safely close the terminal window without stopping it. Stop the database container by running the following command from the server directory:
 
 ```bash
-$ docker compose down
+docker compose down
 ```
 
 :::tip
@@ -148,8 +148,8 @@ If you are using Docker Desktop, you can see and manage all your installed Docke
 Now that the database is up and running we can start the Serverpod server. Because we are running the project for the first time, we need to create the database tables used by Serverpod. This is done through a [database migration](./06-concepts/06-database/11-migrations.md). An initial migration is already created for us, so all we need to do is pass the `--apply-migrations` flag when starting the server:
 
 ```bash
-$ cd my_project/my_project_server
-$ dart run bin/main.dart --apply-migrations
+cd my_project/my_project_server
+dart run bin/main.dart --apply-migrations
 ```
 
 This will start the server and set up the initial database tables. You can now access the server at `http://localhost:8080` and the web server is available at `http://localhost:8082`. It should look like this:
@@ -159,8 +159,8 @@ This will start the server and set up the initial database tables. You can now a
 Now let's run our Flutter app. You can do this by running `flutter run -d chrome` in the flutter directory:
 
 ```bash
-$ cd my_project/my_project_flutter
-$ flutter run -d chrome
+cd my_project/my_project_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look like this:
diff --git a/versioned_docs/version-3.1.0/serverpod-mini.md b/versioned_docs/version-3.1.0/serverpod-mini.md
index 62516c16..2ee7d247 100644
--- a/versioned_docs/version-3.1.0/serverpod-mini.md
+++ b/versioned_docs/version-3.1.0/serverpod-mini.md
@@ -39,7 +39,7 @@ Serverpod Mini is a lightweight version of Serverpod that is perfect for small p
 Create a mini project by running:
 
 ```bash
-$ serverpod create myminipod --mini
+serverpod create myminipod --mini
 ```
 
 Serverpod will create a new project for you. It contains three Dart packages, but you only need to pay attention to the `myminipod_server` and `myminipod_flutter` directories. The server directory contains your server files, and the flutter directory contains your app. The third package (`myminipod_client`) contains generated code that is used by the Flutter app to communicate with the server.
@@ -47,15 +47,15 @@ Serverpod will create a new project for you. It contains three Dart packages, bu
 Start your server by changing directory into your server directory, and run the `bin/main.dart` file:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ dart bin/main.dart
+cd myminipod/myminipod_server
+dart bin/main.dart
 ```
 
 Your default project comes with a sample Flutter app, all hooked up to talk with your server. Run it with the `flutter` command:
 
 ```bash
-$ cd myminipod/myminipod_flutter
-$ flutter run -d chrome
+cd myminipod/myminipod_flutter
+flutter run -d chrome
 ```
 
 Easy as that. 🥳
@@ -83,8 +83,8 @@ For types, you can use most basic Dart types, such as `String`, `double`, `int`,
 Whenever you add or edit a model file, run `serverpod generate` in your server directory. Then, Serverpod will generate all the updated Dart classes:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Adding methods to your server
@@ -120,8 +120,8 @@ class CompanyEndpoint extends Endpoint {
 After adding or modifying endpoints and endpoint methods, you must run `serverpod generate` to keep your Flutter app up-to-date.
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Calling the server methods from the app
diff --git a/versioned_docs/version-3.2.0/01-get-started/01-creating-endpoints.md b/versioned_docs/version-3.2.0/01-get-started/01-creating-endpoints.md
index ebfb16da..6a5402af 100644
--- a/versioned_docs/version-3.2.0/01-get-started/01-creating-endpoints.md
+++ b/versioned_docs/version-3.2.0/01-get-started/01-creating-endpoints.md
@@ -37,8 +37,8 @@ development:
 Next, we add the Dartantic AI package as a dependency to our server. This package provides a convenient interface for working with different AI providers, including Google's Gemini API.
 
 ```bash
-$ cd magic_recipe_server
-$ dart pub add dartantic_ai
+cd magic_recipe_server
+dart pub add dartantic_ai
 ```
 
 ## Create a new endpoint
@@ -99,8 +99,8 @@ For methods to be recognized by Serverpod, they need to return a typed `Future`
 Now, you need to generate the code for your new endpoint. You do this by running `serverpod generate` in the server directory of your project:
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 `serverpod generate` will create bindings for the endpoint and register them in the server's `generated/protocol.dart` file. It will also generate the required client code so that you can call your new `generateRecipe` method from your app.
@@ -220,16 +220,16 @@ Before you start your server, ensure no other Serverpod server is running. Also,
 Let's try our new recipe app! First, start the server:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart --apply-migrations
+cd magic_recipe_server
+docker compose up -d
+dart bin/main.dart --apply-migrations
 ```
 
 Now, you can start the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser:
diff --git a/versioned_docs/version-3.2.0/01-get-started/02-models-and-data.md b/versioned_docs/version-3.2.0/01-get-started/02-models-and-data.md
index bd2ed418..1b25a289 100644
--- a/versioned_docs/version-3.2.0/01-get-started/02-models-and-data.md
+++ b/versioned_docs/version-3.2.0/01-get-started/02-models-and-data.md
@@ -33,8 +33,8 @@ You can use most primitive Dart types here or any other models you have specifie
 To generate the code for the model, run the `serverpod generate` command in your server directory:
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 This will generate the code for the model and create a new file called `recipe.dart` in the `lib/src/generated` directory. It will also update the client code in `magic_recipe/magic_recipe_client` so you can use it in your Flutter app.
@@ -132,8 +132,8 @@ class RecipeEndpoint extends Endpoint {
 First, we need to update our generated client by running `serverpod generate`.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 Now that we have created the `Recipe` model we can use it in the app. We will do this in the `_callGenerateRecipe` method of the `magic_recipe_flutter/lib/main.dart` file. Let's update our `RecipeWidget` so that it displays the author and year of the recipe in addition to the recipe itself.
@@ -432,16 +432,16 @@ class ResultDisplay extends StatelessWidget {
 First, start the server:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart
+cd magic_recipe_server
+docker compose up -d
+dart bin/main.dart
 ```
 
 Then, start the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look something like this:
diff --git a/versioned_docs/version-3.2.0/01-get-started/03-working-with-the-database.md b/versioned_docs/version-3.2.0/01-get-started/03-working-with-the-database.md
index 51034f07..9ce74949 100644
--- a/versioned_docs/version-3.2.0/01-get-started/03-working-with-the-database.md
+++ b/versioned_docs/version-3.2.0/01-get-started/03-working-with-the-database.md
@@ -41,9 +41,9 @@ To create a migration, follow these two steps in order:
 2. Run `serverpod create-migration` to create the necessary database migration.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
-$ serverpod create-migration
+cd magic_recipe_server
+serverpod generate
+serverpod create-migration
 ```
 
 Each time you run `serverpod create-migration`, a new migration file will be created in your _migrations_ folder. These step-by-step migrations provide a history of your database changes and allow you to roll back changes if needed.
@@ -189,8 +189,8 @@ The `insertRow` method is used to insert a new row into the database. The `find`
 Like before, when you change something that has an effect on your client code, you need to run `serverpod generate`. We don't need to run `serverpod create-migrations` again because we already created a migration in the previous step and haven't done any changes that affect the database.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 ## Call the endpoint from the app
@@ -433,9 +433,9 @@ To run the application with database support, follow these steps in order:
 First, start the database and apply migrations:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d                   # Start the database container
-$ dart bin/main.dart --apply-migrations  # Apply any pending migrations
+cd magic_recipe_server
+docker compose up -d                   # Start the database container
+dart bin/main.dart --apply-migrations  # Apply any pending migrations
 ```
 
 :::tip
@@ -445,8 +445,8 @@ The `--apply-migrations` flag is safe to use during development - if no migratio
 Next, launch the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 ## Summary
diff --git a/versioned_docs/version-3.2.0/06-concepts/06-database/01-connection.md b/versioned_docs/version-3.2.0/06-concepts/06-database/01-connection.md
index 0c9ce97a..05bff19a 100644
--- a/versioned_docs/version-3.2.0/06-concepts/06-database/01-connection.md
+++ b/versioned_docs/version-3.2.0/06-concepts/06-database/01-connection.md
@@ -100,19 +100,19 @@ development:
 A newly created Serverpod project has a preconfigured Docker instance with a Postgres database set up. Run the following command from the root of the `server` package to start the database:
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To stop the database run:
 
 ```bash
-$ docker compose stop
+docker compose stop
 ```
 
 To remove the database and __delete__ all associated data, run:
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
 
 ## Connecting to a custom Postgres instance
diff --git a/versioned_docs/version-3.2.0/06-concepts/06-database/11-migrations.md b/versioned_docs/version-3.2.0/06-concepts/06-database/11-migrations.md
index 80bc54c2..ad8f803b 100644
--- a/versioned_docs/version-3.2.0/06-concepts/06-database/11-migrations.md
+++ b/versioned_docs/version-3.2.0/06-concepts/06-database/11-migrations.md
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,7 +47,7 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
@@ -55,7 +55,7 @@ $ serverpod create-migration --force
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,7 +162,7 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
@@ -170,7 +170,7 @@ $ serverpod create-repair-migration --force
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
diff --git a/versioned_docs/version-3.2.0/06-concepts/10-modules.md b/versioned_docs/version-3.2.0/06-concepts/10-modules.md
index 442b0747..1bd1f12f 100644
--- a/versioned_docs/version-3.2.0/06-concepts/10-modules.md
+++ b/versioned_docs/version-3.2.0/06-concepts/10-modules.md
@@ -32,15 +32,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -79,13 +79,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.
diff --git a/versioned_docs/version-3.2.0/06-concepts/11-authentication/04-providers/02-google/01-setup.md b/versioned_docs/version-3.2.0/06-concepts/11-authentication/04-providers/02-google/01-setup.md
index d5d72451..14f09004 100644
--- a/versioned_docs/version-3.2.0/06-concepts/11-authentication/04-providers/02-google/01-setup.md
+++ b/versioned_docs/version-3.2.0/06-concepts/11-authentication/04-providers/02-google/01-setup.md
@@ -190,7 +190,7 @@ If your `google-services.json` does not include a web OAuth client entry, you ma
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 :::
 
@@ -208,7 +208,7 @@ Navigate to _Clients_ and select the server credentials (the one configured as a
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 :::
 
diff --git a/versioned_docs/version-3.2.0/06-concepts/11-authentication/11-legacy/01-setup.md b/versioned_docs/version-3.2.0/06-concepts/11-authentication/11-legacy/01-setup.md
index 677ac269..c2769e98 100644
--- a/versioned_docs/version-3.2.0/06-concepts/11-authentication/11-legacy/01-setup.md
+++ b/versioned_docs/version-3.2.0/06-concepts/11-authentication/11-legacy/01-setup.md
@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
 Add the module as a dependency to the server project's `pubspec.yaml`.
 
 ```sh
-$ dart pub add serverpod_auth_server
+dart pub add serverpod_auth_server
 ```
 
 Add the authentication handler to the Serverpod instance.
@@ -46,7 +46,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
@@ -54,19 +54,19 @@ $ serverpod generate
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../../database/migrations).
diff --git a/versioned_docs/version-3.2.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md b/versioned_docs/version-3.2.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
index 7b52c420..8fe10f12 100644
--- a/versioned_docs/version-3.2.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
+++ b/versioned_docs/version-3.2.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
@@ -119,7 +119,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -136,7 +136,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::
diff --git a/versioned_docs/version-3.2.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md b/versioned_docs/version-3.2.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
index f5aab8fc..b1a4e0dc 100644
--- a/versioned_docs/version-3.2.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
+++ b/versioned_docs/version-3.2.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
@@ -31,8 +31,8 @@ To add authentication with Firebase, you must first install and initialize the F
 The short version:
 
 ```bash
-$ flutter pub add firebase_core firebase_auth firebase_ui_auth
-$ flutterfire configure
+flutter pub add firebase_core firebase_auth firebase_ui_auth
+flutterfire configure
 ```
 
 In the Firebase console, configure the different social sign-ins you plan to use, under `Authentication > Sign-in method`.
@@ -67,7 +67,7 @@ void main() async {
 Add the [serverpod_auth_firebase_flutter](https://pub.dev/packages/serverpod_auth_firebase_flutter) package.
 
 ```bash
-$ flutter pub add serverpod_auth_firebase_flutter
+flutter pub add serverpod_auth_firebase_flutter
 ```
 
 The `SignInWithFirebaseButton` is a convenient button that triggers the sign-in flow and can be used like this:
diff --git a/versioned_docs/version-3.2.0/06-concepts/12-file-uploads.md b/versioned_docs/version-3.2.0/06-concepts/12-file-uploads.md
index bbb788ab..b3439eba 100644
--- a/versioned_docs/version-3.2.0/06-concepts/12-file-uploads.md
+++ b/versioned_docs/version-3.2.0/06-concepts/12-file-uploads.md
@@ -98,7 +98,7 @@ You may also want to add the bucket as a backend for your load balancer to give
 When you have set up your GCP bucket, you need to configure it in Serverpod. Add the GCP package to your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_gcp
+dart pub add serverpod_cloud_storage_gcp
 ```
 
 ```dart
@@ -126,7 +126,7 @@ This section shows how to set up a storage using S3. Before you write your Dart
 When you are all set with the AWS setup, include the S3 package in your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_s3
+dart pub add serverpod_cloud_storage_s3
 ```
 
 ```dart
diff --git a/versioned_docs/version-3.2.0/06-concepts/14-scheduling/01-setup.md b/versioned_docs/version-3.2.0/06-concepts/14-scheduling/01-setup.md
index 26b43915..69efaee8 100644
--- a/versioned_docs/version-3.2.0/06-concepts/14-scheduling/01-setup.md
+++ b/versioned_docs/version-3.2.0/06-concepts/14-scheduling/01-setup.md
@@ -31,7 +31,7 @@ It is not valid to override the `invoke` method of the `FutureCall` class. This
 Next, you need to generate the code for your future calls:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 Calling `serverpod generate` will create a type-safe interface for invoking the future calls in the server's `generated/future_calls.dart` file. This interface can be accessed from the Serverpod object.
diff --git a/versioned_docs/version-3.2.0/06-concepts/14-scheduling/02-recurring-task.md b/versioned_docs/version-3.2.0/06-concepts/14-scheduling/02-recurring-task.md
index 0ae25963..ef4444bd 100644
--- a/versioned_docs/version-3.2.0/06-concepts/14-scheduling/02-recurring-task.md
+++ b/versioned_docs/version-3.2.0/06-concepts/14-scheduling/02-recurring-task.md
@@ -20,7 +20,7 @@ class ExampleFutureCall extends FutureCall {
 Next, generate the code for your future call:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 :::info
diff --git a/versioned_docs/version-3.2.0/06-concepts/21-experimental.md b/versioned_docs/version-3.2.0/06-concepts/21-experimental.md
index 075877af..6f87ca22 100644
--- a/versioned_docs/version-3.2.0/06-concepts/21-experimental.md
+++ b/versioned_docs/version-3.2.0/06-concepts/21-experimental.md
@@ -25,7 +25,7 @@ If possible, the experimental API will remain for some time as `@deprecated`, an
 Some of the experimental features are enabled by including the `--experimental-features` flag when running the serverpod command:
 
 ```bash
-$ serverpod generate --experimental-features=all
+serverpod generate --experimental-features=all
 ```
 
 The current options you can pass are:
diff --git a/versioned_docs/version-3.2.0/07-deployments/02-deploying-to-gce-terraform.md b/versioned_docs/version-3.2.0/07-deployments/02-deploying-to-gce-terraform.md
index 3a2ac487..f55c21bd 100644
--- a/versioned_docs/version-3.2.0/07-deployments/02-deploying-to-gce-terraform.md
+++ b/versioned_docs/version-3.2.0/07-deployments/02-deploying-to-gce-terraform.md
@@ -126,7 +126,7 @@ Depending on your domain name registrar, the process for setting up your domain
 You can test that the domain points to the correct name servers by running `dig` on the command line. It will output the domain name servers.
 
 ```bash
-$ dig +short NS examplepod.com
+dig +short NS examplepod.com
 ```
 
 Should yield an output similar to this:
@@ -228,13 +228,13 @@ If you are deploying a staging server in addition to your production server, you
 Once you have configured Terraform and your Serverpod, you are ready to deploy your infrastructure. Make sure that you have `cd` into your `deploy/gcp/terraform_gce` directory. Now run:
 
 ```bash
-$ terraform init
+terraform init
 ```
 
 This will download the Serverpod module and initialize your Terraform configuration. Now, deploy your infrastructure by running:
 
 ```bash
-$ terraform apply
+terraform apply
 ```
 
 Terraform will ask you for the password to your production and staging database. You will find the passwords in your `config/passwords.yaml` file. If you are not deploying a staging server, you can leave the staging database password blank.
diff --git a/versioned_docs/version-3.2.0/07-deployments/03-deploying-to-gcr-console.md b/versioned_docs/version-3.2.0/07-deployments/03-deploying-to-gcr-console.md
index cdd5991d..b647215c 100644
--- a/versioned_docs/version-3.2.0/07-deployments/03-deploying-to-gcr-console.md
+++ b/versioned_docs/version-3.2.0/07-deployments/03-deploying-to-gcr-console.md
@@ -11,13 +11,13 @@ Before you begin, you will need to install and configure the Google Cloud CLI to
 - To [initialize](https://cloud.google.com/sdk/docs/initializing) the gcloud CLI, run the following command:
 
 ```bash
-$ gcloud init
+gcloud init
 ```
 
 - To set the default project for your Cloud Run service:
 
 ```bash
-$ gcloud config set project <PROJECT_ID>
+gcloud config set project <PROJECT_ID>
 ```
 
 ## Setup the database
@@ -75,8 +75,8 @@ database:
 Your server is now ready to be deployed. When you created your project, Serverpod also created a script for deploying your server. Copy it to the root of your server directory and make it executable. Make sure you are in your server directory (e.g., `myproject_server`). Then run the following command:
 
 ```bash
-$ cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
-$ chmod u+x cloud-run-deploy.sh
+cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
+chmod u+x cloud-run-deploy.sh
 ```
 
 Open up the script in your favorite editor. You will need to fill in your _database instance's connection name_ and the _email of your service account_.
@@ -84,7 +84,7 @@ Open up the script in your favorite editor. You will need to fill in your _datab
 Now, deploy your server by running the following:
 
 ```bash
-$ ./cloud-run-deploy.sh
+./cloud-run-deploy.sh
 ```
 
 The script runs two deployment commands, one for your API and one for the Insights API used by the Serverpod app. While running, it may ask you to enable the Cloud Run and SQL Admin services. Answer yes to all these questions.
diff --git a/versioned_docs/version-3.2.0/07-deployments/04-deploying-to-aws.md b/versioned_docs/version-3.2.0/07-deployments/04-deploying-to-aws.md
index af139474..713e4d4c 100644
--- a/versioned_docs/version-3.2.0/07-deployments/04-deploying-to-aws.md
+++ b/versioned_docs/version-3.2.0/07-deployments/04-deploying-to-aws.md
@@ -202,14 +202,14 @@ database:
 Your Serverpod should now be configured and ready to be deployed. Exciting times! Open up a terminal and `cd` into your server `aws/terraform` directory. First, you need to add an environment variable so that Terraform can correctly set the password for the Postgres database. You will find the production password for the database in your `config/passwords.yaml` file.
 
 ```bash
-$ export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
+export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
 ```
 
 Next, we are ready to initialize Terraform and deploy our server. You will only need to run the `terraform init` command the first time you deploy the configuration.
 
 ```bash
-$ terraform init
-$ terraform apply
+terraform init
+terraform apply
 ```
 
 Terraform will now run some checks and make a plan for the deployment. If everything looks good, it will ask you if you are ready to go ahead with the changes. Type `yes` and hit the return key. Applying the changes can take up to five minutes as AWS creates the different resources needed for your Serverpod.
diff --git a/versioned_docs/version-3.2.0/07-deployments/05-general.md b/versioned_docs/version-3.2.0/07-deployments/05-general.md
index 981bb8d9..fa1f3878 100644
--- a/versioned_docs/version-3.2.0/07-deployments/05-general.md
+++ b/versioned_docs/version-3.2.0/07-deployments/05-general.md
@@ -11,7 +11,7 @@ Serverpod will not run without a link to a Postgres database with the correct ta
 Serverpod has three main configuration files, depending on which mode the server is running; `development`, `staging`, or `production`. The files are located in the `config/` directory. By default, the server will start in development mode. To use another configuration file, use the `--mode` option when starting the server. If you are running multiple servers in a cluster, use the `--server-id` option to specify the id of each server. By default, the server will run as id `default`. For instance, to start the server in production mode with id `2`, run the following command:
 
 ```bash
-$ dart bin/main.dart --mode production --server-id 2
+dart bin/main.dart --mode production --server-id 2
 ```
 
 :::info
@@ -35,7 +35,7 @@ Serverpod can assume different roles depending on your configuration. If you run
 You can specify the role of your server when you launch it by setting the `--role` argument.
 
 ```bash
-$ dart bin/main.dart --role serverless
+dart bin/main.dart --role serverless
 ```
 
 ## Docker container
diff --git a/versioned_docs/version-3.2.0/08-upgrading/03-upgrade-to-pgvector.md b/versioned_docs/version-3.2.0/08-upgrading/03-upgrade-to-pgvector.md
index 24896009..6f94d34c 100644
--- a/versioned_docs/version-3.2.0/08-upgrading/03-upgrade-to-pgvector.md
+++ b/versioned_docs/version-3.2.0/08-upgrading/03-upgrade-to-pgvector.md
@@ -64,8 +64,8 @@ fields:
 4. Generate and apply a migration:
 
 ```bash
-$ serverpod create-migration
-$ dart run bin/main.dart --apply-migrations
+serverpod create-migration
+dart run bin/main.dart --apply-migrations
 ```
 
 For more details on creating and applying migrations, see the [Migrations](../concepts/database/migrations) section.
diff --git a/versioned_docs/version-3.2.0/08-upgrading/04-archive/03-upgrade-to-two.md b/versioned_docs/version-3.2.0/08-upgrading/04-archive/03-upgrade-to-two.md
index 54e3b54d..5ef0d80a 100644
--- a/versioned_docs/version-3.2.0/08-upgrading/04-archive/03-upgrade-to-two.md
+++ b/versioned_docs/version-3.2.0/08-upgrading/04-archive/03-upgrade-to-two.md
@@ -284,7 +284,7 @@ To ensure new databases are created with the new representation, the latest migr
 A new empty migration can be created by running the following command in the terminal:
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 #### Migration of existing tables
diff --git a/versioned_docs/version-3.2.0/09-tools/02-lsp.md b/versioned_docs/version-3.2.0/09-tools/02-lsp.md
index 2374cf57..8da02d1b 100644
--- a/versioned_docs/version-3.2.0/09-tools/02-lsp.md
+++ b/versioned_docs/version-3.2.0/09-tools/02-lsp.md
@@ -5,7 +5,7 @@ The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server
 To start the Serverpod LSP server, use the following command:
 
 ```bash
-$ serverpod language-server
+serverpod language-server
 ```
 
 :::info
diff --git a/versioned_docs/version-3.2.0/09-tools/03-run-scripts.md b/versioned_docs/version-3.2.0/09-tools/03-run-scripts.md
index 699ed8ce..d040adcb 100644
--- a/versioned_docs/version-3.2.0/09-tools/03-run-scripts.md
+++ b/versioned_docs/version-3.2.0/09-tools/03-run-scripts.md
@@ -19,13 +19,13 @@ serverpod:
 To run a script:
 
 ```bash
-$ serverpod run start
+serverpod run start
 ```
 
 To list all available scripts, use the `--list` flag or omit the script name:
 
 ```bash
-$ serverpod run --list
+serverpod run --list
 ```
 
 Scripts run in a shell environment (`bash` on Linux/macOS, `cmd` on Windows), so you can use pipes, conditionals, and environment variables. The CLI forwards signals like `Ctrl+C` to the running script and propagates exit codes.
diff --git a/versioned_docs/version-3.2.0/index.md b/versioned_docs/version-3.2.0/index.md
index 98651371..acb61a6d 100644
--- a/versioned_docs/version-3.2.0/index.md
+++ b/versioned_docs/version-3.2.0/index.md
@@ -64,7 +64,7 @@ Serverpod is tested on Mac, Windows, and Linux. Before you can install Serverpod
 Check your Flutter installation by running the following command in your terminal:
 
 ```bash
-$ flutter doctor
+flutter doctor
 ```
 
 :::
@@ -75,7 +75,7 @@ To make use of Serverpod's database connectivity, you need to have access to a P
 Check your Docker installation by running the following command in your terminal:
 
 ```bash
-$ docker info
+docker info
 ```
 
 If you are using Docker Desktop and you get an error, make sure that Docker is running. You can check this by looking for the Docker icon in your system tray or taskbar. If it's not running, start Docker Desktop and try again.
@@ -86,13 +86,13 @@ If you are using Docker Desktop and you get an error, make sure that Docker is r
 Serverpod is installed using the Dart package manager. To install Serverpod, run the following command in your terminal:
 
 ```bash
-$ dart pub global activate serverpod_cli
+dart pub global activate serverpod_cli
 ```
 
 This command will install the Serverpod command-line interface (CLI) globally on your machine. You can verify the installation by running:
 
 ```bash
-$ serverpod
+serverpod
 ```
 
 If everything is correctly configured, the help for the `serverpod` command is now displayed.
@@ -115,7 +115,7 @@ To create a new Serverpod project, use the `serverpod create` command. It will s
 The project will be created in a new directory with the name you specify. For example, to create a new project called `my_project`, run the following command:
 
 ```bash
-$ serverpod create my_project
+serverpod create my_project
 ```
 
 :::tip
@@ -125,20 +125,20 @@ The name of the project must be a valid Dart package name. It should start with
 To run your new project you must first start the database from the Docker file that is included with the project. Do this by running the `docker compose up` command in the server directory:
 
 ```bash
-$ cd my_project/my_project_server
-$ docker compose up
+cd my_project/my_project_server
+docker compose up
 ```
 
 This will start the PostgreSQL database. You can stop the database server by pressing `Ctrl+C` in the terminal. If you want to run the servers in the background, you can use the `-d` flag:
 
 ```bash
-$ docker compose up -d
+docker compose up -d
 ```
 
 This will start the database server in detached mode, meaning it will run in the background and you can safely close the terminal window without stopping it. Stop the database container by running the following command from the server directory:
 
 ```bash
-$ docker compose down
+docker compose down
 ```
 
 :::tip
@@ -148,8 +148,8 @@ If you are using Docker Desktop, you can see and manage all your installed Docke
 Now that the database is up and running we can start the Serverpod server. Because we are running the project for the first time, we need to create the database tables used by Serverpod. This is done through a [database migration](./06-concepts/06-database/11-migrations.md). An initial migration is already created for us, so all we need to do is pass the `--apply-migrations` flag when starting the server:
 
 ```bash
-$ cd my_project/my_project_server
-$ dart run bin/main.dart --apply-migrations
+cd my_project/my_project_server
+dart run bin/main.dart --apply-migrations
 ```
 
 This will start the server and set up the initial database tables. You can now access the server at `http://localhost:8080` and the web server is available at `http://localhost:8082`. It should look like this:
@@ -159,8 +159,8 @@ This will start the server and set up the initial database tables. You can now a
 Now let's run our Flutter app. You can do this by running `flutter run -d chrome` in the flutter directory:
 
 ```bash
-$ cd my_project/my_project_flutter
-$ flutter run -d chrome
+cd my_project/my_project_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look like this:
diff --git a/versioned_docs/version-3.2.0/serverpod-mini.md b/versioned_docs/version-3.2.0/serverpod-mini.md
index 62516c16..2ee7d247 100644
--- a/versioned_docs/version-3.2.0/serverpod-mini.md
+++ b/versioned_docs/version-3.2.0/serverpod-mini.md
@@ -39,7 +39,7 @@ Serverpod Mini is a lightweight version of Serverpod that is perfect for small p
 Create a mini project by running:
 
 ```bash
-$ serverpod create myminipod --mini
+serverpod create myminipod --mini
 ```
 
 Serverpod will create a new project for you. It contains three Dart packages, but you only need to pay attention to the `myminipod_server` and `myminipod_flutter` directories. The server directory contains your server files, and the flutter directory contains your app. The third package (`myminipod_client`) contains generated code that is used by the Flutter app to communicate with the server.
@@ -47,15 +47,15 @@ Serverpod will create a new project for you. It contains three Dart packages, bu
 Start your server by changing directory into your server directory, and run the `bin/main.dart` file:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ dart bin/main.dart
+cd myminipod/myminipod_server
+dart bin/main.dart
 ```
 
 Your default project comes with a sample Flutter app, all hooked up to talk with your server. Run it with the `flutter` command:
 
 ```bash
-$ cd myminipod/myminipod_flutter
-$ flutter run -d chrome
+cd myminipod/myminipod_flutter
+flutter run -d chrome
 ```
 
 Easy as that. 🥳
@@ -83,8 +83,8 @@ For types, you can use most basic Dart types, such as `String`, `double`, `int`,
 Whenever you add or edit a model file, run `serverpod generate` in your server directory. Then, Serverpod will generate all the updated Dart classes:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Adding methods to your server
@@ -120,8 +120,8 @@ class CompanyEndpoint extends Endpoint {
 After adding or modifying endpoints and endpoint methods, you must run `serverpod generate` to keep your Flutter app up-to-date.
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Calling the server methods from the app
diff --git a/versioned_docs/version-3.3.0/01-get-started/01-creating-endpoints.md b/versioned_docs/version-3.3.0/01-get-started/01-creating-endpoints.md
index ebfb16da..6a5402af 100644
--- a/versioned_docs/version-3.3.0/01-get-started/01-creating-endpoints.md
+++ b/versioned_docs/version-3.3.0/01-get-started/01-creating-endpoints.md
@@ -37,8 +37,8 @@ development:
 Next, we add the Dartantic AI package as a dependency to our server. This package provides a convenient interface for working with different AI providers, including Google's Gemini API.
 
 ```bash
-$ cd magic_recipe_server
-$ dart pub add dartantic_ai
+cd magic_recipe_server
+dart pub add dartantic_ai
 ```
 
 ## Create a new endpoint
@@ -99,8 +99,8 @@ For methods to be recognized by Serverpod, they need to return a typed `Future`
 Now, you need to generate the code for your new endpoint. You do this by running `serverpod generate` in the server directory of your project:
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 `serverpod generate` will create bindings for the endpoint and register them in the server's `generated/protocol.dart` file. It will also generate the required client code so that you can call your new `generateRecipe` method from your app.
@@ -220,16 +220,16 @@ Before you start your server, ensure no other Serverpod server is running. Also,
 Let's try our new recipe app! First, start the server:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart --apply-migrations
+cd magic_recipe_server
+docker compose up -d
+dart bin/main.dart --apply-migrations
 ```
 
 Now, you can start the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser:
diff --git a/versioned_docs/version-3.3.0/01-get-started/02-models-and-data.md b/versioned_docs/version-3.3.0/01-get-started/02-models-and-data.md
index bd2ed418..1b25a289 100644
--- a/versioned_docs/version-3.3.0/01-get-started/02-models-and-data.md
+++ b/versioned_docs/version-3.3.0/01-get-started/02-models-and-data.md
@@ -33,8 +33,8 @@ You can use most primitive Dart types here or any other models you have specifie
 To generate the code for the model, run the `serverpod generate` command in your server directory:
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 This will generate the code for the model and create a new file called `recipe.dart` in the `lib/src/generated` directory. It will also update the client code in `magic_recipe/magic_recipe_client` so you can use it in your Flutter app.
@@ -132,8 +132,8 @@ class RecipeEndpoint extends Endpoint {
 First, we need to update our generated client by running `serverpod generate`.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 Now that we have created the `Recipe` model we can use it in the app. We will do this in the `_callGenerateRecipe` method of the `magic_recipe_flutter/lib/main.dart` file. Let's update our `RecipeWidget` so that it displays the author and year of the recipe in addition to the recipe itself.
@@ -432,16 +432,16 @@ class ResultDisplay extends StatelessWidget {
 First, start the server:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart
+cd magic_recipe_server
+docker compose up -d
+dart bin/main.dart
 ```
 
 Then, start the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look something like this:
diff --git a/versioned_docs/version-3.3.0/01-get-started/03-working-with-the-database.md b/versioned_docs/version-3.3.0/01-get-started/03-working-with-the-database.md
index 51034f07..9ce74949 100644
--- a/versioned_docs/version-3.3.0/01-get-started/03-working-with-the-database.md
+++ b/versioned_docs/version-3.3.0/01-get-started/03-working-with-the-database.md
@@ -41,9 +41,9 @@ To create a migration, follow these two steps in order:
 2. Run `serverpod create-migration` to create the necessary database migration.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
-$ serverpod create-migration
+cd magic_recipe_server
+serverpod generate
+serverpod create-migration
 ```
 
 Each time you run `serverpod create-migration`, a new migration file will be created in your _migrations_ folder. These step-by-step migrations provide a history of your database changes and allow you to roll back changes if needed.
@@ -189,8 +189,8 @@ The `insertRow` method is used to insert a new row into the database. The `find`
 Like before, when you change something that has an effect on your client code, you need to run `serverpod generate`. We don't need to run `serverpod create-migrations` again because we already created a migration in the previous step and haven't done any changes that affect the database.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 ## Call the endpoint from the app
@@ -433,9 +433,9 @@ To run the application with database support, follow these steps in order:
 First, start the database and apply migrations:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d                   # Start the database container
-$ dart bin/main.dart --apply-migrations  # Apply any pending migrations
+cd magic_recipe_server
+docker compose up -d                   # Start the database container
+dart bin/main.dart --apply-migrations  # Apply any pending migrations
 ```
 
 :::tip
@@ -445,8 +445,8 @@ The `--apply-migrations` flag is safe to use during development - if no migratio
 Next, launch the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 ## Summary
diff --git a/versioned_docs/version-3.3.0/06-concepts/06-database/01-connection.md b/versioned_docs/version-3.3.0/06-concepts/06-database/01-connection.md
index 0c9ce97a..05bff19a 100644
--- a/versioned_docs/version-3.3.0/06-concepts/06-database/01-connection.md
+++ b/versioned_docs/version-3.3.0/06-concepts/06-database/01-connection.md
@@ -100,19 +100,19 @@ development:
 A newly created Serverpod project has a preconfigured Docker instance with a Postgres database set up. Run the following command from the root of the `server` package to start the database:
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To stop the database run:
 
 ```bash
-$ docker compose stop
+docker compose stop
 ```
 
 To remove the database and __delete__ all associated data, run:
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
 
 ## Connecting to a custom Postgres instance
diff --git a/versioned_docs/version-3.3.0/06-concepts/06-database/11-migrations.md b/versioned_docs/version-3.3.0/06-concepts/06-database/11-migrations.md
index 80bc54c2..ad8f803b 100644
--- a/versioned_docs/version-3.3.0/06-concepts/06-database/11-migrations.md
+++ b/versioned_docs/version-3.3.0/06-concepts/06-database/11-migrations.md
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,7 +47,7 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
@@ -55,7 +55,7 @@ $ serverpod create-migration --force
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,7 +162,7 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
@@ -170,7 +170,7 @@ $ serverpod create-repair-migration --force
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
diff --git a/versioned_docs/version-3.3.0/06-concepts/10-modules.md b/versioned_docs/version-3.3.0/06-concepts/10-modules.md
index 442b0747..1bd1f12f 100644
--- a/versioned_docs/version-3.3.0/06-concepts/10-modules.md
+++ b/versioned_docs/version-3.3.0/06-concepts/10-modules.md
@@ -32,15 +32,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -79,13 +79,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.
diff --git a/versioned_docs/version-3.3.0/06-concepts/11-authentication/04-providers/02-google/01-setup.md b/versioned_docs/version-3.3.0/06-concepts/11-authentication/04-providers/02-google/01-setup.md
index d5d72451..14f09004 100644
--- a/versioned_docs/version-3.3.0/06-concepts/11-authentication/04-providers/02-google/01-setup.md
+++ b/versioned_docs/version-3.3.0/06-concepts/11-authentication/04-providers/02-google/01-setup.md
@@ -190,7 +190,7 @@ If your `google-services.json` does not include a web OAuth client entry, you ma
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 :::
 
@@ -208,7 +208,7 @@ Navigate to _Clients_ and select the server credentials (the one configured as a
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 :::
 
diff --git a/versioned_docs/version-3.3.0/06-concepts/11-authentication/11-legacy/01-setup.md b/versioned_docs/version-3.3.0/06-concepts/11-authentication/11-legacy/01-setup.md
index 677ac269..c2769e98 100644
--- a/versioned_docs/version-3.3.0/06-concepts/11-authentication/11-legacy/01-setup.md
+++ b/versioned_docs/version-3.3.0/06-concepts/11-authentication/11-legacy/01-setup.md
@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
 Add the module as a dependency to the server project's `pubspec.yaml`.
 
 ```sh
-$ dart pub add serverpod_auth_server
+dart pub add serverpod_auth_server
 ```
 
 Add the authentication handler to the Serverpod instance.
@@ -46,7 +46,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
@@ -54,19 +54,19 @@ $ serverpod generate
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../../database/migrations).
diff --git a/versioned_docs/version-3.3.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md b/versioned_docs/version-3.3.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
index 7b52c420..8fe10f12 100644
--- a/versioned_docs/version-3.3.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
+++ b/versioned_docs/version-3.3.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
@@ -119,7 +119,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -136,7 +136,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::
diff --git a/versioned_docs/version-3.3.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md b/versioned_docs/version-3.3.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
index f5aab8fc..b1a4e0dc 100644
--- a/versioned_docs/version-3.3.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
+++ b/versioned_docs/version-3.3.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
@@ -31,8 +31,8 @@ To add authentication with Firebase, you must first install and initialize the F
 The short version:
 
 ```bash
-$ flutter pub add firebase_core firebase_auth firebase_ui_auth
-$ flutterfire configure
+flutter pub add firebase_core firebase_auth firebase_ui_auth
+flutterfire configure
 ```
 
 In the Firebase console, configure the different social sign-ins you plan to use, under `Authentication > Sign-in method`.
@@ -67,7 +67,7 @@ void main() async {
 Add the [serverpod_auth_firebase_flutter](https://pub.dev/packages/serverpod_auth_firebase_flutter) package.
 
 ```bash
-$ flutter pub add serverpod_auth_firebase_flutter
+flutter pub add serverpod_auth_firebase_flutter
 ```
 
 The `SignInWithFirebaseButton` is a convenient button that triggers the sign-in flow and can be used like this:
diff --git a/versioned_docs/version-3.3.0/06-concepts/12-file-uploads.md b/versioned_docs/version-3.3.0/06-concepts/12-file-uploads.md
index bbb788ab..b3439eba 100644
--- a/versioned_docs/version-3.3.0/06-concepts/12-file-uploads.md
+++ b/versioned_docs/version-3.3.0/06-concepts/12-file-uploads.md
@@ -98,7 +98,7 @@ You may also want to add the bucket as a backend for your load balancer to give
 When you have set up your GCP bucket, you need to configure it in Serverpod. Add the GCP package to your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_gcp
+dart pub add serverpod_cloud_storage_gcp
 ```
 
 ```dart
@@ -126,7 +126,7 @@ This section shows how to set up a storage using S3. Before you write your Dart
 When you are all set with the AWS setup, include the S3 package in your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_s3
+dart pub add serverpod_cloud_storage_s3
 ```
 
 ```dart
diff --git a/versioned_docs/version-3.3.0/06-concepts/14-scheduling/01-setup.md b/versioned_docs/version-3.3.0/06-concepts/14-scheduling/01-setup.md
index 26b43915..69efaee8 100644
--- a/versioned_docs/version-3.3.0/06-concepts/14-scheduling/01-setup.md
+++ b/versioned_docs/version-3.3.0/06-concepts/14-scheduling/01-setup.md
@@ -31,7 +31,7 @@ It is not valid to override the `invoke` method of the `FutureCall` class. This
 Next, you need to generate the code for your future calls:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 Calling `serverpod generate` will create a type-safe interface for invoking the future calls in the server's `generated/future_calls.dart` file. This interface can be accessed from the Serverpod object.
diff --git a/versioned_docs/version-3.3.0/06-concepts/14-scheduling/02-recurring-task.md b/versioned_docs/version-3.3.0/06-concepts/14-scheduling/02-recurring-task.md
index 0ae25963..ef4444bd 100644
--- a/versioned_docs/version-3.3.0/06-concepts/14-scheduling/02-recurring-task.md
+++ b/versioned_docs/version-3.3.0/06-concepts/14-scheduling/02-recurring-task.md
@@ -20,7 +20,7 @@ class ExampleFutureCall extends FutureCall {
 Next, generate the code for your future call:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 :::info
diff --git a/versioned_docs/version-3.3.0/06-concepts/21-experimental.md b/versioned_docs/version-3.3.0/06-concepts/21-experimental.md
index 075877af..6f87ca22 100644
--- a/versioned_docs/version-3.3.0/06-concepts/21-experimental.md
+++ b/versioned_docs/version-3.3.0/06-concepts/21-experimental.md
@@ -25,7 +25,7 @@ If possible, the experimental API will remain for some time as `@deprecated`, an
 Some of the experimental features are enabled by including the `--experimental-features` flag when running the serverpod command:
 
 ```bash
-$ serverpod generate --experimental-features=all
+serverpod generate --experimental-features=all
 ```
 
 The current options you can pass are:
diff --git a/versioned_docs/version-3.3.0/07-deployments/02-deploying-to-gce-terraform.md b/versioned_docs/version-3.3.0/07-deployments/02-deploying-to-gce-terraform.md
index 3a2ac487..f55c21bd 100644
--- a/versioned_docs/version-3.3.0/07-deployments/02-deploying-to-gce-terraform.md
+++ b/versioned_docs/version-3.3.0/07-deployments/02-deploying-to-gce-terraform.md
@@ -126,7 +126,7 @@ Depending on your domain name registrar, the process for setting up your domain
 You can test that the domain points to the correct name servers by running `dig` on the command line. It will output the domain name servers.
 
 ```bash
-$ dig +short NS examplepod.com
+dig +short NS examplepod.com
 ```
 
 Should yield an output similar to this:
@@ -228,13 +228,13 @@ If you are deploying a staging server in addition to your production server, you
 Once you have configured Terraform and your Serverpod, you are ready to deploy your infrastructure. Make sure that you have `cd` into your `deploy/gcp/terraform_gce` directory. Now run:
 
 ```bash
-$ terraform init
+terraform init
 ```
 
 This will download the Serverpod module and initialize your Terraform configuration. Now, deploy your infrastructure by running:
 
 ```bash
-$ terraform apply
+terraform apply
 ```
 
 Terraform will ask you for the password to your production and staging database. You will find the passwords in your `config/passwords.yaml` file. If you are not deploying a staging server, you can leave the staging database password blank.
diff --git a/versioned_docs/version-3.3.0/07-deployments/03-deploying-to-gcr-console.md b/versioned_docs/version-3.3.0/07-deployments/03-deploying-to-gcr-console.md
index cdd5991d..b647215c 100644
--- a/versioned_docs/version-3.3.0/07-deployments/03-deploying-to-gcr-console.md
+++ b/versioned_docs/version-3.3.0/07-deployments/03-deploying-to-gcr-console.md
@@ -11,13 +11,13 @@ Before you begin, you will need to install and configure the Google Cloud CLI to
 - To [initialize](https://cloud.google.com/sdk/docs/initializing) the gcloud CLI, run the following command:
 
 ```bash
-$ gcloud init
+gcloud init
 ```
 
 - To set the default project for your Cloud Run service:
 
 ```bash
-$ gcloud config set project <PROJECT_ID>
+gcloud config set project <PROJECT_ID>
 ```
 
 ## Setup the database
@@ -75,8 +75,8 @@ database:
 Your server is now ready to be deployed. When you created your project, Serverpod also created a script for deploying your server. Copy it to the root of your server directory and make it executable. Make sure you are in your server directory (e.g., `myproject_server`). Then run the following command:
 
 ```bash
-$ cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
-$ chmod u+x cloud-run-deploy.sh
+cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
+chmod u+x cloud-run-deploy.sh
 ```
 
 Open up the script in your favorite editor. You will need to fill in your _database instance's connection name_ and the _email of your service account_.
@@ -84,7 +84,7 @@ Open up the script in your favorite editor. You will need to fill in your _datab
 Now, deploy your server by running the following:
 
 ```bash
-$ ./cloud-run-deploy.sh
+./cloud-run-deploy.sh
 ```
 
 The script runs two deployment commands, one for your API and one for the Insights API used by the Serverpod app. While running, it may ask you to enable the Cloud Run and SQL Admin services. Answer yes to all these questions.
diff --git a/versioned_docs/version-3.3.0/07-deployments/04-deploying-to-aws.md b/versioned_docs/version-3.3.0/07-deployments/04-deploying-to-aws.md
index af139474..713e4d4c 100644
--- a/versioned_docs/version-3.3.0/07-deployments/04-deploying-to-aws.md
+++ b/versioned_docs/version-3.3.0/07-deployments/04-deploying-to-aws.md
@@ -202,14 +202,14 @@ database:
 Your Serverpod should now be configured and ready to be deployed. Exciting times! Open up a terminal and `cd` into your server `aws/terraform` directory. First, you need to add an environment variable so that Terraform can correctly set the password for the Postgres database. You will find the production password for the database in your `config/passwords.yaml` file.
 
 ```bash
-$ export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
+export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
 ```
 
 Next, we are ready to initialize Terraform and deploy our server. You will only need to run the `terraform init` command the first time you deploy the configuration.
 
 ```bash
-$ terraform init
-$ terraform apply
+terraform init
+terraform apply
 ```
 
 Terraform will now run some checks and make a plan for the deployment. If everything looks good, it will ask you if you are ready to go ahead with the changes. Type `yes` and hit the return key. Applying the changes can take up to five minutes as AWS creates the different resources needed for your Serverpod.
diff --git a/versioned_docs/version-3.3.0/07-deployments/05-general.md b/versioned_docs/version-3.3.0/07-deployments/05-general.md
index 981bb8d9..fa1f3878 100644
--- a/versioned_docs/version-3.3.0/07-deployments/05-general.md
+++ b/versioned_docs/version-3.3.0/07-deployments/05-general.md
@@ -11,7 +11,7 @@ Serverpod will not run without a link to a Postgres database with the correct ta
 Serverpod has three main configuration files, depending on which mode the server is running; `development`, `staging`, or `production`. The files are located in the `config/` directory. By default, the server will start in development mode. To use another configuration file, use the `--mode` option when starting the server. If you are running multiple servers in a cluster, use the `--server-id` option to specify the id of each server. By default, the server will run as id `default`. For instance, to start the server in production mode with id `2`, run the following command:
 
 ```bash
-$ dart bin/main.dart --mode production --server-id 2
+dart bin/main.dart --mode production --server-id 2
 ```
 
 :::info
@@ -35,7 +35,7 @@ Serverpod can assume different roles depending on your configuration. If you run
 You can specify the role of your server when you launch it by setting the `--role` argument.
 
 ```bash
-$ dart bin/main.dart --role serverless
+dart bin/main.dart --role serverless
 ```
 
 ## Docker container
diff --git a/versioned_docs/version-3.3.0/08-upgrading/03-upgrade-to-pgvector.md b/versioned_docs/version-3.3.0/08-upgrading/03-upgrade-to-pgvector.md
index 24896009..6f94d34c 100644
--- a/versioned_docs/version-3.3.0/08-upgrading/03-upgrade-to-pgvector.md
+++ b/versioned_docs/version-3.3.0/08-upgrading/03-upgrade-to-pgvector.md
@@ -64,8 +64,8 @@ fields:
 4. Generate and apply a migration:
 
 ```bash
-$ serverpod create-migration
-$ dart run bin/main.dart --apply-migrations
+serverpod create-migration
+dart run bin/main.dart --apply-migrations
 ```
 
 For more details on creating and applying migrations, see the [Migrations](../concepts/database/migrations) section.
diff --git a/versioned_docs/version-3.3.0/08-upgrading/04-archive/03-upgrade-to-two.md b/versioned_docs/version-3.3.0/08-upgrading/04-archive/03-upgrade-to-two.md
index 54e3b54d..5ef0d80a 100644
--- a/versioned_docs/version-3.3.0/08-upgrading/04-archive/03-upgrade-to-two.md
+++ b/versioned_docs/version-3.3.0/08-upgrading/04-archive/03-upgrade-to-two.md
@@ -284,7 +284,7 @@ To ensure new databases are created with the new representation, the latest migr
 A new empty migration can be created by running the following command in the terminal:
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 #### Migration of existing tables
diff --git a/versioned_docs/version-3.3.0/09-tools/02-lsp.md b/versioned_docs/version-3.3.0/09-tools/02-lsp.md
index 2374cf57..8da02d1b 100644
--- a/versioned_docs/version-3.3.0/09-tools/02-lsp.md
+++ b/versioned_docs/version-3.3.0/09-tools/02-lsp.md
@@ -5,7 +5,7 @@ The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server
 To start the Serverpod LSP server, use the following command:
 
 ```bash
-$ serverpod language-server
+serverpod language-server
 ```
 
 :::info
diff --git a/versioned_docs/version-3.3.0/09-tools/03-run-scripts.md b/versioned_docs/version-3.3.0/09-tools/03-run-scripts.md
index 699ed8ce..d040adcb 100644
--- a/versioned_docs/version-3.3.0/09-tools/03-run-scripts.md
+++ b/versioned_docs/version-3.3.0/09-tools/03-run-scripts.md
@@ -19,13 +19,13 @@ serverpod:
 To run a script:
 
 ```bash
-$ serverpod run start
+serverpod run start
 ```
 
 To list all available scripts, use the `--list` flag or omit the script name:
 
 ```bash
-$ serverpod run --list
+serverpod run --list
 ```
 
 Scripts run in a shell environment (`bash` on Linux/macOS, `cmd` on Windows), so you can use pipes, conditionals, and environment variables. The CLI forwards signals like `Ctrl+C` to the running script and propagates exit codes.
diff --git a/versioned_docs/version-3.3.0/index.md b/versioned_docs/version-3.3.0/index.md
index 1b104851..88c4313d 100644
--- a/versioned_docs/version-3.3.0/index.md
+++ b/versioned_docs/version-3.3.0/index.md
@@ -64,7 +64,7 @@ Serverpod is tested on Mac, Windows, and Linux. Before you can install Serverpod
 Check your Flutter installation by running the following command in your terminal:
 
 ```bash
-$ flutter doctor
+flutter doctor
 ```
 
 :::
@@ -75,7 +75,7 @@ To make use of Serverpod's database connectivity, you need to have access to a P
 Check your Docker installation by running the following command in your terminal:
 
 ```bash
-$ docker info
+docker info
 ```
 
 If you are using Docker Desktop and you get an error, make sure that Docker is running. You can check this by looking for the Docker icon in your system tray or taskbar. If it's not running, start Docker Desktop and try again.
@@ -86,13 +86,13 @@ If you are using Docker Desktop and you get an error, make sure that Docker is r
 Serverpod is installed using the Dart package manager. To install Serverpod, run the following command in your terminal:
 
 ```bash
-$ dart pub global activate serverpod_cli
+dart pub global activate serverpod_cli
 ```
 
 This command will install the Serverpod command-line interface (CLI) globally on your machine. You can verify the installation by running:
 
 ```bash
-$ serverpod
+serverpod
 ```
 
 If everything is correctly configured, the help for the `serverpod` command is now displayed.
@@ -115,7 +115,7 @@ To create a new Serverpod project, use the `serverpod create` command. It will s
 The project will be created in a new directory with the name you specify. For example, to create a new project called `my_project`, run the following command:
 
 ```bash
-$ serverpod create my_project
+serverpod create my_project
 ```
 
 :::tip
@@ -140,20 +140,20 @@ During project creation, dependencies are automatically fetched.
 To run your new project you must first start the database from the Docker file that is included with the project. Do this by running the `docker compose up` command in the server directory:
 
 ```bash
-$ cd my_project/my_project_server
-$ docker compose up
+cd my_project/my_project_server
+docker compose up
 ```
 
 This will start the PostgreSQL database. You can stop the database server by pressing `Ctrl+C` in the terminal. If you want to run the servers in the background, you can use the `-d` flag:
 
 ```bash
-$ docker compose up -d
+docker compose up -d
 ```
 
 This will start the database server in detached mode, meaning it will run in the background and you can safely close the terminal window without stopping it. Stop the database container by running the following command from the server directory:
 
 ```bash
-$ docker compose down
+docker compose down
 ```
 
 :::tip
@@ -163,8 +163,8 @@ If you are using Docker Desktop, you can see and manage all your installed Docke
 Now that the database is up and running we can start the Serverpod server. Because we are running the project for the first time, we need to create the database tables used by Serverpod. This is done through a [database migration](./06-concepts/06-database/11-migrations.md). An initial migration is already created for us, so all we need to do is pass the `--apply-migrations` flag when starting the server:
 
 ```bash
-$ cd my_project/my_project_server
-$ dart run bin/main.dart --apply-migrations
+cd my_project/my_project_server
+dart run bin/main.dart --apply-migrations
 ```
 
 This will start the server and set up the initial database tables. You can now access the server at `http://localhost:8080` and the web server is available at `http://localhost:8082`. It should look like this:
@@ -174,8 +174,8 @@ This will start the server and set up the initial database tables. You can now a
 Now let's run our Flutter app. You can do this by running `flutter run -d chrome` in the flutter directory:
 
 ```bash
-$ cd my_project/my_project_flutter
-$ flutter run -d chrome
+cd my_project/my_project_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look like this:
diff --git a/versioned_docs/version-3.3.0/serverpod-mini.md b/versioned_docs/version-3.3.0/serverpod-mini.md
index 62516c16..2ee7d247 100644
--- a/versioned_docs/version-3.3.0/serverpod-mini.md
+++ b/versioned_docs/version-3.3.0/serverpod-mini.md
@@ -39,7 +39,7 @@ Serverpod Mini is a lightweight version of Serverpod that is perfect for small p
 Create a mini project by running:
 
 ```bash
-$ serverpod create myminipod --mini
+serverpod create myminipod --mini
 ```
 
 Serverpod will create a new project for you. It contains three Dart packages, but you only need to pay attention to the `myminipod_server` and `myminipod_flutter` directories. The server directory contains your server files, and the flutter directory contains your app. The third package (`myminipod_client`) contains generated code that is used by the Flutter app to communicate with the server.
@@ -47,15 +47,15 @@ Serverpod will create a new project for you. It contains three Dart packages, bu
 Start your server by changing directory into your server directory, and run the `bin/main.dart` file:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ dart bin/main.dart
+cd myminipod/myminipod_server
+dart bin/main.dart
 ```
 
 Your default project comes with a sample Flutter app, all hooked up to talk with your server. Run it with the `flutter` command:
 
 ```bash
-$ cd myminipod/myminipod_flutter
-$ flutter run -d chrome
+cd myminipod/myminipod_flutter
+flutter run -d chrome
 ```
 
 Easy as that. 🥳
@@ -83,8 +83,8 @@ For types, you can use most basic Dart types, such as `String`, `double`, `int`,
 Whenever you add or edit a model file, run `serverpod generate` in your server directory. Then, Serverpod will generate all the updated Dart classes:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Adding methods to your server
@@ -120,8 +120,8 @@ class CompanyEndpoint extends Endpoint {
 After adding or modifying endpoints and endpoint methods, you must run `serverpod generate` to keep your Flutter app up-to-date.
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Calling the server methods from the app
diff --git a/versioned_docs/version-3.4.0/01-get-started/01-creating-endpoints.md b/versioned_docs/version-3.4.0/01-get-started/01-creating-endpoints.md
index 4dc7828d..ebb75fd6 100644
--- a/versioned_docs/version-3.4.0/01-get-started/01-creating-endpoints.md
+++ b/versioned_docs/version-3.4.0/01-get-started/01-creating-endpoints.md
@@ -38,8 +38,8 @@ development:
 Next, we add the Dartantic AI package as a dependency to our server. This package provides a convenient interface for working with different AI providers, including Google's Gemini API.
 
 ```bash
-$ cd magic_recipe_server
-$ dart pub add dartantic_ai
+cd magic_recipe_server
+dart pub add dartantic_ai
 ```
 
 ## Create a new endpoint
@@ -100,8 +100,8 @@ For methods to be recognized by Serverpod, they need to return a typed `Future`
 Now, you need to generate the code for your new endpoint. You do this by running `serverpod generate` in the server directory of your project:
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 `serverpod generate` will create bindings for the endpoint and register them in the server's `generated/protocol.dart` file. It will also generate the required client code so that you can call your new `generateRecipe` method from your app.
@@ -221,16 +221,16 @@ Before you start your server, ensure no other Serverpod server is running. Also,
 Let's try our new recipe app! First, start the server:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart --apply-migrations
+cd magic_recipe_server
+docker compose up -d
+dart bin/main.dart --apply-migrations
 ```
 
 Now, you can start the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser:
diff --git a/versioned_docs/version-3.4.0/01-get-started/02-models-and-data.md b/versioned_docs/version-3.4.0/01-get-started/02-models-and-data.md
index 482e7ea7..a050cd54 100644
--- a/versioned_docs/version-3.4.0/01-get-started/02-models-and-data.md
+++ b/versioned_docs/version-3.4.0/01-get-started/02-models-and-data.md
@@ -34,8 +34,8 @@ You can use most primitive Dart types here or any other models you have specifie
 To generate the code for the model, run the `serverpod generate` command in your server directory:
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 This will generate the code for the model and create a new file called `recipe.dart` in the `lib/src/generated` directory. It will also update the client code in `magic_recipe/magic_recipe_client` so you can use it in your Flutter app.
@@ -133,8 +133,8 @@ class RecipeEndpoint extends Endpoint {
 First, we need to update our generated client by running `serverpod generate`.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 Now that we have created the `Recipe` model we can use it in the app. We will do this in the `_callGenerateRecipe` method of the `magic_recipe_flutter/lib/main.dart` file. Let's update our `RecipeWidget` so that it displays the author and year of the recipe in addition to the recipe itself.
@@ -433,16 +433,16 @@ class ResultDisplay extends StatelessWidget {
 First, start the server:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d
-$ dart bin/main.dart
+cd magic_recipe_server
+docker compose up -d
+dart bin/main.dart
 ```
 
 Then, start the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look something like this:
diff --git a/versioned_docs/version-3.4.0/01-get-started/03-working-with-the-database.md b/versioned_docs/version-3.4.0/01-get-started/03-working-with-the-database.md
index 44a6048a..17909692 100644
--- a/versioned_docs/version-3.4.0/01-get-started/03-working-with-the-database.md
+++ b/versioned_docs/version-3.4.0/01-get-started/03-working-with-the-database.md
@@ -42,9 +42,9 @@ To create a migration, follow these two steps in order:
 2. Run `serverpod create-migration` to create the necessary database migration.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
-$ serverpod create-migration
+cd magic_recipe_server
+serverpod generate
+serverpod create-migration
 ```
 
 Each time you run `serverpod create-migration`, a new migration file will be created in your _migrations_ folder. These step-by-step migrations provide a history of your database changes and allow you to roll back changes if needed.
@@ -190,8 +190,8 @@ The `insertRow` method is used to insert a new row into the database. The `find`
 Like before, when you change something that has an effect on your client code, you need to run `serverpod generate`. We don't need to run `serverpod create-migrations` again because we already created a migration in the previous step and haven't done any changes that affect the database.
 
 ```bash
-$ cd magic_recipe_server
-$ serverpod generate
+cd magic_recipe_server
+serverpod generate
 ```
 
 ## Call the endpoint from the app
@@ -434,9 +434,9 @@ To run the application with database support, follow these steps in order:
 First, start the database and apply migrations:
 
 ```bash
-$ cd magic_recipe_server
-$ docker compose up -d                   # Start the database container
-$ dart bin/main.dart --apply-migrations  # Apply any pending migrations
+cd magic_recipe_server
+docker compose up -d                   # Start the database container
+dart bin/main.dart --apply-migrations  # Apply any pending migrations
 ```
 
 :::tip
@@ -446,8 +446,8 @@ The `--apply-migrations` flag is safe to use during development - if no migratio
 Next, launch the Flutter app:
 
 ```bash
-$ cd magic_recipe_flutter
-$ flutter run -d chrome
+cd magic_recipe_flutter
+flutter run -d chrome
 ```
 
 ## Summary
diff --git a/versioned_docs/version-3.4.0/06-concepts/06-database/01-connection.md b/versioned_docs/version-3.4.0/06-concepts/06-database/01-connection.md
index 0c9ce97a..05bff19a 100644
--- a/versioned_docs/version-3.4.0/06-concepts/06-database/01-connection.md
+++ b/versioned_docs/version-3.4.0/06-concepts/06-database/01-connection.md
@@ -100,19 +100,19 @@ development:
 A newly created Serverpod project has a preconfigured Docker instance with a Postgres database set up. Run the following command from the root of the `server` package to start the database:
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 To stop the database run:
 
 ```bash
-$ docker compose stop
+docker compose stop
 ```
 
 To remove the database and __delete__ all associated data, run:
 
 ```bash
-$ docker compose down -v
+docker compose down -v
 ```
 
 ## Connecting to a custom Postgres instance
diff --git a/versioned_docs/version-3.4.0/06-concepts/06-database/11-migrations.md b/versioned_docs/version-3.4.0/06-concepts/06-database/11-migrations.md
index 80bc54c2..ad8f803b 100644
--- a/versioned_docs/version-3.4.0/06-concepts/06-database/11-migrations.md
+++ b/versioned_docs/version-3.4.0/06-concepts/06-database/11-migrations.md
@@ -28,7 +28,7 @@ If you want to transition a manually managed table to then be managed by Serverp
 To create a migration navigate to your project's `server` package directory and run the `create-migration` command.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 The command reads the database schema from the last migration, then compares it to the database schema necessary to accommodate the projects, and any module dependencies, current database requirements. If differences are identified, a new migration is created in the `migrations` directory to roll the database forward.
@@ -47,7 +47,7 @@ The migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 ### Tag migration
@@ -55,7 +55,7 @@ $ serverpod create-migration --force
 Tags can be useful to identify migrations that introduced specific changes to the project. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-migration --tag "v1-0-0"
+serverpod create-migration --tag "v1-0-0"
 ```
 
 This would create a migration named `<timestamp>-v1-0-0`:
@@ -97,13 +97,13 @@ For each migration, five files are created:
 Migrations are applied using the server runtime. To apply migrations, navigate to your project's `server` package directory, then start the server with the `--apply-migrations` flag. Migrations are applied as part of the startup sequence and the framework asserts that each migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-migrations
+dart run bin/main.dart --apply-migrations
 ```
 
 Migrations can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 This is useful if migrations are applied as part of an automated process.
@@ -119,7 +119,7 @@ By default, the command connects to and pulls a live database schema from a runn
 To create a repair migration, navigate to your project's `server` package directory and run the `create-repair-migration` command.
 
 ```bash
-$ serverpod create-repair-migration
+serverpod create-repair-migration
 ```
 
 This creates a repair migration in the `repair-migration` directory targeting the project's latest migration.
@@ -137,7 +137,7 @@ Since each repair migration is created for a specific live database schema, Serv
 By default, the repair migration system connects to your `development` database using the information specified in your Serverpod config. To use a different database source, the `--mode` option is used.
 
 ```bash
-$ serverpod create-repair-migration --mode production
+serverpod create-repair-migration --mode production
 ```
 
 The command connects and pulls the live database schema from a running server.
@@ -147,7 +147,7 @@ The command connects and pulls the live database schema from a running server.
 Repair migrations can also target a specific migration version by specifying the migration name with the `--version` option.
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0
+serverpod create-repair-migration --version 20230821135718-v1-0-0
 ```
 
 This makes it possible to revert your database schema back to any older migration version.
@@ -162,7 +162,7 @@ The repair migration command aborts and displays an error under two conditions:
 To override these safeguards and force the creation of a repair migration, use the `--force` flag.
 
 ```bash
-$ serverpod create-repair-migration --force
+serverpod create-repair-migration --force
 ```
 
 ### Tag repair migration
@@ -170,7 +170,7 @@ $ serverpod create-repair-migration --force
 Repair migrations can be tagged just like regular migrations. Tags are appended to the migration name and can be added with the `--tag` option.
 
 ```bash
-$ serverpod create-repair-migration --tag "reset-migrations"
+serverpod create-repair-migration --tag "reset-migrations"
 ```
 
 This would create a repair migration named `<timestamp>-reset-migrations` in the `repair` directory:
@@ -194,13 +194,13 @@ The `repair` directory only exists if a repair migration has been created and co
 The repair migration is applied using the server runtime. To apply a repair migration, start the server with the `--apply-repair-migration` flag. The repair migration is applied as part of the startup sequence and the framework asserts that each repair migration is only applied once to the database.
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
 
 The repair migration can also be applied using the maintenance role. In maintenance, after migrations are applied, the server exits with an exit code indicating if migrations were successfully applied, zero for success or non-zero for failure.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-repair-migration
+dart run bin/main.dart --role maintenance --apply-repair-migration
 ```
 
 If a repair migration is applied at the same time as migrations, the repair migration is applied first.
@@ -214,11 +214,11 @@ Note that data is not rolled back, only the database schema.
 To roll back to a previous migration, first create a repair migration targeting the desired migration version:
 
 ```bash
-$ serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
+serverpod create-repair-migration --version 20230821135718-v1-0-0 --tag "roll-back-to-v1-0-0"
 ```
 
 Then apply the repair migration, any repair migration will only be applied once:
 
 ```bash
-$ dart run bin/main.dart --apply-repair-migration
+dart run bin/main.dart --apply-repair-migration
 ```
diff --git a/versioned_docs/version-3.4.0/06-concepts/10-modules.md b/versioned_docs/version-3.4.0/06-concepts/10-modules.md
index 442b0747..1bd1f12f 100644
--- a/versioned_docs/version-3.4.0/06-concepts/10-modules.md
+++ b/versioned_docs/version-3.4.0/06-concepts/10-modules.md
@@ -32,15 +32,15 @@ modules:
 Then run `pub get` and `serverpod generate` from your server's directory (e.g., `mypod_server`) to add the module to your project's deserializer.
 
 ```bash
-$ dart pub get
-$ serverpod generate
+dart pub get
+serverpod generate
 ```
 
 Finally, since modules might include modifications to the database schema, you should create a new database migration and apply it by running `serverpod create-migration`  then `dart bin/main.dart --apply-migrations` from your server's directory.
 
 ```bash
-$ serverpod create-migration
-$ dart bin/main.dart --apply-migrations
+serverpod create-migration
+dart bin/main.dart --apply-migrations
 ```
 
 ### Client setup
@@ -79,13 +79,13 @@ fields:
 With the `serverpod create` command, it is possible to create new modules for code that is shared between projects or that you want to publish to pub.dev. To create a module instead of a server project, pass `module` to the `--template` flag.
 
 ```bash
-$ serverpod create --template module my_module
+serverpod create --template module my_module
 ```
 
 The create command will create a server and a client Dart package. If you also want to add custom Flutter code, use `flutter create` to create a package.
 
 ```bash
-$ flutter create --template package my_module_flutter
+flutter create --template package my_module_flutter
 ```
 
 In your Flutter package, you most likely want to import the client libraries created by `serverpod create`.
diff --git a/versioned_docs/version-3.4.0/06-concepts/11-authentication/04-providers/03-google/01-setup.md b/versioned_docs/version-3.4.0/06-concepts/11-authentication/04-providers/03-google/01-setup.md
index d5d72451..14f09004 100644
--- a/versioned_docs/version-3.4.0/06-concepts/11-authentication/04-providers/03-google/01-setup.md
+++ b/versioned_docs/version-3.4.0/06-concepts/11-authentication/04-providers/03-google/01-setup.md
@@ -190,7 +190,7 @@ If your `google-services.json` does not include a web OAuth client entry, you ma
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 :::
 
@@ -208,7 +208,7 @@ Navigate to _Clients_ and select the server credentials (the one configured as a
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 :::
 
diff --git a/versioned_docs/version-3.4.0/06-concepts/11-authentication/11-legacy/01-setup.md b/versioned_docs/version-3.4.0/06-concepts/11-authentication/11-legacy/01-setup.md
index 677ac269..c2769e98 100644
--- a/versioned_docs/version-3.4.0/06-concepts/11-authentication/11-legacy/01-setup.md
+++ b/versioned_docs/version-3.4.0/06-concepts/11-authentication/11-legacy/01-setup.md
@@ -15,7 +15,7 @@ Serverpod's auth module makes it easy to authenticate users through email or 3rd
 Add the module as a dependency to the server project's `pubspec.yaml`.
 
 ```sh
-$ dart pub add serverpod_auth_server
+dart pub add serverpod_auth_server
 ```
 
 Add the authentication handler to the Serverpod instance.
@@ -46,7 +46,7 @@ modules:
 While still in the server project, generate the client code and endpoint methods for the auth module by running the `serverpod generate` command line tool.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 ### Initialize the auth database
@@ -54,19 +54,19 @@ $ serverpod generate
 After adding the module to the server project, you need to initialize the database. First you have to create a new migration that includes the auth module tables. This is done by running the `serverpod create-migration` command line tool in the server project.
 
 ```bash
-$ serverpod create-migration
+serverpod create-migration
 ```
 
 Start your database container from the server project.
 
 ```bash
-$ docker compose up --build --detach
+docker compose up --build --detach
 ```
 
 Then apply the migration by starting the server with the `apply-migrations` flag.
 
 ```bash
-$ dart run bin/main.dart --role maintenance --apply-migrations
+dart run bin/main.dart --role maintenance --apply-migrations
 ```
 
 The full migration instructions can be found in the [migration guide](../../database/migrations).
diff --git a/versioned_docs/version-3.4.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md b/versioned_docs/version-3.4.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
index 7b52c420..8fe10f12 100644
--- a/versioned_docs/version-3.4.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
+++ b/versioned_docs/version-3.4.0/06-concepts/11-authentication/11-legacy/04-providers/02-google.md
@@ -119,7 +119,7 @@ Put the file inside the `android/app/` directory and rename it to `google-servic
 For a production app you need to get the SHA-1 key from your production keystore! This can be done by running this command: ([Read more](https://support.google.com/cloud/answer/6158849#installedapplications&android&zippy=%2Cnative-applications%2Candroid)).
 
 ```bash
-$ keytool -list -v -keystore /path/to/keystore
+keytool -list -v -keystore /path/to/keystore
 ```
 
 :::
@@ -136,7 +136,7 @@ Navigate to _Credentials_ under _APIs & Services_ and select the server credenti
 Force flutter to run on a specific port by running.
 
 ```bash
-$ flutter run -d chrome --web-port=49660
+flutter run -d chrome --web-port=49660
 ```
 
 :::
diff --git a/versioned_docs/version-3.4.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md b/versioned_docs/version-3.4.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
index f5aab8fc..b1a4e0dc 100644
--- a/versioned_docs/version-3.4.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
+++ b/versioned_docs/version-3.4.0/06-concepts/11-authentication/11-legacy/04-providers/05-firebase.md
@@ -31,8 +31,8 @@ To add authentication with Firebase, you must first install and initialize the F
 The short version:
 
 ```bash
-$ flutter pub add firebase_core firebase_auth firebase_ui_auth
-$ flutterfire configure
+flutter pub add firebase_core firebase_auth firebase_ui_auth
+flutterfire configure
 ```
 
 In the Firebase console, configure the different social sign-ins you plan to use, under `Authentication > Sign-in method`.
@@ -67,7 +67,7 @@ void main() async {
 Add the [serverpod_auth_firebase_flutter](https://pub.dev/packages/serverpod_auth_firebase_flutter) package.
 
 ```bash
-$ flutter pub add serverpod_auth_firebase_flutter
+flutter pub add serverpod_auth_firebase_flutter
 ```
 
 The `SignInWithFirebaseButton` is a convenient button that triggers the sign-in flow and can be used like this:
diff --git a/versioned_docs/version-3.4.0/06-concepts/12-file-uploads.md b/versioned_docs/version-3.4.0/06-concepts/12-file-uploads.md
index 8c3b42a0..5b0fa10f 100644
--- a/versioned_docs/version-3.4.0/06-concepts/12-file-uploads.md
+++ b/versioned_docs/version-3.4.0/06-concepts/12-file-uploads.md
@@ -140,7 +140,7 @@ You may also want to add the bucket as a backend for your load balancer to give
 When you have set up your GCP bucket, you need to configure it in Serverpod. Add the GCP package to your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_gcp
+dart pub add serverpod_cloud_storage_gcp
 ```
 
 ```dart
@@ -233,7 +233,7 @@ This section shows how to set up a storage using S3. Before you write your Dart
 When you are all set with the AWS setup, include the S3 package in your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_s3
+dart pub add serverpod_cloud_storage_s3
 ```
 
 ```dart
@@ -271,7 +271,7 @@ Serverpod supports Cloudflare R2 as a cloud storage provider. R2 is S3-compatibl
 Add the R2 package to your `pubspec.yaml` file and import it in your `server.dart` file.
 
 ```bash
-$ dart pub add serverpod_cloud_storage_r2
+dart pub add serverpod_cloud_storage_r2
 ```
 
 ```dart
diff --git a/versioned_docs/version-3.4.0/06-concepts/14-scheduling/01-setup.md b/versioned_docs/version-3.4.0/06-concepts/14-scheduling/01-setup.md
index cdad56cd..5b6847d8 100644
--- a/versioned_docs/version-3.4.0/06-concepts/14-scheduling/01-setup.md
+++ b/versioned_docs/version-3.4.0/06-concepts/14-scheduling/01-setup.md
@@ -31,7 +31,7 @@ It is not valid to override the `invoke` method of the `FutureCall` class. This
 Next, you need to generate the code for your future calls:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 Calling `serverpod generate` will create a type-safe interface for invoking the future calls in the server's `generated/future_calls.dart` file. This interface can be accessed from the Serverpod object.
diff --git a/versioned_docs/version-3.4.0/06-concepts/14-scheduling/02-recurring-task.md b/versioned_docs/version-3.4.0/06-concepts/14-scheduling/02-recurring-task.md
index 0ae25963..ef4444bd 100644
--- a/versioned_docs/version-3.4.0/06-concepts/14-scheduling/02-recurring-task.md
+++ b/versioned_docs/version-3.4.0/06-concepts/14-scheduling/02-recurring-task.md
@@ -20,7 +20,7 @@ class ExampleFutureCall extends FutureCall {
 Next, generate the code for your future call:
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 :::info
diff --git a/versioned_docs/version-3.4.0/06-concepts/20-shared-packages.md b/versioned_docs/version-3.4.0/06-concepts/20-shared-packages.md
index fdd23d23..dd4c8e8c 100644
--- a/versioned_docs/version-3.4.0/06-concepts/20-shared-packages.md
+++ b/versioned_docs/version-3.4.0/06-concepts/20-shared-packages.md
@@ -75,7 +75,7 @@ Paths are relative to the server project directory. You can list multiple shared
 Run `serverpod generate` from your server directory.
 
 ```bash
-$ serverpod generate
+serverpod generate
 ```
 
 This generates the Dart classes and protocol in the shared package's `lib/src/generated/` directory. After generation, a typical shared package looks like:
diff --git a/versioned_docs/version-3.4.0/06-concepts/22-experimental.md b/versioned_docs/version-3.4.0/06-concepts/22-experimental.md
index 075877af..6f87ca22 100644
--- a/versioned_docs/version-3.4.0/06-concepts/22-experimental.md
+++ b/versioned_docs/version-3.4.0/06-concepts/22-experimental.md
@@ -25,7 +25,7 @@ If possible, the experimental API will remain for some time as `@deprecated`, an
 Some of the experimental features are enabled by including the `--experimental-features` flag when running the serverpod command:
 
 ```bash
-$ serverpod generate --experimental-features=all
+serverpod generate --experimental-features=all
 ```
 
 The current options you can pass are:
diff --git a/versioned_docs/version-3.4.0/07-deployments/02-deploying-to-gce-terraform.md b/versioned_docs/version-3.4.0/07-deployments/02-deploying-to-gce-terraform.md
index 3a2ac487..f55c21bd 100644
--- a/versioned_docs/version-3.4.0/07-deployments/02-deploying-to-gce-terraform.md
+++ b/versioned_docs/version-3.4.0/07-deployments/02-deploying-to-gce-terraform.md
@@ -126,7 +126,7 @@ Depending on your domain name registrar, the process for setting up your domain
 You can test that the domain points to the correct name servers by running `dig` on the command line. It will output the domain name servers.
 
 ```bash
-$ dig +short NS examplepod.com
+dig +short NS examplepod.com
 ```
 
 Should yield an output similar to this:
@@ -228,13 +228,13 @@ If you are deploying a staging server in addition to your production server, you
 Once you have configured Terraform and your Serverpod, you are ready to deploy your infrastructure. Make sure that you have `cd` into your `deploy/gcp/terraform_gce` directory. Now run:
 
 ```bash
-$ terraform init
+terraform init
 ```
 
 This will download the Serverpod module and initialize your Terraform configuration. Now, deploy your infrastructure by running:
 
 ```bash
-$ terraform apply
+terraform apply
 ```
 
 Terraform will ask you for the password to your production and staging database. You will find the passwords in your `config/passwords.yaml` file. If you are not deploying a staging server, you can leave the staging database password blank.
diff --git a/versioned_docs/version-3.4.0/07-deployments/03-deploying-to-gcr-console.md b/versioned_docs/version-3.4.0/07-deployments/03-deploying-to-gcr-console.md
index cdd5991d..b647215c 100644
--- a/versioned_docs/version-3.4.0/07-deployments/03-deploying-to-gcr-console.md
+++ b/versioned_docs/version-3.4.0/07-deployments/03-deploying-to-gcr-console.md
@@ -11,13 +11,13 @@ Before you begin, you will need to install and configure the Google Cloud CLI to
 - To [initialize](https://cloud.google.com/sdk/docs/initializing) the gcloud CLI, run the following command:
 
 ```bash
-$ gcloud init
+gcloud init
 ```
 
 - To set the default project for your Cloud Run service:
 
 ```bash
-$ gcloud config set project <PROJECT_ID>
+gcloud config set project <PROJECT_ID>
 ```
 
 ## Setup the database
@@ -75,8 +75,8 @@ database:
 Your server is now ready to be deployed. When you created your project, Serverpod also created a script for deploying your server. Copy it to the root of your server directory and make it executable. Make sure you are in your server directory (e.g., `myproject_server`). Then run the following command:
 
 ```bash
-$ cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
-$ chmod u+x cloud-run-deploy.sh
+cp deploy/gcp/console_gcr/cloud-run-deploy.sh .
+chmod u+x cloud-run-deploy.sh
 ```
 
 Open up the script in your favorite editor. You will need to fill in your _database instance's connection name_ and the _email of your service account_.
@@ -84,7 +84,7 @@ Open up the script in your favorite editor. You will need to fill in your _datab
 Now, deploy your server by running the following:
 
 ```bash
-$ ./cloud-run-deploy.sh
+./cloud-run-deploy.sh
 ```
 
 The script runs two deployment commands, one for your API and one for the Insights API used by the Serverpod app. While running, it may ask you to enable the Cloud Run and SQL Admin services. Answer yes to all these questions.
diff --git a/versioned_docs/version-3.4.0/07-deployments/04-deploying-to-aws.md b/versioned_docs/version-3.4.0/07-deployments/04-deploying-to-aws.md
index af139474..713e4d4c 100644
--- a/versioned_docs/version-3.4.0/07-deployments/04-deploying-to-aws.md
+++ b/versioned_docs/version-3.4.0/07-deployments/04-deploying-to-aws.md
@@ -202,14 +202,14 @@ database:
 Your Serverpod should now be configured and ready to be deployed. Exciting times! Open up a terminal and `cd` into your server `aws/terraform` directory. First, you need to add an environment variable so that Terraform can correctly set the password for the Postgres database. You will find the production password for the database in your `config/passwords.yaml` file.
 
 ```bash
-$ export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
+export TF_VAR_DATABASE_PASSWORD_PRODUCTION="<MY PRODUCTION PASSWORD>"
 ```
 
 Next, we are ready to initialize Terraform and deploy our server. You will only need to run the `terraform init` command the first time you deploy the configuration.
 
 ```bash
-$ terraform init
-$ terraform apply
+terraform init
+terraform apply
 ```
 
 Terraform will now run some checks and make a plan for the deployment. If everything looks good, it will ask you if you are ready to go ahead with the changes. Type `yes` and hit the return key. Applying the changes can take up to five minutes as AWS creates the different resources needed for your Serverpod.
diff --git a/versioned_docs/version-3.4.0/07-deployments/05-general.md b/versioned_docs/version-3.4.0/07-deployments/05-general.md
index 981bb8d9..fa1f3878 100644
--- a/versioned_docs/version-3.4.0/07-deployments/05-general.md
+++ b/versioned_docs/version-3.4.0/07-deployments/05-general.md
@@ -11,7 +11,7 @@ Serverpod will not run without a link to a Postgres database with the correct ta
 Serverpod has three main configuration files, depending on which mode the server is running; `development`, `staging`, or `production`. The files are located in the `config/` directory. By default, the server will start in development mode. To use another configuration file, use the `--mode` option when starting the server. If you are running multiple servers in a cluster, use the `--server-id` option to specify the id of each server. By default, the server will run as id `default`. For instance, to start the server in production mode with id `2`, run the following command:
 
 ```bash
-$ dart bin/main.dart --mode production --server-id 2
+dart bin/main.dart --mode production --server-id 2
 ```
 
 :::info
@@ -35,7 +35,7 @@ Serverpod can assume different roles depending on your configuration. If you run
 You can specify the role of your server when you launch it by setting the `--role` argument.
 
 ```bash
-$ dart bin/main.dart --role serverless
+dart bin/main.dart --role serverless
 ```
 
 ## Docker container
diff --git a/versioned_docs/version-3.4.0/08-upgrading/03-upgrade-to-pgvector.md b/versioned_docs/version-3.4.0/08-upgrading/03-upgrade-to-pgvector.md
index 24896009..6f94d34c 100644
--- a/versioned_docs/version-3.4.0/08-upgrading/03-upgrade-to-pgvector.md
+++ b/versioned_docs/version-3.4.0/08-upgrading/03-upgrade-to-pgvector.md
@@ -64,8 +64,8 @@ fields:
 4. Generate and apply a migration:
 
 ```bash
-$ serverpod create-migration
-$ dart run bin/main.dart --apply-migrations
+serverpod create-migration
+dart run bin/main.dart --apply-migrations
 ```
 
 For more details on creating and applying migrations, see the [Migrations](../concepts/database/migrations) section.
diff --git a/versioned_docs/version-3.4.0/08-upgrading/04-archive/03-upgrade-to-two.md b/versioned_docs/version-3.4.0/08-upgrading/04-archive/03-upgrade-to-two.md
index 54e3b54d..5ef0d80a 100644
--- a/versioned_docs/version-3.4.0/08-upgrading/04-archive/03-upgrade-to-two.md
+++ b/versioned_docs/version-3.4.0/08-upgrading/04-archive/03-upgrade-to-two.md
@@ -284,7 +284,7 @@ To ensure new databases are created with the new representation, the latest migr
 A new empty migration can be created by running the following command in the terminal:
 
 ```bash
-$ serverpod create-migration --force
+serverpod create-migration --force
 ```
 
 #### Migration of existing tables
diff --git a/versioned_docs/version-3.4.0/09-tools/02-lsp.md b/versioned_docs/version-3.4.0/09-tools/02-lsp.md
index 2374cf57..8da02d1b 100644
--- a/versioned_docs/version-3.4.0/09-tools/02-lsp.md
+++ b/versioned_docs/version-3.4.0/09-tools/02-lsp.md
@@ -5,7 +5,7 @@ The [Language Server Protocol (LSP)](https://microsoft.github.io/language-server
 To start the Serverpod LSP server, use the following command:
 
 ```bash
-$ serverpod language-server
+serverpod language-server
 ```
 
 :::info
diff --git a/versioned_docs/version-3.4.0/09-tools/03-run-scripts.md b/versioned_docs/version-3.4.0/09-tools/03-run-scripts.md
index 699ed8ce..d040adcb 100644
--- a/versioned_docs/version-3.4.0/09-tools/03-run-scripts.md
+++ b/versioned_docs/version-3.4.0/09-tools/03-run-scripts.md
@@ -19,13 +19,13 @@ serverpod:
 To run a script:
 
 ```bash
-$ serverpod run start
+serverpod run start
 ```
 
 To list all available scripts, use the `--list` flag or omit the script name:
 
 ```bash
-$ serverpod run --list
+serverpod run --list
 ```
 
 Scripts run in a shell environment (`bash` on Linux/macOS, `cmd` on Windows), so you can use pipes, conditionals, and environment variables. The CLI forwards signals like `Ctrl+C` to the running script and propagates exit codes.
diff --git a/versioned_docs/version-3.4.0/index.md b/versioned_docs/version-3.4.0/index.md
index cedb7939..a1189aa9 100644
--- a/versioned_docs/version-3.4.0/index.md
+++ b/versioned_docs/version-3.4.0/index.md
@@ -65,7 +65,7 @@ Serverpod is tested on Mac, Windows, and Linux. Before you can install Serverpod
 Check your Flutter installation by running the following command in your terminal:
 
 ```bash
-$ flutter doctor
+flutter doctor
 ```
 
 :::
@@ -76,7 +76,7 @@ To make use of Serverpod's database connectivity, you need to have access to a P
 Check your Docker installation by running the following command in your terminal:
 
 ```bash
-$ docker info
+docker info
 ```
 
 If you are using Docker Desktop and you get an error, make sure that Docker is running. You can check this by looking for the Docker icon in your system tray or taskbar. If it's not running, start Docker Desktop and try again.
@@ -87,13 +87,13 @@ If you are using Docker Desktop and you get an error, make sure that Docker is r
 Serverpod is installed using the Dart package manager. To install Serverpod, run the following command in your terminal:
 
 ```bash
-$ dart pub global activate serverpod_cli
+dart pub global activate serverpod_cli
 ```
 
 This command will install the Serverpod command-line interface (CLI) globally on your machine. You can verify the installation by running:
 
 ```bash
-$ serverpod
+serverpod
 ```
 
 If everything is correctly configured, the help for the `serverpod` command is now displayed.
@@ -116,7 +116,7 @@ To create a new Serverpod project, use the `serverpod create` command. It will s
 The project will be created in a new directory with the name you specify. For example, to create a new project called `my_project`, run the following command:
 
 ```bash
-$ serverpod create my_project
+serverpod create my_project
 ```
 
 :::tip
@@ -141,20 +141,20 @@ During project creation, dependencies are automatically fetched.
 To run your new project you must first start the database from the Docker file that is included with the project. Do this by running the `docker compose up` command in the server directory:
 
 ```bash
-$ cd my_project/my_project_server
-$ docker compose up
+cd my_project/my_project_server
+docker compose up
 ```
 
 This will start the PostgreSQL database. You can stop the database server by pressing `Ctrl+C` in the terminal. If you want to run the servers in the background, you can use the `-d` flag:
 
 ```bash
-$ docker compose up -d
+docker compose up -d
 ```
 
 This will start the database server in detached mode, meaning it will run in the background and you can safely close the terminal window without stopping it. Stop the database container by running the following command from the server directory:
 
 ```bash
-$ docker compose down
+docker compose down
 ```
 
 :::tip
@@ -164,8 +164,8 @@ If you are using Docker Desktop, you can see and manage all your installed Docke
 Now that the database is up and running we can start the Serverpod server. Because we are running the project for the first time, we need to create the database tables used by Serverpod. This is done through a [database migration](./06-concepts/06-database/11-migrations.md). An initial migration is already created for us, so all we need to do is pass the `--apply-migrations` flag when starting the server:
 
 ```bash
-$ cd my_project/my_project_server
-$ dart run bin/main.dart --apply-migrations
+cd my_project/my_project_server
+dart run bin/main.dart --apply-migrations
 ```
 
 This will start the server and set up the initial database tables. You can now access the server at `http://localhost:8080` and the web server is available at `http://localhost:8082`. It should look like this:
@@ -175,8 +175,8 @@ This will start the server and set up the initial database tables. You can now a
 Now let's run our Flutter app. You can do this by running `flutter run -d chrome` in the flutter directory:
 
 ```bash
-$ cd my_project/my_project_flutter
-$ flutter run -d chrome
+cd my_project/my_project_flutter
+flutter run -d chrome
 ```
 
 This will start the Flutter app in your browser. It should look like this:
diff --git a/versioned_docs/version-3.4.0/serverpod-mini.md b/versioned_docs/version-3.4.0/serverpod-mini.md
index d9a254ca..54883a22 100644
--- a/versioned_docs/version-3.4.0/serverpod-mini.md
+++ b/versioned_docs/version-3.4.0/serverpod-mini.md
@@ -40,7 +40,7 @@ Serverpod Mini is a lightweight version of Serverpod that is perfect for small p
 Create a mini project by running:
 
 ```bash
-$ serverpod create myminipod --mini
+serverpod create myminipod --mini
 ```
 
 Serverpod will create a new project for you. It contains three Dart packages, but you only need to pay attention to the `myminipod_server` and `myminipod_flutter` directories. The server directory contains your server files, and the flutter directory contains your app. The third package (`myminipod_client`) contains generated code that is used by the Flutter app to communicate with the server.
@@ -48,15 +48,15 @@ Serverpod will create a new project for you. It contains three Dart packages, bu
 Start your server by changing directory into your server directory, and run the `bin/main.dart` file:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ dart bin/main.dart
+cd myminipod/myminipod_server
+dart bin/main.dart
 ```
 
 Your default project comes with a sample Flutter app, all hooked up to talk with your server. Run it with the `flutter` command:
 
 ```bash
-$ cd myminipod/myminipod_flutter
-$ flutter run -d chrome
+cd myminipod/myminipod_flutter
+flutter run -d chrome
 ```
 
 Easy as that. 🥳
@@ -84,8 +84,8 @@ For types, you can use most basic Dart types, such as `String`, `double`, `int`,
 Whenever you add or edit a model file, run `serverpod generate` in your server directory. Then, Serverpod will generate all the updated Dart classes:
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Adding methods to your server
@@ -121,8 +121,8 @@ class CompanyEndpoint extends Endpoint {
 After adding or modifying endpoints and endpoint methods, you must run `serverpod generate` to keep your Flutter app up-to-date.
 
 ```bash
-$ cd myminipod/myminipod_server
-$ serverpod generate
+cd myminipod/myminipod_server
+serverpod generate
 ```
 
 ## Calling the server methods from the app