From WhatsApp to Multi-Cloud in 20 Minutes

The "Magic" Moment I sent a single WhatsApp message, 20 minutes later, a live, multi-cloud status dashboard (prototype Demo) was public at status.aboutcloud.io. It features two global vantage points, zero stored secrets, a fully automated pipeline, and—crucially—a monthly infrastructure cost of exactly €0.

Here is the blueprint of how I built it.

Video 👇

0:00 /27:42 1×

Live Demo E2E (End to End)

The Vision: Why aboutcloud.io? aboutcloud.io isn't just a domain; it’s a sandbox for exploring production-grade architecture. The philosophy is "Cloud Adoption Framework (CAF) first and Zero Trust by design." Every project must be Microsoft-aligned, Cloudflare-enhanced, and open-source-centric. The goal for this status dashboard was to prove that you don't need a massive budget to implement high-availability monitoring with a Zero Trust security posture.

The Architecture: The Dual-Vantage Strategy A status page is only as good as its data. To avoid "false positives," I implemented two independent vantage points to check services every 5 minutes:

• ⚡ The Edge Perspective: A Cloudflare Worker (TypeScript) running across 330+ global PoPs. This provides a "real-world" view of how users experience the service globally.
• 🔵 The Regional Perspective: An Azure Function (Python 3.11, Consumption Plan) running in West Europe. This provides a stable, regional cloud perspective to verify connectivity from within a major provider's backbone.
• 🗄️ The Data Layer: Both monitors write results into Cloudflare D1, an SQLite database located at the edge.
• 💻 The UI: A Cloudflare Pages frontend that polls the Worker API every 60 seconds to provide real-time updates.

Architecture

Architecture

Technical stack

The Zero Trust Pipeline: Killing Long-Lived Credentials In modern DevSecOps, "Zero Trust" isn't a buzzword; it's a requirement. We eliminated long-lived credentials by ensuring no permanent secrets exist in the environment.

• Azure Authentication: We leveraged GitHub OIDC (Workload Identity Federation). Instead of a Client Secret or Service Principal password, the GitHub runner requests an ephemeral token from Azure. This token is strictly scoped to the repository and the main branch.
• Scoped Cloudflare Tokens: We used the principle of least privilege. One token is scoped to the account level (managing Workers/D1/Pages), while a separate domain-scoped token manages DNS.
• Ingest Security: To prevent rogue data injection, the Azure Function authenticates to the /api/ingest endpoint via an x-ingest-secret header. The database has no public write access.
• Governance: No direct pushes to the production branch are allowed. All changes require a Pull Request, triggering a CI/CD validation before deployment.

The deployment pipeline

Six steps, fully automated:

1. Provision (Terraform)
   → Azure RG + Function App + Storage
   → Cloudflare D1 database
   → DNS CNAME (status.aboutcloud.io)
   → CF Pages custom domain binding

2. Bootstrap D1 schema
   → wrangler d1 execute --remote

3. Deploy CF Worker
   → npx wrangler deploy

4. Deploy Azure Function
   → az functionapp deployment source config-zip

5. Deploy CF Pages
   → npx wrangler pages deploy

6. Summary
   → GitHub step summary with live URLs

Triggered by a WhatsApp message → OpenClaw AI → gh workflow run.

The Reality Check: Hard Lessons from Issue #30 This wasn't a "one-click" success. It took nine iterations to polish the edge cases. If you're building something similar, watch out for these "gotchas" documented in Issue #30:

1. Secret Scope Isolation: Terraform jobs in GitHub Actions only see secrets from their declared Environment. If your TF script touches both Azure and Cloudflare, ensure both sets of secrets are in the same GitHub Environment.
2. Provider Aliases: Cloudflare’s token scopes are extremely granular. An "Account" token cannot manage "DNS." I had to use Terraform provider aliases to handle two different tokens within the same execution.
3. The Lockfile Trap: npm ci will fail without a committed package-lock.json. Always generate this locally before pushing your Worker code.
4. Action Ephemeralness: Never rely on global npm installs across different jobs. Each job runs on a fresh runner. Use npx to ensure the binaries you need are fetched on the fly.
5. Pre-Creation Requirement: Unlike some services, Cloudflare Pages projects must be pre-created (via the dashboard or CLI) before running wrangler pages deploy.
6. The BOT was "smart" enough to self-heal and overcome the issue .... but lot of work ahead and things are not perfect of course....

Conclusion

By combining AI orchestration (OpenClaw), serverless compute, and OIDC-based security, we've built a production-grade status page for the cost of a domain name. Multi-cloud doesn't have to be expensive—it just has to be well-architected.

Try it yourself

• 🌐 Live dashboard: status.aboutcloud.io | Is a Demo Prototype of course . . .

If you're running a similar setup or have questions, reach out in the comments or on LinkedIn.

— Antonio | AboutCloud

arusso@aboutcloud.io