Deploying an Agent Substrate Actor After ActorTemplate Left Kubernetes

As of 09/02/2026, the ActorTemplate object no longer exists. It was created, as the name suggests, to be the template/golden template that Actors use to deploy with particular settings and configurations for it to run as expected.

In this quickstart blog post, you'll see how to deploy Actors without an ActorTemplate and also understand the reasoning behind this change.

Prerequisites

To follow along with this blog post in a hands-on fashion, you will need:

1. A GKE cluster or a raw k8s cluster (microk8s, kubeadm, etc.) running locally so you have direct access to the API server.
2. Agent Substrate installed. You can learn how to do so here.

If you don't have a cluster, that's totally fine. You can still follow along from a theoretical standpoint and implement later.

Why?

The primary reason for this was that it was decided that the ActorTemplate object should be an ateapi resource, not a Kubernetes object/CRD. When it was running as a k8s object, it leaked the wrong identity, naming, lifecycle, and auth into the public API (same conventions as any other k8s object - kubectl apply, namespaces, CRD conventions, etc.), so CLI, SaaS, and gRPC clients could not share one surface and the schema could not evolve independently of Kubernetes. Because Actors are an ateapi object, it made sense to have the templates for said Actors as an ateapi object as well.

What's Kubernetes and What's Ateapi

The ate-api-server now owns templates through:

- ateapi.Control

- `CreateActorTemplate`
- `GetActorTemplate`
- `ListActorTemplates`
- `DeleteActorTemplate`

Along with the Actor, Worker, and atespace objects

However, there are still objects/CRDs that exist in Kubernetes.

With the core knowledge of what exists and what has changed, let's now dive in from a hands-on perspective to deploy the resources.

Prepare The Template

The Template will now be a YAML configuration that is fed into the ateapi.

Below is an example configuration that:

• Creates a new template called counter in the ate-demo-counter namespace.
• Creates a Worker Selector so Actors from this template may only schedule onto WorkerPools whose metadata.labels include workload: counter. It is pool selection, same idea as a Pod nodeSelector.
• Specifies the container along with the ready probes.
• Volume mounts for persistent data.
• Resource limits.
• Snapshot configurations.

metadata:
  atespace: ate-demo-counter
  name: counter
workerSelector:
  matchLabels:
    workload: counter
containers:
- name: counter
  image: <digest-pinned image>
  command:
  - /ko-app/counter
  readyz:
    httpGet:
      path: /readyz
      port: 80
  volumeMounts:
  - name: data
    mountPath: /home/counter
resources:
  limits:
  - name: cpu
    quantity: "1"
  - name: memory
    quantity: 512Mi
snapshotsConfig:
  onPause: SNAPSHOT_CONTENT_SCOPE_FULL
  onCommit: SNAPSHOT_CONTENT_SCOPE_FULL
  storageLocation: gs://${BUCKET_NAME}/ate-demo-counter/
sandboxConfig:
  sandboxClass: SANDBOX_CLASS_GVISOR
  configName: gvisor-default
volumes:
- name: data
  durableDir: {}

Once the configuration like the one above is defined, you would save it and then create the template.

For example, if you saved it as counter-template.yaml, you would create the atespace and then the template within the atespace.

kubectl ate create atespace ate-demo-counter
kubectl ate create actor-template -f counter-template.yaml

Create An Actor

With the template created, you can now create an Actor.

The actor ID is a DNS-1123 label. --template-ref is the template name that exists in the atespace.

The Actor creation looks like the following.

kubectl ate create actor my-counter-1 \
  --atespace ate-demo-counter \
  --template-ref counter

Wrapping Up

Agent Substrate is a fast-moving project, and for good reason - because the AI world is moving at a rapid pace, probably faster than any other technological evolution. Because of that, the project needs to change what makes the most sense for how engineers will use Substrate. Changing the Template to the Substrate API instead of relying on the Kubernetes API is a great implementation to "split the responsibility".