Config Profiles — Megaport CLI

Config profiles let you store named sets of credentials so you can switch between environments and accounts without re-entering credentials on every command.

Profiles are stored in ~/.megaport/config.json with 0600 permissions (readable only by your user account).

Why use profiles?

Most teams work across at least two environments:

Staging — safe for experimentation, no billing impact, same API surface
Production — live infrastructure, billed resources

Without profiles, you'd need to set environment variables every time you switch. With profiles, one command changes your active context:

bash

megaport-cli config use-profile staging
megaport-cli config use-profile production

Create profiles

bash

# Create a production profile
megaport-cli config create-profile production \
  --access-key your_access_key \
  --secret-key your_secret_key \
  --environment production \
  --description "Production account"

# Create a staging profile
megaport-cli config create-profile staging \
  --access-key your_staging_key \
  --secret-key your_staging_secret \
  --environment staging \
  --description "Staging — safe for testing"

Environments: production, staging, development

Switch and use profiles

bash

# Switch active profile globally
megaport-cli config use-profile staging

# All subsequent commands use the staging profile
megaport-cli locations list
megaport-cli ports list

# Use a different profile for just one command
megaport-cli locations list --profile production

# See which profile is active
megaport-cli config view

config view shows the current config with secrets masked:

text

Active profile: staging
Environment:    staging
Access key:     abc123**********
Secret key:     ****************************

List and inspect profiles

bash

# List all configured profiles
megaport-cli config list-profiles

text

┌────────────┬────────────┬──────────────────────────────┬────────┐
│ NAME       │ ENVIRONMENT│ DESCRIPTION                  │ ACTIVE │
├────────────┼────────────┼──────────────────────────────┼────────┤
│ production │ production │ Production account           │ false  │
│ staging    │ staging    │ Staging — safe for testing   │ true   │
└────────────┴────────────┴──────────────────────────────┴────────┘

Update and delete profiles

bash

# Update credentials for an existing profile (e.g., after key rotation)
megaport-cli config update-profile production \
  --access-key new_access_key \
  --secret-key new_secret_key

# Delete a profile (cannot delete the currently active profile)
megaport-cli config delete-profile old-profile

If you try to delete the active profile, the CLI will return an error. Switch to another profile first:

bash

megaport-cli config use-profile staging
megaport-cli config delete-profile old-profile

Default settings

Defaults are preferences that apply globally across all commands, regardless of which profile is active. The most common use is setting a preferred output format.

bash

# Always output JSON instead of table
megaport-cli config set-default output json

# Check what default is set
megaport-cli config get-default output
# json

# Always use staging environment unless overridden
megaport-cli config set-default environment staging

# Remove a single default
megaport-cli config remove-default output

# Reset all defaults at once
megaport-cli config clear-defaults

Export and import config

Share your config structure across machines or team members. Credentials are automatically redacted in the export — you never accidentally share secrets.

bash

# Export — secrets appear as [REDACTED]
megaport-cli config export --file megaport-config.json

# On another machine: edit the file to fill in [REDACTED] values, then import
megaport-cli config import --file megaport-config.json

Example exported file:

json

{
  "profiles": {
    "production": {
      "accessKey": "[REDACTED]",
      "secretKey": "[REDACTED]",
      "environment": "production",
      "description": "Production account"
    },
    "staging": {
      "accessKey": "[REDACTED]",
      "secretKey": "[REDACTED]",
      "environment": "staging",
      "description": "Staging — safe for testing"
    }
  },
  "activeProfile": "staging",
  "defaults": {
    "output": "json"
  }
}

This is safe to commit to a shared repo as a template — team members fill in their own credentials after importing.

Credential precedence

When multiple credential sources are configured, the CLI uses this priority order:

Priority	Source	How to set
1 (highest)	Command flags	`--access-key`, `--secret-key`, `--env`
2	Environment variables	`MEGAPORT_ACCESS_KEY`, `MEGAPORT_SECRET_KEY`, `MEGAPORT_ENVIRONMENT`
3	Active config profile	`megaport-cli config use-profile <name>`
4 (lowest)	Config defaults	`megaport-cli config set-default`

This means you can always override any profile setting for a single command by passing the flag directly.

Security best practices

⚠️

Keep credentials safe

Config is stored at ~/.megaport/config.json with 0600 permissions — only your user can read it
Never commit config.json to git — add it to .gitignore
Use config export to share team config templates — credentials are redacted automatically
Use environment variables in CI/CD pipelines (GitHub Secrets, GitLab CI Variables)
Rotate keys regularly in the Megaport Portal, then update with config update-profile
Use Staging for experiments — same API surface, no billing impact

What's next?

Authentication — env vars, inline flags, and credential precedence introduced here
Output Formats — set a default format with config set-default output json
Port Lifecycle tutorial — put profiles into practice across environments