[candiddevmike]

Your product looks neat but I think you're a few years too late, for most folks the Kubernetes platform is kind of a done deal. Couple of questions:

- Who is your target customer?

- How does it compare to OpenShift?

- Can you bring your own Kubernetes provider?

- You have nothing on your page that would make me trust you enough to give you the level of access you need to deploy. Are you pursuing any kind of partnerships with AWS or security audits?

[debarshri]

I have been curating list of PaaS, kubernetes abstractions etc. in Awesome PaaS [1].

PS. This space is super competitive. One of the things I have noticed is that the life of an organisation using a platform like this is very short. For example, a startup might use this right away to become compliant and stuff, but once they mature and hire devops engineers, which they will when they hit PMF, they will plan a migration out of your platform.

I am wondering how you are planning to counter this behavior.

[1] https://github.com/debarshibasak/awesome-paas

[evisdrenova]

Totally fair question - we're thinking about this in 2 ways:

1. Continue to build out integrations across the toolset. For ex. we provide a built-in CI/CD pipeline but know that most mature orgs will want to use Jenkins/Argo/Github Actions etc. so we are building out those integrations (have Github already). Our goal is to give customers an onramp to get started and then once they mature, have the integrations ready for them to easily adopt the tools they care about.

2. Continue to expand the platform into other areas of the service layer. We're working on building out a service cataloguing module and testing module to make it easy for teams to understand what services they have, who owns them, scorecards etc. and to test them. The goal is to expand across the service layer vs. up and down the stack (DB or front-end layer).

[whalesalad]

Huh, I have the opposite. There is a huge hole in the ecosystem between Fly.io/Heroku and managed Kubernetes.

If you want to deploy a handful of services, databases, caches, queues, inside of a single private network, with load balancing, security, deployments, per-environment (versioned) config, rollbacks, blue/green deploys, etc... it is not trivial. It's easy for me because I have been building this stuff for the last 15 years, but I also get sick and tired of reinventing the wheel all the time.

My team and I built an internal PaaS on Kube to power Farmlogs back in 2016. This experience had a tough initial learning curve, but ultimately paid off bigtime and gave me the assurance that yes kubernetes can absolutely work in production at scale reliably. But it's tough to grok and use correctly. So I've been wanting to solve the aforementioned problem for a while now.

This product honestly looks like the perfect answer. My only hesitation would be longevity ie what happens if this company fails. Ultimately I want them to manage the thing, but I also want a reproducible artifact of my entire system so that if they get hit by a bus my business isn't fucked.

It checks all the boxes for me: heroku-style ui to enable devs from different levels of experience to contribute and have visibility into the system but I bring my own AWS account and therefore ultimately have sudo access to my network and how this env might interact with other envs.

[evisdrenova]

Appreciate the feedback! That was the experience we had as well - there wasn't anything in between render/heroku/fly.io and EKS and why we started Nucleus. We're not going out of business anytime soon but its a very fair concern and there's ways that we can help mitigate that i.e. offering an on-prem version, exporting terraform files, etc. Working towards this but it will take some time.

[sanderjd]

> exporting terraform files

This is what I came here to ask about. Managing my infrastructure only through a UI makes me nervous. I much prefer having the source of truth for configuration be in version control. Having said that, I do love what you've launched here, and totally get the value proposition. If I could get that value without sacrificing infra-as-code, this would really speak to me.

A way this could potentially work (albeit with a pretty significant bump in complexity I think) would be for the UI to sync with an IaC repo. That is, changes through the UI would commit to the repo and need to be applied (either automatically or on-demand), and changes to the repo outside the UI would need to be sync'd into the UI.

Just a thought! Nice work on this!

[2023throwawayy]

I have to agree here. I have collected a list of companies in this space. Unless you have a large differentiator, you've got your work out for you trying to attract customers.

acorn.io ambassador architect brev.dev builder.ai buildkite.com bunnyshell circleci cloudbees.com codespaces crafting.dev cycloid.io d2iq.com dagger.io depot.dev devzero ergomake.dev facets.cloud flightcontrol.dev floxdev.com fly.io garden.io getport.io gitpod gradle harness.io hop.io kurtosis.com lambdalabs.com loft.sh massdriver netlify nomadproject.io nullstone.io oatfin.com okta okteto opsera.io porter.run quali.com rafay.co raftt.io railway.app refcetl.run release.com render.com replit.com reploy roost.ai shipyard signadot.com styra.com tesorio timoni.io tsuru.io tugboat uffizzi.com vercel.com vivun webapp.io withcoherence.com

[evisdrenova]

Thought I replied here but must have missed it. It's a solid list! From my perspective, our market is a much smaller market than just "developer tools" we're really focusing on teams that want to move to kubernetes but don't have the expertise/don't want to spend the time setting it up or teams that are on kubernetes but having challenges managing and scaling their systems.

[jaguar75]

Impressive list indeed! Co-founder of Signadot here. Btw, we don't manage Kubernetes (K8s) environments; instead, we enable multi-tenancy for test tenants within a customer's existing K8s setup, without duplicating infrastructure. We leverage sidecars or a service mesh for request-based isolation, dynamically routing traffic based on request headers (typically propagated using OpenTelemetry).

[suryao]

Yeah, customer acquisition and dev experience makes all the difference here.

Also, you missed out my company, argonaut.dev :-)

[debarshri]

Is it also a YC company?

[suryao]

Yes, we are a YC S21 company and are on the awesome PaaS list you've compiled. We have been focusing on building in stealth so far and are planning some public launches over the next few weeks. We are already more mature and feature rich than most of the tools on the list for instance.

[igorzij]

one more list collected by us; Digger was initially about something along similar lines, still watching the space closely the list is focused specifically on "better DX for your cloud account" products

https://diggerdev.notion.site/DX-platforms-for-your-cloud-ac...

[esafak]

Which ones do you recommend for startups that want to deploy services? If that does not winnow the list enough, which of the good ones are open source?

[rubenfiszel]

Missing windmill.dev :)

[tommiegannert]

namespace.so by friends of mine.

[evisdrenova]

Thanks for the feedback! Answers below: - Target customer is small to medium sized companies - we see the best fit with companies that have 2->30 engineers - we definitely have similarities but I think we have a better developer experience + we're much much cheaper than their managed version - we're working on releasing support for over this in the next 1-2 months - we're SOC 2 type 1 certified right now, and will be getting our SOC 2 Type 2 in 1 month. We have a few partnerships that we're working on but they're not ready to completely announce just yet.

[avbanks]

So this runs on top of AKS?

[nickzelei]

Today our platform is built ontop of EKS. We are currently working on GKE support, and then AKS to follow.

[cpach]

It might not be a done deal for companies that were recently founded. And definitely not for companies who have yet to be founded.