Skip to content

Operator-powered SaaS

Many teams already have a Kubernetes Operator that knows how to run their product: it creates clusters, rolls upgrades, manages backup resources, or reconciles product-specific custom resources. The operator solves the application lifecycle problem, but it does not by itself create a SaaS control plane.

To launch a customer-facing product, you still need:

  • Tenant onboarding and subscription management.
  • A Customer Portal and generated APIs.
  • Cloud account onboarding and deployment-cell management.
  • Per-tenant provisioning, scaling, stopping, starting, backups, restores, and deletes.
  • RBAC, audit logs, workflow visibility, support tooling, and fleet operations.
  • Metering, billing, alerts, observability, and upgrade workflows.

Omnistrate lets you keep your operator and build the rest of the product around it.

What Problem This Solves

Without Omnistrate, teams often need to build a custom control plane around their operator. That means writing APIs, forms, tenant models, subscription approval flows, deployment orchestration, backup and restore orchestration, status polling, logging, operational dashboards, and cloud-account management.

With Omnistrate, your operator stays responsible for reconciling Kubernetes resources, while Omnistrate provides the product control plane and lifecycle orchestration. You define a service plan once and Omnistrate exposes it through the Customer Portal, APIs, CLI, and Operations Center.

Reference Example

The operator spec template shows a complete CloudNativePG PostgreSQL service plan:

  • CloudNativePG is installed as an operator Helm dependency.
  • A customer provisions a PostgreSQL cluster from the Omnistrate Customer Portal or API.
  • Omnistrate passes customer inputs such as instance type, storage size, database name, and replica count into the workflow context.
  • Required systemWorkflows.create, modify, and delete hooks provision, update, and remove the CNPG Cluster custom resource.
  • systemWorkflows.stop and start toggle CNPG hibernation.
  • systemWorkflows.backup creates a CNPG Backup resource and captures provider backup metadata.
  • systemWorkflows.restore creates a new target cluster from the selected Omnistrate snapshot and the captured backup metadata.
  • systemWorkflows.deleteBackup cleans up provider-side backup resources.

This pattern applies to other operators as well: databases, queues, search engines, AI platforms, data pipelines, or internal platforms that already have a CRD-driven lifecycle. If your product needs operations beyond the standard platform lifecycle APIs, you can add provider-defined customWorkflows separately.

No Lock-In to a Proprietary Lifecycle Model

Omnistrate is designed to work with the artifacts your platform team already uses:

  • Kubernetes Operators and CRDs remain the source of truth for application reconciliation.
  • Helm charts can install the operator and CRDs.
  • Argo Workflow-style YAML defines lifecycle workflows using DAGs, parameters, and Kubernetes resource actions.
  • Terraform or OpenTofu can optionally manage cloud resources such as buckets, IAM roles, KMS keys, VPC attachments, or external services.
  • Your existing portal or API can call Omnistrate APIs if you do not want to use the generated Customer Portal directly.

The result is an end-to-end SaaS solution without rewriting your operator or moving product lifecycle logic into a proprietary format. You keep standard Kubernetes and infrastructure-as-code assets, and Omnistrate adds the control plane surfaces around them.

End-to-End Architecture

A common operator-powered SaaS architecture looks like this:

  1. Service plan definition

You define a plan spec with customer inputs, endpoint configuration, operator dependencies, backup policy, and system workflows. Provider-defined custom workflows can be added when the product needs operations outside the standard lifecycle APIs.

  1. Customer onboarding

Customers sign up through the generated Customer Portal, your custom portal, or your API integration. Omnistrate manages tenant records, subscriptions, permissions, and deployment requests.

  1. Provisioning

Omnistrate creates or selects a deployment cell, creates the tenant namespace, installs required dependencies, and runs the create workflow. The workflow applies operator-managed custom resources.

  1. Day-2 operations

Customers or operators can scale, stop, start, back up, restore, delete, or invoke optional provider-defined operations. Omnistrate runs the corresponding Argo Workflow-style lifecycle definition and records debug events for workflow steps.

  1. Optional cloud infrastructure

If the operator needs cloud resources, Terraform can be part of the same plan. For example, Terraform can create an S3 bucket or IAM role, and the operator workflow can use those outputs when creating backup resources.

  1. Operations and support

Your operators use the Operations Center to inspect workflows, debug events, deployment cells, snapshots, alerts, logs, and fleet health.

When to Use This Pattern

Use this pattern when:

  • You already have an operator and want to commercialize it as a SaaS Product.
  • Your product requires lifecycle operations beyond create and delete.
  • You need customer-facing backup and restore backed by operator-native backup resources.
  • You want to expose controlled day-2 actions such as diagnostics or other provider-defined administrative operations.
  • You need to support hosted, BYOC, private networking, or more than one cloud/region without building each control plane flow yourself.

Start with Build from Kubernetes Operators, then use the full Build with Kubernetes Operators guide when you are ready to model workflows and backup/restore behavior.