As i always wanted to help and teach people, I wanted to do my part by teaching, by the way I'm working as a devops enginner.

FYI without money , for the first time I'm gonna do what I wanted to , let me know which topic has to be picked and interested people ping the comments.

I want to start the basics on kubernetes cuz I like kubernetes I want to start with this. Thank you. Not sure if this post will be retained or delayed.

Disclosure: I build Control Cloud, the tool mentioned halfway down. Everything else here is what I learned building it.

Context: I run infrastructure that is split across two public clouds and an on-prem rack, the way most mid-size shops end up after a couple of vendor decisions nobody wants to revisit.

Every cross-cloud incident was the same dance: provider A's console in tab 1, provider B's portal in tab 2 (after the conditional-access prompt), an SSH session into the on-prem box, and the monitoring tool to guess where the traffic went. The consoles don't see each other. A subnet that exists on one side but is routed to nothing on the other is invisible until production traffic hits it.

So over the last six months I built Control Cloud: a single live topology that polls every provider over its API and renders resources, networks and dependencies as one graph, with live status and cross-provider edges, and start/stop/reboot from the same surface.

Lessons that cost me the most:

1. Polling cadence has to follow how the cloud answers, not a round number. A full inventory crawl on one provider takes far longer than a UI should wait. We split it: the backend polls each region in its own goroutine behind a semaphore (unbounded concurrency = rate limits and context deadline exceeded), every region is published the moment it lands instead of waiting for all of them, and a file cache serves the last known state at startup so a restart isn't a blank screen. The UI refreshes every 10 s.

2. Dragged nodes must stay where the user put them. Auto-layout from scratch on every poll looks great in demos and is unusable in practice: people move nodes to match their mental model. A refresh updates status, not positions.

3. Provider parity is the whole point. If one provider shows nested scopes with subnets, every other provider has to show the same shape, even when its own model is flat. "The same concept renders differently per provider" is exactly what people are trying to escape. We keep a rules file derived from the code (the shared state helpers, the per-provider collectors, the navigator) and diff every change against it.

4. Status colors have to be honest. Every provider has its own vocabulary for "healthy" (RUNNING, AVAILABLE, Succeeded, Ready, Attached…). Inlining a regex per call site is how we shipped a red edge on a healthy cluster. One shared helper, one vocabulary per provider, and anything unconfirmed renders as unknown, never as a made-up warning.

5. Validation against live state paid back more than the canvas. Once everything is in one graph you can check a planned change against what is running: credentials with reach over the right scope, network (missing network or subnet = error; no NAT, no internet egress, no firewall = warning), on-prem hosts reachable, the dependencies of the template you picked. Anything it can't confirm comes back as informational, not as a green tick.

Stack: Go backend polling each provider SDK in parallel, React + Vite frontend, file-based cache, Postgres (Supabase) for orgs, audit log and schedules. Read-only API access with credentials you grant, encrypted with a managed KMS; no agents in your VMs. The Terraform it generates is committed to your repo and runs under your pipeline.

Live at https://controlcloud.dev/en if you want to poke around (free plan: 1 operator + 1 provider). Docs at /en/docs.

Happy to go deeper on:

• Why not the observability platform you already pay for (great at its thing; this answers a different question)
• The parity work: every provider added meant refactoring the first one
• Where the polling still doesn't scale (many regions per provider gets hairy)

Anyone here running their own version of this? What did you try first?

I need set of scenario based interview questions asked in interviews related to devops with topics like EKS, AWS architecture , production incidents

Any interviewer can asked based on his personal experience so just want reddit help to accumulate questions to prepare better and deep understanding of the tech.

Thanks in advance.

honestly i dont get why current multi-agent setups are built like this.

if you connect 4 or 5 mcp servers (github, postgres, filesystem, slack etc) you easily end up with 40-50+ tool schemas. right now the standard pattern in langchain or claude code is dumping all 4,000+ tokens of json schemas into the prompt on every single turn just so the llm can pick which function to run.

you end up paying token costs and waiting ~2 seconds of network latency just for what is basically an L7 routing lookup.

i spent the last few weeks testing if we can just decouple tool discovery completely from the llm using a local cpu vector mesh (all-MiniLM-L6-v2 + chromadb hnsw index) and a split execution daemon.

instead of embedding just the function name (which fails on synonyms), i combined the tool name, description, schema keys, and tags into a single profile vector. when a prompt comes in, it embeds the query on cpu and pulls the top match before ever touching the llm.

ran a cold-cache benchmark across 100,000 synthetic tool endpoints on my local machine (standard cpu, no gpu):

method top-1 acc avg latency p95 latency

---------------------------------------------------------------

naive keyword scan 38.1% 46.41 ms 57.60 ms

bm25 lexical index 40.4% 194.05 ms 247.25 ms

local vector mesh 70.7% 9.56 ms 11.44 ms

in-memory fast path n/a 0.082 ms 0.15 ms

We just published new research on using deception against AI attackers.

In controlled AWS tests, agents took up to 8× longer and cost 23× more per objective. With all nine techniques combined, Kimi, Qwen, DeepSeek and GPT-5.6 Cyber reached zero objectives across 40 runs.

We build a patch management product. Right now it uses Dynatrace to pull health signals from managed assets (things like whether a service or host is healthy before and after a patch is applied).

Before we commit further, I'd like to hear from people who use these tools every day. Which APM or monitoring tool does your team use (Dynatrace, Datadog, New Relic, AppDynamics, Elastic, Grafana/Prometheus, something else)?

I'm most curious about:

- How reliable the health and alerting data is in practice (false positives, gaps, lag)

- How comfortable your team is using it day to day

- How easy it was to integrate with other tools through its API

- Anything you regret or wish you'd known before choosing it

I'm not selling anything. I just want to understand what teams trust so we can support the right tools. Thanks in advance!

Hi everyone,

I’m a student in the early stages of a DevOps degree, and I have to complete an individual project within 5 months. My lecturer asked for a unique, new topic that is purely DevOps, not system engineering. I searched for a long time without luck, then used Perplexity to explore ideas and found one that my lecturer approved. He told me to start with a literature review and continue from there.

The topic is: I don't want to reveal it here, but I'll let you know when you are willing to help me.

Now that I’m starting, I’m honestly panicking. DevOps is new to me; the degree has only just begun, and many of the tools and terms are unfamiliar. I’m comfortable with practical work, but I’m worried about how much I need to learn in such a short time and whether I can finish on schedule.

I’d really appreciate help with:

1. How should I approach the literature review when I don’t know the terminology yet?
2. What core DevOps concepts and tools should I learn first (CI/CD, containers, IaC, etc.)?
3. Any tips for planning a 5-month project as a beginner?
4. Good free resources, communities, or books you’d recommend?

If you’ve been through something similar, I’d love to hear how you handled it. Thanks so much in advance!

I'm interested in Open Source Contribution and looking for recommendations for projects that are related to DevOps and Platform Engineering.

I'd like my contribution to be relevant to my everyday work.

I'm good with python, go, nodejs and typescript.

This will be my first contribution so, I'm also looking for something that's not so difficult to work on.

I'd appreciate any advice or recommendations

Both the braces and sprintf-js security advisories have been withdrawn, despite previously being marked as GitHub Reviewed.

braces: CVE-2026-93687 / GHSA-vfj7-8cjw-p6xm
sprintf-js: CVE-2026-97058 / GHSA-hp3w-g68c-fv3c

I understand that third-party security risks are a pressing concern. Last week was particularly rough, with incidents and critical vulnerabilities involving LiteLLM, PHP, intermediate CAs, Brotli, and more. Security teams everywhere have been scrambling to assess their exposure and mitigate potential risks.

However, these two widely used npm packages, commonly pulled in through linters, test frameworks, and other development tools, have once again caused unnecessary alarm across the ecosystem.

Both advisories have now been withdrawn, but not before triggering security alerts and forcing developers to investigate issues that turned out not to be practically exploitable.

How much can we trust automated dependency audits when even reviewed security advisories can turn out to be false positives?

More importantly, what should change in how vulnerability reports are vetted, published, and propagated to downstream security tools?

Hey guys, quick question for anyone in the AI or infrastructure space.

I was never really interested in running AI models on my homelab cluster, but this job offer looked too good to pass up.

I have a technical interview coming up soon for an SRE role on High Availability AI clusters, and honestly I have zero clue what to expect or what kind of questions they might throw at me.

The position is completely remote, focusing on monitoring, troubleshooting, and keeping things running via SSH without any hands-on access to physical hardware.

Core stack is mostly standard Linux, Docker, Kubernetes, and networking.

If anyone here works with HA AI infrastructure or went through a similar interview process, what do they actually ask about?

Do they stick to standard Linux and networking troubleshooting, or do they push hard on AI-specific tech like GPU drivers, Infiniband, NCCL, or CUDA failures?

Any heads up or real-world examples would be awesome. Thanks in advance!

Hello community,

I am really stressed about my cka exam. I have bought it but have not prepared yet. My goal is to give exam in december. I have udemy monthly subscription and thrive subscription for this year. I am watching mumshad course on udemy.

I have 4 years of experience as a devops engineer. Done ccna training and comptia security plus. I have a very good command on linux(ubuntu) because my career started with it.

But the uncertain and pressure of work is giving me hard time. I am also works as a consultant so have to give time on that as well. I get exhausted after work. I consumed half of the course with labs on udemy and kodekloud but having no experience of production kubernetes. I understand the concepts but still thinks something is missing. The last topic of admission controllers gave me hard time to consume.

Do you guys know anything like tips and tricks to pass this exam. Anyone studying or prepping for the same can also collaborate. Because it is better to clear the concepts.

Dont ignore this post.

Regards

Worried and stressed person

Edit: thankyou everyone for the kind advices. Maybe I have many sources that is why I overthink it. Because I switch from udemy to thrive to multiple youtube channels. I will stick to 1 course and complete it.

​

Hey everyone! I’m exploring ways to extend an existing internal production health-check bot that monitors systems checks whether the important pages loads or not and sends status updates to Microsoft Teams.

I’m looking for ideas beyond basic health checks, such as proactive alerts, log analysis, incident detection, automated troubleshooting, or AI-powered features.

What useful automations have you built around monitoring bots? Which ones have made the biggest difference in real-world scenarios?

Would love to hear your suggestions and experiences!

Got this email from them this morning. My understanding is you can't fully audit GitHub access through the API, which is how accounts were connected, so it's best to assume the worst. Most connected accounts gave full read and write access, so if true, this constitutes serious IP theft concerns.

I personally don't feel like they have been fully transparent with the breach. This was essentially a footnote and buried under a misleading statement "Review provider activity and audit logs; especially AI keys". It should be flashing and unambiguous "GitHub code is possibly compromised".

Furthmore, a simple, nonchalant "we're sorry" and that's it!? Not "we're deeply sorry that we messed up and we take full responsibility, it won't happen again and we are doing x, y, z for our customers..."

I'm switching away permanently. I highly recommend Fly instead, took 30 mins to migrate. Not sure what to do about to do about the IP theft though? I would expect legal action to come of this, possibly a Class Action Lawsuit regarding IP theft.

With Black October happening and all.

How do you all perform full automated tests after deployment? Using postsync hooks in argocd or use Argo events? Do you use ephemeral or static environments?

Reading the php2shell research, the bit that stuck with me was how AI helped turn longstanding bug into working exploit. The bugs was already there, getting them to work reliably was the difficult part.

That make “hard to exploits” feel like a shaky reason to leave something in the backlog. For people maintain production system, has this changed your patching schedule at all? We are still on php 7.4 and the last upgrade attempt broke half of our cron jobs, so i’m curious how other team handle an urgent patch when the upgrade itself need debugging

source: Wiz’s PHP2Shell research, published october 21

I’ve spent a while working in product/application security, and one thing always bugged me: most supply-chain tools scan dependencies after npm install or pip install has already run — by which point the install scripts have executed. The decision happens too late.

So I built DepGate, an open-source dependency gateway. It’s a single proxy + policy engine that sits in front of npm, PyPI, Maven, Go modules, NuGet, Cargo, Composer and RubyGems. Your devs and CI point their package managers at DepGate instead of the public registry. It fetches the package, checks it against a malware feed and your policies, and either serves it or returns a 403 naming the exact policy and reason.

What it does:

• Known malware never downloads — every request is checked against a synced feed of 200k+ malicious packages before any policy runs.
• Readable policies — block by CVSS/EPSS, license, release age, release type, OpenSSF Scorecard, or package name. One rule per policy, stated in a sentence.
• Monitor mode — run a new policy against real traffic first and see exactly what it would break before you enforce it.
• Dependency-confusion protection — internal names are served only from internal registries, never a public look-alike.
• Decision Ledger — every block is recorded with the reason and who asked, down to the CI job.
• Self-hosted, one Docker image (Postgres + Redis), runs air-gapped, and can sit in front of or behind Artifactory/Nexus.

It’s basically meant to be the open-source answer to the commercial “repository firewall” products, with a lot fewer moving parts. TypeScript end to end, MIT licensed.

Repo (quick start + docs): https://github.com/secmods/depgate

Still early and I’m actively building — would genuinely appreciate feedback, criticism of the approach, or feature requests. Heuristic detection of never-before-seen malware is on the roadmap. Happy to answer anything in the comments.

Hi All,

It has been my experience at a couple of different organizations that almost all engineering teams own their own CI/CD pipelines. So my question is how do you enforce or ensure that these teams are performing SAST or DAST (Snyk, Trivy, IaC, etc) on their pipelines? I read that Github has some capability of enforcement, but that doesn't seem like a sound solution. I am curious to understand this and if there is any good litereature on how mature organizations handle this please point me in the right direction.

This is my own personal research and drive to understand being a cloud security engineer.

TIA

Our QA team has years of jmeters scripts for our core apps, but running our own load generation infra is turning into a huge operational and expensive headache.

Every time we do a high concurrency run or need traffic spread out across different geographic regions, half our sprint is spent provisioning EC2 boxes, setting up slave nodes and dealing with network timeouts.

My team lead wants us to explore managed cloud platforms to take that maintenance off our backs. But part of our team is hesitant about moving everything over. Has anyone moved from a self hosted JMeters to a cloud solution? Does the saving in infra justify the subscription cost? And most importantly, were you able to keep your existing .jmx test assets or you had to rewrite everything from scratch?

Curious how this is going in practice, not how the vendor demos make it look.
When an alert fires, how much of the investigation does AI actually handle for you today (pulling the right logs and traces, correlating with deploys, narrowing down root cause)? Where does it fall over?
Also wondering if anyone's kept this inside their own environment, self-hosted models or anything private, rather than sending telemetry to a vendor's AI or a frontier API. Was that a requirement, or just not worth the effort?
I'm researching this space, not a pitch. It'd help if you mention your stack (Datadog, Grafana, other)
Thanks!

Disclosure: I work at Bonree, the company behind Bonree ONE, an AI observability platform. I’m asking about the general problem of choosing a platform, and I’m not trying to pitch ours.

AI agents are moving from chat interfaces into production workflows, and teams are now picking tools to observe them. Feature lists for AI agent observability platforms look alike, so I’ve been trying to write down questions that can actually be tested instead of ticked off.

Here is my current list.

1.  Does it trace at the session level? An agent conversation has several turns, each with model calls and tool calls. I want to open the whole conversation as one unit, not look at isolated requests.

2.  Which frameworks does it cover, and how deeply? Teams build agents with LangChain, LangGraph, low-code platforms such as Dify, and other frameworks such as OpenClaw. I care less about the length of the list than whether the frameworks my teams use are covered automatically, or only through manual work.

3.  Is the evidence separate from the reasoning? A read-only tool call with the same input should return the same data, while model output varies. If a platform records them separately, I can tell a data failure from a reasoning failure.

4.  Can it attribute token cost? By model, application, team, business line and time.

5.  How does it handle sensitive content? I want to choose per field whether to store, sample, redact or never store it.

6.  Can AI traces be linked to the services and infrastructure underneath? A slow answer is sometimes a database problem.

7.  If it offers AI agents for operations, what are the limits? What can the agents do alone, what needs approval, and is every step logged?

8.  What does the bill look like at my volume?

For the proof of concept, I’d instrument two agents built with different frameworks, replay three real incidents where an agent gave a wrong or slow answer, and measure how long it takes to find the cause in each tool.

A note on criterion 7: AI agent operations platforms, where agents diagnose incidents or inspect systems on observability data, are a newer category and the hardest to evaluate. We work on this at Bonree with Bonree ONE·Sage AI, so I would particularly like to hear how others test whether an operations agent is trustworthy.

Some things I’m still unsure about:

1.  Which of these criteria do you weight most heavily, and which do you ignore?

2.  How do you test “trustworthy” in practice, beyond reading a vendor’s description?

3.  Do you prefer one platform for AI and infrastructure, or a dedicated LLM tool next to your existing stack?

4.  What did your proof of concept reveal that the feature list did not?

Con las últimas alertas de seguridad sobre PHP, me dio curiosidad saber cómo están llevando esto en sus empresas.
¿Ya están migrando o siguen con el clásico “si funciona, no lo toques”?
Me pregunto cuántos todavía tienen servidores con PHP 5.4, 7.x o alguna reliquia que nadie se atreve a actualizar porque la aplicación depende de una librería que dejó de existir cuando todavía usábamos MSN Messenger.
Y lo mejor: ¿la empresa entendió la urgencia de actualizar o todavía estás explicándole al jefe por qué tener software sin soporte es una mala idea?
Tengo curiosidad por saber cómo está la situación en otras empresas:
¿Ya tienen un plan de migración?
¿Están peleando con aplicaciones legacy y dependencias imposibles?
¿Seguridad está presionando o nadie se ha enterado?
¿O eres el único que está preocupado mientras todo el mundo dice que no pasa nada?
Cuéntame tu experiencia. ¿Qué versión de PHP tienes en producción y qué tan complicado está siendo convencer a la empresa de actualizar?
Necesito saber si estamos todos en el mismo barco o si el mío ya tiene PHP 5.4 y está haciendo agua. 😂

I've been following the Railway situation since the outage started, and things have gotten pretty concerning.

I'm currently using Railway to host the backend of a small gaming marketplace I've been building. Like many developers, I initially thought this was another infrastructure outage affecting builds and deployments.

But on October 21, Railway published a security disclosure confirming something much more serious.

According to their statement, they detected anomalous activity involving systems responsible for storing customer environment variables.

Their investigation suggests an unauthorized third party may have accessed encrypted environment variables and, in some cases, obtained their decrypted contents.

That's a serious concern for anyone hosting production applications on Railway.

What Railway has disclosed so far

• Suspicious activity was detected in systems storing customer environment variables.
• An unauthorized third party may have accessed encrypted secrets and obtained some decrypted values.
• The impact may be limited to a subset of customers, although the investigation is ongoing.
• Railway is recommending that all customers rotate their stored credentials, including API keys and database credentials.
• Deployments have been paused during the investigation.
• Railway believes the incident may be connected to a broader campaign targeting platform companies and AI inference providers.
• Railway has also started automatically rotating its bucket credentials and resetting certain integration credentials.

As of the latest update I've seen, deployments remain paused.

My biggest concern is how developers are supposed to rotate production credentials during an outage like this.

Think about a small startup running its entire backend on Railway.

You might have PostgreSQL credentials, JWT secrets, payment API keys, SMTP credentials, webhook secrets, and other sensitive information stored as environment variables.

Now imagine being told that some of those credentials may have been exposed and that you should rotate everything immediately.

That's obviously the correct security recommendation.

But there's a problem.

If you revoke your current database credentials or payment API keys before your running backend can use the replacements, you risk breaking critical functionality.

And when deployments are paused, rolling out those changes becomes much more complicated.

At the same time, leaving potentially compromised credentials active is also risky.

For solo developers and small teams without dedicated infrastructure engineers, this is not a simple situation.

What I've personally done so far

I've reviewed my Railway account sessions, signed out older sessions, and inspected my existing environment-variable configuration.

Everything appears normal from my side.

But I understand that simply checking whether the variables still exist doesn't prove they weren't accessed.

An attacker could potentially copy credentials without modifying anything visible in the dashboard.

I haven't received confirmation that my particular project was affected, and I'm preparing to rotate my sensitive credentials carefully.

The bigger issue is trust in managed infrastructure.

One of the reasons developers use services like Railway is that they don't want to manage every part of their infrastructure manually.

We trust these platforms to handle deployment infrastructure and provide secure storage for sensitive configuration.

Of course, no platform can guarantee perfect security.

But when the infrastructure responsible for storing customer secrets is potentially compromised, the impact can extend far beyond the hosting provider itself.

A stolen database password could potentially allow unauthorized data access, depending on network restrictions and database permissions.

A stolen API key could allow unauthorized operations or unexpected charges.

A compromised authentication secret could potentially affect user sessions, depending on how the application implements authentication.

None of this automatically means these things happened to Railway customers. These are potential consequences of exposed credentials.

And that's exactly why the incident deserves serious attention.

There are still several questions I'd like Railway to answer.

1. What was the actual entry point used by the attacker?
2. How could encrypted environment variables potentially be decrypted?
3. Was this caused by compromised internal credentials, an infrastructure vulnerability, or something else?
4. How many customers or projects were actually affected?
5. Was there any evidence of attackers accessing customer databases directly?
6. What time period should developers investigate when reviewing suspicious activity?
7. What additional security measures will Railway introduce to prevent this from happening again?

I appreciate that Railway disclosed the incident and started providing recovery guidance.

But until the full scope is known, it's difficult for developers to understand their actual exposure.

I'm curious how other Railway users are handling this.

Have you already rotated all your production credentials?

Have you noticed any unusual database activity, suspicious API calls, or unexpected service charges?

Has Railway contacted you directly about your project being affected?

Are you waiting for deployments to resume before rotating certain credentials, or have you temporarily disabled critical functionality?

And probably the biggest question: Has this incident changed your trust in Railway, or do you still plan to keep your production applications there?

I'm not trying to spread panic or suggest that every Railway project has been compromised.

I'm sharing this because I'm running a real application on the platform, and I know other independent developers and small teams are in a similar position.

I'd like to hear how others are approaching the security risks and what precautions they're taking.

Hopefully, Railway publishes a detailed technical postmortem once the investigation is complete.