One workspace for the whole infrastructure team.
Every engineer gets the same application for SSH, RDP, Kubernetes, tunnels, Vault secrets and runbooks, with sign-in and an Activity Log built in, and organization roles for sharing and administration. Fewer tools to install, onboard and secure, and credentials Ark8's servers never receive: they stay on each Mac or in your own HashiCorp Vault.
Google or Microsoft sign-in
Sign in with a Google or Microsoft (Entra ID) account. PKCE in the system sign-in sheet; no secret in the app.
Organization roles
Owner, Admin, Member and Viewer. The database enforces them for your organization's data, and Ark8 for macOS applies them to shared hosts.
Audit
An append-only organization audit log of member, invitation, role, group, ownership and sharing changes, with secret-named fields redacted as each event is written.
Local-first
Sharing publishes descriptors only. Keys, kubeconfigs and passwords are never sent to Ark8: they stay on each Mac or in your own HashiCorp Vault.
The cost case
Fewer tools to license, onboard and secure.
A stack of separate clients costs more than its licenses. Each one has to be installed, configured, updated, secured and learned by every engineer. One workspace reduces how many of those your team runs.
Consolidate the tooling
SSH, RDP, Kubernetes, Docker, tunnels, Vault secrets, and Terraform and Ansible runbooks in one application, instead of one tool for each.
One app to roll out
One signed and notarized macOS application to install and learn. Updates arrive through the app itself.
Repeatable procedures
Runbooks run the same steps on the targets you choose, and Change Review shows what will run and where before a whole-runbook run starts.
Organization model
Organizations, memberships and groups, enforced by the database.
Anyone signed in on the Ark8 website with a verified Google or Microsoft account can create an organization and becomes its Owner. People join it by accepting an invitation there; signing in alone never joins anyone. Groups let admins give a role to many people at once.
- One user can belong to several organizations, with a separate role in each. The web admin console and the Mac app's account menu switch between them; the Mac app works in one organization at a time.
- A group can hold Admin, Member or Viewer, never Owner. The database enforces it.
- A person's effective role is the higher of their own role and their groups' roles, while their own membership is active.
- Isolation between organizations is enforced per row by the database, not by the interface.
People sign in with a Google or Microsoft account and join an organization by invitation. Each member's role comes from their own membership and the groups they are in. Members share SSH hosts with everyone in the organization or with its admins only. Member, invitation, role, group, ownership and sharing changes are written to the organization's audit log.
Who enforces what
The database decides the data. Ark8 applies the role on each Mac.
Enforced by the database
Who can see or change organization data is decided by the database on every query, through row rules and checked functions: members, invitations, groups, shared hosts and the audit log. Internal database functions are closed to clients, and only the Owner can grant Admin, directly or through a group.
Applied by Ark8 for macOS
What Ark8 itself does with shared hosts: who gets the Share menu, and for whom it opens a shared host. This is Ark8's policy, not a security boundary: the SSH credentials are each person's own.
Ark8 re-checks the role at launch, when the app comes to the foreground, every 5 minutes, and before an organization action if the last check is over a minute old. When a person's role or membership no longer allows a shared host, the tabs opened from it close. If Ark8 can't confirm the role for 15 minutes, it refuses organization actions, and local work carries on.
Invitations and the web admin console
Run the organization from the web.
The web admin console opens for the Owner and Admins.
Invitations
Admins invite people by email with a role and an expiry. Ark8 emails each person their link, or shows it for you to send when email isn’t available. To join, that person opens the link, signs in on the Ark8 website with the invited, verified email and presses Accept, or Decline. Signing in alone never joins. Resend or revoke it.
Admin is the Owner's call
Only the Owner can invite someone as an Admin or make someone an Admin.
Members
Change roles, suspend, reactivate or remove members. The Owner can transfer ownership.
Groups
Groups give a role (Admin, Member or Viewer, never Owner) to many people at once.
At a glance
Members, signed in within the last 30 days, invited (with how many expired) and suspended, each by role, plus who never signed in and the most recent sign-in.
Organization policy
The Owner sets who can open hosts shared as PROD and how long invitation links last by default. Admins can read it.
Sign-in
OIDC with PKCE. No secret in the app.
Sign-in with Google and Microsoft (Entra ID) accounts ships today. Provider secrets stay on the server, and the macOS application only ever completes a PKCE flow. Ark8 doesn't offer sign-in through generic or custom OIDC identity providers.
PlannedSAML single sign-on for Okta and other SAML 2.0 identity providers, set up by your organization's Owner after verifying its email domain. Not available today.
Auditability
An audit trail admins can read but not edit or delete.
Added and invited members, role changes, suspensions, group changes, ownership transfers and sharing changes land in an append-only log. Secret-named fields are redacted as each event is written, and the database refuses updates and deletes from every organization role. Sign-ins are not recorded in it.
Each Mac's Activity Log also records which Ark8 account did each thing, next to the Mac user: the email, how it signed in (Google or Microsoft), the organization and the role. Its JSON and CSV exports, and your SIEM once you set your Enterprise number, carry the account, sign-in method and organization; the role is in History and the JSON export. SIEM export is off until you set it up, and the Activity Log stays on each Mac: Ark8 doesn't collect it.
Credentials and production
Credentials in your Vault. Production behind Touch ID.
Secrets on your own HashiCorp Vault
Secrets manages the secrets in your own HashiCorp Vault. Values stay in Vault until you click Show or Copy, and a copied value clears from the clipboard after 30 seconds. A secret linked to a PROD host asks for Touch ID or your Mac password first, and each reveal, copy and edit is recorded in the Activity Log by path, never by value.
Each engineer signs in to Vault with their own identity, through Vault's OIDC method in the browser. Ark8 stores no Vault token: it holds it in memory for at most four hours and asks Vault to revoke it when you sign out or quit (a batch token can't be revoked; it simply runs out).
Needs: your own HashiCorp Vault (KV v2), with its OIDC auth method and a role for Ark8 set up by a Vault admin.
Production safeguards
Before Ark8 opens a terminal, the Files browser, a tunnel, a Docker action over SSH or a runbook step on a PROD host, macOS asks for Touch ID or your login password. One approval lasts five minutes for that session, and a runbook step also goes ahead on a PROD host whose terminal is already open. Each decision is in the Activity Log while its security events are on (the default).
A host a teammate shared opens with the environment it was shared with, so the same safeguards apply to it.
Not covered today: Touch ID isn't asked for web tabs. The check is on by default with no switch in Settings, but it is a per-Mac setting that your organization can't enforce.
Runbook governance
Change control for the work you repeat.
Approvals
A runbook can be set to ask for approval when it touches environments you choose (PROD is pre-selected). Approval is given in Ark8 on the same Mac. It is recorded with the run and in the Activity Log under the Mac user's name, and flagged as a self-approval. There is no second-person or remote approval.
Where Change Review applies
Change Review shows what will run, where and in what order before a whole-runbook run and a Terraform Apply or Destroy. Ansible's Check and Run playbook buttons, Terraform Init, Plan, Validate and Output, and Run on GitHub Runner skip it, and don't check calendars either.
Maintenance windows and change freezes
Calendars hold weekly windows, date ranges and one external calendar: your Mac's, or Google or Microsoft 365 read-only with your organization's own OAuth client ID. Schedules skip a blocked time, webhooks and nested runbooks are refused, and a manual run waits for Run anyway, which is logged.
Production is never scheduled
A schedule on PROD targets is refused when you create it and again when it fires. Schedules run only while Ark8 is open and the Mac is awake; a missed run is recorded, never replayed, and one that needs approval is skipped. A webhook can start a PROD run only when the runbook requires approval for PROD, and the run waits for it.
Runbooks in Git
Turn On Source Control makes the runbook library a Git repository: side-by-side diffs, commit, commit and push, branches, fetch, pull (fast-forward only) and push, with the system git and your own credentials.
Self-hosted GitHub runners
Deploy to GitHub Runner writes a runbook's Bash, Python and PowerShell steps as a GitHub Actions workflow for your self-hosted runner, and Run on GitHub Runner starts it on github.com, on main. Its result isn't in Runbook History. Needs: the gh CLI, signed in.