# Disable

The disable command is used to disable features enabled by the enable command.

### Syntax

```
$ vela disable <feature>
```

The following features can be disabled:

- [`auth`](/disable/auth) - Disable authentication
- [`api`](/disable/api) - Disable the REST API
- [`api-keys`](/disable/api-keys) - Disable API key management
- [`backend`](/disable/backend) - Disable the PocketBase backend
- [`content-negotiation`](/disable/content-negotiation) - Disable content negotiation
- [`i18n`](/disable/i18n) - Disable internationalization
- [`notifications`](/disable/notifications) - Disable in-app notifications
- [`analytics`](/disable/analytics) - Disable web analytics
- [`ai`](/disable/ai) - Disable AI chat
- [`teams`](/disable/teams) - Disable teams
- [`payments`](/disable/payments) - Disable payments
- [`subscriptions`](/disable/subscriptions) - Disable Stripe subscriptions
- [`s3`](/disable/s3) - Disable S3 file storage
- [`smtp`](/disable/smtp) - Disable SMTP configuration

### Options

Every feature that changes files prompts before it does so. Pass `-y` or `--yes` to skip that confirmation. `s3` and `smtp` only flip a PocketBase setting, so they take no options.

### Data

Disabling reverts the code Vela generated, and some features take their data with them: `disable backend` deletes the local database in `data/`, and features that added collections drop them with every record in them (auth's `oauth_accounts`, API keys, teams, notifications, payments and subscriptions). Everything else is left alone: `disable auth` keeps the `users` collection and its records, the databases on your deploy targets are never touched, and nothing is deleted at Stripe. Each page lists what it removes and what it leaves behind.