Skip to main content
New Orka users typically hit three different credential prompts before they can do anything useful, and none of the three are the same thing. Here’s how they fit together. For how they connect to roles and namespaces, see How access works in Orka.

The three systems

1. MacStadium portal credentials

Your MacStadium account username and password. Use these to log in to portal.macstadium.com to access My Cloud, manage billing, and request changes to your cluster. You also use them to sign in to Orka: orka login and the Orka web UI ask for them. On their own they don’t run commands. orka login exchanges them for a short-lived Orka token.

2. Orka user tokens

The token the Orka CLI uses for your requests. You get one by signing in with your portal credentials:
This mints a short-lived token that expires after 1 hour. The token carries your identity and Portal role. Which namespaces you can work in depends on role bindings, not on the token.
Do not use orka login or orka user get-token in CI/CD pipelines. Tokens expire after 1 hour and will break long-running jobs.
For CI/CD, use service accounts instead:
Service account tokens are long-lived (default: 1 year) or non-expiring, and are designed to be injected as environment variables in your pipeline. See Manage Service Accounts for the full workflow.

3. VM credentials

The macOS username and password inside each VM. These are what you use to SSH in or connect via Screen Sharing. MacStadium base images ship with default credentials:
  • Username: admin
  • Password: admin
Change the default VM password after your first login. The default admin/admin credentials are well known and your VMs are accessible to anyone with VPN access to your cluster.

Quick reference

Common mistakes

Using orka login in a pipeline. The token will expire mid-job and cause confusing authentication errors. Use a service account. Rotating portal credentials and expecting Orka to break. They’re independent: changing your portal password doesn’t affect your Orka tokens or service accounts. Leaving VM credentials at admin/admin. Every VM on your cluster shares the same default, so a single compromised VM credential means all of them are exposed.