Operator Overview

If you operate Worka, you are responsible for more than uptime.

You are running a platform that can create workspaces, connect external services, build or attach packs, publish shared views, and keep work moving after a user stops typing. That means operations in Worka always combine three concerns:

• platform reliability
• access and security
• governance over what new capability may appear or run

The operator role is where Worka becomes accountable. If users cannot tell what the platform is doing, if new capability appears without review, or if a failed task cannot be traced back to its cause, the platform is not being operated well even if the servers are technically up.

What you are responsible for

At a minimum, you own these areas:

Deployment and availability

You decide where Worka runs, how it is exposed, how it scales, and how it is recovered after failure. That includes the shell, realtime transport, pack runtime, service runtime, registry integrations, data stores, and any private infrastructure you operate around them.

Identity and access

You control who can sign in, who can join a workspace, what roles they may hold, which devices may participate, and which public access paths are allowed. Worka is multi-tenant and role-sensitive by design, so identity mistakes turn directly into data-exposure mistakes.

Capability expansion

You decide how Worka is allowed to grow. That includes:

• which packs may be attached
• which publication destinations are allowed
• which external services users may connect
• which browser and computer-use capabilities are allowed
• when new capability requires approval

Runtime safety

You decide how much network reach, secret access, and external execution power the platform may hand to packs and services. You also decide how visible those actions need to be to users and auditors.

Observability and recovery

You need enough visibility to answer practical questions quickly:

• why is this workflow still running
• why did this pack fail to invoke
• what changed in this workspace
• which approval is blocking release
• which service is degraded

If you cannot answer those questions without reading raw database rows, you do not have enough operational visibility.

What good operation looks like

Worka is being operated well when:

• users can tell what the platform is doing and what it is waiting for
• capability expansion is deliberate rather than accidental
• packs and services can be traced back to their source, release, and workspace attachment
• approvals are visible, actionable, and auditable
• failures are isolated to the right workspace, tenant, or runtime boundary
• recovery can restore a tenant without improvisation

Good operation is not about hiding complexity. It is about putting the complexity in the right place so users see a coherent product and operators see the controls they need.

Your regular operating cycle

In practice, operating Worka usually means repeating the same cycle:

1. keep the deployment healthy
2. review capability and publication policies
3. monitor workflow, pack, and service health
4. respond to failed or blocked work
5. rotate secrets and credentials
6. review shared/public exposure
7. test backup and recovery paths

The rest of this section goes deeper into each of those responsibilities.

Read the next pages in order

If you are new to operating Worka, use this reading path:

1. Deployment Guide
2. Identity and Access
3. Authorization Model
4. Treasury and Secrets
5. Broker and Network Controls
6. Pack Governance
7. Workflow Governance
8. Observability and Audit
9. Troubleshooting and Incidents

That order matches the way operational problems usually appear in the real system: first deployment, then access, then capability, then runtime behavior.