Testing your application

Before you roll Architect out in production, validate your own application in a staging environment. The Quick start covers the mechanics of hibernating and waking a pod; this page is about confirming your workload comes through that cycle correctly.

Deploy under Architect

Add the runtime class and annotations to your workload and deploy it to staging. See Configuration for the full annotation reference.

spec:
  template:
    metadata:
      annotations:
        architect.loopholelabs.io/managed-containers: '["my-container"]'
        architect.loopholelabs.io/scaledown-durations: '{"my-container":"60s"}'
    spec:
      runtimeClassName: runc-architect

What to validate

Drive your app through a full hibernate and wake cycle (the Quick start has the exact commands) and confirm:

• It hibernates. After the idle timeout, the status.architect.loopholelabs.io/<container> label reads SCALED_DOWN.
• It wakes. A kubectl exec, or incoming traffic when network-monitor is set, returns the label to RUNNING and the app responds normally.
• In-memory state survives. Write a value, let the container hibernate, wake it, and read the value back; it should still be there.
• Health checks pass after wake. Liveness and readiness probes recover. If they keep the container awake or fail, enable the health-check proxy.
• Open work is not corrupted. Connections, transactions, and background jobs resume cleanly rather than erroring.

Run the built-in self-test

Beyond validating your own workload, Architect ships a self-test component that verifies its core functionality inside your cluster — useful after an install or upgrade, or when a customized cluster (containerd config, CNI, kernel) might behave differently from the tested matrix. It is enabled by default and needs no configuration; its test workloads run in a dedicated namespace (architect-self-test by default). To disable the component, set architectSelfTestEnabled: false in the Helm chart — see the Helm values for the full list.

Then open the cluster in the Console and switch to the Health tab. By default Run self-test runs every check at once and shows whether the cluster passed, along with past runs.

Each check in the results expands in place to show its individual steps, and each step links to the pod it acted on — so a failing check tells you where it failed and on which pod without changing any settings. A failing check is expanded for you.

While a run is in progress you can Cancel it (its workloads are cleaned up). Export events downloads the run's events and every event of each pod the run touched, as NDJSON — the pods' own events are usually what explains a failure. Results are stored as ordinary Architect events, so they also appear in the cluster's regular event history.

Expand Advanced (under the run button) to change what the next run does:

• Pick which checks to run — hibernate, wake on exec, data persistence, wake on network, and migration, each a narrow version of the core flows this page describes — and how many run in parallel.
• Apply customization slots (labels, annotations, and a node selector) to the test workloads so they pass the same admission controllers and node selectors as your real workloads; the last-used slots are remembered.

A pass means Architect's core functionality works in your cluster; a failing check's log narrows down where.

Check logs on failure

kubectl logs -n architect -l app.kubernetes.io/name=architectd | grep <pod>

The Architect Console also shows per-pod events, timings, and checkpoint details.

Compatibility matrix

GPU workloads are not supported yet. These language and framework combinations have been tested:

Node.js and ASP.NET aren't supported yet: their runtimes rely on kernel features CRIU cannot checkpoint. For Node.js this is io_uring, which libuv enables by default in current releases.