That's correct that the entire engineering team is on the platform. I appreciate the feedback and perhaps the post didn't message this well.

There are many value-adds that developers use from the platform beyond deployments like a monitoring/status dashboards, access control, and preview environments.

Many of our customers use our platform as a DevOps platform. We've seen many engineering teams hire 1 DevOps engineer per 10 software engineers (this varies based on industry and tech complexity). We chose to price the offering based on the value we're driving to each developer.

Thanks for the feedback!

We have seen the same with our customers and our own experiences -- most teams "graduate" from a PaaS because you're locked into a set of proprietary technologies and hosting.

When they do get large enough, they leave to build their own infrastructure. Unfortunately, they have to rebuild much of the automation and user experience that a PaaS provided for them.

It's fair to call us a PaaS given our launch, but our vision is to give teams automation and collaboration in their own tooling and workflows.

Ok, let me give you 2 more cents on that. When we had pivoted, to pivoted to automation, tooling and workflows, if-then-then-that framework with webhook and github hook etc. Exactly what you are pitching. That has another set of challenges. It is very hard to sell and motivate engineering teams to use a product like that, forget about even monetizing it. It is what I call the chasm. You get some revenue but not enough to get a breakthrough. One of the insights we had, is that you have to become an enterprise product and you have to let go of consumer-like or product led approach you have in the product. Also, the ICP of your current product is probably not the ICP of the automation product you are building, the learning from the current iteration is not transferrable. I have lot of cuts in this space. Feel free to reach out to me.

As other replies have mentioned, Terraform is challenging to create a smooth experience. We have spent many cycles working on smooth orchestration so that it's fast and intuitive. Our primary motivation was to avoid hiding infrastructure behind proprietary technology.

We have support for other IaC tools on our roadmap so that each team can use what is comfortable.

We appreciate the honesty, but more importantly, we appreciate the willingness to try another one out. We welcome your feedback to see where we're doing things right or wrong.

This is something we support as well. You're correct that most of our documentation (including quickstarts) focuses primarily on web-facing apps.

Our current modules support running Python jobs using Fargate/ECS and Lambda (using Docker containers or packaged zip files).

Today, it is possible to pause workloads by destroying the app (nullstone down --app=<app>). Obviously, that's not ideal and we do have plans to support pausing workloads to reduce costs.

Gotcha, do you also provide functions to build and store docker images from a code repo?

We support auto build/deploy upon the launch of your application and then on every code commit to the branch configured. The docker image is stored in a container registry in your cloud account.

Outside of the auto build/deploy process, we don't yet support ad-hoc docker builds.

We are a Hashicorp Tech Partner (https://www.hashicorp.com/partners/tech/nullstone#all). This partnership requires that we're not competitive in nature.

We have plans on our roadmap to support other IaC tooling if Hashicorp makes future changes to their licensing that prevents this arrangement.

Kubernetes is a powerful platform. It has become a standard language for building and operating cloud/on-prem infrastructures. It will be the end point for how infrastructure is orchestrated and configured.

However, Kubernetes is more a primitive for infrastructure rather than a tool to build automation workflows for software teams. Our focus is to complement teams that may or may not choose Kubernetes.

Thanks for the feedback!

I do think that AI is going to have a massive impact on development including cloud infrastructure; however, we rarely see junior developers setting up cloud infrastructure because it is dangerous.

Our motivation is to make the cloud easier for all skill levels. In many organizations, this usually requires platform engineers or lead engineers that determine what works best with their technical strategy.

Our goal is to (yes, remove the arcaneness), but also remove the tedium and distraction from development.

> we rarely see junior developers setting up cloud infrastructure because it is dangerous.

So whom is this for?

Doesn’t this set up cloud infrastructure? Dangerous how exactly?

It’s not a tautology. Someone who can’t handle like, using AWS directly, is a junior developer.

Another perspective is the founderese is not very reassuring.

Sorry for the confusion. It's dangerous for junior developers to interact directly with cloud providers. Our motivation is to provide guard rails for developers of all skill levels to build and run their infrastructure without exposing their organization to risk.

Here are some dangers we've seen from our customers: - Misconfigurations that result in no backups, disabled encryption, etc. - Resources accidentally configured with Internet access - Exposing internal secrets or credentials in source code - Misconfiguration of IaC that results in destruction of databases

I'm not claiming that we have eliminated these dangers. Instead, our goal is to provide a platform for software teams to codify their security and compliance practices so that all developers on their team can avoid these dangers.

More senior folks can be specialized in other things, and be less than great at infrastructure code. I think I can hold my own when it comes to Terraform, but that doesn't mean I don't have to fight with IAM for longer than I care for, on the regular.

Thanks! Join our community slack or message me directly if you hit any issues setting it up.

Have you considered a community Discord?

We considered Discord, but went with Slack (mainly because we have dedicated support channels for customers).

If we provided a Discord, would that be more appealing to join?

Voice of 1: I prefer Slack so it's closer my work comms. Having a shared channel with y'all is infinitely easier than hopping between workspaces or apps.

For me yes. A lot of my professional communities use Discord. It seems like a pretty even split so I find myself using both and preferring Discord.

Thanks! We are not affected by the license changes. We are a tech partner with Hashicorp which requires us to not be competitors. If Hashicorp ever changes this position, we have plans on our roadmap to support other IaC tooling.