4 ms·
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 https://app.distr.sh/register) and explore our documentation (https://distr.sh/docs/ https://distr.sh/docs/) to learn more.
- deleted 2y ago[deleted]
- rudasn 2y agoThis 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 2y agoThanks! > 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.
- rudasn 2y ago> a GitHub Action utilizing our SDK to upload latest releases Cool. So the tar would be uploaded to the hub and from there the user can manage deployments. Or maybe even create draft? deployments from the gh action and the user would only have to confirm/approve before shipping to clients. > Do you have an exact upgrade case in mind? Yeah, some apps could get quite complicated due to <reasons> and a single `docker compose up` for deployment won't cut it. For example, user may need to do a backup before deployment or some post deployment steps like db migrations. These steps may depend on which app version you are updating from, so even though they can be handled from within the app some logic/state is needed to determine when to execute them. The ability to specify pre-deploy, post-deploy and a custom deploy command (not just docker compose up) would be helpful. > A deployment can either be managed by the vendor or by the customer. But not both? Can't the customer invite the vendor back to allow them to perform such actions when necessary? The customer portal is a good idea, the ux needs a little polish I think. Make it super easy to see if there's a new app version, a button to install it, and perhaps real time feedback/progress. Some customers would also appreciate the ability to export a list of app deployments with logs for auditing.