Deprecated Commands Migration Guide

Version: v0.9.9+ Last Updated: 2026-02-16

Overview

Starting in v0.9.9, nself consolidated 79 top-level commands into 31 organized command hierarchies. This consolidation improves:

Discoverability - Related functionality grouped logically
Consistency - Predictable command patterns
Maintainability - Easier to document and extend
User Experience - Less cognitive load, clearer mental model

What this means for you:

All deprecated commands still work in v0.9.9+ with warning messages
Commands will be removed in v1.0.0 (planned)
Simple migration: most commands just need a prefix added

Example:

# Old (deprecated)
nself email send [email protected] "Subject" --body "Message"

# New (recommended)
nself service email send [email protected] "Subject" --body "Message"

Quick Reference Table

All Deprecated Commands

Old Command	New Command	Category	Notes
`billing <cmd>`	`tenant billing <cmd>`	Multi-tenancy	Billing is tenant-specific
`org <cmd>`	`tenant org <cmd>`	Multi-tenancy	Organizations are tenant containers
`upgrade <cmd>`	`deploy upgrade <cmd>`	Deployment	Upgrade is a deployment operation
`staging`	`deploy staging`	Deployment	Quick access to staging deployment
`prod`	`deploy production`	Deployment	Quick access to prod deployment
`production`	`deploy production`	Deployment	Alias for consistency
`provision <cmd>`	`deploy provision <cmd>`	Deployment	Provision for deployment
`server <cmd>`	`deploy server <cmd>`	Deployment	Server management for deployment
`servers <cmd>`	`deploy server list`	Deployment	Alias for server listing
`sync <cmd>`	`deploy sync <cmd>` OR `config sync <cmd>`	Deployment/Config	Context-dependent (see below)
`provider <cmd>`	`infra provider <cmd>`	Infrastructure	Cloud infrastructure
`cloud <cmd>`	`infra provider <cmd>`	Infrastructure	Deprecated, now provider
`k8s <cmd>`	`infra k8s <cmd>`	Infrastructure	Kubernetes infrastructure
`helm <cmd>`	`infra helm <cmd>`	Infrastructure	Helm infrastructure
`storage <cmd>`	`service storage <cmd>`	Services	Storage is a service
`email <cmd>`	`service email <cmd>`	Services	Email is a service
`search <cmd>`	`service search <cmd>`	Services	Search is a service
`redis <cmd>`	`service redis <cmd>`	Services	Redis is a service
`functions <cmd>`	`service functions <cmd>`	Services	Functions are a service
`mlflow <cmd>`	`service mlflow <cmd>`	Services	MLflow is a service
`realtime <cmd>`	`service realtime <cmd>`	Services	Realtime is a service
`admin-dev`	`service admin --dev`	Services	Dev mode flag
`env <cmd>`	`config env <cmd>`	Configuration	Environment configuration
`secrets <cmd>`	`config secrets <cmd>`	Configuration	Secrets are configuration
`vault <cmd>`	`config vault <cmd>`	Configuration	Vault is for secrets/config
`validate`	`config validate`	Configuration	Configuration validation
`mfa <cmd>`	`auth mfa <cmd>`	Security	MFA is authentication
`roles <cmd>`	`auth roles <cmd>`	Security	Roles are auth/security
`devices <cmd>`	`auth devices <cmd>`	Security	Device management is auth
`oauth <cmd>`	`auth oauth <cmd>`	Security	OAuth is authentication
`security <cmd>`	`auth security <cmd>`	Security	Security operations
`ssl <cmd>`	`auth ssl <cmd>`	Security	SSL is security
`trust`	`auth ssl trust`	Security	Trust local certificates
`rate-limit <cmd>`	`auth rate-limit <cmd>`	Security	Rate limiting is security
`webhooks <cmd>`	`auth webhooks <cmd>`	Security	Webhook security
`bench <cmd>`	`perf bench <cmd>`	Performance	Benchmarking is performance
`scale <cmd>`	`perf scale <cmd>`	Performance	Scaling is performance
`migrate <cmd>`	`perf migrate <cmd>`	Performance	Migration is performance-related
`rollback`	`backup rollback`	Backup	Rollback is backup/recovery
`reset`	`backup reset`	Backup	Reset is recovery
`clean`	`backup clean`	Backup	Cleanup is maintenance
`frontend <cmd>`	`dev frontend <cmd>`	Developer Tools	Frontend is dev tooling
`ci <cmd>`	`dev ci <cmd>`	Developer Tools	CI/CD is dev tooling
`docs <cmd>`	`dev docs <cmd>`	Developer Tools	Documentation is dev tooling
`whitelabel <cmd>`	`dev whitelabel <cmd>`	Developer Tools	White-label is dev tooling

Detailed Migrations by Category

1. Service Commands

Philosophy: All optional services (storage, email, search, redis, functions, mlflow, realtime) are now under the unified service command.

email → service email

Old:

nself email send [email protected] "Welcome" --body "Hello!"
nself email template list
nself email test smtp
nself email config sendgrid

New:

nself service email send [email protected] "Welcome" --body "Hello!"
nself service email template list
nself service email test smtp
nself service email config sendgrid

Why: Email is a service like any other. Grouping under service makes it consistent with other service management commands.

functions → service functions

Old:

nself functions init
nself functions deploy my-function
nself functions list
nself functions logs my-function
nself functions invoke my-function --data '{"key":"value"}'

New:

nself service functions init
nself service functions deploy my-function
nself service functions list
nself service functions logs my-function
nself service functions invoke my-function --data '{"key":"value"}'

mlflow → service mlflow

Old:

nself mlflow init
nself mlflow ui
nself mlflow experiments
nself mlflow models

New:

nself service mlflow init
nself service mlflow ui
nself service mlflow experiments
nself service mlflow models

realtime → service realtime

Old:

nself realtime init
nself realtime events
nself realtime test

New:

nself service realtime init
nself service realtime events
nself service realtime test

redis → service redis

Old:

nself redis init
nself redis flush --pattern "session:*"
nself redis cli
nself redis stats

New:

nself service redis init
nself service redis flush --pattern "session:*"
nself service redis cli
nself service redis stats

search → service search

Old:

nself search init meilisearch
nself search index create products
nself search query "laptop"
nself search config

New:

nself service search init meilisearch
nself service search index create products
nself service search query "laptop"
nself service search config

storage → service storage

Old:

nself storage init
nself storage upload photo.jpg
nself storage list images/
nself storage delete old-file.pdf
nself storage config
nself storage status
nself storage test
nself storage graphql-setup

New:

nself service storage init
nself service storage upload photo.jpg
nself service storage list images/
nself service storage delete old-file.pdf
nself service storage config
nself service storage status
nself service storage test
nself service storage graphql-setup

admin-dev → service admin --dev

Old:

nself admin-dev

New:

nself service admin --dev
# Or simply:
nself admin --dev

Note: nself admin is still a top-level utility command, but the dev mode is now a flag.

2. Deployment Commands

Philosophy: All deployment-related operations (staging, production, provisioning, servers, upgrades) belong under deploy.

staging → deploy staging

Old:

nself staging --auto-migrate

New:

nself deploy staging --auto-migrate

Why: Staging is a deployment environment, not a standalone concept.

prod / production → deploy production

Old:

nself prod --auto-migrate
nself production --auto-migrate

New:

nself deploy production --auto-migrate
# Or use the alias:
nself deploy prod --auto-migrate

provision → deploy provision

Old:

nself provision hetzner --size cx21 --region nbg1
nself provision digitalocean --size s-2vcpu-4gb --region nyc3

New:

nself deploy provision hetzner --size cx21 --region nbg1
nself deploy provision digitalocean --size s-2vcpu-4gb --region nyc3

Why: Provisioning is the first step in deployment. It creates the server you'll deploy to.

server / servers → deploy server

Old:

nself server list
nself server create staging-1 --host 192.168.1.100
nself server status staging-1
nself server ssh staging-1
nself server destroy staging-1

nself servers list  # Alias

New:

nself deploy server list
nself deploy server create staging-1 --host 192.168.1.100
nself deploy server status staging-1
nself deploy server ssh staging-1
nself deploy server destroy staging-1

Note: servers list is now deploy server list (singular).

New in v0.9.6 - Enhanced Server Management:

nself deploy server init <host> --domain example.com    # Initialize VPS for nself
nself deploy server check <host>                        # Verify server readiness
nself deploy server diagnose staging                    # Comprehensive diagnostics
nself deploy server add staging-2 --host 10.0.0.5       # Add server configuration
nself deploy server remove staging-2 --force            # Remove server configuration
nself deploy server info staging-1                      # Display comprehensive info

upgrade → deploy upgrade

Old:

nself upgrade --zero-downtime
nself upgrade --version 0.9.8

New:

nself deploy upgrade --zero-downtime
nself deploy upgrade --version 0.9.8

Why: Upgrading is a deployment operation that affects running infrastructure.

sync → deploy sync OR config sync (Special Case)

This command was SPLIT into two categories based on context:

Deploy Sync (Remote Environment Synchronization)

Use case: Syncing code/configurations between local and remote environments.

Old:

nself sync staging pull
nself sync prod push
nself sync status

New:

nself deploy sync pull staging --dry-run
nself deploy sync push prod --force
nself deploy sync status
nself deploy sync full staging --no-rebuild

New in v0.9.6:

--dry-run flag for safe preview
--force flag to skip confirmations
full subcommand for complete synchronization

Config Sync (Configuration Management)

Use case: Syncing configuration files, environment variables, secrets.

Old:

nself sync env staging
nself sync secrets prod

New:

nself config sync env staging
nself config sync secrets prod
nself config sync validate

Decision Guide:

Deploying/pushing code to servers? → Use deploy sync
Managing environment variables/secrets? → Use config sync

3. Infrastructure Commands

Philosophy: All cloud, Kubernetes, and infrastructure operations belong under infra.

provider / cloud → infra provider

Old:

nself provider list
nself provider init hetzner
nself provider validate aws
nself provider server create digitalocean

nself cloud list  # Deprecated alias

New:

nself infra provider list
nself infra provider init hetzner
nself infra provider validate aws
nself infra provider server create digitalocean

New in v0.9.6 - Kubernetes Abstraction:

# Unified K8s cluster management across 8 cloud providers
nself infra provider k8s-create aws my-cluster us-east-1 3 medium
nself infra provider k8s-delete gcp my-cluster us-central1
nself infra provider k8s-kubeconfig digitalocean my-cluster nyc3

Supported K8s Providers:

AWS (EKS) - $73/month control plane
GCP (GKE) - Free control plane
Azure (AKS) - Free control plane
DigitalOcean (DOKS) - $12/month
Linode (LKE) - Free control plane
Vultr (VKE) - Free control plane
Hetzner - Free control plane (manual via console)
Scaleway (Kapsule) - Free control plane

k8s → infra k8s

Old:

nself k8s init
nself k8s convert
nself k8s apply
nself k8s deploy
nself k8s status
nself k8s logs my-pod
nself k8s scale my-deployment 5
nself k8s rollback
nself k8s delete

New:

nself infra k8s init
nself infra k8s convert
nself infra k8s apply
nself infra k8s deploy
nself infra k8s status
nself infra k8s logs my-pod
nself infra k8s scale my-deployment 5
nself infra k8s rollback
nself infra k8s delete

helm → infra helm

Old:

nself helm init
nself helm generate
nself helm install my-release
nself helm upgrade my-release
nself helm rollback my-release
nself helm list
nself helm status my-release

New:

nself infra helm init
nself infra helm generate
nself infra helm install my-release
nself infra helm upgrade my-release
nself infra helm rollback my-release
nself infra helm list
nself infra helm status my-release

4. Configuration Commands

Philosophy: All environment variables, secrets, and configuration management belong under config.

env → config env

Old:

nself env list
nself env switch staging
nself env create testing
nself env delete testing
nself env sync prod

New:

nself config env list
nself config env switch staging
nself config env create testing
nself config env delete testing
nself config env sync prod

secrets → config secrets

Old:

nself secrets list
nself secrets get DATABASE_PASSWORD
nself secrets set API_KEY "abc123"
nself secrets delete OLD_KEY
nself secrets rotate

New:

nself config secrets list
nself config secrets get DATABASE_PASSWORD
nself config secrets set API_KEY "abc123"
nself config secrets delete OLD_KEY
nself config secrets rotate

vault → config vault

Old:

nself vault init
nself vault config
nself vault status

New:

nself config vault init
nself config vault config
nself config vault status

validate → config validate

Old:

nself validate
nself validate --strict

New:

nself config validate
nself config validate --strict

5. Authentication & Security Commands

Philosophy: All authentication, authorization, SSL, and security operations belong under auth.

mfa → auth mfa

Old:

nself mfa enable
nself mfa disable
nself mfa verify 123456
nself mfa backup-codes

New:

nself auth mfa enable
nself auth mfa disable
nself auth mfa verify 123456
nself auth mfa backup-codes

roles → auth roles

Old:

nself roles list
nself roles create admin "admin,users,billing"
nself roles assign [email protected] admin
nself roles remove [email protected] admin

New:

nself auth roles list
nself auth roles create admin "admin,users,billing"
nself auth roles assign [email protected] admin
nself auth roles remove [email protected] admin

devices → auth devices

Old:

nself devices list
nself devices register my-laptop
nself devices revoke old-phone
nself devices trust my-laptop

New:

nself auth devices list
nself auth devices register my-laptop
nself auth devices revoke old-phone
nself auth devices trust my-laptop

oauth → auth oauth

Old:

nself oauth install
nself oauth enable google
nself oauth disable github
nself oauth config google --client-id XXX --client-secret YYY
nself oauth test google
nself oauth list
nself oauth status

New:

nself auth oauth install
nself auth oauth enable google
nself auth oauth disable github
nself auth oauth config google --client-id XXX --client-secret YYY
nself auth oauth test google
nself auth oauth list
nself auth oauth status

security → auth security

Old:

nself security scan
nself security scan --deep
nself security audit
nself security report

New:

nself auth security scan
nself auth security scan --deep
nself auth security audit
nself auth security report

ssl → auth ssl

Old:

nself ssl generate example.com
nself ssl install ./cert.pem
nself ssl renew example.com
nself ssl info example.com

New:

nself auth ssl generate example.com
nself auth ssl install ./cert.pem
nself auth ssl renew example.com
nself auth ssl info example.com

trust → auth ssl trust

Old:

nself trust

New:

nself auth ssl trust

Why: "Trust" specifically refers to trusting self-signed SSL certificates for local development.

rate-limit → auth rate-limit

Old:

nself rate-limit config --requests 100 --window 60
nself rate-limit status
nself rate-limit reset 192.168.1.100

New:

nself auth rate-limit config --requests 100 --window 60
nself auth rate-limit status
nself auth rate-limit reset 192.168.1.100

webhooks → auth webhooks

Old:

nself webhooks create https://example.com/hook user.created,user.updated
nself webhooks list
nself webhooks delete webhook-123
nself webhooks test webhook-123
nself webhooks logs webhook-123

New:

nself auth webhooks create https://example.com/hook user.created,user.updated
nself auth webhooks list
nself auth webhooks delete webhook-123
nself auth webhooks test webhook-123
nself auth webhooks logs webhook-123

Why: Webhooks are a security concern (authentication, validation, replay protection).

6. Performance Commands

Philosophy: All performance, benchmarking, and scaling operations belong under perf.

bench → perf bench

Old:

nself bench
nself bench postgres --duration 60
nself bench api --requests 10000

New:

nself perf bench
nself perf bench postgres --duration 60
nself perf bench api --requests 10000

scale → perf scale

Old:

nself scale api 5
nself scale worker 10

New:

nself perf scale api 5
nself perf scale worker 10

migrate → perf migrate

Old:

nself migrate --analyze
nself migrate --optimize

New:

nself perf migrate --analyze
nself perf migrate --optimize

Note: This is different from nself db migrate (database migrations). perf migrate is for performance optimization during migrations.

7. Backup & Recovery Commands

Philosophy: All backup, restore, rollback, and cleanup operations belong under backup.

rollback → backup rollback

Old:

nself rollback
nself rollback --version 3

New:

nself backup rollback
nself backup rollback --version 3

reset → backup reset

Old:

nself reset
nself reset --confirm

New:

nself backup reset
nself backup reset --confirm

clean → backup clean

Old:

nself clean
nself clean --age 30
nself clean --dry-run

New:

nself backup clean
nself backup clean --age 30
nself backup clean --dry-run

8. Multi-Tenancy & Billing Commands

Philosophy: All tenant operations (including billing and organizations) belong under tenant.

billing → tenant billing

Old:

nself billing plans
nself billing subscribe tenant-123 enterprise
nself billing cancel tenant-123
nself billing usage tenant-123
nself billing invoice tenant-123
nself billing payment tenant-123
nself billing stripe
nself billing test

New:

nself tenant billing plans
nself tenant billing subscribe tenant-123 enterprise
nself tenant billing cancel tenant-123
nself tenant billing usage tenant-123
nself tenant billing invoice tenant-123
nself tenant billing payment tenant-123
nself tenant billing stripe
nself tenant billing test

Why: Billing is always tenant-specific. No billing exists without a tenant context.

org → tenant org

Old:

nself org create "Acme Corp"
nself org list
nself org show org-123
nself org members org-123
nself org delete org-123

New:

nself tenant org create "Acme Corp"
nself tenant org list
nself tenant org show org-123
nself tenant org members org-123
nself tenant org delete org-123

Why: Organizations are containers for multiple tenants. They're part of the multi-tenancy system.

9. Developer Tools Commands

Philosophy: All developer tooling (frontend, CI, docs, white-label) belongs under dev.

frontend → dev frontend

Old:

nself frontend add webapp 3000
nself frontend remove webapp
nself frontend list
nself frontend config webapp

New:

nself dev frontend add webapp 3000
nself dev frontend remove webapp
nself dev frontend list
nself dev frontend config webapp

ci → dev ci

Old:

nself ci generate
nself ci generate --provider github
nself ci update
nself ci templates

New:

nself dev ci generate
nself dev ci generate --provider github
nself dev ci update
nself dev ci templates

docs → dev docs

Old:

nself docs generate
nself docs serve
nself docs build

New:

nself dev docs generate
nself dev docs serve
nself dev docs build

whitelabel → dev whitelabel

Old:

nself whitelabel config --brand "MyCompany"
nself whitelabel preview
nself whitelabel deploy

New:

nself dev whitelabel config --brand "MyCompany"
nself dev whitelabel preview
nself dev whitelabel deploy

Special Cases & Exceptions

Commands That Stayed Top-Level

Some commands remain at the top level because they're fundamental utilities:

nself admin - Direct access to admin UI
nself hasura - Direct access to Hasura console
nself status - Quick health check
nself logs - Quick log access
nself urls - Quick URL listing
nself monitor - Direct monitoring access
nself version - Version info
nself update - Self-update
nself help - Help system

Why? These are high-frequency commands that benefit from short paths.

The sync Command Split Explained

The sync command was unique in that it had two distinct use cases:

Deployment synchronization - Syncing code/configs between local and remote servers
Configuration synchronization - Syncing environment variables and secrets

Decision:

Deployment context → nself deploy sync
Configuration context → nself config sync

Examples:

# Deploying to staging? Use deploy sync
nself deploy sync pull staging
nself deploy sync push prod

# Managing environment variables? Use config sync
nself config env sync staging
nself config secrets sync prod

Migration Strategies

Strategy 1: Search & Replace (Simple Projects)

If you have a small number of command invocations:

# Example: Migrate all email commands
find . -type f -name "*.sh" -exec sed -i '' 's/nself email /nself service email /g' {} \;
find . -type f -name "*.md" -exec sed -i '' 's/nself email /nself service email /g' {} \;

Strategy 2: Gradual Migration (Large Projects)

Phase 1 - Update documentation first
Phase 2 - Update CI/CD pipelines
Phase 3 - Update application scripts
Phase 4 - Update developer guides

Strategy 3: Alias Wrapper (Temporary Bridge)

Create a shell function/alias for transition:

# In your ~/.bashrc or ~/.zshrc
nself-old-email() {
  echo "DEPRECATED: Use 'nself service email' instead" >&2
  nself service email "$@"
}

Strategy 4: Pre-commit Hook

Add a pre-commit hook to catch deprecated commands:

#!/bin/bash
# .git/hooks/pre-commit

deprecated_commands=(
  "nself email"
  "nself storage"
  "nself redis"
  "nself functions"
  "nself mlflow"
  "nself realtime"
  "nself search"
  "nself billing"
  "nself org "
  "nself provision"
  "nself upgrade"
  # ... add more
)

for cmd in "${deprecated_commands[@]}"; do
  if git diff --cached --name-only | xargs grep -l "$cmd" 2>/dev/null; then
    echo "ERROR: Deprecated command found: $cmd"
    echo "Please update to new command structure."
    exit 1
  fi
done

Timeline & Breaking Changes

v0.9.9 (Current)

Status: Deprecated commands show warnings
Behavior: All old commands still work
Warning message: "DEPRECATED: Use 'nself service email' instead of 'nself email'"
Action required: None (but start migrating)

v0.9.10 - v0.9.99 (Future)

Status: Transition period
Behavior: Warnings continue
Action required: Migrate your scripts

v1.0.0 (Planned - Breaking Release)

Status: Deprecated commands removed
Behavior: Old commands will error
Action required: All migrations MUST be complete

Testing Your Migration

1. Check for Deprecated Usage

# Search your project for deprecated commands
grep -r "nself email" .
grep -r "nself storage" .
grep -r "nself billing" .
# ... etc

2. Test New Commands

# Verify new commands work as expected
nself service email --help
nself tenant billing --help
nself deploy sync --help

3. Run Your Test Suite

After migration, run your full test suite to ensure nothing broke.

4. Update Documentation

Don't forget to update:

README files
Developer guides
CI/CD documentation
Deployment playbooks
Training materials

Getting Help

Command Help

# View all subcommands
nself service --help
nself deploy --help
nself tenant --help

# View specific subcommand help
nself service email --help
nself tenant billing --help
nself deploy sync --help

Documentation

Command Tree: .wiki/commands/COMMAND-TREE-V1.md
Service Commands: .wiki/commands/service/README.md
Deploy Commands: .wiki/commands/deploy/README.md
Full Wiki: .wiki/Home.md

Community Support

GitHub Issues: https://github.com/nself-org/cli/issues
Discussions: https://github.com/nself-org/cli/discussions
Discord: https://discord.gg/nself

Reporting Issues

If you find a command that doesn't work as documented:

nself doctor --verbose > issue-report.txt

Then open an issue with the report attached.

FAQ

Q: Will my old scripts break immediately?

A: No. Deprecated commands still work in v0.9.9+ with warnings. They won't be removed until v1.0.0.

Q: Can I disable the deprecation warnings?

A: Yes, set NSELF_SUPPRESS_WARNINGS=1 in your environment:

export NSELF_SUPPRESS_WARNINGS=1
nself email send ...  # No warning

Q: How do I know which commands I'm using?

A: Run this audit:

nself history --filter deprecated

Q: Is there an automated migration tool?

A: Not yet, but you can use search & replace (see Migration Strategies above).

Q: Why consolidate now?

A: The project grew organically to 79 commands. Before v1.0, we're establishing a sustainable structure.

Q: Will there be more consolidations?

A: No. The 31 top-level commands in v1.0 are the stable structure going forward.

Q: What if I have custom scripts that use old commands?

A: Migrate them before v1.0.0. Use the deprecation period to update at your own pace.

Q: Can I use both old and new commands during migration?

A: Yes! This is encouraged. Migrate incrementally, test thoroughly.

Quick Migration Cheat Sheet

Print this section for quick reference:

OLD                              NEW
────────────────────────────────────────────────────────
nself email <cmd>          →    nself service email <cmd>
nself storage <cmd>        →    nself service storage <cmd>
nself redis <cmd>          →    nself service redis <cmd>
nself functions <cmd>      →    nself service functions <cmd>
nself mlflow <cmd>         →    nself service mlflow <cmd>
nself realtime <cmd>       →    nself service realtime <cmd>
nself search <cmd>         →    nself service search <cmd>
nself billing <cmd>        →    nself tenant billing <cmd>
nself org <cmd>            →    nself tenant org <cmd>
nself provision <cmd>      →    nself deploy provision <cmd>
nself server <cmd>         →    nself deploy server <cmd>
nself upgrade <cmd>        →    nself deploy upgrade <cmd>
nself staging              →    nself deploy staging
nself prod                 →    nself deploy production
nself sync <cmd>           →    nself deploy sync <cmd> OR nself config sync <cmd>
nself provider <cmd>       →    nself infra provider <cmd>
nself k8s <cmd>            →    nself infra k8s <cmd>
nself helm <cmd>           →    nself infra helm <cmd>
nself env <cmd>            →    nself config env <cmd>
nself secrets <cmd>        →    nself config secrets <cmd>
nself vault <cmd>          →    nself config vault <cmd>
nself validate             →    nself config validate
nself mfa <cmd>            →    nself auth mfa <cmd>
nself roles <cmd>          →    nself auth roles <cmd>
nself devices <cmd>        →    nself auth devices <cmd>
nself oauth <cmd>          →    nself auth oauth <cmd>
nself security <cmd>       →    nself auth security <cmd>
nself ssl <cmd>            →    nself auth ssl <cmd>
nself trust                →    nself auth ssl trust
nself rate-limit <cmd>     →    nself auth rate-limit <cmd>
nself webhooks <cmd>       →    nself auth webhooks <cmd>
nself bench <cmd>          →    nself perf bench <cmd>
nself scale <cmd>          →    nself perf scale <cmd>
nself migrate <cmd>        →    nself perf migrate <cmd>
nself rollback             →    nself backup rollback
nself reset                →    nself backup reset
nself clean                →    nself backup clean
nself frontend <cmd>       →    nself dev frontend <cmd>
nself ci <cmd>             →    nself dev ci <cmd>
nself docs <cmd>           →    nself dev docs <cmd>
nself whitelabel <cmd>     →    nself dev whitelabel <cmd>

Conclusion

The command consolidation in v0.9.9 creates a more maintainable, discoverable, and consistent CLI experience. While migration requires some effort, the long-term benefits are significant:

Easier to learn - Logical grouping reduces cognitive load
Easier to discover - Related commands are together
Easier to document - Clear hierarchies and patterns
Easier to extend - New features fit into existing structure

Migration is straightforward: most commands just need a prefix added. Take advantage of the transition period to migrate at your own pace, and reach out if you need help!

Happy migrating! 🚀

DEPRECATED COMMANDS MIGRATION - nself-org/cli GitHub Wiki

Deprecated Commands Migration Guide

Overview

Quick Reference Table

All Deprecated Commands

Detailed Migrations by Category

1. Service Commands

email → service email

functions → service functions

mlflow → service mlflow

realtime → service realtime

redis → service redis

search → service search

storage → service storage

admin-dev → service admin --dev

2. Deployment Commands

staging → deploy staging

prod / production → deploy production

provision → deploy provision

server / servers → deploy server

upgrade → deploy upgrade

sync → deploy sync OR config sync (Special Case)

Deploy Sync (Remote Environment Synchronization)

Config Sync (Configuration Management)

3. Infrastructure Commands

provider / cloud → infra provider

k8s → infra k8s

helm → infra helm

4. Configuration Commands

env → config env

secrets → config secrets

vault → config vault

validate → config validate

5. Authentication & Security Commands

mfa → auth mfa

roles → auth roles

devices → auth devices

oauth → auth oauth

security → auth security

ssl → auth ssl

trust → auth ssl trust

rate-limit → auth rate-limit

webhooks → auth webhooks

6. Performance Commands

bench → perf bench

scale → perf scale

migrate → perf migrate

7. Backup & Recovery Commands

rollback → backup rollback

reset → backup reset

clean → backup clean

8. Multi-Tenancy & Billing Commands

billing → tenant billing

org → tenant org

9. Developer Tools Commands

frontend → dev frontend

ci → dev ci

docs → dev docs

whitelabel → dev whitelabel

Special Cases & Exceptions

Commands That Stayed Top-Level

The sync Command Split Explained

Migration Strategies

Strategy 1: Search & Replace (Simple Projects)

Strategy 2: Gradual Migration (Large Projects)

Strategy 3: Alias Wrapper (Temporary Bridge)

Strategy 4: Pre-commit Hook

Timeline & Breaking Changes

v0.9.9 (Current)

v0.9.10 - v0.9.99 (Future)

v1.0.0 (Planned - Breaking Release)

Testing Your Migration

1. Check for Deprecated Usage

2. Test New Commands

3. Run Your Test Suite

4. Update Documentation

Getting Help

Command Help

Documentation

Community Support

⚠️ GitHub.com Fallback ⚠️