Back to authors
omnistrate-oss

omnistrate-oss

4 Skills published on GitHub.

omnistrate-fde

Guide users through onboarding any application onto the Omnistrate platform and turning it into a managed SaaS offering. Covers Docker Compose, Helm charts, Terraform/OpenTofu modules, Kustomize, and mixed stacks, across all deployment models - hosted (your cloud), BYOC (customer cloud accounts, incl. BYO-VPC and PrivateLink), BYOC-K8s (customer-managed Kubernetes, no infra provisioning), and air-gapped/on-prem installers. Also covers monetization - pricing, Stripe end-to-end billing, usage metering export, custom billing dimensions, and cloud-marketplace/Chargebee/Clazar integrations. Use when a customer/ISV wants to onboard, "SaaS-ify", productize, or offer their software as a managed service, asks about BYOC / bring-your-own-cloud / on-prem / air-gapped delivery, or asks how to charge, meter, or bill for it. For Kubernetes operator-based services (CRDs + controller) use omnistrate-operator; for designing an architecture from scratch use omnistrate-sa; for debugging failed instances use omnistrate-sre.

UncategorizedView skill →

omnistrate-operator

Use when onboarding a Kubernetes operator-based service (CRDs + controller, e.g. CloudNativePG, Strimzi, KubeAI, ECK) onto the Omnistrate platform; when writing or reviewing an Omnistrate ServicePlanSpec with systemWorkflows; or when an operator/Helm+CR deployment must become a managed SaaS offering with create/modify/stop/backup/restore lifecycle. For Docker-Compose services use omnistrate-fde; for debugging failed instances use omnistrate-sre.

UncategorizedView skill →

omnistrate-sa

Guide users through designing application architectures from scratch for SaaS deployment on Omnistrate, including deployment-model selection (hosted/BYOC/BYOC-K8s/air-gapped) and monetization model (Stripe end-to-end billing vs custom metering export for marketplaces, Chargebee, or non-built-in pricing dimensions). Focuses on technology selection, domain-specific architecture patterns, compliance and SLA requirements, and iterative compose spec development. Output may be a production-ready Docker Compose spec handed off to the FDE skill, or a ServicePlanSpec skeleton recommendation (when the stack uses Helm, Terraform, or a Kubernetes operator). Do NOT use when the user already has a deployable artifact (→ omnistrate-fde; operator services → omnistrate-operator) or needs to debug a failed instance (→ omnistrate-sre).

UncategorizedView skill →

omnistrate-sre

Systematically debug failed or stuck Omnistrate instance deployments across all resource types (Docker Compose containers, Helm releases, Terraform/OpenTofu, Kustomize, Kubernetes operator CRs) and all deployment models (hosted, BYOC customer accounts, BYOC-K8s customer-managed clusters, air-gapped). Progressive workflow - deployment status, workflow events, rendered-artifact debug, live cluster access - that finds root causes while avoiding token limits. Use for FAILED/DEPLOYING instances, probe failures, terraform apply errors, helm release issues, operator CR reconciliation problems, and BYOC agent/connectivity issues. Do NOT use for onboarding a new service (compose/helm/terraform/kustomize → omnistrate-fde; operators → omnistrate-operator) — only for debugging instances that already exist.

UncategorizedView skill →