Skip to main content

Container Runtime Model

Worka runs server-executed packs in containers.

That is not only a packaging detail. It is one of the main ways the platform keeps tenant boundaries, runtime behavior, and host mediation under control.

Packs are not persistent services​

Keep these two models separate in your head:

  • pack execution: tool-oriented capability invoked through MCP
  • service execution: long-running HTTP software with a domain and health lifecycle

They may both use container technology, but they solve different problems and have different security and networking expectations.

What this means for builders​

When you build a pack, assume:

  • the runtime discovers and invokes your tools through MCP
  • host-controlled paths mediate sensitive operations
  • the container boundary is part of the trust model

That means you should design the pack to be explicit about what it needs rather than assuming ambient access.

What this means for debugging​

When a pack “works locally but not in Worka,” the missing piece is often not the tool logic itself. It is usually one of:

  • manifest mismatch
  • tool discovery mismatch
  • missing connection state
  • missing broker policy declaration
  • runtime invocation failure

That is why release and runtime docs matter as much as source code.