Strike48 Labs Strike48 Labs

Deployment Architecture

Strike48 can be deployed two ways. Managed cloud (SaaS) is the primary option — we run it in our AWS account. On-premises (self-hosted) is a secondary install type that runs the whole platform on your own hardware.

Managed Cloud (SaaS)

In managed-cloud mode, the platform runs in our AWS account. Traffic is fronted by Cloudflare, enters a single hardened boundary, and is routed inside a private Kubernetes cluster. The diagram traces the network path and shows where encryption terminates at each hop.

AWS VPCPUBLICBoundaryload balancerNATgatewayEgress nodes *optionalPRIVATEWorker nodesControl planeDATAAmazon RDSencrypted at restmanagesCloudflareTLS · WAFBrowserKeycloakOIDCTLS 1.3OIDCLEGENDClient / edgePublic subnetControl planeWorker nodes (scale out)DatabaseEncrypted in transitEncrypted at rest (KMS)* Egress nodes optional — for fixed / whitelisted outbound IPsIn transit: TLS at the edge; instance-to-instance encrypted by Amazon (Nitro). At rest: KMS.

The flow, hop by hop:

  1. Browser → Cloudflare — the user connects over HTTPS (TLS 1.3). TLS terminates at the Cloudflare edge, which proxies, caches, and absorbs DDoS/WAF duties.
  2. Keycloak (edge identity) — sits alongside Cloudflare as the OIDC identity provider. The browser is redirected to Keycloak for login over TLS; issued tokens are later validated by the cluster.
  3. Cloudflare → boundary load balancer — Cloudflare re-encrypts to the origin. The boundary load balancer accepts traffic only from Cloudflare, so the cluster has no directly-reachable public origin.
  4. Public subnet — the load balancer and NAT gateways live here. Egress nodes are optional — added only when outbound traffic needs to leave from fixed, whitelistable IPs.
  5. Private subnet — the worker nodes run the application workloads and scale out horizontally (shown as stacked boxes); the control plane nodes manage the cluster.
  6. Data tier — application state lives in Amazon RDS, reachable only from the private subnet over TLS and encrypted at rest with AWS KMS.

Encryption everywhere: traffic is encrypted in transit (green) — TLS from the browser to Cloudflare and from Cloudflare to the cluster origin — and instance-to-instance traffic is encrypted by Amazon (the Nitro System, at the hardware level). The database is encrypted at rest with KMS.

On-Premises (Self-Hosted)

The secondary install type runs the entire platform on your own hardware — no dependency on our cloud. The diagram shows what the host must supply and how the installed platform isolates each service.

ON-PREM HOST · customer-providedKUBERNETES · system-level orchestrationSSL terminationsingle TLS entryIdentityguest kernelLLM gatewayguest kernelProspectorStudioguest kernelDatabaseguest kernelLLM inferencingoptionalguest kernel · GPU PCI passthroughoptional · CUDAHost provides: trusted compute (memory encryption) + full-disk encryption (OS)VM-to-VM communication also stays in protected (encrypted) memory spaceOperators & usersyour networkHTTPS · TLS

What the host must provide:

  • Trusted compute — CPU memory encryption (confidential computing), so workload memory is protected even from the host.
  • Disk encryption — full-disk encryption supplied to the operating system.

What the install provides:

  • Single SSL termination — all external traffic enters through one TLS endpoint. From there it reaches only the identity service and Prospector Studio; the LLM gateway and database are internal-only, called by the other services.
  • Kubernetes orchestration — the platform is orchestrated by Kubernetes at the system level.
  • Hardware-level isolation per service — every workload runs as a pod inside its own lightweight virtual machine with a dedicated guest kernel and network-policy separation. A compromise in one service can't reach another through a shared kernel. VM-to-VM communication also stays in protected (encrypted) memory space.
  • Optional local inference — an LLM inferencing layer can be added, with a GPU attached via PCI passthrough (CUDA) for fully on-prem model execution.

See the Deployment Models page for how individual connectors attach.