Show HN: Distr 2.0 – A year of learning how to ship to customer environments (github.com)
It turned out things get messy when your software is running in places you can't simply SSH into.
Over the last year, we’ve also helped modernize a lot of home-baked solutions: bash scripts that email when updates fail, Excel sheets nobody trusts to track customer versions, engineers driving to customer sites to fix things in person, debug sessions over email (“can you take a screenshot of the logs and send it to me?”), customers with access to internal AWS or GCP registries because there was no better option, and deployments two major versions behind that nobody wants to touch.
We waited a year before making our first breaking change, which led to a major SemVer update—but it was eventually necessary. We needed to completely rewrite how we manage customer organizations. In Distr, we differentiate between vendors and customers. A vendor is typically the author of a software / AI application that wants to distribute it to customers. Previously, we had taken a shortcut where every customer was just a single user who owned a deployment. We’ve now introduced customer organizations. Vendors onboard customer organizations onto the platform, and customers own their internal user management, including RBAC. This change obviously broke our API, and although the migration for our cloud customers was smooth, custom solutions built on top of our APIs needed updates.
Other notable features we’ve implemented since our first launch:
- An OCI container registry built on an adapted version of https://github.com/google/go-containerregistry/, directly embedded into our codebase and served via a separate port from a single Docker image. This allows vendors to distribute Docker images and other OCI artifacts if customers want to self-manage deployments.
- License Management to restrict which customers can access which applications or artifact versions. Although “license management” is a broadly used term, the main purpose here is to codify contractual agreements between vendors and customers. In its simplest form, this is time-based access to specific software versions, which vendors can now manage with Distr.
- Container logs and metrics you can actually see without SSH access. Internally, we debated whether to use a time-series database or store all logs in Postgres. Although we had to tinker quite a bit with Postgres indexes, it now runs stably.
- Secret Management, so database passwords don’t show up in configuration steps or logs.
Distr is now used by 200+ vendors, including Fortune 500 companies, across on-prem, GovCloud, AWS, and GCP, spanning health tech, fintech, security, and AI companies. We’ve also started working on our first air-gapped environment.
For Distr 3.0, we’re working on native Terraform / OpenTofu and Zarf support to provision and update infrastructure in customers’ cloud accounts and physical environments—empowering vendors to offer BYOC and air-gapped use cases, all from a single platform.
Distr is fully open source and self-hostable: https://github.com/distr-sh/distr
Docs: https://distr.sh/docs
We’re YC S24. Happy to answer questions about on-prem deployments and would love to hear about your experience with complex customer deployments.
11 comments
[ 5.7 ms ] story [ 57.7 ms ] threadWe develop one or more apps that we deploy on-prem. An app for us is a git repo with a docker compose file. On-prem is either a Linux server or a Linux vm that we have ssh access to (normally via Wireguard vpn).
For app updates, we use ansible to ssh into machines, run pre-deployment scripts, pull git repo and docker images, restart containers and run post-deployment scripts.
It could be better, but it works for us.
The biggest bottleneck we have now is communication with customers, scheduling of updates, letting them know of breaking changes or new features, that kind of stuff.
The apps are provided "fully managed". They dont know and don't care about the details I just described, but they do need assurances that everything is done "properly".
What we think would help us a lot is a way to easily let them know of new releases of any apps they have installed, let them read release notes, docs, and be able to either deploy on-demand or schedule a deployment at a certain time.
Although having fewer things for us to do is nice, what is crucial is to oversee deployments and make sure they are successful (and intervene if not).
Is distr for us?
how does it handle very bad internet connection on-prem?
Can you explain how „AI Application“ differs from „Software“ in your model?
Have you considered the perspective that this could be used for internal deployments of product as well to multiple clusters/environments?
It puts a lot of pieces together end to end that are missing from building a deployment system around the defaults ArgoCD etc. There's a substantial gap between ArgoCD and getting to automated CI/CD with multi cluster support etc.
Users definitely also use us for internal deployments, but there are some trade-offs you’ll need to make compared to the zero-config setup you get when deploying your Next.js app to Vercel on the one hand, and the hardcore customization you get when running your own GitOps/Terraform setup on the other.
Is there any specific feature you’re missing, or is it just that our website doesn’t really highlight that use case?
We've spent over a year creating a delivery platform based on ArgoCD that bundles a git server and a registry (for air-gapped clients) so that we can deliver our products into various customer environments. This pretty much does it all, but with bells and whistles on top! Nice!
Curious why the pricing page doesn't seem to allow Euros and yet its an option?