[HN Gopher] Show HN: Distr 2.0 - A year of learning how to ship ...
___________________________________________________________________
Show HN: Distr 2.0 - A year of learning how to ship to customer
environments
A year ago, we launched Distr here to help software vendors manage
customer deployments remotely. We had agents that pulled updates, a
hub with a GUI, and a lot of assumptions about what on-prem
deployment needed. 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.
Author : louis_w_gk
Score : 57 points
Date : 2026-02-10 12:19 UTC (10 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| pmig wrote:
| Hi HN, I am Philip, one of the creators of Distr and happy to
| answer questions.
| rudasn wrote:
| Hi Philip!
|
| We 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?
| louis_w_gk wrote:
| We already have a customer portal where you can display any
| information you want for your customers. We also provide
| container and deployment logs, as well as alerts in the
| platform, so you can immediately see if an update failed and
| what went wrong. Release notes are already on our roadmap,
| and a lightweight issue tracker has also been requested.
|
| Scheduled updates are currently not on the roadmap, but we'd
| be happy to scope that feature together and add it.
|
| I think Distr could be a great fit. If you're interested, I'm
| happy to walk you through the platform in a quick demo:
| https://cal.glasskube.com/team/gk/distr-demo
| rudasn wrote:
| Thanks:)
| mrbluecoat wrote:
| Is it just meant for software or also IoT use cases, like
| https://github.com/balena-io/open-balena ?
| leetrout wrote:
| Any chance you would consider avoiding the SSO tax and making it
| available for all tiers?
| pmig wrote:
| SSO (Google, Microsoft, GitHub) is available on all tiers.
| Custom OIDC provider support is even available in our ~MIT~
| (Apache2) licensed community edition if you self host Distr.
| Even TOTP MFA is available for all users and part of the
| community edition.
|
| How can we improve in reducing SSO tax?
| leetrout wrote:
| Starter package does not show SSO as being available. Thanks
| for clarifying https://distr.sh/pricing/
|
| I see Apache 2 licensed code in your GitHub but not MIT. Is
| there another repo or that's what you were referring to?
| pmig wrote:
| Custom SSO integrations often require specific development
| and are therefore not available in our beginner tier.
|
| Oh my bad. Our repository[1] is obviously Apache2.0
| licensed, not MIT. Thanks for pointing that out.
|
| [1] https://github.com/distr-sh/distr
| medv wrote:
| we may be interested in it.
|
| how does it handle very bad internet connection on-prem?
| pmig wrote:
| Feel free to reach out via our website[1]. Distr does not
| require an internet connection to keep your application
| running. Update commands are fetched directly from the agent
| and do not require any special connectivity.
|
| Updates are pulled before the rollover to a new version is
| performed, so a poor internet connection may only affect the
| download speed of new updates. Distr is designed to operate
| even when no connection is available, or when connectivity is
| only allowed in short time slots.
|
| [1] https://distr.sh/contact/
| abtinf wrote:
| How does Distr compare to Replicated?
| louis_w_gk wrote:
| Distr is a modern Open Source alternative to Replicated. We
| have a more in-depth comparison over here
| https://distr.sh/compare/replicated/. If you have any
| questions, I'm happy to help.
| solarkraft wrote:
| > A vendor is typically the author of a software / AI application
|
| Can you explain how ,,AI Application" differs from ,,Software" in
| your model?
| Valodim wrote:
| Man. I absolutely hate that the term AI just has to be
| meaninglessly sprinkled over every single piece of marketing
| material now.
|
| I don't even hate the player, it's just what you gotta do to
| run a business now. But man I can't wait for this chapter of
| the game to be over.
| pmig wrote:
| I feel you, but a huge percentage of recently funded
| companies are in the AI space. Software distribution for them
| is even more complex due to all the moving parts, and we want
| to make sure these companies know that our solution is a
| great fit for them.
| pmig wrote:
| Sure, multiple of our customers that distribute applications
| with a machine learning/AI component also need to distribute
| their models. They can use our OCI registry to distribute large
| images with huge layers. We specifically reworked our registry
| implementation to storing in-transit blobs on disk to save
| memory, ensuring the application doesn't run out of memory [1].
|
| [1] https://github.com/distr-sh/distr/pull/1478
___________________________________________________________________
(page generated 2026-02-10 23:00 UTC)