Opsy is an Internal Developer Platform for Kubernetes. It onboards new services self-service, standardizes delivery and keeps control - all without giving the platform access to your cluster. Below: how it works and what's inside.
The Opsy agent lives inside your perimeter and initiates outbound HTTPS requests for tasks. It runs kubectl, helm and git locally. No inbound port is open, and no cluster key ever leaves.
Opsy parses the project and generates Helm, Dockerfile and a pipeline under one policy.
All deploys in one place. One-click rollback.
Gradual rollout with metric-based auto-rollback.
dev → stage → prod with approvals and config carry-over.
AI parses pod logs and events, finds the crash cause and OOM.
CPU and memory recommendations, not just charts.
Every new service is onboarded the same way, under one policy.
Who can deploy where is your decision, not chance.
Critical changes go through a human, not automatically.
Deploy is blocked on critical vulnerabilities before rollout.
Who, what, when and with what result - in the log.
Onboarding and rollout from a description. Learn more →
State, resources, search. Learn more →
Roles, namespaces, keys. Learn more →
Guardrails and limits. Learn more →
SAST before deploy, policy gating. Learn more →
Node and workload load. Learn more →
Find a service and its log stream. Learn more →
Requests/limits recommendations. Learn more →
Several clusters and environments. Learn more →
Helm and manifests with hints. Learn more →
Releases without bloated pipelines. Learn more →
HTTP API and GitLab linkage. Learn more →
GitLab CI, Azure DevOps Pipelines, GitHub Actions.
Kubernetes and OpenShift · Helm · werf.
Private Docker registry, Harbor, ACR, GHCR.
SaaS or fully on-premise in your perimeter.
We'll deploy into a test environment and go through your security checklist.