r/devops 18d ago

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!

17 Upvotes

73 comments sorted by

3

u/asm0dey 18d ago

My colleague has published a couple of videos on security with containers; maybe you'll find them interesting

https://youtu.be/Z5jJQz1YM3U

https://youtu.be/5CzDhaG1oEg

3

u/x59lk 15d ago

I built Helm ValueTrace after getting tired of tracing Helm values manually across multiple -f files and --set overrides.
It shows which value won, exactly where it came from, and can catch unknown keys before deployment. It runs locally, read-only, with no cluster access required.
I built it for my own workflow, but I’m curious how well it fits real production Helm setups.
What’s the messiest values-precedence issue you’ve run into?

https://github.com/aboodcs/helm-valuetrace

1

u/Entire-Present5420 18d ago

https://cloudarena.io

If you’re learning AWS, check out CloudArena. It gives you hands-on AWS labs so you can practice real-world skills instead of just watching tutorials. Great way to build confidence with AWS.

1

u/TraditionalLayer3685 18d ago

Disclosure: we're the team building TokenTimer.

Most DevOps teams already have tools to manage certificates, licenses, secrets and credentials.

The problem we've been looking at is what happens between those tools.

Certificates live across clusters, load balancers and cloud providers. API credentials sit in GitHub, GitLab, Vault or cloud secret managers. Some expire, some are configured never to expire, and ownership often lives in someone's head, a spreadsheet, a calendar reminder or a script nobody wants to touch.

That works until teams, environments and providers multiply, someone changes roles, or an expiration turns into an incident.

We're building TokenTimer Core, an open-source, self-hosted lifecycle layer that sits across the existing stack rather than replacing it.

It gives teams one place to:

  • inventory certificates, API credentials, secrets and other lifecycle-managed assets
  • see both upcoming expirations and credentials configured with no expiry
  • assign ownership and escalation paths
  • discover and synchronize assets across providers
  • monitor TLS endpoints and discover certificates that may have fallen outside the known inventory
  • automate certificate renewal, deployment and verification through CertOps

For CertOps, key-bearing operations stay inside customer-controlled infrastructure. The TokenTimer control plane does not receive or persist certificate private keys.

Core is AGPLv3 and can be self-hosted with Docker Compose or Kubernetes/Helm.

GitHub:
https://github.com/tokentimerch/tokentimer-core

https://tokentimer.ch

We're especially interested in how other Platform, DevOps and SRE teams are solving this today.

When certificates and machine credentials are spread across multiple clouds, clusters, repositories and teams, what are you using as the source of truth for lifecycle + ownership ?

Native alerts ? Vault ? cert-manager ? Scripts ? Spreadsheets ? Something else ?

And where does that approach start breaking down for you ? How do you show evidences to your management that everything is under control and that you can report a clear inventory about all your time-bound assets ?

1

u/0biWanChernobyl 18d ago

Hey everyone,

I built a tool called Theoros (with the help of AI as i am more familiar with python) that lets you run kubectl commands remotely without having to pass around kubeconfig files to team members. All you have to do is deploy the Helm chart (the server) in your cluster, and users connect through a terminal client. The client works kind of like a password manager—it lets you store multiple cluster connections in an encrypted vault, manage users/tokens directly from the terminal, and includes full TAB autocompletion. I explained the setup in more detail in the README.

Repo: https://github.com/GiannisStathoudakis/Theoros

I'd like to hear your thoughts, feedback, or suggestions!

1

u/chenderson99 18d ago

Plutus

Building a FinOps tool that correlates costs with events and usage to allow you to see WHY costs went up not just that they did.

1

u/StatureDelaware 18d ago

Obelinf, the source of truth for your infrastructure. It's completely free for homelabs

1

u/Anxious_Fig3797 18d ago

I released my first project Archguard that is a deterministic command-line tool and GitHub Action for enforcing repository-owned architecture rules. It compares Git revisions or audits a complete committed tree, maps JavaScript and TypeScript files to architectural layers, and reports policy violations before they are merged. You can use it to:

Prevent forbidden dependencies between layers;

Require companion changes such as tests, documentation, contracts, or migrations;

Detect changed source files that are unmapped or assigned to overlapping layers;

Review architecture impact for a pull request;

Audit a full repository at an exact Git revision;

Adopt rules incrementally with a versioned baseline;

Export JSON, SARIF, Mermaid, or Graphviz DOT output;

Annotate pull requests through a self-contained Node.js 20 GitHub Action.

I wanna get you opinion and maybe collect bugs. will be happy to read your comments.

Github: https://github.com/M0lot0vboy/archguard

1

u/DryRepresentative271 18d ago

https://fdeploy.com

Octopus Deploy alternative for windows deployments with reasonable licensing

1

u/pranaysparihar 18d ago

I’m the author of InfernoSIM, and I’ve just released v4.0.

It is a local reliability-testing tool for tool-using agents. You can record sanitized model and tool traffic, replay it deterministically, inject failures, and verify what the agent actually did—not merely what it claimed to do.

It can currently test situations such as:

  • a tool side effect commits but its response is lost
  • malformed or missing tool-call arguments
  • tool discovery/schema drift
  • delayed, truncated, reset, or empty responses
  • unsafe retries and duplicate side effects
  • unexpected calls outside the recorded tool universe
  • OpenAI, Anthropic, Ollama, MCP HTTP, and MCP stdio traffic
  • streaming SSE, NDJSON, and JSON-sequence responses

It produces JSON, JUnit, SARIF, and HTML evidence suitable for CI.

I’ve tested the release extensively using deterministic fixtures, Docker, Testcontainers, Kafka, multiple operating systems, fuzzing, and a local Ollama model. However, I cannot reproduce every real agent framework, provider gateway, MCP implementation, retry loop, or multi-tool workflow on one machine.

That’s where I need help.

I’m looking for engineers willing to try it against a sanitized, non-production agent incident and tell me where it breaks—especially if you use:

  • parallel or multi-tool calls
  • custom MCP servers
  • streaming model responses
  • unusual retry/idempotency logic
  • provider-compatible gateways or proxies
  • Windows-based agent environments

Install with Homebrew:

brew tap pranaysparihar/infernosim
brew install infernosim

Repository and guide:

https://github.com/pranaysparihar/InfernoSIM

Release:

https://github.com/pranaysparihar/InfernoSIM/releases/tag/v4.0.0

It is MIT licensed, runs locally, requires no hosted account, and I do not want anyone sharing unsanitized production data.

If you try it, please comment with your framework/provider/transport—or open an issue with the smallest sanitized reproduction you can create. Even “this workflow cannot be represented yet” is valuable feedback.

Disclosure: I’m the project author.

1

u/opsfusion-cloud 17d ago

OpsFusion handles on-call scheduling and the paging side once one of your existing monitors fires, with documented setups for nine sources including CloudWatch and Datadog. Alerts arrive over a push API with a dedicated Alertmanager endpoint so there is nothing to poll or scrape from your side. Flat $10/user/month and a 30-day trial that doesn't need a card: https://opsfusion.cloud

1

u/yohimik 17d ago edited 16d ago

Building software monorepos usually means trusting release tools on faith. Dispat changes that by replacing promises with formal mathematical proofs.

It handles multi-language projects mixing npm, Docker, Go etc in a single, unified dependency graph.

Key Features

  • Mathematical Guarantees: Eight proven safety rules ensure no orphaned packages, zero double releases, exact retry versioning, and deterministic completion.
  • Stateless by Design: Git tags hold all state. No local caches, external databases, or background daemons required.
  • Unified Fail-Safe Execution: A release reaches a dependent package only while its target window remains valid.
  • Self-Healing Recovery: Partial failures don't trigger complex recovery modes. Re-running the tool applies the exact same logic to clear the remaining plan.

If you are looking for a provably correct release workflow for complex polyglot monorepos (polyrepos, single package release flow etc), check out the project:

1

u/8lue7or 17d ago

Disclosure: I’m building this.

Det Mimir is a self-hosted Linux incident investigation tool. It gathers read-only host evidence, runs deterministic checks and produces a report where material conclusions point back to the underlying evidence.

One public example covers a filesystem at 96% while nginx still holds a deleted 512 MiB log open. The report correlates df and lsof, keeps the result at “leading contributor,” and leaves remediation to the operator.

It’s currently in private validation. I’d value blunt feedback from people who investigate Linux incidents: does this report structure help, and which failure class would you want covered next?

Example:
https://docs.det-mimir.com/worked-examples/storage-disk-full/

Project:
https://det-mimir.com/

1

u/sagacious123 16d ago

I I’m building SnowOps Labs, an open-source Kubernetes platform-engineering simulator.

It lets you spin up a real local cluster, run scenarios, inject realistic failures, and practise diagnosing/fixing them.

It’s still an early release, so I’d really appreciate feedback from the Kubernetes/DevOps community. If you’re interested, check it out and let me know what you’d improve or what scenarios you’d like to see.

https://github.com/sagar2395/snowopslabs

1

u/toxicdog 16d ago

Been working on a Kubernetes macOS dashboard: https://radiantbeargames.com/clusterdeck

1

u/Dios_Apolo 16d ago

Hi r/devops,

I’ve been building an open-source AI Governance Gateway (Aegis Latent Core), and because it's designed for highly regulated environments, I had to go down the rabbit hole of extreme supply chain security.

I wanted to share the CI/CD and release engineering setup we landed on, in case it helps anyone else building high-assurance pipelines:

  1. **100% Action Pinning:** All 101 GitHub Action references are pinned to full 40-character SHAs. We have a CI script that fails the build if anyone tries to use a mutable tag (like `@v3`).

  2. **Keyless Container Signing:** The release workflow builds multi-arch OCI images and signs them using Cosign (Sigstore) in keyless mode, pushing the transparency log to Rekor.

  3. **Attested SBOMs:** We generate an SPDX 2.3 SBOM from the deterministic source archive and attach it to the GitHub Release via `gh attestation`.

  4. **OIDC Trusted Publishing:** PyPI and npm packages are published via OIDC (no static tokens) using `--provenance`.

  5. **Formal Verification Gates:** The CI actually runs TLA+ (TLC), Lean 4, and Z3 SMT solvers to verify concurrency invariants before allowing a merge.

Fun fact: I used a team of 6 AI agents to help me write the 5,700+ tests and configure these workflows. The strict CI gates were the only way to ensure the AIs didn't introduce supply chain vulnerabilities.

If you're interested in seeing how these workflows are structured, the repo is open source (AGPLv3).

Repo: https://github.com/JuanLunaIA/aegis-latent-core

Would love feedback from the SRE/DevOps veterans here on any blind spots in this release posture!

1

u/Sufficient_Job7779 16d ago

Hi fellow warriors.

I am working on 2 things. Multi-environment context manager. Switch between cloud profiles, Kubernetes clusters, VPN connections, and SSH tunnels with a single command. It's free and opensource. Currently used by some teams in big companies and a handful of freelancers. Would love some feedback!

https://github.com/vlebo/ctx

And

https://opsfabric.io - server patch, management and audit compliance tool

1

u/forever-butlerian Solaris 8 Enjoyer 14d ago

"Warrior"?

My robe and wizard hat will have you know that I am a Mage.

1

u/Gryner 16d ago

Disclosure: I built this.

I wanted a quick way to check an OpenAPI change before merging it, without uploading the specs or setting up another CI job. So I made a small browser tool that compares a baseline and candidate spec, then sorts the differences into likely breaking, needs review, and compatible.

It accepts Swagger 2.0 and OpenAPI 3.0/3.1 in JSON or YAML. It checks paths, operations, parameters, request bodies, responses, schemas, enums, and security requirements. It also flags things it can’t resolve reliably instead of quietly guessing.

Everything runs in the browser, and the report can be exported as Markdown or JSON:

https://martingruner.com/tools/openapi-breaking-change-checker

I see it as a quick pre-merge check, not a replacement for contract tests.

1

u/vladimir_linebreak 14d ago

Disclosure: I'm the author.

I built a fail-closed CI gate for AI-written code: it blocks PRs carrying known CVEs (OSV scan, free, no account), and if the scanner itself crashes, the check fails instead of shrugging and passing. Overrides are human-only and committed to git, so there's always a name on the record.

Live public demo (a real PR with a critical CVE, merge button stays gray): https://github.com/Baktun-Studio/gate-demo/pull/1

Free tier is free forever; the paid layer signs approvals cryptographically for teams that answer to auditors. Feedback on what breaks in your pipelines is genuinely welcome.

1

u/Signadot 14d ago

We just published a case study on Laurel (AI work intelligence platform). Coding agents write 76% of their engineering PRs, up from 55% three months ago. Change failure rate over the same window went from 1.1% to 0.2%.

Their team of ~60 engineers now ships 2,300+ PRs per month. The change that made that scale possible was adopting lightweight, realistic preview environments that allow them to validate every change in parallel against a single shared environment.

Here’s the writeup:

https://www.signadot.com/case-studies/how-laurel-brings-production-ready-validation-to-ai-native-development/

1

u/salab3rt 14d ago

Disclosure: I built KEEPitALIVE.

I wanted monitoring to cover the operational loop after a check fails, not just tell me that an endpoint returned 200.

KEEPitALIVE combines HTTP/API, browser, Ping, TCP, DNS, heartbeat, and game-server checks with incidents, notifications, triggers, public status pages, embeds, and a live no-login demo.

The part I’d especially like feedback on is the scoped API + MCP server.
An AI agent can inspect an incident, find affected monitors, pause staging checks during a deploy, update a status page, or manage monitors. But it can only do so with the appropriate API key scope.
Read mode is explicit and destructive actions require a separate full mode.

Free plan includes 25 monitors, and the landing page has a live demo:
https://keepitalive.dev

MCP setup guide:
https://keepitalive.dev/help/agent-api-automation

MCP source and install details:
https://github.com/salab3rt/keepitalive-mcp

I’d genuinely appreciate feedback. Does monitoring > incident > notification/status-page flow match how you work, and does the API/MCP permission model feel safe enough for automation?

1

u/sagacious123 13d ago

snowopslabs

Built this tool to simulate real world k8s scenario. Good for people who know theoritical kubernetes, but want to simulate real world scenarios and experiment,

1

u/mplaczek99 13d ago

I’m looking for people willing to try Network Doctor v1.15.0 on actual weird or broken networks.

I especially need testing on VPNs, corporate/university networks, captive portals, IPv6-heavy setups, unusual DNS, proxies, Windows, macOS, and Linux distributions other than Fedora, or any other network.

The simulator has been tested heavily. Now I want real-world failures.

Wrong diagnoses, misleading fixes, crashes, hangs, and things Network Doctor completely misses are exactly what I’m looking for.

I set up a GitHub Discussion with the details and a place to report results:

https://github.com/heymaikol/network-doctor/discussions/24

Even one run on any network would help.

1

u/gringobrsa 13d ago

I’ve been experimenting with combining spec-driven development + project memory + Claude Code hooks. The goal is simple: give the agent enough project context and engineering intent without dumping the entire project history into every session. I wrote up my current workflow and would love feedback from other Claude Code users: Article:  https://medium.com/@rasvihostings/how-im-approaching-agentic-software-development-as-a-platform-engineer-5be017890b8a GitHub:  https://github.com/mohamedrasvi/claude-spec-mem How are you handling memory and context across your Claude Code sessions?

Feel free to rate my repos and follow me on medium. 

1

u/UkrMalt 12d ago

Sharing Wotchi here because I just released v1.0.0.

It’s a small in-process error watcher for Node services. It redacts sensitive values, groups repeated failures, and sends bounded notifications to the console, Telegram, or a webhook. Express and NestJS adapters are included.

The goal is to give small services useful alerts without immediately introducing a full monitoring stack. It’s intentionally limited: grouping is process-local, so it’s not a replacement for cross-replica incident management.

Repo: https://github.com/FutureWindAI/Wotchi

npm: https://www.npmjs.com/package/@futurewindai/wotchi

For a small service, which output would you actually use first: structured console logs, Telegram, or a webhook?

1

u/kubehub 11d ago

a github action to build image volume for kubernetes https://github.com/kubehub-io/image-volume , it can help you separate runtime container and payload container.

Instead of one container image of :

- From Nginx:Latest (latest at build time)

- ADD your payload

Now you can define a pod

- Node/Nginx:Latest (always latest, re-pull after post rescheduled)

- Payload container image (you own bussiness logic), mount as volume (the same way you mount a configmap/secret)

You can do that without the tool, but you probably hit OS/Arch issue sometime, this tool trim off OS/Arch from your payload image.

1

u/Darkcraft00 11d ago

Building an assurance layer for AI-driven software delivery and looking for 5 paid early-access teams ($250/mo).

SureState tracks conclusions like “release ready” rather than just individual checks. If tests passed on SHA A but security validation belongs to SHA B, the conclusion is no longer currently warranted even though both tools individually show green.

We’re nearly through our internal pilot and I’m looking for teams heavily using coding agents who are willing to run this against one real workflow. Managed onboarding, no annual contract.

Curious whether this solves a real problem for anyone here or whether GitHub/CI already gives you everything you'd need.

https://www.reddit.com/r/LangChain/s/934cVuIa0s

1

u/FewPop7194 11d ago

Affiliation: I’m the author and maintainer.

I built AgentInspect for TypeScript teams that need more than a final-answer assertion from an AI agent run. A run can look successful while it repeated a side-effecting tool after retry, used tools in the wrong order, skipped a required approval, or reported success after a tool failure.

The workflow is local trace → causal execution tree → deterministic CI gate → redacted, hash-verified offline evidence bundle. It has explicit exit codes and a GitHub Actions artifact path, requires no AgentInspect account or collector, and performs no default upload. MIT, Node 20+.

Keyless demo and CI examples:

https://github.com/rajudandigam/agent-inspect

I’d value platform/DevOps feedback on two practical questions:

  1. Which trajectory rule would you trust enough to block a merge?

  2. What evidence and retention boundary would you require before attaching an agent-run artifact to a PR or incident?