How Revivify works

Setting it up

Setup happens once, run by whoever already administers the cluster. Everyone who casts a spell afterward holds none of what setup touches. What follows is the model laid out in enough detail to check; nothing here runs today.

1. 1.

   Run the collector in your cluster

   The collector is deployed into its own namespace with its own ServiceAccount. It needs no inbound networking, because it opens the connection to the control plane itself, outbound over mTLS. SPELLBOOK_NAMESPACES pins the namespaces it may ever touch, set here, on your side, where the control plane cannot change it.

   collector env

   SPELLBOOK_NAMESPACES=storefront,checkout

2. 2.

   Bind the restart grant

   Revivify's ServiceAccount gets get, list, and patch on Deployments and read on pods. This is the ceiling the API server enforces. There is no delete and no scale in it, so a restart cannot become a deletion or a resize even through a bug on our side.

   revivify ClusterRole

   rules:
     - apiGroups: ["apps"]
       resources: [deployments]
       verbs:     [get, list, patch]
     - apiGroups: [""]
       resources: [pods, pods/log]
       verbs:     [get, list]

3. 3.

   Grant the entitlement, pin the targets

   Two strings, deliberately apart. spell.revivify.cast puts the spell in reach; restart.revivify.cast is the write entitlement, held outside the spell.* family so a read role cannot carry it by accident. The target allowlist defaults to dev and staging, and production is not on it.

   entitlements

   spell.revivify.cast
   restart.revivify.cast
   # targets: dev, staging   (prod refused under any name)

4. 4.

   Cast it

   Ana signs in as herself and restarts checkout in staging. She holds no kubeconfig, and the cast is a casts row before the patch is sent.

   slack

   /revivify checkout-api --target staging

This is the design, not an install guide. The collector bundle, the flags, and the manifests are not something you can apply today.

What it refuses to do

A permission that was never issued cannot be misused, by a person, by a compromised account, or by an agent.

/revivify checkout-api --target prod

Refused. The target allowlist is dev and staging by default, and production is off it under any name. The refusal fires at preflight and again inside the invoke path, so it cannot be won by racing the check. There is no override flag, because an override flag is a permission you would be holding.

kubectl rollout restart deploy/checkout-api

There is nothing to revoke here, because kubectl was never issued to you. The spell is the only path, so the version of this that can be aimed at the wrong namespace or the wrong environment does not exist for you.

Restart with only read spells granted

Refused. Restarting needs restart.revivify.cast, which lives outside the spell.* family. Holding every read spell in the book does not add up to a restart, because the write was never granted.

Restart a StatefulSet or a DaemonSet

Revivify resolves a Deployment by exact name and patches a Deployment. A StatefulSet or DaemonSet is neither, and neither is in the grant. Restarting a stateful workload is a different blast radius, and it will be a different spell before it is a flag on this one.

Scale it, change its image, edit its env

Not this spell and not this grant. Revivify's only write is the restart annotation on the pod template. There is no apply-this-manifest and no run-this-command behind it.

Roll it back for me

Revivify restarts; it does not roll back. A rollback changes what is running, a different action with a different blast radius. If a rollout times out, Revivify says so and stops, rather than reverting on your behalf.

Failure modes

What happens when it cannot do the thing.

The new pods never become Ready

The poll runs to the spell's 300-second deadline, then reports timed out at the replica count it reached, marked degraded. Revivify does not roll back, so under a default rolling strategy the workload sits at reduced capacity until you act, and the report says that plainly rather than reporting success.

The Deployment reports a status error mid-rollout

The cast ends in a status error, degraded, carrying what the Deployment said.

The name is not a Deployment, or matches nothing

It refuses. Revivify resolves a Deployment by exact name in scope, so a StatefulSet, a typo, or an out-of-scope namespace does not resolve, and nothing is patched.

The entitlement or the RBAC is missing

The cast fails before the patch and names what is missing, the restart.revivify.cast string or the patch verb, so whoever administers it fixes one line instead of bisecting an RBAC error.

The restart runs but the symptom stays

Revivify reports that the pods came back and stops there; it cannot tell whether the underlying cause is gone. That read is /scry, so check before you cast it again.