Kubernetes deployment · no access to your cluster

Deploy services easily and
instantly find the root cause

Forget hand-writing manifests - Opsy detects the stack and rolls out the service to your standard. And if it breaks, AI instantly finds the cause in the logs.

One standard Approvals & SAST Delivery analytics
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
Incident diagnosis

From a tangle of logs - to one root cause

No more digging through Grafana and logs by hand - AI correlates them in seconds.

Root cause in seconds Logs, metrics, events Right in the UI
14:02:21 INFO  POST /checkout 200 340ms
14:02:23 INFO  calling payment-service...
14:02:23 WARN  payment-service: empty response body
14:02:23 panic: nil pointer in checkout handler
AI
Root cause
Panic in the /checkout handler - an empty response from payment-service was never checked for nil
Recommendation: validate the response before reading its fields
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
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

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 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.

Standard and control

Self-service - within your guardrails.

Single golden path

Every new service is onboarded the same way, under one policy.

RBAC by namespace

Who can deploy where is your decision, not chance.

Prod & merge approvals

Critical changes go through a human, not automatically.

SAST gate

Deploy is blocked on critical vulnerabilities before rollout.

Immutable audit

Who, what, when and with what result - in the log.

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

Setup routine moves into the product. You set policy instead of clearing tickets.

Team lead

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

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.

Get started

Onboard your first service on a pilot.

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

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

Take DevOps out of every new service.

Without granting cluster access. See it on your workloads.