From 1b4b422a32395fbda4e046d9809d6e8a06bf86c9 Mon Sep 17 00:00:00 2001 From: "sentry-junior[bot]" <264270552+sentry-junior[bot]@users.noreply.github.com> Date: Wed, 28 Oct 2026 21:26:37 +0000 Subject: [PATCH] docs(develop): Use sentry-server for Sentry server CLI commands Co-Authored-By: David Cramer --- .../database-migrations/index.mdx | 22 +++++++++---------- .../encrypted-fields/index.mdx | 4 ++-- .../feature-flags/index.mdx | 2 +- .../backend/application-domains/kafka.mdx | 2 +- .../backend/application-domains/options.mdx | 10 ++++----- .../tasks/running-workers.mdx | 6 ++--- develop-docs/backend/config.mdx | 6 ++--- .../issue-platform/issue-types/index.mdx | 2 +- .../writing-performance-detectors/index.mdx | 2 +- .../backend-development-server.mdx | 6 ++--- .../environment/index.mdx | 9 ++++++-- .../environment/ports.mdx | 12 +++++----- .../environment/u2f.mdx | 2 +- .../development-infrastructure/ngrok.mdx | 2 +- develop-docs/frontend/component-library.mdx | 2 +- develop-docs/frontend/upgrade-policies.mdx | 2 +- .../external-storage.mdx | 4 ++-- develop-docs/self-hosted/tasks.mdx | 2 +- 18 files changed, 51 insertions(+), 46 deletions(-) diff --git a/develop-docs/backend/application-domains/database-migrations/index.mdx b/develop-docs/backend/application-domains/database-migrations/index.mdx index 5e097d1f7ed770..4c3078512e88d4 100644 --- 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 ` - Note that `migration_name` can be a partial match, often the number is all you need. +`sentry-server django migrate ` - 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 ` +`sentry-server django sqlmigrate ` -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 ` for a specific app. +`sentry-server django makemigrations ` 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 --empty`. This is useful for data migrations and other custom work. +You can also generate an empty migration with `sentry-server django makemigrations --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 --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 --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 --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 --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 index 17faf852ec1b31..ae718957563302 100644 --- 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 index 1124feffb0489b..f07c3c0f19efa5 100644 --- 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 index e4a8ae4d36ffed..2449ec771d56fc 100644 --- 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 ` +3. Make sure you can run it: `sentry-server run consumer ` 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 index a2cc26366d3976..cd305fbd7a5c05 100644 --- 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 index 4ee55e6f35003a..015b4c7b755b7e 100644 --- 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 index 5ad41ec8d1a30f..d6ed3db21ebd75 100644 --- 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 ``` @@ -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 ``` diff --git a/develop-docs/backend/issue-platform/issue-types/index.mdx b/develop-docs/backend/issue-platform/issue-types/index.mdx index 316bd2e4cb50d6..4aaed212302c11 100644 --- 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= --owner=`. 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= --owner=`. 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 index 36bcd078c583bf..eef0d8df7688dd 100644 --- 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 index e85269ecd6c6ed..150fea1ed94ed0 100644 --- a/develop-docs/development-infrastructure/backend-development-server.mdx +++ b/develop-docs/development-infrastructure/backend-development-server.mdx @@ -16,7 +16,7 @@ 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. @@ -24,8 +24,8 @@ When you browse `localhost:9001`, the browser will load JavaScript from producti 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 index 8180f91de1d107..c16ee60be9b32a 100644 --- 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`. + + + The server CLI was renamed from `sentry` to `sentry-server`. `sentry` now + refers to the [Sentry CLI](https://github.com/getsentry/cli). + 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 create split silo databases. +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 create split silo databases. 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 index 8f80c01f9d73fd..85857ad08a0587 100644 --- 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 | Devservice `redis` (or perhaps installed via Homebrew in rustier setups), responsible for caches, relay projectconfigs and Celery queues | 5432 | Postgres | Devservice `postgres` (or perhaps installed via Homebrew in rustier setups) -| 7899 | [Relay][] | Devservice `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][] | Devservice `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 | Sentry Dev | 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. Sentry Dev 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. Sentry Dev 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 | taskbroker 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 index a632d9a2d1e6f9..665ab70ec2fe82 100644 --- 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 index 85f97e4642dd2c..4b5430fa5ad959 100644 --- 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 create split silo databases. +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 create split silo databases. ### Step 2: Create Ngrok Config File diff --git a/develop-docs/frontend/component-library.mdx b/develop-docs/frontend/component-library.mdx index df100a6709ef06..8bf594c3671c5b 100644 --- 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**
- 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 index a5918f51bed162..58da27592055a5 100644 --- 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? diff --git a/develop-docs/self-hosted/production-enhancements/external-storage.mdx b/develop-docs/self-hosted/production-enhancements/external-storage.mdx index e8361734609152..ed449b2205c225 100644 --- a/develop-docs/self-hosted/production-enhancements/external-storage.mdx +++ b/develop-docs/self-hosted/production-enhancements/external-storage.mdx @@ -14,7 +14,7 @@ In some cases, storing Sentry data on-disk is not really something people can do Sentry has an abstraction called "filestore" that handles storing attachments, sourcemaps (release artifacts), and replays. Filestore configuration for Sentry should be configured on the `sentry/config.yml` file. -**Important:** `sentry cleanup` command won't delete files that is stored on an external storage such as GCS or S3. You will have to configure your own cleanup mechanism by utilizing your storage provider's object retention configuration. This should be set accordingly to the `SENTRY_EVENTS_RETENTION_DAYS`, although you can set it as a different value than what's set on the Docker Compose file. +**Important:** `sentry-server cleanup` command won't delete files that is stored on an external storage such as GCS or S3. You will have to configure your own cleanup mechanism by utilizing your storage provider's object retention configuration. This should be set accordingly to the `SENTRY_EVENTS_RETENTION_DAYS`, although you can set it as a different value than what's set on the Docker Compose file. ### Google Cloud Storage backend @@ -71,7 +71,7 @@ Refer to [botocore configuration](https://botocore.amazonaws.com/v1/documentatio Vroom is the service that handles profiling. By default the data for profiling is saved on the local filesystem. On self-hosted deployments, this should be done by overriding the `SENTRY_BUCKET_PROFILES` environment variable. It's also possible that additional environment variables should be added, depending on the backend of choice. -**Important:** `sentry cleanup` command won't delete files that is stored on an external storage such as GCS or S3. You will have to configure your own cleanup mechanism by utilizing your storage provider's object retention configuration. This should be set accordingly to the `SENTRY_EVENTS_RETENTION_DAYS`, although you can set it as a different value than what's set on the Docker Compose file. +**Important:** `sentry-server cleanup` command won't delete files that is stored on an external storage such as GCS or S3. You will have to configure your own cleanup mechanism by utilizing your storage provider's object retention configuration. This should be set accordingly to the `SENTRY_EVENTS_RETENTION_DAYS`, although you can set it as a different value than what's set on the Docker Compose file. ### Google Cloud Storage backend diff --git a/develop-docs/self-hosted/tasks.mdx b/develop-docs/self-hosted/tasks.mdx index 0c85b86b528786..ff60d330351589 100644 --- a/develop-docs/self-hosted/tasks.mdx +++ b/develop-docs/self-hosted/tasks.mdx @@ -34,7 +34,7 @@ additional broker replicas and use CLI options to inform the workers of the broker addresses: ```bash -sentry run taskworker --rpc-host-list=sentry-broker-default-0:50051,sentry-broker-default-1:50051 +sentry-server run taskworker --rpc-host-list=sentry-broker-default-0:50051,sentry-broker-default-1:50051 ``` Workers use client-side loadbalancing to distribute load across the brokers they