How are you guys using Claude code or any other ai tool for devops. My team have started using Claude code but we are struggling to make it work at team level.
How are you guys using Claude code or any other ai tool for devops. My team have started using Claude code but we are struggling to make it work at team level. If I create tasks which have well defined acceptance criteria, team mates are still producing code using Claude code which doesn't meet AC. If I review merge request by Claude code and then run experts opinions on it, it finds additional issues. I then ask codex to review same MR and then codex finds additional issues. When I merge both codex and Claude feedback and ask Claude to fix the issues and ask Claude to run experts reviews, it finds issues again. Codex review find issues. It is never never ending. What are you guys doing to fix it ? My code is infrastructure as a code terraform deploy on AWS. We are using eks , aurora DB, gitops, argocd, cloud front, API gateway S3 etc
https://redd.it/1vhxf93
@r_devops
How are you guys using Claude code or any other ai tool for devops. My team have started using Claude code but we are struggling to make it work at team level. If I create tasks which have well defined acceptance criteria, team mates are still producing code using Claude code which doesn't meet AC. If I review merge request by Claude code and then run experts opinions on it, it finds additional issues. I then ask codex to review same MR and then codex finds additional issues. When I merge both codex and Claude feedback and ask Claude to fix the issues and ask Claude to run experts reviews, it finds issues again. Codex review find issues. It is never never ending. What are you guys doing to fix it ? My code is infrastructure as a code terraform deploy on AWS. We are using eks , aurora DB, gitops, argocd, cloud front, API gateway S3 etc
https://redd.it/1vhxf93
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
Home Lab Solutions
Hey guys I wanna to do some home labing ( using a kube cluster to run my workflow and use cases .. ) but I need some free infrastructure solution ( Servers for exemple) .. I tried to get A1 OCP ( ORACLE CLOUD) Server which is free ( 24Gb RAM and 8 VCPU .. ) but Always I'm getting OUT OF CAPACITY.. so if someone know some other SOLUTIONS ....
https://redd.it/1viclf3
@r_devops
Hey guys I wanna to do some home labing ( using a kube cluster to run my workflow and use cases .. ) but I need some free infrastructure solution ( Servers for exemple) .. I tried to get A1 OCP ( ORACLE CLOUD) Server which is free ( 24Gb RAM and 8 VCPU .. ) but Always I'm getting OUT OF CAPACITY.. so if someone know some other SOLUTIONS ....
https://redd.it/1viclf3
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
Gym for DevOps practice
I have seen a coding interview that hands in docker logs, the logs have some error, and the interviewer asks you to recreate that docker file from the logs, what really struck my mind is that, i have never really practiced docker like that and now i feel that i was wasting my time not knowing how to critic my skills and put them in question, which is what practice does, in this context, are there any ways i could practice certain tools in DevOps? specially docker, kubernetes, terraform
also i am looking for something free
PS: i have experience with docker, primarily from the nextcloud app i deployed on an old pc sitting around in my house
https://redd.it/1vivzci
@r_devops
I have seen a coding interview that hands in docker logs, the logs have some error, and the interviewer asks you to recreate that docker file from the logs, what really struck my mind is that, i have never really practiced docker like that and now i feel that i was wasting my time not knowing how to critic my skills and put them in question, which is what practice does, in this context, are there any ways i could practice certain tools in DevOps? specially docker, kubernetes, terraform
also i am looking for something free
PS: i have experience with docker, primarily from the nextcloud app i deployed on an old pc sitting around in my house
https://redd.it/1vivzci
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
Platform/DevOps/SRE practitioners: looking for independent technical review of a research implementation
I’m developing HybridOps Core, an MIT-0 open-source research implementation for governed infrastructure operations, and I’m looking for practitioners willing to give a short, candid technical assessment of specific parts of the work.
The work examines whether infrastructure intent, environment policy, dependency ordering, preflight, execution, verification and run records can be expressed through a stable runtime contract across heterogeneous environments.
I’ve published several technical papers alongside the implementation and opened focused GitHub review threads for independent critique. The aim is not a code audit or unpaid QA. Reviewers are being asked to assess the architecture, operating assumptions, failure boundaries and practical relevance of the work.
Current review areas include contract-driven runtime design, image lifecycle and verification, reproducible network environments, infrastructure authority and source-of-truth boundaries, and recovery operations.
If one of those areas overlaps with your experience, comment with the area and I’ll send the relevant paper and review thread. Critical findings and counterexamples are welcome.
https://redd.it/1vituwp
@r_devops
I’m developing HybridOps Core, an MIT-0 open-source research implementation for governed infrastructure operations, and I’m looking for practitioners willing to give a short, candid technical assessment of specific parts of the work.
The work examines whether infrastructure intent, environment policy, dependency ordering, preflight, execution, verification and run records can be expressed through a stable runtime contract across heterogeneous environments.
I’ve published several technical papers alongside the implementation and opened focused GitHub review threads for independent critique. The aim is not a code audit or unpaid QA. Reviewers are being asked to assess the architecture, operating assumptions, failure boundaries and practical relevance of the work.
Current review areas include contract-driven runtime design, image lifecycle and verification, reproducible network environments, infrastructure authority and source-of-truth boundaries, and recovery operations.
If one of those areas overlaps with your experience, comment with the area and I’ll send the relevant paper and review thread. Critical findings and counterexamples are welcome.
https://redd.it/1vituwp
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
Moving from Senior to Lead
If you got promoted from Senior to Lead, please could you share your journey, as to what all challenges you faced, techniques you used, any books you read, how you’ve tackled office politics, rapport with the manager/colleagues and so on..
Thanks!
https://redd.it/1vj1854
@r_devops
If you got promoted from Senior to Lead, please could you share your journey, as to what all challenges you faced, techniques you used, any books you read, how you’ve tackled office politics, rapport with the manager/colleagues and so on..
Thanks!
https://redd.it/1vj1854
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
What is the single DevOps skill or tool that gave you the biggest
career leap?
There's an endless sea of tools in the Cloud/DevOps ecosystem
(Kubernetes, Terraform, CI/CD pipelines, Prometheus, eBPF, Python/Go,
etc.).
For experienced engineers, what was the single tool, architectural
concept, or skill you mastered that made you significantly better at
your job or opened the most senior doors?
https://redd.it/1vj5wqp
@r_devops
career leap?
There's an endless sea of tools in the Cloud/DevOps ecosystem
(Kubernetes, Terraform, CI/CD pipelines, Prometheus, eBPF, Python/Go,
etc.).
For experienced engineers, what was the single tool, architectural
concept, or skill you mastered that made you significantly better at
your job or opened the most senior doors?
https://redd.it/1vj5wqp
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
Why do experienced engineers open cloud provider support cases for customer managed resources?
This isn't a dig at anyone ..I'm genuinely trying to understand the thought process or organizational pressure behind this.
I regularly see tickets from senior platform engineers, DevOps leads, and cloud architects asking Azure (or AWS/GCP) support to troubleshoot Terraform state issues, fix customer-managed IAM policies, or debug application code running on VMs.
The response is almost always: "This is outside our scope."
If you're someone who has opened these tickets (or works somewhere that expects you to), what drives that? Is it:
SLA pressure:
you need someone on the hook while you investigate?
Org policy:
management mandates opening a case before escalating internally?
Knowledge gaps:
the line between "managed by cloud provider" vs. "managed by customer" is blurrier than it looks from the outside?
Hail Mary:
you've exhausted everything and hope support has an internal tool or undocumented fix?
I'm asking because I want to be less cynical when I see these tickets. There might be a structural reason I'm not seeing. Would love to hear from people who've been on either side of this.
https://redd.it/1vj88zq
@r_devops
This isn't a dig at anyone ..I'm genuinely trying to understand the thought process or organizational pressure behind this.
I regularly see tickets from senior platform engineers, DevOps leads, and cloud architects asking Azure (or AWS/GCP) support to troubleshoot Terraform state issues, fix customer-managed IAM policies, or debug application code running on VMs.
The response is almost always: "This is outside our scope."
If you're someone who has opened these tickets (or works somewhere that expects you to), what drives that? Is it:
SLA pressure:
you need someone on the hook while you investigate?
Org policy:
management mandates opening a case before escalating internally?
Knowledge gaps:
the line between "managed by cloud provider" vs. "managed by customer" is blurrier than it looks from the outside?
Hail Mary:
you've exhausted everything and hope support has an internal tool or undocumented fix?
I'm asking because I want to be less cynical when I see these tickets. There might be a structural reason I'm not seeing. Would love to hear from people who've been on either side of this.
https://redd.it/1vj88zq
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
Seaking genuine advice
So I've been a software engineer focused on the backend for almost 10 years now, at the beginning of this year I faced a small bump and found needed solutions are paid, so did myself a favour and build myself a tool, and used it for a month, then thought wth, why don't I go public with it, it didn't have any interface at the beginning, so I started building and iterating a lot, and like a lot, to the point it's not advised to do so with a product on an MVP phase, and now I've reached a state where I believe I'm a head of my competitors (hopefully I'm not delusional)
And then nothing, I've been online for a month now, and I've very low traffic, my purpose of this is not promoting, therefore I'm not mentioning the product, nor even what it does
My question though, since obviously the product mostly concerns DevOps, what's the best channels you take seriously? And what could get you to try out or shift to something new? Cost a side since I've a full free tier.
https://redd.it/1vjgbcm
@r_devops
So I've been a software engineer focused on the backend for almost 10 years now, at the beginning of this year I faced a small bump and found needed solutions are paid, so did myself a favour and build myself a tool, and used it for a month, then thought wth, why don't I go public with it, it didn't have any interface at the beginning, so I started building and iterating a lot, and like a lot, to the point it's not advised to do so with a product on an MVP phase, and now I've reached a state where I believe I'm a head of my competitors (hopefully I'm not delusional)
And then nothing, I've been online for a month now, and I've very low traffic, my purpose of this is not promoting, therefore I'm not mentioning the product, nor even what it does
My question though, since obviously the product mostly concerns DevOps, what's the best channels you take seriously? And what could get you to try out or shift to something new? Cost a side since I've a full free tier.
https://redd.it/1vjgbcm
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
Cloud Engineers: Which YouTube roadmap/course would you follow in 2026?
I'm currently working toward a Cloud Engineer role and I'm trying to avoid jumping between 20 different YouTube playlists without actually becoming job-ready.
I already have a foundation in Linux and networking, and I'm now focusing on AWS/cloud.
I've found several 2026 Cloud Engineer roadmaps covering things like:
\- Linux & Networking
\- AWS
\- Python/Bash
\- Git/GitHub
\- Docker
\- Kubernetes
\- Terraform/IaC
\- CI/CD
\- Monitoring
\- Cloud Security
\- Real-world projects
But I'm confused about which YouTube course/playlist is actually worth following from start to finish.
For someone targeting an entry-level Cloud Engineer / Cloud Support / DevOps role in 2026, which YouTube channel or full course would you personally recommend?
I'd especially appreciate recommendations from people currently working in Cloud/DevOps, rather than just generic “best YouTube channel” lists.
Also, if you think some topics above are unnecessary at the beginning, please tell me what to learn first, what to postpone, and what I can skip.
Thanks!
https://redd.it/1vj6h2l
@r_devops
I'm currently working toward a Cloud Engineer role and I'm trying to avoid jumping between 20 different YouTube playlists without actually becoming job-ready.
I already have a foundation in Linux and networking, and I'm now focusing on AWS/cloud.
I've found several 2026 Cloud Engineer roadmaps covering things like:
\- Linux & Networking
\- AWS
\- Python/Bash
\- Git/GitHub
\- Docker
\- Kubernetes
\- Terraform/IaC
\- CI/CD
\- Monitoring
\- Cloud Security
\- Real-world projects
But I'm confused about which YouTube course/playlist is actually worth following from start to finish.
For someone targeting an entry-level Cloud Engineer / Cloud Support / DevOps role in 2026, which YouTube channel or full course would you personally recommend?
I'd especially appreciate recommendations from people currently working in Cloud/DevOps, rather than just generic “best YouTube channel” lists.
Also, if you think some topics above are unnecessary at the beginning, please tell me what to learn first, what to postpone, and what I can skip.
Thanks!
https://redd.it/1vj6h2l
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
When does “just rebuild it” stop being safe?
I am looking for practitioner views on a lifecycle problem, not a code review.
In many teams, temporary environments are treated as disposable until they quietly become important. They accumulate state, access paths, recovery assumptions, cost exposure and operational evidence. Then teardown becomes risky, but leaving them running also creates waste.
I built an open-source implementation that treats readiness, dependency order, access, health checks, cost visibility, state preservation and teardown as one runtime contract.
The question I am trying to validate is simple:
>What evidence should exist before a system is allowed to destroy or rebuild an environment that may contain useful state?
If you have dealt with ephemeral environments, recovery runs, lab platforms or image lifecycles, I would value a short sanity check. I can share the relevant paper and GitHub discussion.
>NOTE: I am not asking for code review or implementation help. I am trying to sanity-check one operating-design question.
https://redd.it/1vj7co0
@r_devops
I am looking for practitioner views on a lifecycle problem, not a code review.
In many teams, temporary environments are treated as disposable until they quietly become important. They accumulate state, access paths, recovery assumptions, cost exposure and operational evidence. Then teardown becomes risky, but leaving them running also creates waste.
I built an open-source implementation that treats readiness, dependency order, access, health checks, cost visibility, state preservation and teardown as one runtime contract.
The question I am trying to validate is simple:
>What evidence should exist before a system is allowed to destroy or rebuild an environment that may contain useful state?
If you have dealt with ephemeral environments, recovery runs, lab platforms or image lifecycles, I would value a short sanity check. I can share the relevant paper and GitHub discussion.
>NOTE: I am not asking for code review or implementation help. I am trying to sanity-check one operating-design question.
https://redd.it/1vj7co0
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
What is the best architecture for a developer-friendly, virtualized execution environment for AI agents?
What is the best architecture for a developer-friendly, virtualized execution environment for AI agents?
I'm exploring an idea for running AI agents inside isolated, virtualized environments.
The basic concept is:
**AI Agent → Sandbox API/SDK → Firecracker microVM → isolated Linux filesystem**
The goal is to make the developer experience extremely simple. A developer should be able to create an environment for an agent, give it a shell/filesystem/tools, let it execute code and install packages, and then destroy or snapshot the environment — without having to manually deal with Firecracker configuration, kernels, rootfs, networking, etc.
The agent itself could run outside the VM, while all potentially unsafe operations (shell commands, file modifications, code execution, package installation, etc.) happen inside the microVM.
I'm aware of projects such as E2B, Daytona, Modal, and OpenHands, but I'm trying to understand the infrastructure layer more deeply.
**My questions:**
1. Is Firecracker actually a good foundation for this, or would containers, gVisor, Kata, Cloud Hypervisor, or something else make more sense?
2. What are the hardest parts that aren't obvious when building this? I'm thinking about VM startup time, filesystem images, snapshots, networking, resource limits, persistent workspaces, and VM lifecycle management.
3. Is there already an open-source project that provides this kind of developer-friendly abstraction over Firecracker specifically for AI agents?
4. What would you change about the current E2B/Daytona-style approach if you were designing it from scratch?
5. Do you think there is a meaningful gap for a **local-first** version where the agent uses the developer's own CPU/RAM/storage while getting a fully isolated virtualized Linux environment?
I'm particularly interested in feedback from people who have actually built or operated sandboxed execution environments, Firecracker infrastructure, coding agents, or multi-tenant compute systems.
I'm not looking for another AI-agent framework; I'm more interested in the **execution/sandbox infrastructure underneath the agent**.
https://redd.it/1vjuku9
@r_devops
What is the best architecture for a developer-friendly, virtualized execution environment for AI agents?
I'm exploring an idea for running AI agents inside isolated, virtualized environments.
The basic concept is:
**AI Agent → Sandbox API/SDK → Firecracker microVM → isolated Linux filesystem**
The goal is to make the developer experience extremely simple. A developer should be able to create an environment for an agent, give it a shell/filesystem/tools, let it execute code and install packages, and then destroy or snapshot the environment — without having to manually deal with Firecracker configuration, kernels, rootfs, networking, etc.
The agent itself could run outside the VM, while all potentially unsafe operations (shell commands, file modifications, code execution, package installation, etc.) happen inside the microVM.
I'm aware of projects such as E2B, Daytona, Modal, and OpenHands, but I'm trying to understand the infrastructure layer more deeply.
**My questions:**
1. Is Firecracker actually a good foundation for this, or would containers, gVisor, Kata, Cloud Hypervisor, or something else make more sense?
2. What are the hardest parts that aren't obvious when building this? I'm thinking about VM startup time, filesystem images, snapshots, networking, resource limits, persistent workspaces, and VM lifecycle management.
3. Is there already an open-source project that provides this kind of developer-friendly abstraction over Firecracker specifically for AI agents?
4. What would you change about the current E2B/Daytona-style approach if you were designing it from scratch?
5. Do you think there is a meaningful gap for a **local-first** version where the agent uses the developer's own CPU/RAM/storage while getting a fully isolated virtualized Linux environment?
I'm particularly interested in feedback from people who have actually built or operated sandboxed execution environments, Firecracker infrastructure, coding agents, or multi-tenant compute systems.
I'm not looking for another AI-agent framework; I'm more interested in the **execution/sandbox infrastructure underneath the agent**.
https://redd.it/1vjuku9
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
CTO says AI makes junior and senior engineers the same
Hi everyone,
I’m a junior DevOps engineer, and recently our CTO said something that honestly made me question my understanding of software engineering.
He has around 30 years of experience, and his statement was basically:
>With AI tools like Claude Code, there is no real difference anymore between a junior and a senior engineer, or between a mobile developer, backend developer, and infrastructure engineer. If you have access to AI, you should be able to do any task assigned to you.
I understand that AI has changed a lot. Claude Code can help you write code, understand unfamiliar technologies, debug problems, and even work on things you have never done before.
But I’m not sure I agree that this removes the difference between experience and specialization.
his statement made me feel unstable about my career and what I should focus on learning.
Has AI actually reduced the gap between junior and senior engineers?
Does AI really make specialization less important?
https://redd.it/1vjxidv
@r_devops
Hi everyone,
I’m a junior DevOps engineer, and recently our CTO said something that honestly made me question my understanding of software engineering.
He has around 30 years of experience, and his statement was basically:
>With AI tools like Claude Code, there is no real difference anymore between a junior and a senior engineer, or between a mobile developer, backend developer, and infrastructure engineer. If you have access to AI, you should be able to do any task assigned to you.
I understand that AI has changed a lot. Claude Code can help you write code, understand unfamiliar technologies, debug problems, and even work on things you have never done before.
But I’m not sure I agree that this removes the difference between experience and specialization.
his statement made me feel unstable about my career and what I should focus on learning.
Has AI actually reduced the gap between junior and senior engineers?
Does AI really make specialization less important?
https://redd.it/1vjxidv
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
Karpenter Implementation
I want to deploy Karpenter. However, I would like to learn the best practices for using Karpenter on EKS. Currently, we are using app-of-apps in ArgoCD, all within a Managed Node Group.
With Karpenter, our plan is to have it configured like this:
\- Scale down the MNG and run the Karpenter Controller inside the static MNG, alongside cluster system resources (DaemonSets, add-ons, including ArgoCD)
\- Karpenter is managed as an app in ArgoCD (using bootstrap with ArgoCD)
Is this design already suitable, or should we consider changing it? We need advice.
https://redd.it/1vk641k
@r_devops
I want to deploy Karpenter. However, I would like to learn the best practices for using Karpenter on EKS. Currently, we are using app-of-apps in ArgoCD, all within a Managed Node Group.
With Karpenter, our plan is to have it configured like this:
\- Scale down the MNG and run the Karpenter Controller inside the static MNG, alongside cluster system resources (DaemonSets, add-ons, including ArgoCD)
\- Karpenter is managed as an app in ArgoCD (using bootstrap with ArgoCD)
Is this design already suitable, or should we consider changing it? We need advice.
https://redd.it/1vk641k
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
How do you handle conflicting infrastructure state?
Curious how people handle this in real environments.
Say Terraform says an EC2 instance should have encryption enabled, but the AWS console/API shows it disabled. Your CMDB still says it's compliant.
How do you figure out which one is actually telling the truth?
Do you have a defined source of truth, or do you usually investigate the discrepancy manually?
And how do you tell whether it's actual drift, stale information, or something that failed during deployment?
https://redd.it/1vk7lk2
@r_devops
Curious how people handle this in real environments.
Say Terraform says an EC2 instance should have encryption enabled, but the AWS console/API shows it disabled. Your CMDB still says it's compliant.
How do you figure out which one is actually telling the truth?
Do you have a defined source of truth, or do you usually investigate the discrepancy manually?
And how do you tell whether it's actual drift, stale information, or something that failed during deployment?
https://redd.it/1vk7lk2
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
Weekly Self Promotion Thread
Hey r/devops, welcome to our weekly self-promotion thread!
Feel free to use this thread to promote any projects, ideas, or any repos you're wanting to share. Please keep in mind that we ask you to stay friendly, civil, and adhere to the subreddit rules!
https://redd.it/1vkd20a
@r_devops
Hey r/devops, welcome to our weekly self-promotion thread!
Feel free to use this thread to promote any projects, ideas, or any repos you're wanting to share. Please keep in mind that we ask you to stay friendly, civil, and adhere to the subreddit rules!
https://redd.it/1vkd20a
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
Communication with non-technical people
Hi. I have been working in the IT field for about 15 years now and am constantly faced with the problem of communicating with non-technical people such as managers of various levels, etc. I constantly have to fend off all sorts of idiotic ideas that management is trying to impose on me. As a technician, I can make a diagram, a presentation, and write program code, but for non-technical people it all sounds like spells and Harry Potter. I have seen this problem in different companies regardless of the size of the company and in which country it is located.
My question is, are there books or online courses that simply explain how to communicate your message to non-technical officials?
P.S. I'm just tired of doing pointless work just because I can't explain to management that it doesn't work that way and there are better ways to complete the task.
https://redd.it/1vkegda
@r_devops
Hi. I have been working in the IT field for about 15 years now and am constantly faced with the problem of communicating with non-technical people such as managers of various levels, etc. I constantly have to fend off all sorts of idiotic ideas that management is trying to impose on me. As a technician, I can make a diagram, a presentation, and write program code, but for non-technical people it all sounds like spells and Harry Potter. I have seen this problem in different companies regardless of the size of the company and in which country it is located.
My question is, are there books or online courses that simply explain how to communicate your message to non-technical officials?
P.S. I'm just tired of doing pointless work just because I can't explain to management that it doesn't work that way and there are better ways to complete the task.
https://redd.it/1vkegda
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
AI agent shouldn't stop working when you close your laptop.Here's what actually fixed it
We've been running AI coding agents inside Kubernetes instead of on developer laptops, and the first thing that broke was the most obvious one: any long-running process died the moment someone closed their browser tab.
If you've only ever run short-lived jobs, this doesn't come up. But a coding agent doing a large refactor can run for hours, and losing it at hour three because someone's laptop went to sleep is miserable. The goal we ended up with was agents that keep working overnight, several in parallel, on cluster capacity the team is already paying for.
What didn't work:
Running the process as the container's main command. Fine until you want to attach, detach, or run a second thing in the same workspace. You get one process and no way to interact with it.
Streaming a raw terminal over a websocket. The process is still tied to the connection. Network blip, laptop sleep, tab close process gone. Also, scraping terminal output for structured status is painful and breaks constantly on ANSI escapes.
`kubectl exec` for everything. Same problem the process is a child of the exec session and dies with it. It also means every user needs exec permissions on the pod, which we didn't want.
What worked:
Decouple the process lifetime from the connection entirely.
The agent runs inside a
A per-user PVC mounted at the home directory. Pod restarts, chart upgrades, and rollbacks don't lose work. This matters more than expected agents accumulate a lot of state in dotfiles and caches.
A structured session layer instead of terminal scraping. The agent CLI runs headless and emits structured events; the web layer renders those as readable text plus expandable tool-call entries. Much more reliable than parsing a terminal, and it means you can actually see what the agent did rather than a wall of escape codes.
Because sessions are detached and addressable rather than tied to a viewer, a second agent can be started in the same workspace while the first is still running, and you can check on either one later from a different device without disturbing it.
On the multi-tenancy side, since each user gets their own workspace:
Namespace per user, with its own service account and resource limits. Simple and it maps cleanly onto RBAC.
NetworkPolicy restricting ingress to the platform's own ingress layer. Also and this is the one people forget block egress to the cloud metadata endpoint (169.254.169.254). An agent that can reach node metadata can potentially pull cloud credentials. If you're running any kind of agent or untrusted code in-cluster, check this today.
Short-lived tokens issued by a sidecar rather than mounting long-lived signing keys into the workspace container. The agent container never holds the sensitive key material.
Ingress + cert per user, so each workspace has its own URL and its own OAuth binding. Only that user can reach their own workspace.
Workspace config committed to git, so provisioning is reproducible and auditable rather than living in someone's shell history.
The practical upshot of doing it in-cluster is that source,
The whole thing ends up as one Helm chart: shared ingress/OAuth/cert infrastructure, plus a workspace per developer with the editor, terminal and agent CLIs already in the image.
The honest tradeoff: namespace isolation is not microVM isolation. If you're running genuinely untrusted code from strangers, this is not the model you want you want Firecracker or Kata. For a team's own developers and their agents, namespaces
We've been running AI coding agents inside Kubernetes instead of on developer laptops, and the first thing that broke was the most obvious one: any long-running process died the moment someone closed their browser tab.
If you've only ever run short-lived jobs, this doesn't come up. But a coding agent doing a large refactor can run for hours, and losing it at hour three because someone's laptop went to sleep is miserable. The goal we ended up with was agents that keep working overnight, several in parallel, on cluster capacity the team is already paying for.
What didn't work:
Running the process as the container's main command. Fine until you want to attach, detach, or run a second thing in the same workspace. You get one process and no way to interact with it.
Streaming a raw terminal over a websocket. The process is still tied to the connection. Network blip, laptop sleep, tab close process gone. Also, scraping terminal output for structured status is painful and breaks constantly on ANSI escapes.
`kubectl exec` for everything. Same problem the process is a child of the exec session and dies with it. It also means every user needs exec permissions on the pod, which we didn't want.
What worked:
Decouple the process lifetime from the connection entirely.
The agent runs inside a
tmux session in the pod, started detached. The web layer attaches to tmux rather than owning the process. Disconnect, reconnect, connect from a different device the session keeps running because nothing about it depends on the viewer.A per-user PVC mounted at the home directory. Pod restarts, chart upgrades, and rollbacks don't lose work. This matters more than expected agents accumulate a lot of state in dotfiles and caches.
A structured session layer instead of terminal scraping. The agent CLI runs headless and emits structured events; the web layer renders those as readable text plus expandable tool-call entries. Much more reliable than parsing a terminal, and it means you can actually see what the agent did rather than a wall of escape codes.
Because sessions are detached and addressable rather than tied to a viewer, a second agent can be started in the same workspace while the first is still running, and you can check on either one later from a different device without disturbing it.
On the multi-tenancy side, since each user gets their own workspace:
Namespace per user, with its own service account and resource limits. Simple and it maps cleanly onto RBAC.
NetworkPolicy restricting ingress to the platform's own ingress layer. Also and this is the one people forget block egress to the cloud metadata endpoint (169.254.169.254). An agent that can reach node metadata can potentially pull cloud credentials. If you're running any kind of agent or untrusted code in-cluster, check this today.
Short-lived tokens issued by a sidecar rather than mounting long-lived signing keys into the workspace container. The agent container never holds the sensitive key material.
Ingress + cert per user, so each workspace has its own URL and its own OAuth binding. Only that user can reach their own workspace.
Workspace config committed to git, so provisioning is reproducible and auditable rather than living in someone's shell history.
The practical upshot of doing it in-cluster is that source,
.env files, and model API calls stay inside the same perimeter as everything else you run there's no third-party environment holding the code while the agent works on it.The whole thing ends up as one Helm chart: shared ingress/OAuth/cert infrastructure, plus a workspace per developer with the editor, terminal and agent CLIs already in the image.
The honest tradeoff: namespace isolation is not microVM isolation. If you're running genuinely untrusted code from strangers, this is not the model you want you want Firecracker or Kata. For a team's own developers and their agents, namespaces
plus network policy plus scoped credentials has been a reasonable place to land.
Happy to go deeper on any of this if useful.
Full disclosure -I work on KubeCoder, the open-source project this comes out of (MIT, one Helm chart).
https://redd.it/1vkkmiu
@r_devops
Happy to go deeper on any of this if useful.
Full disclosure -I work on KubeCoder, the open-source project this comes out of (MIT, one Helm chart).
https://redd.it/1vkkmiu
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
Adapting to AI tooling in DevOps
My company is making a hard shift towards AI and I'm struggling. I'm tasked with something I have a small amount of knowledge about, but not enough to fully implement. Before AI, my approach to challenges like this would be to iterate on it, work through the problems, and learn what's required. Using Claude has just been a terrible experience for me, and I'm wondering if I'm the problem, my approach is the problem, or if this is just what we're all doing now.
I explained what I wanted (essentially a DB migration pipeline from RDS -> k8s pod) and claude barfed out about 10 shell scripts and a handful of pod templates. Everything had long, meandering comments that made very little sense. Is my job now to just start running this code and feeding pipeline errors back into claude and not worrying about it?
I started to pick apart the comments, ask questions, and update with my own comments, with the goal of being able to understand the process in detail. In doing this, I found a bunch of things that just didn't make sense or weren't optimal. When I ask the AI agent about it, it says I'm right and generates a bunch more stuff that may or may not make sense. Interacting with it is making me feel like a crazy person. I hate the way it presents information back to me. It's not succinct, it pulls in context that is of negligible value and just muddies the waters, and it's been very frustrating and existentially upsetting.
I'm willing to hear that I'm using the wrong model, or that I didn't spend enough time on my .md files and skills, but I'm also wondering if this is a normal experience, or if my approach is just dated, and I need to get over my personal values about understanding what I'm generating and giving to customers? I'm not so-much asking about the specific task at hand, just about adapting and having realistic expectations and reducing friction. I'm also very happy to hear about people's struggles.
https://redd.it/1vklxud
@r_devops
My company is making a hard shift towards AI and I'm struggling. I'm tasked with something I have a small amount of knowledge about, but not enough to fully implement. Before AI, my approach to challenges like this would be to iterate on it, work through the problems, and learn what's required. Using Claude has just been a terrible experience for me, and I'm wondering if I'm the problem, my approach is the problem, or if this is just what we're all doing now.
I explained what I wanted (essentially a DB migration pipeline from RDS -> k8s pod) and claude barfed out about 10 shell scripts and a handful of pod templates. Everything had long, meandering comments that made very little sense. Is my job now to just start running this code and feeding pipeline errors back into claude and not worrying about it?
I started to pick apart the comments, ask questions, and update with my own comments, with the goal of being able to understand the process in detail. In doing this, I found a bunch of things that just didn't make sense or weren't optimal. When I ask the AI agent about it, it says I'm right and generates a bunch more stuff that may or may not make sense. Interacting with it is making me feel like a crazy person. I hate the way it presents information back to me. It's not succinct, it pulls in context that is of negligible value and just muddies the waters, and it's been very frustrating and existentially upsetting.
I'm willing to hear that I'm using the wrong model, or that I didn't spend enough time on my .md files and skills, but I'm also wondering if this is a normal experience, or if my approach is just dated, and I need to get over my personal values about understanding what I'm generating and giving to customers? I'm not so-much asking about the specific task at hand, just about adapting and having realistic expectations and reducing friction. I'm also very happy to hear about people's struggles.
https://redd.it/1vklxud
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
Any devops from Perth here?
Hi there I have been working as a DevOps for past 5 years and I recently moved to Perth so I am finding harder here… moreover I am feeling like people still don’t understand DevOps what really is DevOps we can catch up so Perth DevOps hmu..
https://redd.it/1vl14gc
@r_devops
Hi there I have been working as a DevOps for past 5 years and I recently moved to Perth so I am finding harder here… moreover I am feeling like people still don’t understand DevOps what really is DevOps we can catch up so Perth DevOps hmu..
https://redd.it/1vl14gc
@r_devops
Reddit
From the devops community on Reddit
Explore this post and more from the devops community
Sydney DevOps Meetup: AI Agents and Open Source Developer Platforms on Kubernetes
Sydney DevOps folks,
If you're working with DevOps, Kubernetes, SRE, platform engineering, or AI infrastructure, CNCF Cloud Native Sydney is hosting a meetup on August 19 around two open source projects.
The session will cover:
kagent — a Kubernetes-native framework for building, deploying, and managing AI agents, including areas such as MCP integration, observability, security, and agent workflows.
GitHub: https://github.com/kagent-dev/kagent
OpenChoreo — an open source developer platform for Kubernetes that brings together platform abstractions, CI/CD, GitOps, observability, Backstage, and developer self-service.
GitHub: https://github.com/openchoreo/openchoreo
The discussions should be especially relevant if you're interested in how DevOps and platform engineering workflows are evolving around Kubernetes and AI.
Location: Cuscal Limited, Barangaroo, Sydney
Date: Wednesday, August 19
Time: 5:30 PM – 8:30 PM AEST
The event is free and includes technical sessions, networking, food and drinks, and Q&A with the maintainers.
RSVP: https://www.meetup.com/cncf-sydney/events/316052564/
If you're around Sydney and working in DevOps or cloud native, come join us.
See you there!
https://redd.it/1vl8akn
@r_devops
Sydney DevOps folks,
If you're working with DevOps, Kubernetes, SRE, platform engineering, or AI infrastructure, CNCF Cloud Native Sydney is hosting a meetup on August 19 around two open source projects.
The session will cover:
kagent — a Kubernetes-native framework for building, deploying, and managing AI agents, including areas such as MCP integration, observability, security, and agent workflows.
GitHub: https://github.com/kagent-dev/kagent
OpenChoreo — an open source developer platform for Kubernetes that brings together platform abstractions, CI/CD, GitOps, observability, Backstage, and developer self-service.
GitHub: https://github.com/openchoreo/openchoreo
The discussions should be especially relevant if you're interested in how DevOps and platform engineering workflows are evolving around Kubernetes and AI.
Location: Cuscal Limited, Barangaroo, Sydney
Date: Wednesday, August 19
Time: 5:30 PM – 8:30 PM AEST
The event is free and includes technical sessions, networking, food and drinks, and Q&A with the maintainers.
RSVP: https://www.meetup.com/cncf-sydney/events/316052564/
If you're around Sydney and working in DevOps or cloud native, come join us.
See you there!
https://redd.it/1vl8akn
@r_devops
GitHub
GitHub - kagent-dev/kagent: Cloud Native Agentic AI | Discord: https://bit.ly/kagentdiscord
Cloud Native Agentic AI | Discord: https://bit.ly/kagentdiscord - kagent-dev/kagent