Hacker News new | past | comments | ask | show | jobs | submit
voatsap | on: Ask HN: What are you working on? (November 2026)
For the last 3 years, with a small team has been building https://kube-dc.com/ - a platform for building enterprise grade private and public clouds. Its like VMware + OpenShift + Railway in a single product: completely multi-tenant, built entirely on the K8s API (we built over 46 custom controllers in Go, with UI in Radix UI), with managed services like nested K8s, Postgres, Kafka, Valkey, and GitHub runners. Not the charts :) real services. Also we can do vlans BGP, shared GPU and all fancy stuff required.

Now we don't deploy this to private companies except some gov projects. But we are engaging existing IaaS and dedicated servers providers. Later hope we would fight with Broadcom and IBM :)

We previously ran a services company that built over 100 private clouds, then decided to turn that experience into a product with an aggressive level of automation to let DevOps, SRE, and platform teams hit a 1:300 ratio per developer (now dev + AI agent teams).

We are currently deployed across 12 datacenters and raising our seed round this month.

Regarding been curious, today I have created my first explainable video with Remotion +claude so if you want to see open edit results check https://promo-review-shalb-promo.stage.kube-dc.com/

Would be glad if you comment. Thanks!

stroebs | parent | next
Really interesting, and I think you’re going to need to charge more for your product (which may come up during your funding rounds). I’ve been building the same thing at $enterprise, totally on-prem multi-AZ, multi-region KaaS, VMaaS, and soon DBaaS, and some of the other services listed. It’s a great deal harder than we initially planned for and we have some ridiculous internal policies that require everything to be git-driven which makes it worse.

Looking forward to see how your product develops. Would love to work with you in future.

kohukohunui | root | parent | next
Genuine question about your git-driven comment.

From my hands-on engineering POV I often set this maybe not as a hard requirement but definitely a goal, and the places where it's not possible I find a little painful.

In your case where is it becoming something that doesn't make sense for you?

stroebs | root | parent | next
For explicit example - we use Crossplane and FluxCD to perform provisioning of our entire on-prem set of resources (VM, k8s, S3, etc). At the moment all git resources live on public Github which has a range of benefits and guarantees survivability outside of our own infrastructure. The most painful bit of this is the instability of the platform. Github down means all provisioning is down. We also use on-prem Github Enterprise and it has its use-cases but we're also multi-region across the world which means the latency of GHES hurts compared to Github.com. Enough to have the trade-off of relying on Github.com's availability.

The other issue is permissions management. Git is great for auditability but it doesn't have the fine-grained permissions management you'd typically require from a "cloud" provider.

The end result is that we've created a "private cloud console" which has AWS-like IAM with fine-grained permissions and RBAC. All of the actions in the console talk to Github.com and open pull requests to repositories which once merged will publish a new OCI artifact. FluxCD pulls the latest artifact and Crossplane does the logic of updating the state of resources. Some (external/non-k8s) resources don't fit into this model very well if they don't have a Crossplane provider like our NetApp arrays where S3 is hosted.

voatsap | root | parent
Let me add my 2 cents on this. The most unconfortable place for GitOps is when you need to keep in sync values that user could define via product UI/cli. For example you change theme color in UI, but you have the same settings you can define in Helm chart inside a git repo. So that brings you to dilema, where and how to store dynamic settings (this could be just inside K8s api change via UI/cli) but changing all of this using GitOps way (UI/CLI-> git commit -> wait reconcile) breaks the comfortable user expierence.

Same things with dynamic changes just for test something, you need or commit temp change and commit back old value again or just pause controller from updating during your tests.

But the bright side of this is the fact that your configuration completly traceble and you have whole IaC backup for your infra in unrbreakable place (git).

For now we fully perform all updates and all configuration with Flux and this was a good decision I can retrospect.

stroebs | root | parent
The GitOps approach definitely has its advantages but for something as simple as a setting as you describe, a round-trip to git makes negative sense when it could've been done directly in a local database.

How have you found the stability of KubeVirt through all of this? Are you using KubeVirt directly or a wrapper? We tried Harvester and it is amazing on day 1. Day 2 is a horrid nightmare of broken upgrade timesink. Granted we started at Harvester 1.4.0 in 2024 but have a couple clusters stuck on 1.5.0 right now and have VM failures regularly. Longhorn was also in use for VM disks and it was horrendously unstable even with dedicated 2x100Gb for each node.

We've moved everything to Proxmox+NetApp now and it's rock solid. Dedicated NICs + switches for corosync since that was the cause of an outage once.

jasonvorhe | parent
I think you meant to link to https://kube-dc.com/ :)
voatsap | root | parent
Good catch, fixed the link! Thanks.