Launch HN: Nullstone (YC W22) – An easier way to deploy and manage cloud apps
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 ...
66 comments
[ 2.9 ms ] story [ 106 ms ] threadIf we provided a Discord, would that be more appealing to join?
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.
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 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.
There are nice perks on this approach but the complexity (for us) is non-negligible.
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.
- Nullstone
- Aptible
- Porter
- Flight Control
- Fly.io
I have a feeling I am missing more.
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.
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.
We have support for other IaC tools on our roadmap so that each team can use what is comfortable.
- Argonaut
There's probably 3-4 more at least, can't think of them now.
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
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.
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.
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.
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.
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.
We have plans on our roadmap to support other IaC tooling if Hashicorp makes future changes to their licensing that prevents this arrangement.
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.
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?
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!
https://dokku.com/docs/getting-started/where-to-get-help/
From a quick glance at your docs, it seems that you are mainly focussing on web facing applications.
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.
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.
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:
To de-provision.https://aws.github.io/copilot-cli/docs/commands/app-delete/
Hope that helps!
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.
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.
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.
Outside of the auto build/deploy process, we don't yet support ad-hoc docker builds.
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.
[1] https://github.com/debarshibasak/awesome-paas
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.
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
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.