Internal Developer Platform · Kubernetes

A new service in prod
without a DevOps ticket.

Describe a new project - Opsy assembles the pipeline, Helm, environments, permissions and SAST checks by one standard. All within your perimeter: kubeconfig and data never leave.

GitLab · Azure DevOps · GitHub Kubernetes and OpenShift on-premise
Problem

Your CI/CD works. Until a new service shows up.

Existing services ship themselves. But every new one is manual DevOps work again: pipeline, Helm, Dockerfile, environments, permissions, registry, security jobs. DevOps becomes the bottleneck, teams wait, and there's no standard - everyone configures their own way.

Developer
I want to spin up a service - another DevOps ticket and waiting.
DevOps
The same manual setup again. On every project.
Security
The new service was set up haphazardly - no unified permissions or SAST.
What changes

A week of manual setup - or minutes of self-service.

The usual way
  1. Developer creates a repository
  2. Files a DevOps ticket
  3. DevOps by hand: pipeline, Helm, namespace, permissions, SAST
  4. Review, approvals, fixes
  5. Service in prod
≈ days-weeks · bottlenecked on DevOps
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
Access model

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

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.

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
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. Learn more →

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.