--- title: "Cloud engineering proof of work" description: "How I think about deployment, networking, security, reliability, and cost. Verified project setup is separated from a local lab that does not provision a cloud account." canonical: "https://www.ayushrai.site/pow/cloud-engineer/" last-updated: "2026-10-19" --- # Cloud engineering proof of work Source: https://www.ayushrai.site/pow/cloud-engineer/ Markdown: https://www.ayushrai.site/pow/cloud-engineer.md How I think about deployment, networking, security, reliability, and cost. Verified project setup is separated from a local lab that does not provision a cloud account. I approach cloud engineering as a systems problem: deployment, networking, security, reliability, observability, and cost have to work together. The Cloud Operations Lab on this page is a local simulation of a fictional app called Fieldnote. It does not provision a cloud account. Reference architectures and sample prices are examples. ## Principles - Infrastructure as code. - Reproducible deployments. - Least-privilege security. - Observable systems. - Automated delivery. - Reliable failure recovery. - Cost-aware architecture. - Clear operational ownership. ## Reference architectures ### Lean application A small app on managed hosting and a managed database. Reference architecture, not a map of a live account. Simplicity and a small maintenance burden. The provider runs the machines. You still own the app, the schema, the domain, and what happens when a deploy is wrong. Components: DNS, CDN or edge, Web application hosting, API, Managed database, Secrets, CI/CD. ### Containerized application An image in a registry, a host that runs it, health checks, and a managed database. Reference architecture. Repeatable builds and a portable artifact. You add the registry, the image build, and the probe. You do not yet operate a cluster. Components: DNS, CDN or edge, Container registry, Container host, API, Managed database, Secrets, Logs and metrics. ### Distributed application More than one service, a queue, separate scaling, and one place to look at logs. Reference architecture. Independent scaling and a place for slow work. Each new service adds a deploy, a failure mode, and an owner. This is the right shape when one process cannot meet the constraints, not because it looks more professional. Components: DNS, CDN or edge, Load balancer, API, Background worker, Queue, Managed database, Object storage, Secrets, Identity and access, Logs and metrics, Alerting. ## Projects Lines are marked verified (repository), observed (a check on 19 Oct 2026), or proposed (not done). ### RevenueRoles - (verified) The repository is a monorepo: Next.js web and API apps, a Python pipeline, Supabase migrations, Dockerfiles, and GitHub Actions for CI, a secret scan, staging migrations, a manual production migration, and a scheduled health probe. - (verified) infra/terraform contains a README and a main file that declare no resources. Terraform is reserved there, not applied. - (verified) The web and API Dockerfiles start the Next.js dev server for local compose. The pipeline Dockerfile is a multi-stage Python image that runs Uvicorn. services/ai-pipeline/railway.toml points Railway at that Dockerfile and at /healthz. I am not claiming a Railway dashboard setting from that file alone. - (verified) docker-compose defines web, api, ai-pipeline, Postgres with pgvector, and Redis for local use. - (observed) On 19 Oct 2026, GET https://revenueroles.in/healthz and https://api.revenueroles.in/healthz returned HTTP 200 with server Vercel. The JSON said production and ok. The API payload said the AI pipeline was configured. That is one check, not an uptime figure. - (proposed) The empty Terraform root should stay empty until a resource is reviewed, or it should be removed so it is not mistaken for a live stack. ### Revenue Intelligence Engine - (verified) vercel.json describes a FastAPI service and a Next.js web app, with the web app receiving the API URL. I did not find a GitHub Actions workflow in that repository. - (verified) The Dockerfile is a single-stage Python 3.12 image that installs the project and also copies the tests. docker-compose runs the API with a SQLite file and the web app with npm run dev. - (observed) On 19 Oct 2026, https://cashmaker-two.vercel.app and https://revopy.vercel.app both returned HTTP 200. I did not verify from a dashboard that they are the same Vercel project. - (proposed) A production image would drop the tests and the dev server, and CI would build the same artifact the host runs. ### AGENYRA - (verified) The public site is Next.js. vercel.json sets the framework to Next.js and the region to bom1. A Supabase migration exists for the waitlist. Package scripts include build, lint, typecheck, and test. I did not find a Dockerfile or a GitHub Actions workflow in that repository. - (observed) On 19 Oct 2026, https://agenyra.space returned HTTP 200 with server Vercel. - (proposed) The checks in package.json are not a pipeline until a workflow runs them on each change. ### SpiderWeb - (verified) docker-compose runs Postgres with pgvector and Redis. The API Dockerfile is a multi-stage build that deploys production dependencies into a runner stage. GitHub Actions CI runs against Postgres and Redis service containers. The project record says it runs locally and has no production deployment. I am not claiming a registry push or a live host. - (proposed) If it ever leaves the laptop, the same image digest CI built should be the one that runs, with secrets outside the image. ### The Open Framework - (verified) vercel.json builds a Vite site and rewrites paths to index.html. I did not find a GitHub Actions workflow or a Dockerfile. The product record describes a front-end prototype with mock sign-in, not a verification backend. - (observed) On 19 Oct 2026, https://the-open-frameworks.vercel.app returned HTTP 200. - (proposed) Static hosting is the right weight for a prototype. It becomes the wrong weight when a private API and a database are actually required. ### This website - (verified) Vite, React, and TypeScript. vercel.json and netlify.toml both exist. GitHub Actions runs lint, typecheck, coverage, build, and Playwright. The build prerenders HTML. There is no Dockerfile in this repository. Serverless functions under api/ handle the contact form and the read-only API. - (observed) On 19 Oct 2026, https://www.ayushrai.site returned HTTP 200 with server Vercel. The repository is also configured for Netlify. I did not inspect DNS beyond that response. - (proposed) A static prerender plus a few functions is enough for this site. A cluster would add ownership without a workload that needs it. ### Life blog - (verified) The LifeOS vercel.json sets an empty build command, security headers, and rewrites for static files and API paths, including markdown negotiation. I did not treat that file as proof of a particular database or cluster. - (observed) On 19 Oct 2026, https://life.ayushrai.site returned HTTP 200 with server Vercel. - (proposed) Header and rewrite config should stay in the repo so a console click is not the only copy. ## Roadmap ### Stage 1. Understand the existing system (Planned) - Map the architecture. - Document dependencies. - Verify environment configuration. - Establish a repeatable deployment process. - Identify critical failure paths. ### Stage 2. Automate delivery (Planned) - Add or improve CI checks. - Automate builds. - Validate configuration. - Introduce release verification. - Document rollback procedures. ### Stage 3. Improve reliability (Planned) - Add health checks. - Standardize logs. - Monitor errors and latency. - Configure meaningful alerts. - Test backup and recovery procedures. ### Stage 4. Strengthen security (Planned) - Audit access permissions. - Remove unnecessary public exposure. - Review secrets handling. - Scan dependencies and container images where applicable. - Document security-sensitive operations. ### Stage 5. Optimize cost and performance (Planned) - Measure resource utilization. - Identify bottlenecks. - Review logging and storage costs. - Benchmark representative workloads. - Optimize based on evidence. ### Stage 6. Introduce infrastructure as code (Planned) - Select an appropriate tool. - Version infrastructure configuration. - Review changes before applying them. - Separate environments. - Add drift detection and safe change management. An SLI is a measurement, such as the share of health checks that succeed, or the p95 latency of one route. An SLO is a target for that measurement over a window, such as 99% of health checks succeeding in 30 days. I am not publishing an SLO for any live site. An error budget is the allowed failure inside that target. When it is gone, the useful move is to slow releases and fix reliability, not to add features on top. _Unverified award metrics are omitted. Wording matches the public site._