Skip to content

Path 2 — Cloud Custom Image

Path 2 is where blueprint composability and app logic composability meet. You've chosen a blueprint topology; now you customize the Section 1 business logic and deploy your own application image.

See The Section 1 / Section 2 Model before starting this guide if you haven't already.

When to use

  • Production deployment with custom authentication, data transformation, or business logic
  • Integrating the blueprint with your existing services (databases, queues, external APIs)
  • Replacing the default stub logic with meaningful application behavior

Prerequisites

All Path 1 requirements, plus:

  • Docker — for rebuilding the app image
  • Container registry account (Docker Hub, GitLab, GitHub Container Registry, or equivalent)

1. Customize Section 1

Open app.py in any pod directory. Section 1 is clearly marked. Replace the stub hook function(s) with your logic:

# ── SECTION 1: Business Logic (yours to modify) ─────────────────────
def on_trigger(payload, headers):
    # YOUR CODE HERE
    return payload
# ── END SECTION 1 ────────────────────────────────────────────────────

See Hook Functions Reference for what each hook receives and returns.

Do NOT modify Section 2

Section 2 contains the WoSP networking layer. Modifying it breaks inter-pod communication and invalidates WoSP security guarantees. If you need networking behavior that Section 2 doesn't provide, contact support@hopr.co.

2. Build and push your image

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

Repeat for each pod you modified.

3. Update the deployment manifest

Edit 03-deployment.yaml in the pod directory and update the image: field for the web-app container:

containers:
  - name: web-app
    image: myregistry/my-gateway:v1.0.0   # ← your image

4. Deploy

bash deploy.sh

5. Verify

kubectl logs -n <blueprint>-gateway-ns deployment/gateway -c web-app -f

Expected: 🔁 Auto-trigger complete — 5/5 messages sent.

The auto-trigger calls your on_trigger() hook with a synthetic payload at startup. If your Section 1 code raises an exception on the stub payload, the auto-trigger will fail. Confirm your hook handles the default payload before deploying.

Iteration workflow

For already-deployed blueprints, use a rolling update to avoid full redeployment:

kubectl set image deployment/gateway \
  web-app=myregistry/my-gateway:v1.0.1 \
  -n <blueprint>-gateway-ns

The WoSP sidecar (xtra-wasm) does not need to be rebuilt — only the web-app container changes.

See Build, Package, and Deploy for the complete iteration workflow.

Teardown

bash teardown.sh