Launch HN: Argonaut (YC S21) – Easily Deploy Apps and Infra to AWS and GCP
I’ve helped build infrastructure tooling from scratch at multiple companies and realized two things: that the shape of the solution with the advent of containerization, Kubernetes, and hyperscalers is quite similar across orgs, and that highly knowledgeable engineers are needed to build and manage this system.
Internal infrastructure teams juggle a multitude of tasks—provisioning cloud infrastructure, configuring runtimes, building code, securing artifacts, running tests, and deploying at scale. Post-deployment, they're also tasked with monitoring app performance, errors, uptime, and cost visibility. It's a lot of work, and having to build this tooling in-house is a deep inefficiency in engineering teams. The root of the problem is that AWS and GCP provide a lower level of abstraction than the entities, such as environments and applications, that developers have to deal with, and a ton of work is getting duplicated, often by underfunded teams, across many orgs. Argonaut’s objective is to be the developer platform and control center that you would otherwise have to build internally.
Argonaut provides an intuitive developer experience that simplifies working with Kubernetes and enables developer self-service, reducing the burden on devops and platform teams. We've productized this workflow orchestration, incorporating best practices to provide a push-to-deploy experience with flexible pipelines and scalable infrastructure, all within minutes.
Our users are startups across various domains like healthcare, IoT, fintech, AI, and SaaS products. Over the last two years, we’ve enabled customers to scale their engineering teams 10x and manage 10+ environments in parallel without needing a dedicated infra/DevOps team, saving them precious time and resources.
Argonaut lets you set up production-ready infrastructure and customize as you scale. We then let you set up automated deployments of your application in minutes. We offer configurable build-and-deploy pipelines, powered by Dagger and ArgoCD, and deep integration with GitHub Actions and GitLab CI. In addition, we support container registries, multiple cloud accounts, observability stacks, cost visibility providers, CDNs, and the entire helm chart ecosystem of Kubernetes, with more integrations on the way.
Key features include: (1) easily create environments encapsulating cloud infrastructure, applications, and deployment pipelines (2) autoscaling deployments for apps and cronjobs to GCP and AWS with a progression across environments (3) compose deployments across multiple environments with our visual pipeline builder (4) get cost estimates before making infra changes, giving you a clear understanding of your expenses; (5) managed Terraform state and pre-built modules that just work, fostering team collaboration on infrastructure.
Argonaut is self-serve, so you can sign up and start using the product right away: https://ship.argonaut.dev. There is a free tier that doesn't require a credit card to get started. We'd be delighted to have you try it, and are happy to help with onboarding.
If your teams work with AWS, GCP, or Kubernetes, I’d love to hear about your experiences, pain points, and what you think a product like Argonaut should be able to do. Looking forward to your comments!
79 comments
[ 3.7 ms ] story [ 125 ms ] threadAs someone who saw the earliest version of the product, the product has come a such a long way! Congrats!
My only concerns would be: 1) do I have a realistic “exit strategy” or am I de facto locked into your platform and 2) as an old school engineer I don’t feel fully comfortable with a click-ops platform, unless it can generate terraform or similar.
There is no easy answer but here is my response: 1. We take precautions to enable connections through oauth/app mechanisms for VCS integrations and IAM roles for cloud accounts like aws and gcp 2. Our incentives are aligned - we make money only if we earn and keep the trust of our customers 3. We have gone to extra lengths to enable easy exits in case companies want to move out.
These, broadly speaking, are true for any other provider that you would use and may now trust for app hosting or CDNs or version control or payments - some of which are SmallCos and some were SmallCos until just a couple of years ago.
At some level, it all boils down to "trust us" but hope this provides context.
From a value perspective, we have a simple per-seat pricing.
I’m in the middle of a particularly annoying ops ticket so this hits home today haha.
Is that something that is easy to setup with Argonaut?
The console is really only meant for prototyping. AWS should really emphasize this more.
https://www.hashicorp.com/blog/terraform-1-5-brings-config-d...
I assume you are already containerized, so there is not much to be done. There is a one time setup of a kubernetes cluster (EKS) that aws takes about 25mins for.
This will give you a rolling zero down-time deploy out of the box along with a few other goodies. You can checkout a quick demo here (~4m) - https://www.youtube.com/watch?v=8DZsYXxA2tQ
Using Kubernetes in Azure (and this might be Azure specific), there isn't enough easy diagnostics via point/click for production issues. It is a nightmare trying to figure out why something happened and feels like you need to gain more expertise (at time sensitive times!) each time it does. Azure has improved over the years in this regard. But it might be a Kubernetes thing.
A cool feature would be "This pod stopped, and didn't restart for 10 minutes" and the reason is "{the reason in plain English}".
Kubernetes feels like a leaky thing to throw abstractions over, so the pain with using it is you need to become an expert in it, more so than the serverless offerings that are more genuinely abstracted, like the various app platforms that run the containers directly, or functions.
I guess even when managed by the cloud host, it is more serverful (e.g. the need to SSH into VMs to do security hardening checks), but then there is this beast running on those servers you need to understand too.
And at that point you need a lot of engineer time anyway and probably a platform separation to deal with it all.
So I think if your product could remove some of those kinds of issues it would be good - but then I am still trying to work out "why choose Kubernetes and not some sort of app service" for the majority of users (I am keeping an open mind!)
There is a little "bulb" icon on the top. That enables a "highlight mode" where you can select some text, usually kubernetes error messages. That is sent to an OpenAI LLM to (1) convert the error into plain english (2) show potential fixes.
This is limited by what GPT4 can provide but it is still helpful in some cases. Maybe we should highlight this feature more :)
> Kubernetes feels like a leaky thing to throw abstractions over, so the pain with using it is you need to become an expert in it, [..]
We believe two things: (1) k8s features exist because they are genuine user needs and we don't want to hide them (2) things get very complex very quickly because the "beast" is complex.
Argonaut's approach is what I call "Progressive Discovery". There is a good happy path that works for 80% of use cases. When you need to deviate, we make it easy to work with the underlying primitives to enable your use case. This enables users to move fast without hitting an abstraction ceiling and it keeps the complexity in check.
That said - Argonaut is not for everyone. If you have just a service or two, you're better off running it on a hosted runner instead of an aws or gcp or azure. It is going to be cheaper at small scale too.
It is unfortunate that this is necessary. This feels like a bodge instead of a fix for the underlying issue.
Are the error messages genuinely impenetrable / the wrong level of abstraction, or are they appropriate and the engineers simply lack the training?
I should point out that I'm not speaking down on the service or the people who use it. I think this is a useful and pragmatic feature, but it feels like those other issues should be looked at before we start throwing everything at LLMs.
However, in the Argonaut context, that only limits the overall infra management piece where we don't have a seamless integration using IAM roles and can't provision infra like dbs and queues. The app deployments to Azure kubernetes (or any k8s cluster) work seamlessly though, and some of our customers deploy to AKS in this manner.
It'd be interesting to know why they failed. I have to admit I got burnt a bit because we started to integrate with Koncrete and then they were out (and we've had to move away).
Does this work in AWS Gov, Azure Gov, Google Cloud Gov?
[...] in the Argonaut context, that only limits the overall infra management piece where we don't have a seamless integration using IAM roles and can't provision infra like dbs and queues. The app deployments to Azure kubernetes (or any k8s cluster) work seamlessly though, and some of our customers deploy to AKS in this manner.
We do not support gov cloud yet.
Does there exist a tool that gives me a fully abstracted layer like Heroku, but on my own AWS account? When I say fully, I mean fully. Where the tool will do maintenance, alert me a few days before it does it, autoremediation if something goes wrong, etc.?
I essentially want the exact same functionality as Heroku, but with the cost savings of running it on my own infrastructure.
For example, in addition to traditional applications, we run: - Kubernetes + Knative - Apache Pulsar - ScyllaDB - Elastic - Clickhouse (soon)
How would Argonaut help us with our (frankly, painful) infra? We're living in YAML hell over here.
The way Argonaut would help is by managing the configs and deployments in one place for easy collaboration and deployment, across environments and having GitOps with secret management for all the configs.
Did you ever consider using Amazon ECS instead of Kubernetes? I made the move from EKS to ECS a couple of years ago, because ECS doesn't require you to pay for your own cluster control plane, and I feel that ECS integrates more seamlessly with the rest of AWS. I suppose that also means more AWS lock-in, but the Linux-based container images themselves are still portable. And overall, I've found that ECS is just less complicated and lower-maintenance than Kubernetes.
But AFAIK, neither GCP nor Azure has an ECS-style shared container orchestration service. I wonder why that is.
Isn't this what Cloud Run on GCP is supposed to be? Or am I misunderstanding?
With Argonaut, we try to make EKS easier to use than ECS to bring the best of both worlds. We handle the kubernetes version upgrades as well.
It’s great to see all the amazing tooling being built into this space. Other companies to check out include flightcontrol, architect, quovery, Coherence (withcoherence.com - disclosure that I’m a founder), stacktape, and zeet.
I know a guy running a startup, and his product and/or CICD pipeline has been broken twice by EKS upgrades. He had originally contacted someone in to build out a robust, scalable, self-healing infra 2 years ago. He then continued to work on the product code himself. Be didn't realise that the infra code would rot so badly until a forced EKS cluster upgrade broke stuff. He had no idea where to start. There isn't an easy upgrade path from 1.1x to 1.27. I told him he might be better off thinking of it a disaster recovery, ie: get his data across to a new cluster, bootstrapped with the latest charts for cert-manager, external-dns, nginx-ingress etc. In many cases he could `helm get values -n $namespace $release` and install the latest chart with the backed up values.
Are there any plans to support private clouds in future?
This product (and all the PaaS abstractions for kubernetes) introduce something called '200% problem' where you have to not only issues in kubernetes now but also fix platform issues.
Platforms like these existed since the dawn of cloud. I think the space is super crowded but no one has actually cracked this market. I think the total addressable market is fairly small for selfhostable PaaS.