DenkOps workspaces give a team three roles, owner, member and viewer, plus per-project overrides, invites by GitHub login, and an audit log that records deploys, rollbacks and membership changes. That is the whole model. It exists because agents multiply how much a team ships, and the more that ships, the more accountability has to come from the platform instead of from memory.
What do the three roles do?
Every person in a workspace has exactly one base role:
- Viewer: read-only. Viewers see projects, deploy history, status and logs, but get no start, stop, rollback or deploy controls. Right for stakeholders and anyone reviewing an agent's output.
- Member: operates projects. Members can deploy, start, stop, and roll back to a previous version. Right for the engineers doing the day-to-day work.
- Owner: everything members can do, plus the sensitive surface: environment variables, custom domains, public paths, the egress allowlist, project access, deletion, and workspace membership itself.
The split follows the risk, not the org chart. Reading logs is cheap, rolling back is recoverable, changing secrets or who is in the room is neither. Owners hold the last category, and a workspace always keeps at least one owner.
How do per-project overrides work?
Base roles set the default; the project's Access panel sets the exception. For any member, an owner can override the effective role on a single project: promote a member to owner of one service they own end to end, drop them to viewer on a sensitive one, or set the role to none, which hides the project from them entirely. A reset removes the override and the person falls back to their workspace role.
This is the pattern that keeps workspaces flat. You do not need a second workspace because one contractor should see one project. You need one override.
How do invites work?
By GitHub login. An owner invites octocat with a role, and the invite waits. When that person signs in to DenkOps with GitHub, the membership applies automatically. There is no email round-trip to a signup page and no shared credentials, the identity is the same one your team already uses to push code.
What lands in the audit log?
The events you will be asked about later: deploys and rollbacks, with the actor that performed them, and membership changes, who was added, removed or re-roled, and by whom. Because the actor can be an agent as easily as a person, the log is what turns "the agent shipped something last night" into a specific answer: which version, when, and who authorized the fix that followed.
This is the accountability half of the agent bargain. Agents raise output; roles cap what each identity can do, and the audit log makes every use of that power reviewable. Pair it with write-only secrets and the platform's other defaults and you get a setup where letting an agent operate in production is a controlled decision, not a leap of faith.
Where should you start?
A working default for a small team:
- Owners: the one or two people who manage secrets and membership.
- Everyone shipping code: member.
- Everyone else, including observers of agent-run projects: viewer.
- Overrides only where a specific project needs a tighter or looser rule.
Revisit it when the audit log surprises you. That is what it is for.