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:
4. Deploy¶
5. Verify¶
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.