[HN Gopher] Show HN: Distr - open-source distribution platform f...
___________________________________________________________________
Show HN: Distr - open-source distribution platform for on-prem
deployments
Distr is designed to help software engineers distribute and manage
their applications or agents in customer-controlled or shared-
responsibility environments. You only need a Docker Compose file or
Helm chart--everything else for on-prem is handled by the platform.
We're are an open source dev tool company. Over the past couple of
months, we've spoken with dozens of software companies to
understand their challenges with on-prem deployments. We analyzed
the internal tools they've built and the best practices from
existing solutions, combining them into a prebuilt, Open Source
solution that works out of the box and integrates seamlessly.
Distr consists of two key components: 1. Hub - Provides a
centralized view of all deployments and controls connected agents.
- Comes with a simple GUI but also supports API and SDK access for
seamless integration. - Fully Open- Surce and self-hostable, or you
can use our fully managed platform. 2. Lightweight Agents - Pre-
built agents for Helm (Kubernetes) and Docker Compose (VM) that run
alongside your application. - Handle lifecycle tasks like guided
installation, updates, and rollbacks. - Provide basic metrics
(health status, application version) and logs If you already have
a customer portal or self-service interface for on-prem
deployments, you can seamlessly integrate all features into your
existing portal or application using our API or SDK. Alternatively,
you can use our pre-built, white-labeled customer portal. Here's
what an integration into your existing customer portal could look
like: import {DistrService} from "@glasskube/distr-
sdk"; const customerHasAutoUpdatesEnabled = false; //
replace with your own logic const deploymentTargetId =
'da1d7130-bfa9-49a1-b567-c49728837df7'; const service = new
DistrService({ apiKey:
'distr-8c24167aeb5fd4bb48b6d2140927df0f' });
const result = await service.isOutdated(deploymentTargetId);
if(result.deploymentTarget.deployment?.latestStatus?.type !== 'ok')
{ // let the user decide whether to allow updates from an
instable state, e.g. with: if(!confirm('The deployment is
not in a stable state. Do you want to update anyway?')) {
return; } } if(result.outdated) {
if(customerHasAutoUpdatesEnabled) { await
service.updateDeployment({deploymentTargetId}); //
notify customer about the update } else {
const newerVersionsAvailable = result.newerVersions;
// notify customer about the newer versions, e.g. via email
} } With the SDK/API, you can: - Display
real-time deployed version and deployment status directly within
the application, notifying customers when their deployed version is
outdated. - Allow customers to trigger updates from within your app
using a simple API call If you're distributing software and want
to streamline updates or enhance monitoring, we'd love your
feedback and are here to answer any questions. Getting started is
easy--just bring your Docker Compose file or Helm chart, and we'll
guide you through the rest. Check out the fully managed version
(https://app.distr.sh/register) and explore our documentation
(https://distr.sh/docs/) to learn more.
Author : louis_w_gk
Score : 42 points
Date : 2025-01-29 16:21 UTC (1 days ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| rudasn wrote:
| This looks super cool and useful! I really like the idea of an
| open source replicated.
|
| I've been through the docs and could find if there's a way to
| deploy a git repo, or a tar file, that contains the docker
| compose file instead if copy pasting. What about env variables?
|
| Also couldn't find how you specify the endpoint(s) of an app.
| Does the agent just calls `docker compose up` or is there a way
| to specify the command(s) that should be executed during
| installation, upgrade, etc.
|
| The customer portal is a great idea. It's not clear though, if
| the customer portal is enabled for a deployment and the customer
| can manage their deployment (eg, update to new version), would
| the isv not be able to do that from the vendor portal? Is it all
| or nothing when it comes to client self-service?
|
| Thanks, great stuff I look forward to trying it out!
| pmig wrote:
| Thanks!
|
| > I've been through the docs and could find if there's a way to
| deploy a git repo, or a tar file, that contains the docker
| compose file instead if copy pasting.
|
| We are currently developing a GitHub Action utilizing our SDK
| to upload latest releases (and provide paths to the docker-
| compose file).
|
| > What about env variables?
|
| These are high up in our backlog and we are looking for initial
| partners to specify them with. We thought about using end-to-
| end encryption for env variables.
|
| What would be an example for an endpoint?
|
| > `docker compose up` Yes currently this all what the agent
| does. We assume that most applications handle upgrades inside
| their applications and not on an infrastructure level. Do you
| have an exact upgrade case in mind?
|
| Regarding the vendor and the customer portal, we want to enable
| both options. A deployment can either be managed by the vendor
| or by the customer. Some customers want to control when they
| want to perform upgrades and set certain variables or helm
| values themselves. In other cases it is fine if the ISV does
| all the management.
|
| This is also what might be configurable in the future.
|
| Thanks again, let us know if you know how can improve Distr.
| All feedback is welcome.
| hobofan wrote:
| Very cool!
|
| I'm a big fan of the trend of on-premise deployable software
| standardizing on Kubernetes/Helm as a deployment method. From my
| perspective as an external freelancers it provides a nice hand-
| off point to the internal IT/devops team.
|
| Looking forward to trying this out on future projects!
|
| ----
|
| I'm wondering how this relates to the glasskube package manager?
| Obviously you just launched, and maybe you are still in the
| discover phase, but is the general idea that this is the
| enterprisey incarnation of the glasskube ideas, and that it will
| over time gain similar features as the existing glasskube?
| pmig wrote:
| Good question, the Glasskube package manager is an alternative
| to Helm. As Distr is the management / distribution layer the
| layer connecting the deployment target to the ISV. On the
| deployment target the software gets installed via docker-
| compose, Helm or - in future - with the Glasskube Package
| Manager. The features don't really overlap they complement each
| other.
| popalchemist wrote:
| Wow. Very impressed, going to look into this.
| louis_w_gk wrote:
| Thanks, let us know what you think!
___________________________________________________________________
(page generated 2025-01-30 23:00 UTC)