Somewhere around summer 2025 I started taking AI coding agents¹ more seriously. I’d been somewhat dismissive of them for a while - the early versions produced code that looked plausible but fell apart rather quickly. They would often get stuck and make silly mistakes. The newer models are different. Not because they magically write perfect code, but because they’re good enough to be directed. You tell them what to build, how to structure it, and they do the mechanical work while you make the decisions. The code is not the most effective and most beatiful but I don’t really care since I can change it so easily.

It clicked when I rebuilt the core of pixbin.net in about two hours. Pixbin is a super simple image sharing service I’ve been running since 2012 - drag and drop upload, auto-expiring images, shareable links. The codebase was showing its age and I’ve been putting off a rewrite/upgrade for years. With an agent handling the boilerplate while I focused on architecture and review, the whole thing came together in a single sitting on a hot summers day. Django, Celery for background image processing, S3 storage, Kubernetes deployment configs. Two hours. And then I started adding features!

This changed how I looked at my project backlog and list of ideas.

I don’t normally do this … but … occasionally I want to let an AI agent run unsupervised on a task: to generate a throwaway POC, explore an implementation idea, or hack on something while I’m doing other work. Even with each Agent’s permission system, giving it free rein over my repo feels uncomfortable. One bad rm -rf or overzealous refactor and I’m picking through git reflog trying to recover my afternoon. Not to mention the damange it could do to my environment or access stuff it shouldn’t.

So I built a small tool called slopbox for running AI agents in isolated Docker containers and a copy of my repo. This way I’m free to merge changes in (or throw them away) without it affecting my main worktree. It was initially inspired by Dagger’s container-use. This is just much more in tune with my workflow and the tools I use - but also I don’t trust an Agent to do something (consistently) just because it says so in a markdown file. I need stronger guarantees.

This post continues the hellok8s-* series, following my previous exploration of deploying a Django applications to Kubernetes. While the technology stack differs, the core DevOps principles and deployment challenges remain remarkably similar across frameworks.

As modern web applications grow in complexity, the gap between development tutorials and production-ready deployments becomes increasingly challenging. Most Next.js guides stop at npm run dev, but production applications require containerization, orchestration, secrets management, CI/CD pipelines, and reproducible development environments. Today, I want to share insights from hellok8s-nextjs, a comprehensive project template that demonstrates how to bridge this gap with battle-tested DevOps practices.

The Challenge: From Tutorial to Production

First, let’s address the elephant in the room: Vercel exists, and it’s excellent. For many Next.js applications, Vercel provides the easiest deployment experience with zero configuration, automatic scaling, and seamless integration with the Next.js ecosystem. If Vercel meets your needs, use it - it’s a fantastic platform that handles most of the complexity I’m about to discuss.

However, real-world enterprise requirements often demand self-hosted solutions for a variety of reasons:

Compliance requirements (HIPAA, SOC 2, PCI DSS) that require data to remain within specific geographic boundaries or private networks.

Cost optimization for high-traffic applications where predictable infrastructure costs matter.

Integration with existing infrastructure and legacy systems that can’t be easily migrated.

Custom security policies that require full control over the deployment environment.

Air-gapped environments or on-premises deployments where external platforms aren’t viable.

Multi-cloud strategies that require vendor independence.

When these constraints apply, scaling from a local development server to a production Kubernetes deployment involves numerous considerations that most tutorials don’t address. How do you ensure consistent environments across team members? How do you manage secrets securely? How do you achieve zero-downtime deployments with proper rollback capabilities?

After implementing these patterns across multiple technology stacks and organizations, I’ve distilled these proven practices into hellok8s-nextjs, a production-ready template that demonstrates the complete DevOps lifecycle for modern Next.js applications. These patterns have proven successful for teams ranging from small startups to enterprise organizations managing hundreds of developers.

When running applications in Docker containers, many developers overlook a critical detail: what process runs as PID 1. This seemingly minor choice can lead to unresponsive containers, resource leaks, and unexpected behavior during shutdown.

Why PID 1 is Special

In Linux, the kernel treats PID 1 differently from all other processes. It’s the “init” process that bootstraps the system and has two critical responsibilities:

Signal handling: The kernel doesn’t deliver certain signals (like SIGTERM) to PID 1 unless it explicitly registers handlers for them.

Process reaping: PID 1 must clean up zombie processes by calling waitpid() on dead children.

When you run a container with:

CMD ["./my-app"]

Your application becomes PID 1, inheriting these kernel expectations whether it’s designed for them or not.

As businesses increasingly move to cloud-native architectures, the complexity of deploying and maintaining modern web applications continues to grow. Today, I want to share insights from a comprehensive project template I’ve developed that demonstrates DevOps best practices, from local development to production Kubernetes deployments. While this example uses Django, the patterns and practices apply to any modern web framework.

The Challenge: Bridging the Gap from Tutorial to Production

Most web framework tutorials stop at basic development servers. But production applications require so much more: containerization, orchestration, secrets management, CI/CD pipelines, and reproducible development environments. The gap between “hello world” and production-ready is where most teams struggle and where costly delays, security vulnerabilities, and scaling bottlenecks emerge.

After years of building web applications across multiple technology stacks, I’ve distilled these battle-tested practices into hellok8s-django, a production-ready template that demonstrates the complete DevOps lifecycle, from local development to Kubernetes at scale. These patterns have proven successful with Python, Node.js, Go, Ruby, Haskell and other modern tech stacks.