Accounts and access
Set up sign-in, project roles and separate credentials for people and CI jobs.
The person completing installation claims the first administrator account with the private setup token. Public registration never creates another installation administrator. Hakopod's current self-hosted trust model is one operator organization with trusted developers.
Human sign-in#
Email/password, GitHub, GitLab.com and Google sign-in are available when their integrations are configured. Passkeys require HTTPS or a loopback development origin. You can enroll authenticator-based TOTP, use recovery codes and revoke sessions in account settings.
OAuth providers need their own operator-owned client configuration and exact callback URL. A provider login does not grant repository access or an installation role. TOTP keys are encrypted separately; preserve the authentication encryption key as part of recovery.
Self-hosted signup is invitation-only after the first administrator claims setup. Public signup stays closed even if HAKOPOD_SIGNUP_ENABLED=true or its operator TOML equivalent is set. A valid invitation can register a new member after email verification; existing accounts can still sign in. The public binaries enforce this invitation policy independently of deployment-mode settings. Hakopod Cloud has a separate, open account signup flow. Creating an account does not guarantee compute allocation. Managed databases require eligible workspace capacity and setup.
Password recovery requires configured SMTP. A reset revokes browser and CLI sessions while retaining enrolled second factors and passkeys. API keys are separate credentials. The API does not provide temporary passwords when email is unavailable.
Personal workspaces and teams#
A verified account can create one private personal workspace in Free. It has a private project and development environment; it cannot be shared through team assignments or member invitations.
Team creation, invitations and fixed shared project roles are included in Free. Project roles are administrator, developer and viewer. Add project grants separately from team membership. Joining a team does not give someone installation-wide access.
Role changes, disabled accounts and revoked sessions are checked on new requests and before subsequent deployment effects. If a license expires, paid permissions stop authorizing new work; Free team access continues. Running workloads and stored data are not deleted, and installation administrators retain Free recovery operations.
CLI sessions and CI keys#
Human CLI login uses browser consent for an explicit project and environment:
hakopod login --api-url https://control.example.com --project demo --environment development
Use your actual API origin. Credentials are stored in a restricted mode-0600 file. For unattended deployments, create a named expiring key with only the required scope and permissions, then store HAKOPOD_API_URL and HAKOPOD_API_KEY in the CI provider's secret store.
Do not place credentials in TOML, image URLs or plain environment variables that appear in history. Machine keys cannot open container terminals. A deployer can run application code that reads its injected secrets, so grant deployment permission only to people or automation you trust with those secrets.
Separate management from applications#
Keep the dashboard on a distinct trusted origin. The API and dashboard share one configured API path; application containers receive no cluster credentials. Default workloads drop capabilities, run without privilege escalation and do not get service-account token mounts, host networking or host-directory mounts.
Private service networking restricts declared peers and ports, and ordinary workload egress excludes management and metadata ranges. Workloads still share a kernel. These controls are not sufficient to isolate hostile tenants. Administrators can also change Kubernetes policies outside Hakopod, so the operator remains part of the trust boundary.
The planned managed Cloud service has additional admission, abuse and account-budget work before it can host unrelated untrusted customers. Selecting managed-cloud disables public TCP; it does not establish all of those guarantees.
See the threat model, account behavior and paid-feature reference for the access rules and their limits.