Deployment Model

Alien Giraffe is deployed into infrastructure controlled by the organization. The platform is containerized and can run in two main deployment models depending on the organization’s operational preferences, security posture, and infrastructure standards.

Click to expand

Supported deployment types

Kubernetes deployment with Helm

The primary deployment model runs Alien Giraffe inside an organization-controlled Kubernetes environment using Helm.

This model is the best fit when the organization wants:

• Kubernetes-native orchestration and lifecycle management
• namespace or cluster-level isolation boundaries
• policy-driven networking, secrets, and workload controls
• repeatable release management through Helm values and chart upgrades

In this deployment shape, the platform runs as containerized workloads orchestrated by Kubernetes primitives such as:

• Deployments for stateless control-plane services
• StatefulSets for stateful components where stable identity or storage is required
• Jobs for one-off bootstrap, maintenance, or migration tasks
• Services, Ingress, NetworkPolicies, and Secrets for connectivity and runtime control

In most deployments, Alien Giraffe runs inside a dedicated namespace. Environments with stricter isolation requirements can place the platform in a dedicated cluster instead.

Virtual machine deployment with a Docker-compatible runtime

Alien Giraffe can also be deployed directly onto a virtual machine that has a Docker-compatible container runtime available.

This model is the best fit when the organization wants:

• a simpler runtime footprint without Kubernetes
• direct control over a single host or small number of hosts
• compatibility with existing VM-based operational models
• a lower-complexity deployment path for smaller environments or early-stage adoption

In this deployment shape, the platform runs as one or more containers managed directly by the host runtime. Isolation still depends on the organization’s host hardening, network controls, secret handling, and runtime configuration.

Deployment outcomes

This deployment model is intended to provide:

• organization ownership of runtime boundaries
• compatibility with either Kubernetes-native or VM-based operating models
• repeatable installation and upgrade workflows
• flexibility to adopt stricter isolation when needed

Continue with Secret Isolation to see how trust boundaries are enforced once the platform is deployed.