DEV Community

Maksym Trofimenko
Maksym Trofimenko

Posted on

Cloud-Native Workflow Engine for Kubernetes - What Would You Use It For?

Hey everyone, I've been building an open-source workflow engine that runs natively on Kubernetes called Tiny Systems (still working on the name). Not "deployed on Kubernetes" - actually native. Flows are CRDs. Nodes are CRDs. So entire state lives in etcd. No external database.

Think n8n or Node-RED, but designed for people who already run Kubernetes and want automation that feels like part of their cluster.

Problems I'm solving right now

These are ready-to-use solutions you can clone and deploy:

  • Cluster Cost Saver — scales down your deployments every evening, brings them back every morning. Dead simple, saves real money. No Lambda functions, no cronjobs, no external schedulers - just a flow inside your cluster.

  • Pod Failure Alerts — watches pods in real time, catches CrashLoopBackOff, OOMKilled, image pull errors, and sends a Slack message before your users start complaining. Yes, Alertmanager exists, but I get my slack message next second after the crash (not like 1-5min it takes for prometheus chain).

  • GitHub Deploy Bot — receives a webhook after CI builds an image, updates the Kubernetes deployment, posts the result to Slack. A lightweight GitOps pipeline without ArgoCD/FluxCD overhead for simpler setups. Using it for really tiny (the title!) clusters.

  • Firestore to ConfigMap Sync - listens to a Firestore collection and syncs changes to a Kubernetes ConfigMap in real time. Useful for feature flags. Got idea from app managements, thought why not to use that for K8s.

  • Service Status Page — a self-hosted status page that pings your endpoints and serves a page. No Statuspage.io subscription, no cron jobs, just a flow.

What workflow engine does today

You build flows visually - drag nodes, connect them, configure, deploy. Each component module runs as its own pod. Nodes in the same module talk over Go channels, across modules — gRPC. Everything stays inside your cluster.

There's also an AI assistant that can build flows from a prompt, but that's a story for another post.

Where I'm headed next

These are the solutions I'm planning to build:

  • CronJob failure alerter — Kubernetes CronJobs fail silently. This would watch them and alert on failure via Slack or PagerDuty.
  • TLS certificate expiry watcher — scan ingresses across namespaces, alert before certs expire (sometimes I miss emails from acme)
  • Slack command bot — slash commands that trigger Kubernetes actions: restart a pod, get logs, scale a deployment. ChatOps without writing a bot from scratch.
  • Webhook relay and transformer — receive webhooks from external services, reshape the payload, forward to internal services. A lightweight alternative to writing one-off HTTP handlers.

Why I'm writing this

I've been building in isolation for too long. The engine works. The solutions work. But I keep guessing what people actually need instead of asking.

So - if you run Kubernetes at work:

  • Which of the solutions above would you actually use?
  • What's a recurring ops task you've been meaning to automate but haven't?
  • What's keeping you on n8n / Airflow / bash scripts?

Thanks!

Top comments (0)