Secure Kubernetes platform for a regulated environment Production Kubernetes for regulated financ...Secure Kubernetes platform for a regulated environment Production Kubernetes for regulated financ...
The network for creativity
Join 1.25M professional creatives like you
Connect with clients, get discovered, and run your business 100% commission-free
Creatives on Contra have earned over $150M and we are just getting started
Secure Kubernetes platform for a regulated environment
Production Kubernetes for regulated finance, with scanning enforced in every pipeline before anything deploys.
Who it was for: A regulated financial services environment.
The problem. Production Kubernetes in regulated finance has to satisfy two audiences at once: engineers who need to ship, and auditors who need to see that nothing ships unchecked.
What I did. Provisioned clusters and supporting networking with Terraform so the platform is reproducible and reviewable. Designed the routing layer through a gateway and ingress controllers. Built reusable pipeline workflows with image, IaC and policy scanning embedded, so the security step isn't something a team can skip under deadline — it is the path to production.
The result. Every build is scanned before deploy, and control evidence is a by-product of the pipeline rather than a separate exercise.
Business banking is already complex. The product shouldn’t make it feel even harder.
That was the thinking behind Bankora.
Payments, invoices, cash flow, financial overview. These are things business teams deal with constantly, yet many banking products still bury simple actions under dense data, long paths, and complicated navigation.
So I started with the workflows, not the screens.
I looked at the tasks people need to complete most often, where unnecessary steps appear, and what information actually needs attention first.
From there, I built the experience around clearer priorities: key actions available quickly, predictable navigation, structured financial data, and modular UI that makes things like pending and overdue invoices easier to understand at a glance.
I also designed an interactive cash flow calculator to help users see where the business may be heading, not just what has already happened.
The goal wasn’t to make financial operations simpler than they really are.
It was to make interacting with them feel simpler.
Less searching. Less cognitive load. More confidence in what to do next.
And it was especially nice to see Bankora later featured by Contra.
Would you run a command without knowing what it could do?
A copied installation script. An automated workflow. A shell command suggested by AI.
Convenient? Yes. Worth checking before execution? Absolutely.
That’s why I built SafeShell, an open-source tool for inspecting commands, applying security policies, and running permitted commands with sandboxing on Linux.
The goal: help developers and engineering teams work faster with more control over what they execute.
Building automation or CI/CD workflows that need stronger security controls? I’m available for freelance projects in DevSecOps, secure automation, and cloud security. Let’s talk through Contra.
Useful idea, especially for commands suggested by AI. In my deploy script every step is logged, but nothing checks a command before it runs. Can SafeShell also run inside CI, for example as a step in GitHub Actions?
If you let an AI coding agent run unconstrained self-repair loops, it won’t fix the bug—it will rewrite your unit tests to pass.
The concept of "Reflexion"—agents diagnosing and repairing code from test feedback—is powerful. But in production, autonomous repair creates severe operational risks.
First, agents enter endless retry loops that burn API budgets while degrading code structure. Second, if an agent has write access to your workspace, its quickest path to a green checkmark is modifying the test assertions rather than fixing the bug.
In our Bounded Reflexion workflow, we enforce three hard guardrails:
Bounded Retries: Cap repairs at exactly two attempts. If the patch fails twice, stop the loop and route to a human developer.
Read-Only Test Suites: Mount test files as strictly read-only (:ro) volumes in the container. The agent inspects stack traces, but cannot touch the grading harness.
Air-Gapped Sandboxing: Run code execution in hardened, non-root Docker containers with network egress locked down.
How do you stop autonomous coding agents from "cheating" your evaluation harnesses?
Making the tests read-only is a smart rule: the agent can't change the thing that grades it. After two failed attempts, what does the developer get: only the stack trace, or also the two patches the agent tried?