◆ Kubernetes deployment · no access to your cluster

A new service in prod
in an hour, not a sprint

Developers ship services themselves, to your standard. If it breaks, AI names the cause. We never get access to your cluster.

SAST blocks the deploy Root cause in seconds Rollback in one action
One service, its first week in prod
opsy · api-service
$ deploy api-service:v42 → prod
The vulnerability never reached prod
SAST2 critical · RCE in a dependency
image1 high · CVE-2026-104
hardcoded secrets0
the deploy is halted until it's fixed
api-service · restart loop: 3 in 40 min
Root cause: OOMKilled
memory limit 128Mi exhausted
panic: runtime error: invalid memory address at checkout.Handler (checkout.go:88) restarting container (back-off 40s)
your move: raise the memory limit or roll back the release - in one click
api-service · release history
Roll back to the previous version
v42now · throwing errors
v41last stablerestore
v40older
the new version turned out bad - back to the previous one in one action, no 3 a.m. calls
analyzing requests/limits · 8 deployments
requests 3× too high
requested now
actually needs
we suggest -65% memory · -40% CPU
≈ -40% off the resource bill per month
◆ Inside the product

After the deploy comes the interesting part

Opsy doesn't drop the service at rollout. It keeps watching: warns about OOMKill before the crash, names the cause of a failure and shows where you're paying for unused resources.

  • The cause of a crash in plain words, not a graph
  • Ready requests and limits values in one click
  • A heads-up before the incident, not after
deostech.kz/platform
Status: payment-service×
ns: production
OverviewEventsRecommendationsAnomaliesRelated
AI-powered recommendations
Analyzed over 24 data points
Confidence Score
78.0%
Average confidence
Collect metrics Apply all (2)
CPU
36%
Utilization
Request: 500m cores
Avg: 180m cores
P95: 240m cores
Memory
61%
Utilization
Request: 512Mi
Avg: 312Mi
P95: 380Mi
CPU optimization Low priority
Average CPU usage ~180m. You can lower the request to 200m to save resources.
Current
cpu_request: 500m
cpu_limit: 1000m
Recommended
cpu_request: 200m
cpu_limit: 500m
Apply recommendation Copy YAML
HPA Autoscaling Low priority
Stable load allows autoscaling: 2-5 replicas at CPU 70%.
deostech.kz/platform
AI analysis: payment-service (production)×
SummaryLogsEventsMetrics
WARNING
Memory is approaching the limit at peak hours - OOMKill risk.
WHAT WE DETECTED
Memory peak 470Mi of 512Mi (92%) at 14:20
CPU steady <40%
Network: 1.2 MB/s ↑ · 3.4 MB/s ↓
RECOMMENDATIONS
→ Raise the memory limit to 640Mi to rule out OOMKill at peak
→ Or add a 4th replica to smooth the load
◆ What changes

A new service - the same manual work, again

Doesn't matter who sets it up - DevOps or the developer themselves: pipeline, Helm, permissions, security jobs, from scratch every time.

The usual way
  1. Developer creates a repository
  2. Sets up the pipeline and Helm by hand
  3. Writes out permissions, namespace and SAST
  4. Review, approvals, fixes
  5. Service in prod
≈ hours per service
With Opsy
  1. Developer picks a repository
  2. Describes the project in words
  3. Opsy generates the whole delivery path by policy
  4. Permissions, environments and SAST applied automatically
  5. Service in prod
≈ minutes · self-service, by standard
◆ Why not build it yourself

And why not grant access.

vs Backstage / Port

A golden-path construction kit - you build and glue it yourself. Opsy is ready and works right away.

vs cloud PaaS

They need access to your infrastructure. We don't. Data stays in the perimeter.

vs «DevOps will set it up»

They will. Every time. Their own way. Opsy does it once, as policy, for all teams.

SaaS or on-premise

Deploys fully in your perimeter: configuration via environment variables, agent image in your registry. No tie to our server.

On top of your stack

GitLab, Azure DevOps, GitHub · Kubernetes and OpenShift. Replaces nothing - adds onboarding, permissions and security.

◆ Security as a precondition

We don't connect to your cluster. Your cluster connects to us.

In a regulated environment - government, finance, security - handing cluster access to an external service is a hard stop. Opsy is built so that isn't needed: the agent lives inside your perimeter and initiates outbound HTTPS requests for tasks, running kubectl, helm and git locally. No inbound port is open, and no cluster key ever leaves.

Your cluster

  • agent (ServiceAccount)
  • kubectl · helm · git - local
  • kubeconfig and secrets stay here
outbound HTTPS no inbound

Opsy control-plane

  • task queue · policy
  • audit and status
  • no kubeconfig · no cluster creds
No inbound to the cluster
kubeconfig in the cluster
Secrets in the perimeter
Token revoked instantly

For a security team this turns a blocked integration into an approved one: no cluster access is granted, data and credentials stay in your perimeter, and every agent action is in the audit log.

How security works
◆ How it works

From repo to prod - in four steps.

1

Connect in a minute

Repo and cluster: GitLab / Azure / GitHub · agent inside the cluster.

2

Describe the project

«Spin up a Go service on port 8080» - Opsy parses the repo itself.

3

Opsy prepares delivery

Pipeline with SAST, Helm, Dockerfile, environments and permissions - by one standard.

4

Teams ship themselves

Under your policy: RBAC, approvals, audit, one-click rollback.

◆ Step 3 live · Opsy prepares delivery
opsy · onboard
$ opsy onboard
› analyzing api-service... Go, HTTP :8080
Dockerfile✓
FROM golang:1.23-alpine
EXPOSE 8080
helm/values.yaml✓
replicas: 2
resources: { cpu: 200m }
.gitlab-ci.yml✓
stages: [build, sast, deploy]
→ dev/stage/prod environments · RBAC applied
◆ Product

Not just onboarding. Full control over delivery.

Onboarding

Service to prod from a description

Opsy parses the project and generates Helm, Dockerfile and a pipeline under one policy.

History

History & Rollback

All deploys in one place. One-click rollback.

RBAC

Per-team permissions

Roles and namespaces: who can deploy where.

AI Search

Cluster search

«Where is high CPU?» - AI finds the right pods itself.

Resources

Resource savings

CPU and memory recommendations, not just charts.

Logs

Log analysis

AI parses pod logs and events, finds the crash cause and OOM - no manual grep.

Strategies

Canary & Blue-Green

Gradual rollout with metric-based auto-rollback. No manual tracking.

Environments

Environment promotion

dev → stage → prod with approvals and config carry-over.

Security

Security & SAST

Scanner by project type, deploy blocked on critical findings.

◆ Who values this

An argument for everyone in the decision.

CTO / VP Eng

New services reach prod in minutes. DevOps isn't the bottleneck. One delivery standard.

CISO

Zero cluster access, data in the perimeter, unified permissions and SAST on every service.

Platform / DevOps

You set policy once instead of clearing «spin me up a service» tickets. Templates and permissions stop being your personal responsibility.

Team lead

Service to prod with no waiting or tickets. Your team, your pace.

◆ Get started

Let's start with one service.

We'll deploy into a test environment and go through your security checklist.

info@deostech.kz
@deostech
Almaty · Kazakhstan & CIS

DevOps stops being the bottleneck.

Without granting cluster access. We'll look at it on your workloads.