sentry-junior · Oct 28, 2026
diff --git a/develop-docs/backend/application-domains/database-migrations/index.mdx b/develop-docs/backend/application-domains/database-migrations/index.mdx
@@ -20,15 +20,15 @@ Note that for all of these commands you can substitute `getsentry` for `sentry`
 
 ### Upgrade your database to latest
 
-`sentry upgrade` will automatically bring your migrations up to date. You can also run `sentry django migrate` to access the migration command directly.
+`sentry-server upgrade` will automatically bring your migrations up to date. You can also run `sentry-server django migrate` to access the migration command directly.
 
 ### Move your database to a specific migration
 
 This can be helpful for when you want to test a migration.
 
-`sentry django migrate <app_name> <migration_name>` - Note that `migration_name` can be a partial match, often the number is all you need.
+`sentry-server django migrate <app_name> <migration_name>` - Note that `migration_name` can be a partial match, often the number is all you need.
 
-eg: `sentry django migrate sentry 0005`
+eg: `sentry-server django migrate sentry 0005`
 
 This can be used to roll a migration back as well. Useful in dev if you make a mistake.
 
@@ -37,23 +37,23 @@ This can be used to roll a migration back as well. Useful in dev if you make a m
 A GitHub action will automatically comment on your PR with the SQL for your migration, and the comment will stay updated with any future changes.
 You can also manually generate SQL with this command.
 
-`sentry django sqlmigrate <app_name> <migration_name>`
+`sentry-server django sqlmigrate <app_name> <migration_name>`
 
-eg `sentry django sqlmigrate sentry 0003`
+eg `sentry-server django sqlmigrate sentry 0003`
 
 ### Generate Migrations
 
 This generates migrations for you automatically based on changes you've made to models.
 
-`sentry django makemigrations`
+`sentry-server django makemigrations`
 
 or
 
-`sentry django makemigrations <app_name>` for a specific app.
+`sentry-server django makemigrations <app_name>` for a specific app.
 
-eg `sentry django makemigrations sentry`
+eg `sentry-server django makemigrations sentry`
 
-You can also generate an empty migration with `sentry django makemigrations <app_name> --empty`. This is useful for data migrations and other custom work.
+You can also generate an empty migration with `sentry-server django makemigrations <app_name> --empty`. This is useful for data migrations and other custom work.
 
 Note that if you have added a new model, you also need to import the model in `__init__.py`, or the model will not be recognized in testing.
 
@@ -310,7 +310,7 @@ operations = [
 ]
 ```
 
-To produce the second migration we generate an empty migration (`sentry django makemigrations <your_app> --empty`), then use the same `SafeRemoveField` command from the previous migration, but change the deletion_action to `DeletionAction.DELETE`. This operation will remove the column from the table in Postgres:
+To produce the second migration we generate an empty migration (`sentry-server django makemigrations <your_app> --empty`), then use the same `SafeRemoveField` command from the previous migration, but change the deletion_action to `DeletionAction.DELETE`. This operation will remove the column from the table in Postgres:
 
 ```python
 operations = [
@@ -444,7 +444,7 @@ operations = [
 ]
 ```
 
-To produce the second migration we generate an empty migration (`sentry django makemigrations <your_app> --empty`), then use the same `SafeDeleteModel` command from the previous migration, but change the deletion_action to `DeletionAction.DELETE`. This operation will remove the table from Postgres:
+To produce the second migration we generate an empty migration (`sentry-server django makemigrations <your_app> --empty`), then use the same `SafeDeleteModel` command from the previous migration, but change the deletion_action to `DeletionAction.DELETE`. This operation will remove the table from Postgres:
 
 ```python
 operations = [

diff --git a/develop-docs/backend/application-domains/encrypted-fields/index.mdx b/develop-docs/backend/application-domains/encrypted-fields/index.mdx
@@ -118,8 +118,8 @@ class MyModel(models.Model):
 and generate a migration:
 
 ```bash
-sentry django makemigrations
-sentry upgrade
+sentry-server django makemigrations
+sentry-server upgrade
 ```
 
 ### Converting Existing Fields

diff --git a/develop-docs/backend/application-domains/feature-flags/index.mdx b/develop-docs/backend/application-domains/feature-flags/index.mdx
@@ -170,7 +170,7 @@ organization.features.includes('test-feature'); // evals to True/False
 
 ## Enabling features in development
 
-In Sentry you can run `sentry devserver` to view your changes in development
+In Sentry you can run `sentry-server devserver` to view your changes in development
 mode. If you would like to view a change behind a feature flag, you will need to
 open the file `~/.sentry/sentry.conf.py` on your local machine. This file
 contains your local settings for the sentry application, and can be viewed and

diff --git a/develop-docs/backend/application-domains/kafka.mdx b/develop-docs/backend/application-domains/kafka.mdx
@@ -27,7 +27,7 @@ KAFKA_CONSUMERS = {
 ```
 2. You may need optional properties (e.g. `click_options`, you will need to research them by looking at [ConsumerDefinition](https://github.com/getsentry/sentry/blob/master/src/sentry/conf/types/kafka_definition.py)'s code.
 
-3. Make sure you can run it: `sentry run consumer <your_topic>`
+3. Make sure you can run it: `sentry-server run consumer <your_topic>`
 4. You may need to add some devserver options [here](https://github.com/getsentry/sentry/blob/master/src/sentry/runner/commands/devserver.py).
 4. Add tests for your consumer
 

diff --git a/develop-docs/backend/application-domains/options.mdx b/develop-docs/backend/application-domains/options.mdx
@@ -42,15 +42,15 @@ feature_rate = options.get("performance.some-feature-rate")
 ```
 
 ## Setting Options
-In SaaS, option values are changed through pull requests to [sentry-options-automator](https://github.com/getsentry/sentry-options-automator). For self-hosted instances, you can change the value of an option using `sentry shell`, or by using the [options UI](#options-ui).
+In SaaS, option values are changed through pull requests to [sentry-options-automator](https://github.com/getsentry/sentry-options-automator). For self-hosted instances, you can change the value of an option using `sentry-server shell`, or by using the [options UI](#options-ui).
 
 ### Sentry Shell
-For direct database manipulation, you can set option values using sentry shell.
+For direct database manipulation, you can set option values using sentry-server shell.
 
-You can set option values using `sentry shell`. e.g.,
+You can set option values using `sentry-server shell`. e.g.,
 
 ```bash
-sentry shell
+sentry-server shell
 ```
 
 then,
@@ -115,7 +115,7 @@ If your option is short-lived, you should remove it once it's no longer needed.
 For self hosted instances, you can use the Sentry shell. e.g.,
 
 ```bash
-sentry shell
+sentry-server shell
 ```
 
 then,

diff --git a/develop-docs/backend/application-domains/tasks/running-workers.mdx b/develop-docs/backend/application-domains/tasks/running-workers.mdx
@@ -17,10 +17,10 @@ running workers:
 
 ```bash
 # Run a worker in the foreground
-sentry run taskworker
+sentry-server run taskworker
 
 # Run a worker as part of the devserver
-sentry devserver --workers
+sentry-server devserver --workers
 
 # Foreground the worker from a devservices mode like `ingest`
 devservices foreground taskworker
@@ -32,7 +32,7 @@ The task-scheduler is responsible for reading the task schedules from
 `settings.TASKWORKER_SCHEDULES` and spawning tasks as schedules become due.
 
 ```bash
-sentry run taskworker-scheduler
+sentry-server run taskworker-scheduler
 ```
 
 ## Running taskbroker

diff --git a/develop-docs/backend/config.mdx b/develop-docs/backend/config.mdx
@@ -17,7 +17,7 @@ During a new install, Sentry prompts first for a walkthrough of the Installation
 
 : The Python file will be loaded once all other configuration is referenced, and allows you to configure various server settings as well as more complex tuning.
 
-Many settings available in `config.yml` will also be able to be configured in the Sentry UI. Declaring them in the file will generally override the dynamically configured value and prevent it from being changed in the UI. These same settings can also be configured via the `sentry config` CLI helper.
+Many settings available in `config.yml` will also be able to be configured in the Sentry UI. Declaring them in the file will generally override the dynamically configured value and prevent it from being changed in the UI. These same settings can also be configured via the `sentry-server config` CLI helper.
 
 ## General
 
@@ -62,7 +62,7 @@ system.secret-key: "a-really-long-secret-value"
 To generate a new value, we’ve provided a helper:
 
 ```shell
-sentry config generate-secret-key
+sentry-server config generate-secret-key
 ```
 
 </markdown></ConfigValue>
@@ -84,7 +84,7 @@ Sentry can override logger levels by providing the CLI with the `-l/--loglevel`
 The value of this can be one of the [standard Python logging level strings](https://docs.python.org/3/library/logging.html#logging-levels).
 
 ```shell
-sentry --loglevel=WARNING
+sentry-server --loglevel=WARNING
 ```
 
 </markdown></ConfigValue>

diff --git a/develop-docs/backend/issue-platform/issue-types/index.mdx b/develop-docs/backend/issue-platform/issue-types/index.mdx
@@ -66,6 +66,6 @@ The issue platform provides functionality to help release your new issue type in
 - Post processing - This controls whether we'll pass the issue along to post processing. If disabled, then issues will be created but no notifications will be sent. This can be helpful for testing out what issues look like before release. _Note:_ Any issues created this way will not send new issue notifications after the flag is enabled, since they already exist. In the future, if there is demand we might provide a way to remove all test versions of a new issue type.
 - UI - This controls whether the issue type will appear in the issue list and elsewhere in the ui.
 
-These flags are all controlled via flagpole and set via options automator. To get the base values for all of these for easy pasting into flagpole, run `sentry createissueflag --slug=<your_group_slug> --owner=<your_team_name>`. The results of this can be directly pasted into flagpole.yml.
+These flags are all controlled via flagpole and set via options automator. To get the base values for all of these for easy pasting into flagpole, run `sentry-server createissueflag --slug=<your_group_slug> --owner=<your_team_name>`. The results of this can be directly pasted into flagpole.yml.
 
 Once your issue type is fully released, and you want it to go out to self-hosted and single tenant you can set `released = True` on your GroupType. This allows it to be released everywhere, and removes the feature flags and options. Generally we recommend doing this after your issue type has been in GA for long enough to verify that it's working as intended.
diff --git a/develop-docs/backend/issue-platform/writing-performance-detectors/index.mdx b/develop-docs/backend/issue-platform/writing-performance-detectors/index.mdx
@@ -103,7 +103,7 @@ Whenever possible, conduct tests using real data. It's advised to use actual tra
 Another tool that we used for validating and testing detector changes is a [CLI script](https://github.com/getsentry/sentry/pull/39727):
 
 ```shell
-sentry performance detect /path/to/event.json
+sentry-server performance detect /path/to/event.json
 ```
 
 ## Deployment

diff --git a/develop-docs/development-infrastructure/backend-development-server.mdx b/develop-docs/development-infrastructure/backend-development-server.mdx
@@ -16,16 +16,16 @@ STATIC_FRONTEND_APP_URL = "https://sentry.io/_static/dist/"
 ...and run:
 
 ```shell
-sentry run web
+sentry-server run web
 ```
 
 When you browse `localhost:9001`, the browser will load JavaScript from production instead of your local static folder.
 
 This will do literally nothing except bring up the web workers. You are now responsible to manually:
 
 * Starting relevant Kafka consumers if you need them (e.g. for ingestion). This highly depends on which dataset you're working on.
-* Starting Celery workers using `sentry run worker` to run most kinds of background jobs.
+* Starting Celery workers using `sentry-server run worker` to run most kinds of background jobs.
 
-Use `sentry run --help` to see what you might be missing by not running devserver.
+Use `sentry-server run --help` to see what you might be missing by not running devserver.
 
 To run the development server with ngrok, see [Developing with Ngrok](/development-infrastructure/ngrok/).
diff --git a/develop-docs/development-infrastructure/environment/index.mdx b/develop-docs/development-infrastructure/environment/index.mdx
@@ -45,7 +45,12 @@ devservices serve
 
 Access it at [http://dev.getsentry.net:8000](http://dev.getsentry.net:8000) (you'll have to wait a bit for webpack to finish).
 A superuser account should have been created for you during bootstrap - `admin@sentry.io` with password `admin`.
-You can create other users with `sentry createuser`.
+You can create other users with `sentry-server createuser`.
+
+<Alert title="Note">
+  The server CLI was renamed from `sentry` to `sentry-server`. `sentry` now
+  refers to the [Sentry CLI](https://github.com/getsentry/cli).
+</Alert>
 
 <Alert title="Note">
   When asked for the root address of the server, make sure that you use
@@ -147,7 +152,7 @@ devservices serve
 
 ## Running siloed instances
 
-By default `sentry devserver` will run a monolith mode application server. You can also run `devserver` with siloed application instances. Before you do, you need to <Link to="/backend/application-domains/database-migrations/#cloning-a-monolith-database">create split silo databases</Link>.
+By default `sentry-server devserver` will run a monolith mode application server. You can also run `devserver` with siloed application instances. Before you do, you need to <Link to="/backend/application-domains/database-migrations/#cloning-a-monolith-database">create split silo databases</Link>.
 
 The devserver command supports `--silo` option that lets you create siloed instances. Any workers, consumers, or celery-beat processes will be started with the same silo mode.
 

diff --git a/develop-docs/development-infrastructure/environment/ports.mdx b/develop-docs/development-infrastructure/environment/ports.mdx
@@ -21,16 +21,16 @@ The following is a non-exhaustive list of ports used by Sentry services or any d
 | 9093  | Kafka                                      |
 | 6379  | Redis                                      | <Link to="/development-infrastructure/devservices/">Devservice</Link> `redis` (or perhaps installed via Homebrew in rustier setups), responsible for caches, relay projectconfigs and Celery queues
 | 5432  | Postgres                                   | <Link to="/development-infrastructure/devservices/">Devservice</Link> `postgres` (or perhaps installed via Homebrew in rustier setups)
-| 7899  | [Relay][]                                  | <Link to="/development-infrastructure/devservices/">Devservice</Link> `relay`. Serves APIs for SDKs to send events to (aka event ingestion). Webpack on 8000 reverse-proxies to this server. Starts/stops with `sentry devserver`.
+| 7899  | [Relay][]                                  | <Link to="/development-infrastructure/devservices/">Devservice</Link> `relay`. Serves APIs for SDKs to send events to (aka event ingestion). Webpack on 8000 reverse-proxies to this server. Starts/stops with `sentry-server devserver`.
 | 8000  | <Link to="/development-infrastructure/environment/">Sentry Dev</Link> | Webpack devserver, routing all ingest paths to Relay, and the rest to uWSGI. Routing is defined in `webpack.config.ts` in Sentry.
-| 8001  | uWSGI                                      | Starts/stops with `sentry devserver`. Serves the Django app/API. Webpack on 8000 reverse-proxies to this server. In a siloed devserver, this port is used for control silo.
-| 8010  | uWSGI (region silo)                        | Starts/stops with `sentry devserver --silo=region`. Serves the Django app/API. Webpack on 8000 reverse-proxies to this server.
+| 8001  | uWSGI                                      | Starts/stops with `sentry-server devserver`. Serves the Django app/API. Webpack on 8000 reverse-proxies to this server. In a siloed devserver, this port is used for control silo.
+| 8010  | uWSGI (region silo)                        | Starts/stops with `sentry-server devserver --silo=region`. Serves the Django app/API. Webpack on 8000 reverse-proxies to this server.
 | 7999  | Sentry frontend prod proxy                 | For testing local UI changes against a prod API
 | 8000  | [Develop docs][]                           | The website around this document. **Conflicts with Sentry Dev.**
 | 3000  | [User docs][]                              | User-facing documentation. May conflict with Relay if Relay is run outside of devservices.
-| 9001  | Sentry Dev Styleguide server               | Bound when running `sentry devserver --styleguide`
-| 9000  | `sentry run web`                           | Legacy default port for `sentry run web`, changed to 9001 to avoid conflict with Clickhouse.
-| 9001  | `sentry run web`                           | Barebones frontend without webpack or Relay. <Link to="/development-infrastructure/environment/">Sentry Dev</Link> is likely better. **Conflicts with Sentry Dev Styleguide server.**
+| 9001  | Sentry Dev Styleguide server               | Bound when running `sentry-server devserver --styleguide`
+| 9000  | `sentry-server run web`                    | Legacy default port for `sentry-server run web`, changed to 9001 to avoid conflict with Clickhouse.
+| 9001  | `sentry-server run web`                    | Barebones frontend without webpack or Relay. <Link to="/development-infrastructure/environment/">Sentry Dev</Link> is likely better. **Conflicts with Sentry Dev Styleguide server.**
 | 8000  | [Relay][] mkdocs documentation             | At some point this is going to get merged into our existing docs repos. **Conflicts with Sentry Dev.**
 | 50051 | Taskbroker                                 | <Link to="/backend/application-domains/tasks/">taskbroker</Link> gRPC interface for taskbroker.
 | 8969  | Sentry Spotlight                           |

diff --git a/develop-docs/development-infrastructure/environment/u2f.mdx b/develop-docs/development-infrastructure/environment/u2f.mdx
@@ -37,5 +37,5 @@ Note: We're using an optional `NGROK` environment variable here so you can easil
 Now you start your development server:
 
 ```shell
-NGROK=1 sentry devserver
+NGROK=1 sentry-server devserver
 ```
diff --git a/develop-docs/development-infrastructure/ngrok.mdx b/develop-docs/development-infrastructure/ngrok.mdx
@@ -65,7 +65,7 @@ To learn more about how silo mode works in the dev environment, refer to <Link t
 
 
 ### Step 1: Split Local DB into Silos
-By default `sentry devserver` will run a monolith mode application server. You can also run ``devserver`` with siloed application instances. Before you do, you need to <Link to="/backend/application-domains/database-migrations/#cloning-a-monolith-database">create split silo databases</Link>.
+By default `sentry-server devserver` will run a monolith mode application server. You can also run ``devserver`` with siloed application instances. Before you do, you need to <Link to="/backend/application-domains/database-migrations/#cloning-a-monolith-database">create split silo databases</Link>.
 
 
 ### Step 2: Create Ngrok Config File

diff --git a/develop-docs/frontend/component-library.mdx b/develop-docs/frontend/component-library.mdx
@@ -21,7 +21,7 @@ Stories is a custom docs framework served under the `/stories` path inside the m
     Log in and then visit [`/stories/`](https://sentry.io/orgredirect/organizations/:orgslug/stories/) on your existing Sentry Organization. This works the same on sentry.io or for self-hosted installations.
 
 - **Dev Access**<br />
-    Whether you are using `pnpm dev-ui` to start a development server, or `sentry devserver` to spin up all the services locally, you can access Stories by logging in and changing the path from `/issues/` (the default landing page) to `/stories/`.
+    Whether you are using `pnpm dev-ui` to start a development server, or `sentry-server devserver` to spin up all the services locally, you can access Stories by logging in and changing the path from `/issues/` (the default landing page) to `/stories/`.
 
 ## Contributing to Stories
 

diff --git a/develop-docs/frontend/upgrade-policies.mdx b/develop-docs/frontend/upgrade-policies.mdx
@@ -147,7 +147,7 @@ For example, some dependencies such as `webpack` fall both into the app build **
 
    If you’ve upgraded a build or development dependency, you’ll definitely want to make sure the development environment is still working as expected.
 
-   - Does `sentry devserver` still correctly run the client-side application?
+   - Does `sentry-server devserver` still correctly run the client-side application?
 
    - Does `pnpm dev-ui` still run the client-only version of the application?