<?xml version="1.0" encoding="utf-8" standalone="yes"?><rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom"><channel><title>Devops on Gaurav.dev</title><link>/tags/devops/</link><description>Recent content in Devops on Gaurav.dev</description><generator>Hugo</generator><language>en-US</language><copyright>© 2026 Gaurav. Built with care and clean code.</copyright><lastBuildDate>Fri, 18 Sep 2026 00:00:00 +0000</lastBuildDate><atom:link href="/tags/devops/index.xml" rel="self" type="application/rss+xml"/><item><title>A Production Checklist for Next.js Applications</title><link>/posts/nextjs-production-checklist/</link><pubDate>Fri, 18 Sep 2026 00:00:00 +0000</pubDate><guid>/posts/nextjs-production-checklist/</guid><description>&lt;p&gt;A successful &lt;code&gt;next build&lt;/code&gt; proves that the application compiles. It does not prove that the product is ready for real users, crawlers, traffic spikes, or a difficult incident.&lt;/p&gt;&#10;&lt;h2 id="rendering-and-caching"&gt;Rendering and caching&lt;/h2&gt;&#10;&lt;p&gt;Confirm the rendering strategy for every important route. Static content should not become dynamic because a convenience API reads request state. Dynamic pages need explicit cache behaviour, and revalidation should match how quickly the underlying data can change. Test authenticated and anonymous paths separately.&lt;/p&gt;</description></item><item><title>A DevOps Pipeline a Small Team Can Actually Operate</title><link>/posts/devops-pipeline-small-team/</link><pubDate>Mon, 24 Aug 2026 00:00:00 +0000</pubDate><guid>/posts/devops-pipeline-small-team/</guid><description>&lt;p&gt;A good delivery pipeline makes the safe path the easy path. For a small team, it should also remain boring enough that anyone can diagnose it during a difficult release.&lt;/p&gt;&#10;&lt;h2 id="start-with-one-repeatable-path"&gt;Start with one repeatable path&lt;/h2&gt;&#10;&lt;p&gt;Every change should run formatting, static analysis, unit tests, dependency checks, and a production build in clean infrastructure. Cache dependencies carefully, but never in a way that changes correctness. Pull requests should show the same checks that protect the main branch.&lt;/p&gt;</description></item><item><title>Containers, Serverless, or Edge: Put Each Workload in the Right Place</title><link>/posts/containers-serverless-edge-deployment/</link><pubDate>Sat, 30 May 2026 00:00:00 +0000</pubDate><guid>/posts/containers-serverless-edge-deployment/</guid><description>&lt;p&gt;Modern applications rarely need one universal deployment model. A web frontend, webhook handler, scheduled pipeline, inference service, and long-running worker behave differently. Containers, serverless functions, and edge runtimes are tools for placing those workloads where their operational characteristics fit.&lt;/p&gt;&#10;&lt;h2 id="containers-a-portable-unit-of-execution"&gt;Containers: a portable unit of execution&lt;/h2&gt;&#10;&lt;p&gt;Docker packages an application with its runtime and system dependencies, making development, CI, and production more consistent. Containers suit APIs, workers, scheduled jobs, and services with predictable resource needs. They allow control over process behaviour, networking, files, and dependencies without coupling the application completely to one platform.&lt;/p&gt;</description></item></channel></rss>