Need advice: Should I mention my previous 1 year of experience when applying for DevOps roles?

Hi everyone, I’m Satish Arya from India.
I graduated in 2024 and got placed as a Graduate Engineer Trainee (GET) in an industry. I worked there for around one year, from September 2024 to October 2025, and resigned due to health reasons.
My previous role was completely related to core engineering, mainly PLC, DCS, instrumentation, and plant operations.
It was not related to IT, DevOps, cloud, or software.

After leaving that job, I decided to switch my career to DevOps. I’m currently learning DevOps and have covered topics like AWS, Linux, Git, Terraform, Ansible, Docker, Jenkins, and Kubernetes.

My main doubt is: Since I’m applying for DevOps roles, should I mention my previous 1 year of experience on my resume, even though it is not related to DevOps?

Will mentioning it help me in the current job market, or would it be better to apply as a fresher and focus only on my DevOps skills and projects?

Also, how should I explain this career transition during interviews?

I would really appreciate advice from people who have made a similar career switch or are currently working in DevOps.

Thank you!

https://redd.it/1vhtjlc
@r_devops

How to effectively use RDS with serverless backend for db migrations?

I'm using AWS SAM to provision API Gateway, Lambdas, and RDS. I want to know how I can do database migrations easily without having to keep up an EC2 instance just for the purpose of connecting to the RDS db and running db migrations?

I wanted to use something like alembic so that most of the migration stuff is automated but ig I can't really use that.

https://redd.it/1vhsvca
@r_devops

How do you guys manage backups of servers?

I am currently using restic to push backups from each server every hour to the R2 bucket.

One thing that bothers me is that in case the server is compromised, the restic bucket is also in danger as it holds r2 token (limited to bucket + object read & write) and restic repo password. The attacker can basically `restic forget` and backups are gone from R2.

I am currently exploring restic's rest-server with append-only option. Although I'm not sure if that'll solve what I want. AI suggested it so I'm exploring that.

I'm thinking from first principles to decide on a backup strategy. Would love to know yours.

https://redd.it/1vhvnf3
@r_devops

NPM Supply Chain Compromise | ChainDrop
https://www.microsoft.com/en-us/security/blog/2026/08/04/chaindrop-supply-chain-compromise-anatomy-self-propagating-worm/?utm_source=chatgpt.com

https://redd.it/1vhv5tm
@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.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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 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