Quick start

Architect scales Kubernetes pods to zero without unscheduling them, and wakes or migrates them instantly with complete state. No code changes required.

Prerequisites:

• Kubernetes 1.33+ with at least 2 nodes
• Helm 3+
• On Amazon EKS: AL2023 AMI required (AL2 not supported)

Install Architect

Sign into console.architect.io, click + Add Cluster, and follow the instructions. The console provides a pre-filled helm install command with your machine token, cluster name, and Kubernetes distribution.

Verify the installation:

kubectl get pods -n architect

You should see architect-admission-controller, architect-control-plane, and architectd on each labeled node. For GitOps setup, prerequisites, and advanced Helm chart options, see the full Installation guide.

Deploy Valkey as an example

helm install \
  example-valkey oci://ghcr.io/loopholelabs/example-valkey-chart --wait

Watch Valkey scale down and wake up

Watch the pod scale down after 10 seconds of inactivity:

watch "kubectl get pod -l app=example-valkey-valkey \
  -o custom-columns=\"\
NAME:.metadata.name,\
ARCHITECT:.metadata.labels['status\.architect\.loopholelabs\.io/valkey'],\
CPU:.spec.containers[0].resources.requests.cpu,\
MEM:.spec.containers[0].resources.requests.memory\""

Wake the pod up:

kubectl exec -it deployment/example-valkey-valkey \
  -c valkey -- valkey-cli ping

Force Valkey migration across nodes

Find the initial node where the Valkey pod runs:

NODE=$(kubectl get pod -l app=example-valkey-valkey \
  -o jsonpath='{.items[0].spec.nodeName}')

Store a Valkey message in memory, on the initial node:

kubectl exec -it deployment/example-valkey-valkey -c valkey -- \
  valkey-cli set architect-quick-start \
  "This Valkey message was stored in memory on node: $NODE"

Confirm that the message can be read:

kubectl exec -it deployment/example-valkey-valkey -c valkey -- \
  sh -c "valkey-cli --raw get architect-quick-start; \
  echo \"Valkey pod is running on node: $NODE\""

Cordon the node and delete the Valkey pod:

kubectl cordon $NODE
kubectl delete pod -l app=example-valkey-valkey

Wait for the new pod to be running before continuing:

kubectl wait pod -l app=example-valkey-valkey \
  --for=condition=Ready --timeout=60s

Find the new node where the Valkey pod migrated to:

NEW_NODE=$(kubectl get pod -l app=example-valkey-valkey \
  -o jsonpath='{.items[0].spec.nodeName}')

Verify that Valkey message is still in memory, on the new node:

kubectl exec -it deployment/example-valkey-valkey -c valkey -- \
  sh -c "valkey-cli --raw get architect-quick-start; \
  echo \"Valkey pod is running on node: $NEW_NODE\""

Uncordon the initial node and delete the Valkey example:

kubectl uncordon $NODE
helm uninstall example-valkey

Takeaways

You've now seen Architect's two core capabilities in action:

1. Valkey scaled to zero CPU and memory after 10 seconds of inactivity, then woke up instantly when you ran a command against it; all without being unscheduled.
2. You then forced a Valkey migration to a different node by cordoning and deleting the pod: the message you stored in memory was still there on the new node. No code changes and no special client logic needed. Valkey's in-memory state survived the move intact.

More examples

Each chart below deploys a small workload with Architect annotations already applied, so it scales down after a short idle period and wakes instantly. Install any of them the same way, swapping in the chart name:

helm upgrade example-go \
  oci://ghcr.io/loopholelabs/example-go-chart --install --wait

Available charts: example-go, example-java-tomcat, example-kafka, example-php-wordpress, example-postgres, example-python, example-ruby, example-rust-miniserve, example-spring-boot.