--- title: "DevOps engineer proof of work" description: "Ayush Rai on DevOps: a local delivery workbench, plus what the public repositories actually automate. Simulations are labeled. Unmeasured uptime and incident history are left out." canonical: "https://www.ayushrai.site/pow/devops-engineer/" last-updated: "2026-10-19" --- # DevOps engineer proof of work Source: https://www.ayushrai.site/pow/devops-engineer/ Markdown: https://www.ayushrai.site/pow/devops-engineer.md Ayush Rai on DevOps: a local delivery workbench, plus what the public repositories actually automate. Simulations are labeled. Unmeasured uptime and incident history are left out. I automate the path from code to reliable production. I approach DevOps as an engineering discipline: automate repetitive work, make delivery reproducible, detect failures early, release safely, and make recovery predictable. This page is a deterministic simulation running in the browser. It does not deploy, call a CI provider, or read production credentials. A working demonstration here is not a claim of production operations experience. ## Principles - **Automation over repetitive manual work.** A release step that people retype will drift. Put the repeatable part in a workflow and keep the judgment where a person is still required. - **Reproducible builds.** The same revision and the same locked dependencies should be what the pipeline builds. I do not claim bit-for-bit reproducibility unless a build has been compared. - **Fast feedback from CI.** Lint and unit tests belong close to the change. A slow or optional check that can fail the release has to be explicit about that. - **Immutable release artifacts.** Build once, name the artifact, and promote that object. Rebuilding per environment is a way to ship something you did not test. - **Safe deployments.** A deploy needs a gate, a health check, and a way back. The strategy depends on compatibility and how much extra infrastructure you can carry. - **Infrastructure and configuration under version control.** If the change is not in a repository, the next person cannot review it. A directory reserved for Terraform is not the same thing as resources under management. - **Observable systems.** A health endpoint and a log line are the start. They are not a service level, and this page does not invent one. - **Tested recovery procedures.** Rollback is a procedure you can rehearse. An application rollback does not automatically undo a schema change. - **Security throughout the delivery lifecycle.** Least privilege, locked dependencies, and secret references belong in the workflow. A scan that cannot fail the job is a report, not a gate. - **Continuous improvement based on evidence.** Change the pipeline because a failure or a measurement said so. This page does not supply deployment frequency or an error budget. ## DevOps Control Room The control room is a browser simulation of one fictional change moving through checkout, tests, build, security, artifact, deploy, smoke tests, and verification. A failed mandatory stage blocks a successful release. Every log line is illustrative. ## Pipeline - Checkout and dependency installation are sequential. Nothing else has a revision or a lockfile until they finish. - Lint, unit tests, and security checks share the next wave. They need the install and they do not need each other, so they can run together. - Integration tests wait for unit tests. If you leave them enabled, the build waits for them too. - The build waits for lint and unit tests. A lint failure or a test failure blocks it. The artifact is created only from a build that ran. - Artifact validation, when enabled, sits between the artifact and deploy. Deploy also waits for a blocking security failure. - Smoke tests run only after deploy. Release verification waits for them when they are enabled. A smoke failure rejects the release. ## GitHub Actions Verified workflows are summarized from the repositories below. The YAML example on the page is proposed and is not installed. - **push and pull_request.** Pull requests get the verify job. The deploy job's if condition limits it to a push of main, so a pull request cannot take the production path. - **Job dependencies.** deploy needs verify. GitHub will not start it when verify fails. - **Cache keys.** setup-node with cache: npm keys the cache from the lockfile. A lockfile change misses the cache on purpose. - **Artifacts and test reports.** This example does not upload an artifact. A real workflow should upload the built output it intends to promote, and upload test reports when the job fails if someone needs them. - **Environment protection and approvals.** environment: production is a request to use that GitHub environment. Protection rules, including required reviewers, are configured on the environment. Naming the environment in YAML does not prove the rules exist. - **Concurrency.** cancel-in-progress keeps one verify run per ref. The RevenueRoles deploy workflows I read set cancel-in-progress to false so a production migrate is not cancelled by a second push. - **Secrets and permissions.** The example grants contents: read and does not echo a secret. A secret is passed through the secrets context into an environment variable at the step that needs it. It is not written into the repository. ## Artifacts The sample manifest names sample-web 1.5.0 at revision a1b2c3d. It is synthetic. not created — this manifest is synthetic. - **Dependency pinning and lockfiles.** Install with the lockfile (`npm ci`, `pnpm install --frozen-lockfile`, or the equivalent) so CI does not resolve a newer tree than the one you reviewed. - **Reproducible builds.** A reproducible build can be repeated from the same inputs. I have not run a bit-for-bit comparison of any artifact in these repositories, so this page does not claim that. - **Immutable artifacts and promotion.** Build once. Promote the same artifact from the test environment to staging and production. Rebuilding in each environment is how configuration and dependency drift sneak in. - **Software bills of materials and integrity.** An SBOM lists what is inside the artifact. A digest lets a later stage check it was not swapped. Neither is generated by this page. - **Supply-chain security.** Least-privilege workflow tokens, pinned actions, and a review before a secret is used are the practical controls. A sample workflow below follows that shape and is not installed anywhere. ## Containers - **Images and containers.** An image is the built filesystem and start command. A container is a running instance of an image. Building an image does not deploy it. - **Build context.** The context is the set of files sent to the build. A context that includes secrets or a huge repository makes the build slower and riskier. - **Multi-stage builds.** One stage can install toolchains and another can copy only the runtime output. That keeps compilers out of the image you run. - **Tagging.** A tag should name an immutable build. Moving tags such as latest are convenient and ambiguous. - **Non-root execution.** A process that does not need root should not run as root. The SpiderWeb API Dockerfile sets a user. The RevenueRoles worker Dockerfile I read does not. - **Scanning, registries, and runtime configuration.** Scan before publish. Authenticate the registry with a short-lived credential, not a token baked into the image. Runtime configuration arrives as environment or mounts, not as a rebuilt image per environment. - **Health checks and shutdown.** A health check tells the platform whether the process should receive traffic. A graceful shutdown handles the signal, finishes or drops in-flight work, and exits. This page does not run either. ## Deployment strategies These comparisons use hypothetical assumptions. I am not claiming that a listed project runs rolling, blue-green, canary, flag, or recreate deploys. - **Rolling deployment.** Replace instances gradually. Old and new versions serve at the same time, so they have to tolerate each other and the shared database. Assumes more than one instance and a load balancer that can drain connections. - **Blue-green deployment.** Keep two environments and switch traffic after the idle one is verified. The idle environment costs money even when it is not serving. Assumes you can run a second full copy and that the switch is a routing change. - **Canary deployment.** Send a small share of traffic to the new version, watch it, then widen or stop. The stop condition has to be decided before the rollout. Assumes traffic can be split and that the sample is large enough to notice a failure. - **Feature flags.** Deploy the code dark, then turn the behavior on. The flag is not a deploy strategy by itself. Old flags that nobody removes become a second product. Assumes the unsafe behavior defaults off and that flag state is visible. - **Recreate deployment.** Stop the old version, then start the new one. There is a gap. The procedure is simple, which is sometimes the right trade when the gap is acceptable. Assumes a maintenance window or a workload that can be down for the swap. ## Release gates and rollback A mandatory failing gate blocks promotion of the synthetic candidate. Rollback returns the sample to the last approved version name. Restoring an application artifact does not reverse a database migration. ## Repository evidence ### This site (ayush-work) Verified workflow Live site: https://www.ayushrai.site. Repository: https://github.com/ayushrai-hub/ayush-work. - .github/workflows/tests.yml runs on push and pull_request to main. It checks out the repo, sets up Node 22 with the npm cache, runs npm ci, lint, typecheck, unit tests with coverage, the production build, and Playwright. - package-lock.json is the JavaScript lockfile. netlify.toml and vercel.json are the host configs. Merging to main is what deploys. - The repository documents GA4 and Vercel Analytics. This page does not publish traffic numbers. Not found, or not claimed: - No Dockerfile and no Terraform files in this repository. - The tests workflow does not set a permissions block, does not upload a build artifact, and does not deploy by itself. ### RevenueRoles Verified workflows, images, and a Terraform stub Live site: https://revenueroles.in/. Repository: https://github.com/ayushrai-hub/RevenueRoles. - CI (ci.yml) on pull_request and push to main, with concurrency that cancels an in-progress run for the same ref. Jobs: TypeScript (pnpm 9.15.0, Node 22, frozen lockfile, typecheck, lint, web and API builds, API tests), Python (uv, ruff, mypy, pytest), E2E smoke after the TypeScript job, migration and RLS checks, a worker Docker build, and ops unit tests. - The worker job runs docker build for services/ai-pipeline and curls http://127.0.0.1:18000/healthz. I did not see a registry push in that job. - Deploy Staging runs on push to main and workflow_dispatch. It waits for the TypeScript check, then uses the staging environment, the Supabase CLI, and scripts/smoke-deploy.sh. Secrets are referenced as SUPABASE_ACCESS_TOKEN, SUPABASE_PROJECT_REF, and SUPABASE_DB_PASSWORD. URLs come from vars.STAGING_WEB_URL, STAGING_API_URL, and STAGING_WORKER_URL. - Deploy Production is workflow_dispatch only. The confirm input must be the word deploy. Jobs use the production environment and the same smoke script with PRODUCTION_* variables. - scheduled-health.yml is a cron every 6 hours plus workflow_dispatch. It GETs https://revenueroles.in/healthz and the API healthz URLs. I did not read run history, so I am not claiming the schedule succeeds. - security.yml runs ops tests, a secret-pattern scan, and pnpm audit --prod || true. The || true means a non-zero audit does not fail that step. - pnpm-lock.yaml and uv.lock are present. Dockerfiles exist for the web app, the API, and the AI pipeline. The worker Dockerfile is multi-stage (Python 3.12, uv) and the file I read does not set a USER. The web Dockerfile I read starts next dev for compose. - apps/web and apps/api have healthz routes. scripts/ops/commands/health.mjs and the pipeline's test_health.py are in the tree. - infra/terraform/main.tf states that it declares no resources. The README says Terraform is not required for the MVP skeleton. Not found, or not claimed: - No measured deploy frequency, uptime, or incident count. - The environments API on 19 Oct 2026 listed Production and Preview environments with empty protection_rules. The workflow requests environment names staging and production. An empty rule list is not a reviewer gate, and a differently cased name may be a different environment. ### Revenue Intelligence Engine Dockerfile and Compose present. No Actions workflow directory. Live site: https://revopy.vercel.app/. Repository: https://github.com/ayushrai-hub/REVENUE-INTELLIGENCE-ENGINE. - Dockerfile is a single stage from python:3.12-slim. It copies the app, data, and tests, pip-installs the project, and starts uvicorn on port 8000. The file has no USER and no HEALTHCHECK. - docker-compose.yml defines an api service built from that file and a web service that runs npm run dev from a node:22-alpine image. The API uses a sqlite URL in the compose file. - vercel.json is present. pyproject.toml and web/package-lock.json are the lockfiles I found. app/workflows is application code, not GitHub Actions. Not found, or not claimed: - The .github/workflows path returned 404, which is what the contents API does when the directory is missing. - I did not build or push the image. ### AGENYRA Host config only, in the files I listed. Live site: https://agenyra.space/. Repository: https://github.com/ayushrai-hub/AGENYRA_product. - vercel.json sets the framework to Next.js and the region to bom1. pnpm-lock.yaml is present. - The GitHub homepage field points at agenyra-product.vercel.app. The product URL used on this site is agenyra.space. I did not inspect that host's deploy logs. Not found, or not claimed: - No .github/workflows directory and no Dockerfile in the recursive tree listing. ### SpiderWeb Verified CI and Dockerfiles. The CI file does not build the images. Repository: https://github.com/ayushrai-hub/SpiderWeb. - ci.yml runs on push to main and on pull_request, with cancel-in-progress concurrency. The verify job starts Postgres (pgvector) and Redis as service containers, installs with pnpm's frozen lockfile on Node 20, migrates, typechecks, lints, checks formatting, tests, and builds. The e2e job needs verify and uploads the Playwright report only when it fails, for 7 days. - apps/api/Dockerfile is multi-stage. The runner stage adds an app user, copies the deployed output as that user, and defines a HEALTHCHECK against /health. apps/web and the ingestion worker also have Dockerfiles. docker-compose.yml is in the repository. - pnpm-lock.yaml is present. The API has a health route. Not found, or not claimed: - The CI workflow I read does not run docker build and does not push an image. - No live URL is recorded on the project homepage field I read. ### The Open Framework Vercel config and an npm lockfile. No Actions workflow in the tree. Live site: https://the-open-framework.vercel.app/. Repository: https://github.com/ayushrai-hub/the-open-framework. - vercel.json builds with npm run build, publishes dist, and rewrites paths to index.html. package-lock.json is present. Not found, or not claimed: - No .github/workflows directory and no Dockerfile in the recursive tree listing. ### LifeOS Verified content workflows. The live site is the archive linked from this portfolio; I did not read its deploy logs. Live site: https://life.ayushrai.site/. Repository: https://github.com/ayushrai-hub/LifeOS. - currently-reading.yml runs on push and pull_request when the reading data, the build script, or the reading site changes. It runs node scripts/build-reading.js --check. - publish-sdk.yml runs on workflow_dispatch and on a published GitHub release. It references NPM_TOKEN and PYPI_TOKEN. Both publish steps set continue-on-error, so a failed publish does not fail the job. - package-lock.json and vercel.json are present. vercel.json sets an empty build command and clean URLs. Not found, or not claimed: - sites/domains/kubernetes is a content page in the repository, not a cluster I found. - No Dockerfile turned up in the filtered tree listing. ## Limits - The control room, pipeline, container lab, strategy comparison, and release gates are local simulations. Logs, waves, versions, and the sample error rule are illustrative. - I did not re-run GitHub Actions, build an image, or push a tag while making this page. - I am not publishing deployment frequency, uptime, release duration, cost, team size, customer impact, or an incident narrative. - A GitHub environment name in a workflow is not proof of required reviewers. The RevenueRoles environments I listed had no protection rules in the API response. - Terraform in RevenueRoles reserves a directory and declares no resources. - An audit step that ends in || true does not block a release. - Application rollback and database rollback are different. Restoring the previous artifact does not reverse a migration that already ran. - GitHub: https://github.com/ayushrai-hub - LinkedIn: https://www.linkedin.com/in/ayushrai02/ - Site: https://www.ayushrai.site _Unverified award metrics are omitted. Wording matches the public site._