Hacker News new | past | comments | ask | show | jobs | submit login
Launch HN: Nullstone (YC W22) – An easier way to deploy and manage cloud apps
105 points by bsick7 18 days ago | hide | past | favorite | 64 comments
Hi HN! We’re Brad and Scott from Nullstone (https://nullstone.io), a developer platform to deploy and manage cloud apps and infrastructure. Here’s a demo: https://www.loom.com/share/924b1f57ba2143eeabb43ee8cbe3fe88?....

Running your app on a major cloud provider makes a lot of things easier, but it’s tedious to configure IAM, security groups, networking, secrets, autoscaling, health checks, zero-downtime deployments, and more. It is also difficult and time-consuming to release and synchronize app and infra changes across many apps and environments.

Nullstone provides an intuitive developer experience to deploy any app—be it an API, web app, static site, or one-off job—to AWS or GCP. We provide a simple, consistent experience for automatically deploying to any platform (e.g., Fargate, Kubernetes, Lambda, etc.). We provision and configure infrastructure depending on your use case (e.g., networks, clusters, datastores, load balancers, third-party logging providers, and much more). We offer many features that are hard to build in-house: automatic secrets management, GitOps, and preview environments.

Everything runs in your own cloud accounts. You own your data and we cannot access it. Secrets are stored in your secrets manager. We support all app types (e.g. APIs, web apps, frontends, jobs, etc.) and platforms (e.g. containers, serverless, s3 sites, VMs, etc.).

Instead of being a black box, our infrastructure modules are open source and you can hot-swap each module for your own Terraform. You can automate deploys and preview environments via GitHub integrations, CI/CD integrations, CLI, or API. All infra/deploy logs are easily accessible through the UI, CLI, and API.

We scan our modules against compliance frameworks to provide a foundation of compliance for your infrastructure. If there are vendors or platforms we don’t support, we provide a quick framework and open hooks to add support.

Nullstone is intended for software teams that don’t want to build an in-house platform. Our customers span many industries and have used us to reduce cloud costs by up to 90%, provide developer self-service, fully automate deployments, migrate to containers, and more.

Previously, we built an internal developer platform at McKinsey (serving 300 workloads across 1000 engineers) to solve a major pain point: engineers were building apps in weeks only to wait months to provision and secure infrastructure (and once provisioned, making changes to the apps was a frustrating back-and-forth process). Later I joined a cybersecurity company and as our team grew, I saw the same challenges: we were spending more time configuring infrastructure than building the product.

We decided to build Nullstone because no existing solution fit our needs. Some of the products we found were all-in-one solutions, meaning we had to sacrifice the tooling we liked and use infrastructure with insufficient security, compliance, and reliability controls. Other products, built for enterprises, provide a poor developer experience in exchange for costly licenses and significant internal resources to operate.

To provide a fully customizable experience that is easy-to-use for developers, we had to solve a few problems. (1) We had to present infrastructure as code configuration in a way that isn’t overwhelming, but allows for flexibility to handle various architectures. (2) We had to insulate developers from infrastructure-as-code errors that would confuse them, while maintaining a level of transparency that devs demand. (3) We had to build tooling around module development because infrastructure takes 10x longer than app code to get feedback on whether it’s working properly.

Nullstone is free for individual use. After that, we charge $100/user/month. A user is anybody committing code that is deployed through Nullstone.

Our docs are at https://docs.nullstone.io/ and our public roadmap is at https://github.com/orgs/nullstone-io/projects/1/views/1.

We would love for you to try it out and give us feedback, and we look forward to your comments!

We've been using Nullstone for a few weeks now, and it's been great. Definitely speeding up our infrastructure migration plans. The app is great, and keeps getting better with improvements launched on a regular basis. The best feature has been the support, though. Most of my questions were answered within minutes, and the team knows their stuff.

Your user was created 4 minutes ago just to reply this comment

That's correct, I don't usually hang out here, but I wanted to support what I think it's an awesome product and team.

I am a real person, and I'm not affiliated with Nullstone. This is me https://github.com/nicdev if you have any questions, feel free to reach out directly. Same username on Twitter/X

I create alts sometimes when I evangelize a company. I'm not always able to publicly acknowledge the inner operations of my employer.

Gotta start somewhere. A positive testimonial is awesome.

I'll plug in my 2 cents.. and yes, I just created a new account to give a thumbs up because Brad and Scott have been awesome in helping me get a whole array of infrastructure stood up as we migrate away from a system that uses puppet. If you have ever needed to read thru the dizzying array of AWSs docs or blog posts about how to do this, then you will be relieved at how easy Nullstone makes it.

They have a full suite of modules that most application can use out of the box to standup your infrastructure in minutes. Now there may be some uptime on learning the UI and how to connect modules together but spinning up and tearing down is easy. I just built a module for deploying an aurora instance that was not available within their registry, but with their help, I was able to code one up in a few hours and have it deployed before the end of the day.

Is there ever going to be another Dropbox?

B2C for developers is really something. Some junior in some huge org, is he going to put his AWS security credentials into a box and expense the $100 a month? Maybe.

It seems really against trend. You're making something for ultra-junior developers who are going to be asking ChatGPT (or whatever soon-to-be vendor LLM) for a solution, which can't interact with UIs. And how is your thing going to have more representation in a dataset than a docker compose file or whatever hackneyed idea is simple enough for this user to adopt?

> We offer many features that are hard to build in-house

I am just saying you should try asking ChatGPT with GPT4 for examples before you make this the premise. What was once super arcane is now just another blob of opaque bullshit Berkeley CS '23 is going to be copying and pasting into somewhere.

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.

I think you give ChatGPT too much credit. Sure, it'll give you a great algorithm in general languages, but in my experience it's still really bad with IaC for anything non-trivial.

These look all the same. I honestly don't know how people choose one over the other. It's like roulette, gotta pick a random one.

Yes, there are a lot of PaaS and Developer Platforms out there to choose from. In my past roles leading development teams, I always found it hard to make existing solutions fit because they were too black box and I couldn't customize or add the things I needed support for. I also had security and compliance considerations that were difficult to navigate because I wasn't in control.

The things unique to Nullstone are: 1. Nullstone launches everything to your cloud account. You keep full ownership of your data. 2. 100% of the infrastructure is launched using modules. You can add your own or customize the out-of-the-box modules to support whatever your use case. 3. Many other solutions just handle your apps (no databases or other infrastructure). Nullstone supports launching apps, datastores, any cloud managed service, and integrations with tools like Datadog, Twilio, Sendgrid, and more.

Hope that gives you an idea of how we differ from other solutions.

It is interesting that YC has invested in many of these similar PaaS already and they keep doing it. Some names that I have come across (all are YC backed):

- Nullstone

- Aptible

- Porter

- Flight Control

- Fly.io

I have a feeling I am missing more.

Can't blame them really, wrapping a few AWS calls in $lang and pitching it to VC as a "disruptor" is a decent techbro playbook. Don't hate the player, etc.

- Nucleus Cloud

- Argonaut

There's probably 3-4 more at least, can't think of them now.

Do they all use the same IaC (guessing Terraform..) under the hood?

I work for a company on the list (Aptible), and we do not use Terraform for our customer-facing infrastructure. We experimented with that approach a bit, but I didn't love it. The primary reason I didn't love it is because Terraform itself is prone to flakiness and failures that requires a real human to clean up. This doesn't matter if you're doing it on a small scale (i.e. if you're an SRE and it's just your infra), but doing it at any large scale for customers it just didn't make sense. I do think there's likely a path forward with more flexible tools like Pulumi and CDK, but those are going to have limits in terms of what they're capable of too.

I know less than I'd like about what some of the others on that list are doing, but for a majority of them, they're heavily k8s/Nomad based (which, we also aren't that either, but it's also something we've been poking around at), which lessens the dependency on IaC after you have the initial cluster up and running. Fly.io also has a problem which I consider potentially even more interesting, which is that they run their own severs, so most IaC doesn't even make sense.

Co-founder of Porter (https://porter.run) here - we do not use Terraform under the hood. We moved away from an IaC based system earlier this year to better manage our users' infrastructure distributed across multiple cloud accounts. A decision that definitely turned out to be conveniently prescient :)

With this new system, we are also able to immediately reconcile drifts that occur in our user's infrastructure, which an IaC based system did not allow us to do.

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.

Which ones deploy to your own cloud accounts?

(I'm the cofounder of Coherence)

I consider the "best-in-breed" tools with this shape to break into the following categories:

"Infra Abstractions": DuploCloud, Massdriver, Stacktape "PaaS in your own cloud": Nullstone, Zeet, Quovery, Porter, Architect.io, FlightControl "SDLC Platform for Teams": Coherence (withcoherence.com) - the key difference here is in how CI/CD (incl integration tests) are handled, how development environments are configured alongside other environments, and how production is segregated from other environments.

This a somehow both a crowded space and an emerging one. But we believe that even with the diversity of choice that there are clear reasons that most teams will by (vs. build) their internal dev platform in the future: namely the cost to buy vs. to build/maintain, and the productivity from better tools.

We are from DuploCloud and hence the following note might be biased. The downside of a pure paas solution like porter, Quovery at al. is that they have a limited scope say kubernetes, pieplines and diagnostics. All of the lower layers of the Devops stack from IAM, networking, AWS services (including non containerized workloads like Lambda, EMR, Airflow etc), scores of compliance and security controls are left out of scope. Then one needs a expert Devops to write boat loads of TF. Our apporoch is of a E2E platform that should do all of what a human devops manually scripts. Thus fundamentally deliver self-service, labor reduction and compliance.

I built yet another similar platform with the goal to keep accounts fully isolated, while it started with preview environments only, we started handling some prod deployments too.

There are nice perks on this approach but the complexity (for us) is non-negligible.

Kubernetes is kind of the intellectually honest, logical end point of this stuff.

That's like saying hammers are a logical end point of trying to get carpentry work done.

Kubernetes is an incredibly useful tool, but it needs at least one layer of abstraction (possibly multiple) on top of it to make it useful for the typical company that isn't doing anything out of the ordinary.

I think of kube as the new de-facto OS, just like Linux back then. Of course it needs config to make it useful for your needs but I think it's really the platform to target for the next decade at least.

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.

Qovery, Porter, and FlightControl are at least a few examples

My 2 cents, having been in the space for a while and then pivoting out of it. All devops first engineers thinking this is a problem, building something that is more like PaaS but then soon you will realise now not only you have convince engineering managers but also engineers. The total addressable market is fairly small for this type of product, you can throw in compliance guard rails but when an org becomes big they will leave your platform. If you find a customer, you should charge 100 or more as your long value is fairly small. Do checkout the list of PaaS here [1]

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

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.

$100/user/mo seems like way too much. The “contributing code that is deployed through Nullstone”. Makes it sound like you have to pay for the whole engineering team even if only a few devs are actually handling the deployments. Is that true?

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.

Great work and as a product guy, I find the preview environments feature explained on your website to be a potential game changer. Being able to spin up and seed environments on demand via pull requests keeps things very clean as I could just look at a particular branch in isolation without the need for fixed dev -> stage environments. By seeding the data, it also means I can "replay" the same scenario again if the developers deploy a change while in the review process.

Congrats on the launch! Are you affected in any way by the license changes made by Hashicorp?

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.

The product is interesting for an individual! However, my company will not accept product that are charged per user. I am based in Hong Kong, and often in Asia, we are hiring with engineers working remotely from Southeast Asia, due to a very low pricing per head.

It would be better if it's a total cost. In this way we could just put it side to side with our cloud billing.

I am looking for a service that helps me orchestrate the deployments of docker containers in AWS. These containers run Python workloads, but are not web-api endpoints. I want to be able to deploy them programmatically and, pause them if they've been idle (something like what supabase does). Is this something you are looking to provide?

From a quick glance at your docs, it seems that you are mainly focussing on web facing applications.

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.

Check out AWS Copilot CLI: https://aws.github.io/copilot-cli/

This is by far the best way to deploy compute into AWS in containerized workloads.

The abstraction you want is Jobs: https://aws.github.io/copilot-cli/docs/concepts/jobs/

Building this any other way on AWS would require provisioning multiple artifacts. The Copilot Jobs abstraction basically encapsulates the provisioning of those artifacts into one repeatable pattern.

Fully extensible with CDK and CF if the out-of-the-box workload abstractions aren't enough or you need deeper customization. I have found that the OOB abstractions are "right-sized" for most common workloads and rarely require extension aside from occasionally IAM when integrating with other AWS services.

AWS Copilot has been great for deploying `services`. But I wasn't sure if the `jobs` were what I was looking for, since they are event triggered. I'll test it our now.

Essentially I'd like to build a docker image of code from a repository, and deploy and run it, and manage its lifecycle. Perhaps I could copy the CF template from the Copilot to do the same.

> Essentially I'd like to build a docker image of code from a repository, and deploy and run it

Presumably, you're running it based on some input. Jobs are the right paradigm if this input is periodic (for example, processing a batch of items in S3 every few hours).

Otherwise, you may want to consider a Worker: https://aws.github.io/copilot-cli/docs/concepts/services/#wo... which can be connected to an SQS queue and activated by publishing messages to the queue.

Lifecycle management is a matter of using the delete commands:

    svc delete
    job delete
    env delete
    app delete
To de-provision.


Hope that helps!

Thanks a ton!

Nullstone does support this use case, all applications are private by default. In order to make them public, you would add a Load Balancer, CDN, or Api Gateway. In your case, just don't add this and your application will remain private.

We don't currently support the automatic pause of applications due to inactivity. However, we do support starting/stopping your app via the UI, API, or CLI.

Cool, could you point me a link to the API for deploying, starting, stopping the app?

We don't have our API documented yet but here is the documentation for the CLI. https://docs.nullstone.io/getting-started/cli/docs.html

To launch your application you would use the `nullstone up` command. To tear it down you would use the `nullstone down` command. To deploy your code, you would use the `nullstone launch`.

Each of these command are just making API calls under the hood. If you want to hop on our Slack channel, I'd be glad to share the details.

Looks great, and I'm excited to try it for a personal project (nice free tier). It looks like it can act as the entire devops team for my single-person project.

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.

Good to see tools like this. However, are you not affected by the recent change in the Terraform licensing?

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.

Congrats on the launch...

tbh, I have tried so many alternatives to this issue (as a Rails dev) and 'til today, I still find the oddest one of the all to be the only one straightforward enough to match the Heroku paradigm, that would be Hatchbox (which only dwells with Rails deployments).

I will give this a shot, but I'm skeptical. Also, I want to thank the Dokku team, since recently I tried a few deployments and while there was hiccups along the way, the platform has improved quite a lot since the last time I tried it.

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.

Dokku Maintainer here.

I'd love to get feedback from you on things that weren't great with your recent Dokku experience. If you want to shoot me a message, hit us up on discord/slack, or file a ticket on our github issue tracker, please do!



In terms of matching the simplicity of Heroku, I feel like Render is probably the closest thing to it.

I'm curious, anything in particular that you are skeptical about?

amazing progress here, very impressed

Hi - I'm a cofounder of https://controlplane.com I played with nullstone and it has some good elements but I didn't love it. It felt heavy, slow and the resulting infra isn't inexpensive.

We built Control Plane to give developers instant cloud-native maturity, allowing them to run their apps/services in a portable way, whether on AWS, Azure, GCP, Linode, Hetzner, Equinix, Oracle, on-premises or anywhere else. In fact you can run on 100 locations on 20 different providers with the same exact ease of use as running on localhost. no kidding!

On Control Plane you get instant multi-region, whether on one cloud, or multiple provider - with a TLS endpoints for your domain(s). You can configure subdomain based routing or path-based routing. You get consolidated (across regions) logs, metrics, tracing, alerting, audit trail, secrets management, service discovery across multiple locations, mutual TLS across services, service mesh, free image repository, all the observability you need and much more. It is the same exact effort to run in one region or a hundred. Geo-routing to the nearest region is baked in and so is automatic failover.

What's more, you can define IAM permissions in one place and move the workload across clouds while still consuming the UNION of ANY of the hundreds of services from AWS, GCP and Azure - without dealing with credentials and with least privilege/zero trust. In other words, you can be running on prem and still consume RDS, S3, SQS, SNS, DynamoDB, Big Query, Spanner, CosmosDB or ANY of the hyper-scalers' services from a single workload - regardless of where it runs.

In terms of cost, we don't charge by developer. We charge by MILLICORE of CPU and MB of RAM and your workload can scale based on many scaling strategies you choose from.

A typical node.js, GoLang or Rust app will cost you less than $2.00 per month per region when you enable Capacity AI, a technology built to optimize the consumption in an automated way - if you choose 10 regions, it will cost you $20. You don't pay for load balancers, NAT gateways, Internet gateways, K8s, secrets, certs, logs, metrics, tracing, etc. We are told it is the most cost effective way to run microservices or any other containerized apps. While you can run completely serverless (not as in Lambda, but as in no need to deal with servers or cloud accounts) - you can also bring your own account (or bare metal hardware in your basemet) and Control Plane-fy your account or hardware. When you bring your own account you do pay for NAT gateways, load balancers, internet gateways and K8s worker nodes (you don't pay for brain nodes). The platform optimizes and auto-scales your cluster automatically so you pay the least amount, regardless of hosting infrastructure.

While it is very inexpensive, I am more than happy to give free credits - just email me at doron at controlplane.com

Applications are open for YC Winter 2024

Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact