Skip to content

Build, Package, and Deploy

You've modified Section 1. Here's the path from edited code to a running deployment.

The build workflow

Every pod that uses a custom image follows the same steps:

a. Edit app.py Section 1 in the pod directory. See Hook Functions Reference for what to implement.

b. Build the image: 

cd gateway/app/
docker build -t myregistry/my-app:v1.0.0 .

c. For Path 0 (local k3d) — import into cluster: 

k3d image import myregistry/my-app:v1.0.0

d. For Path 2 (cloud) — push to your registry: 

docker push myregistry/my-app:v1.0.0

e. Update the image field in 03-deployment.yaml: 

containers:
  - name: web-app
    image: myregistry/my-app:v1.0.0   # ← update this

f. Deploy or rolling-update: 

bash deploy.sh   # full deployment
# — or —
kubectl set image deployment/gateway web-app=myregistry/my-app:v1.0.0 -n <ns>

Rolling update for already-deployed blueprints

For blueprints that are already running, use kubectl set image to update the web-app container without redeploying the entire namespace:

kubectl set image deployment/gateway \
  web-app=myregistry/my-app:v1.0.1 \
  -n armored-convoy-gateway-ns

The WoSP sidecar (xtra-wasm) does not need to be rebuilt or restarted. Only the web-app container changes. The new pod comes up, the WoSP session re-authenticates automatically, and the auto-trigger fires to confirm end-to-end delivery.

The Dockerfile

The delivered Dockerfile copies app.py into the image:

FROM python:3.11-slim
WORKDIR /app
COPY requirements.txt .
RUN pip install -r requirements.txt
COPY app.py .
CMD ["python", "app.py"]

You only need to rebuild when app.py changes. Dependencies (requirements.txt) changes also require a rebuild. The Dockerfile itself rarely needs modification.

Golden Path iteration cycle

Golden Path iteration cycle

  1. Edit Section 1 in app.py (30 minutes of work)
  2. docker build + k3d import or docker push (2–5 minutes)
  3. kubectl set image (30 seconds)
  4. Auto-trigger confirms end-to-end immediately

Total: ~35 minutes per iteration for meaningful business logic changes.

Multi-pod customization

Each pod has its own app.py. You can customize all pods, some, or none independently.

A common pattern:

  • Customize on_trigger in the gateway pod — authentication, rate limiting, input validation
  • Leave relay/processor pods as pass-through stubs — the payload flows through unchanged
  • Customize on_receive_terminator in the sink pod — store results, dispatch to your backend

This lets you add real behavior at the edges of the network first and add middleware logic later, without rebuilding every pod image for every iteration.