> At the bottom layer, we build and manage pre-configured Kubernetes clusters in your AWS accounts

Are you considering supporting other cloud providers? I'd personally always choose GCP for UX reasons, and I know there are many who choose Azure for MS reasons, or Alibaba for price/language/location reasons. I understand starting with AWS, just wondering if that's set in stone or if others are on the roadmap.

> We’ve never been big fans of the complicated pricing that most SaaS companies have so we sell Nucleus as a single annual license where you get everything. In full transparency, we currently price Nucleus around $35k/license, or about 10% of what it would cost you to build and maintain this yourself.

Having come from a startup with ~10-12 eng, in the middle of your target market, using K8S, and building tooling around it, this is substantially more than I think we'd have spent on it. Our Datadog bill for comparison was about half that per year, and our cloud bill was only ~6x that.

Our tooling for K8S was a few thousand lines of Terraform config, a few hundred line Python script, and some GitHub Actions. We spent a fair bit of engineering time on these, but not quite _that_ much. I would imagine Nucleus would have been a much nicer experience, but in reality would only have saved us ~20% of an engineer.

Maybe we weren't the target market! Just my thoughts though. Nice one with having one flat fee, I like that.

> Are you considering supporting other cloud providers? I'd personally always choose GCP for UX reasons, and I know there are many who choose Azure for MS reasons, or Alibaba for price/language/location reasons. I understand starting with AWS, just wondering if that's set in stone or if others are on the roadmap.

We are definitely considering other cloud providers. I'm currently working on adding GKE support. GCP's UX is top-notch in my own experience and is a breath of fresh air when compared to AWS. We've also found a lot of startups are choosing GCP over AWS these days. This at least has been the case for many prospects we've spoken to.

I suggest the founders to focus ONLY on AWS, for the time being.

What's AWS market share? Analysts say 50%, and MS at 30-35%, and GCP at 10-15%. They're wrong. The target for this service is young startups, and in that segment, AWS is still at ~90% market share.

Ignore GCP and Azure for now. Focus on AWS.

Disclaimer: I was at AWS 2008-2014, and met with thousands of startups (I am not exaggerating). Since then I kept tabs on the market. I might be wrong, but I suspect I wouldn't be by much.

Thanks for the feedback! We're still an early company and working through the right pricing - we have some customers who pay less than that and some who pay more. Goal is to get happy customers and being an early stage company we have flexibility on it (the flat pricing makes that much easier).

I always find pricing in terms of developer time saved to be a tough sell, because different companies have different opportunity costs, value the product differently, pay differently, and different engineers have different productivity. That's a lot of axes to reason about. Most tools boil down to this eventually, but some are obviously things you'd never build internally (for a given size of company), whereas some are incremental improvements over what you might already be doing. I think Nucleus is in the latter category for many which makes this harder.

Have you considered things like per-region, per-host, per-cluster, per-active developer etc?

It's a deliberately misleading metric overall imo as it frames the value prop on your developers rather than the product.

Plus, if the argument is to hold and we assume your 'bad' devs can't somehow reinvent K8s in a week and have to buy into this managed one -- surely they're going to waste an equal amount of hours learning and breaking it?

Lunacy!!

We definitely have considered those axes to price against but so far haven't adopted them because we deploy nucleus into your account and its honestly felt a little strange to us to charge a company by region, host, cluster etc. when ultimately you're paying the infra bill.

Not to say that we won't change our packaging and pricing down the line (we certainly will) but for now we're trying to make it easy to adopt without having to think across so many pricing axes. But we've seen pricing questions a few times in this thread - so maybe it's worth evaluating sooner rather than later.

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?

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

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).

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.

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.

> 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!

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

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.

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).

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

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

Is it also a YC company?

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.

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...

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?

Missing windmill.dev :)

namespace.so by friends of mine.

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.

So this runs on top of AKS?

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

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

I've built several massive-scale k8s systems for prior companies, all scaled using the underlying built-in primitives without extreme cost. Where do you get the improvement metrics from? For instance: "5x faster deployments"

This is based on what we're seeing with our customers + our own experience. One example from a customer is that it was taking them 14 minutes to deploy one service to production. Combination of slow build pipelines + manual process to update a tag in a kustomize file and then manually trigger deploy. Given the automation we have in place, they're not pushing to prod in less than 3 minutes. Everyone's environments are a little different but we're seeing encouraging results.

rand();

> we currently price Nucleus around $35k/license, or about 10% of what it would cost you to build and maintain this yourself.

My suggestion is to price this at 20% of what it would cost a customer to run it independently. Perhaps you can make it to 10% for a limited time, but make it clear that the price will go up.

Why? Because:

1) You will need the price to go up.

2) You are positioning your product in a different (better?) way.

Note that things like Amazon RDS, etc, are at about 20-25% premium on top of the tools/softwares that they automate.

Your service is currently not as mature as RDS or others, and therefore it might be right to temporarily price it at 10%, but telling customers that it will eventually go up to 20%.

Looks interesting but at 35k per license I am not sure who you are targeting with this. Why would anyone use this compared to an okteto, a porter or a qovery? They are all priced in the sub 1k$ for essentially the same thing as far as I can tell.

Thanks for the feedback! We're definitely still working on the pricing and work with our customers to find something that makes sense and works for them. We really only offer one version of our platform which is an enterprise version of unlimited users, environments, services etc for one price.

In reality, when you look at okteto and others who use usage based pricing, this would be comparable to their enterprise versions. If you're a team of 10 developers and you want to use Okteto, you're paying $100/month/developer or almost $15k/year for their pro version. Bump that to enterprise and it quickly goes up from there.

PaaS .. it's a thing. Try it out before k8

(I'm not the OP or in any way related to this project; I just heard of it through this post today.)

I think there is a pretty large market of people who have indeed used PaaS and have concluded that the flexibility of kubernetes is worth the complexity. It's not for everyone, but it is useful for a lot of organizations.

Would really love some kind of pricing clarity. "Free Forever" with hard caps and "Custom" with negotiable caps doesn't really suit my needs, and I don't have any idea at all what to expect in terms of pricing "after free but before scale"

@alex - we don't meter usage, environments, services, users, etc. for our paid plan so you have free reign over all of that. We have customers who pay a variety of price points depending on what they can afford/makes sense.

Would more granular pricing that meters users, environments, services etc. be more appealing?

I'm confused, if someone is already using something like GKE or EKS, what do you do? Presuming people are using cloud build/code pipeline with their setups.

Good question! If you already have GKE or EKS + all of your CI/CD pipeline then we can help automate other manual tasks that devops or platforms have to do today. For example, the ability to easily clone and replicate environments for developer self-service, or to get ephemeral environments. We're working on releasing blue/green deploy and multi-cloud features as well. This would require a migration to Nucleus, so you would have deploy your services on to Nucleus from your existing clusters.

Giving admin access to a production AWS account is kinda scary, have you thought about curating the permissions to make them less permissive?

I agree. The role that Nucleus asks you to create does not ask for the AdministratorAccess policy. Instead, it calls out the specific product areas that it accesses. We also have a description of each one and why we need it in our docs. https://docs.nucleuscloud.com/home/concepts/permissions-over...

However, we can definitely be more detailed and call out specific actions that we need in those areas. That still leaves us with IAM though. I think we can still do better here to further limit IAM, but as of right now we can still do a lot if we have full access to the IAM featureset. It's something we're working on improving, but for now, I always suggest folks turn on auditing in their AWS accounts to keep ontop of anything that is happening.