Skip to main content

Deployment Guide

Worka can run in hosted, private, on-prem, and air-gapped environments. The product experience stays recognisable across those modes, but the operational burden changes a lot.

Choose your deployment model before you think about sizing or scaling. The wrong deployment shape creates the wrong trust model, the wrong publication model, and the wrong support expectations.

Choose the deployment model​

Hosted​

Choose hosted when:

  • you want the fastest path to adoption
  • you are comfortable with Worka-managed control plane infrastructure
  • you do not need isolated network boundaries beyond tenant separation and normal hosted controls

Hosted is usually the right starting point for product evaluation and smaller teams.

Private cloud​

Choose private cloud when:

  • you need your own cloud account or dedicated network boundary
  • you want tighter control over storage, routing, and monitoring
  • you still want cloud elasticity and managed infrastructure around the platform

This is the most common enterprise shape when full air-gap is unnecessary but shared hosted is not acceptable.

On-prem​

Choose on-prem when:

  • data locality or internal network reach matters
  • internal services must be reachable without opening them to the public internet
  • your security posture requires your own compute, storage, and routing stack

Air-gapped​

Choose air-gapped when:

  • outbound internet access is heavily restricted or unavailable
  • artifact publication must stay entirely inside your environment
  • external package, model, and registry dependencies must be mirrored or pre-approved

Air-gapped deployment is not just “on-prem without internet.” It changes how publication, artifact acquisition, identity, updates, and debugging all work.

What every deployment needs​

Every Worka deployment needs the same basic foundations:

  • persistent relational storage for canonical state
  • object or registry storage for build and publication outputs
  • runtime capacity for pack execution
  • runtime capacity for persistent services if you use the services plane
  • realtime connectivity for the app clients
  • secure storage and rotation for credentials and secret material
  • audit and metrics pipelines

If any of those are missing, the platform will still appear to work in isolated flows but will fail under real production use.

Decide what will run locally and what will run centrally​

Worka is not purely server-side. Some capability is intentionally local to user devices or trusted hosts.

Plan for at least three execution zones:

  • client and trusted host capabilities such as local CLI access, browser control, and desktop control
  • central platform services such as the control plane, registry, realtime layer, and shell APIs
  • pack and service runtimes where attached packs and published services actually execute

Treat those as separate trust boundaries. Do not collapse them mentally into “the backend.”

Plan your external integrations up front​

Before rollout, decide:

  • which identity provider you will use
  • which source publication destinations you will allow
  • which container registries you will allow
  • whether Worka may publish public artifacts
  • which third-party services users may connect during early rollout
  • whether browser persistence, desktop control, or shared network contribution are allowed

These are not later tuning details. They shape the first user experience.

For most teams, the safest rollout looks like this:

  1. deploy Worka with private-by-default sharing and conservative publication rules
  2. enable workspace creation, connections, and private pack attachment
  3. validate approvals, audit trails, and secret handling
  4. enable broader pack publication or shared/public views
  5. introduce persistent services where needed
  6. introduce network contribution or more advanced local capability sharing only after consent and reservation controls are proven

This sequence limits the number of things that can go wrong at once.

Environment-specific checks​

Hosted and private cloud​

Pay attention to:

  • ingress and TLS
  • secret management integration
  • image registry reachability
  • storage class and backup behavior
  • log and metrics export

On-prem and air-gapped​

Pay attention to:

  • artifact mirroring
  • update process and release import
  • internal CA and certificate distribution
  • offline or internal-only identity integration
  • operator access to runtime logs and container state

Before you call the deployment ready​

Run these checks:

  • create a workspace from a real request
  • connect a service and verify secret handling
  • attach a pack and verify tool discovery
  • trigger a workflow that requires approval
  • publish a shared view and inspect its access path
  • recover the platform from a restart
  • restore from backup into a test environment

If you have only tested the control plane coming up cleanly, you have not tested a Worka deployment.