pmig

This is a problem we, as a company, have thought about a lot, but we always concluded that Kubernetes is already the simplest abstraction of a distributed system that is feasible for the diverse needs that the biggest companies out there have.

We previously built a package manager for Kubernetes to abstract it in the simplest way possible `glasskube install app` but we failed because every abstraction needs to follow a "convention over configuration" pattern at some point. Also, we weren't able to monetize a package manager.

With Distr (https://github.com/distr-sh/distr), we have actually been able to help companies not only package but distribute and either manage or give their customers a way to self-manage applications. Our customers are able to land on-premises contracts at enterprises way faster than before, which is also a clear ROI for paying for Distr.

So, I don't think that you can get the flexibility of a distributed application orchestrator with a simple declarative YAML file if your target environments are diverse.

To be honest I never really understood the benefit of Docker (Compose) Secrets - which is different from Swarm Secrets. Imho there just plain host mounted volumes, which are hidden from inspect commands?

What are the benefits of running Podman Compose instead of Docker Compose? I don't see how it helps with orphan containers, logs and mutable tags.

Good luck, and keep us posted.

You can use it for IoT use cases for sure. Although our software is compatible with Windows, it does not explicitly perform operating system management or the tasks that you typically need to handle in an IoT environment.

Nice to hear, feel free to leave any feedback while exploring Distr.

I think that Dokku [1] https://dokku.com/ is actually the closest to what you are building.

We are actually building in a similar space with Distr [2] and happy to jump on a quick call.

[1] https://dokku.com/

[2] https://distr.sh/docs/

Congrats on building your custom delivery platform. We understand your pain ;-). Any specific pain you want to share or feature you are still missing in your solution?

We’re happy to help you migrate to Distr if you decide you no longer want to maintain your solution or if you’d like to benefit from regular updates and continuous improvements.

Distr SaaS is configured for USD only (via Stripe) for simplicity, but EUR payments are definitely possible (either via Stripe, SEPA, etc.).

Thanks for sticking around! Yes indeed, Distr already has a lot of features and can replace many other tools in your deployment stack (e.g., CI, log collection, alerts, licensing, secrets, OCI registry, customer & user management).

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?

Sure, happy to follow up with a detailed comparison.

TL;DR: Octopus Deploy has a strong focus on CD, providing a Cloud based framework to push your software to multiple targets. Distr also supports directly and continuously deploying your software to various deployment targets, but it additionally supports the pull approach, where the customer fully self-manages their infrastructure and simply fetches the application or artifacts from Distr.

Octopus Deploy also offers deep Argo CD integration (after they acquired Codefresh). On the other hand, Distr is completely open source and can be self-hosted if desired.

If you’re interested in specific features, I’m happy to go into more detail.

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.

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

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

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/

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?

Hi HN, I am Philip, one of the creators of Distr and happy to answer questions.

Thanks. If you are referring to how we handle large OCI images for our OCI-compatible container registry, we create a temporary volume and stream/cache the layers there before streaming them to S3-compatible storage. This mitigates the need to keep large layers in memory, which previously led to memory resource exhaustion.

If want to dig even deeper, this specific implementation was done in this pr: https://github.com/distr-sh/distr/pull/1478

I am still waiting for the day where gMessage (currently called "Messages, Hangouts, or who knows what) & iMessage will be interoperable. The RCS standard is already out there

Thanks god we built all our infra on top of EKS, so everything works smoothly =)

Indeed, they are really pretty similar, but ours is actually also Open Source: https://github.com/hyprmcp/mcp-install-instructions-generato...

After taking a closer look at MCPCat the implementation is quite different for MCPCat you need to integrate a SDK and HyprMCP works as a proxy in front for your already existing MCP server.

The token spend only increases due to the additional parameter names and descriptions, right?

Congrats on the Launch, we build something similar [1], but opted to make name also optional to reduce friction even more. We also built an MCP server that serves these installation instructions :-)

[1]: https://github.com/hyprmcp/mcp-install-instructions-generato...

There is also a first party registry[1] in development, hopefully becoming the next artifact hub for MCP servers.

[1]: https://github.com/modelcontextprotocol/registry

Interesting, have you thought converting the MCP server to a remote http server?

Most software we install locally is at least distributed via a trusted party (App Store, Play Store, Linux package repos, etc) and have a valid signatur (Desktop & Mobile) or are contained in some way (containers, browser extensions, etc..).

In the case of MCP, remote servers at least protect you from local file leakages.

That's a good point, we really think that the future of MCP servers are remote servers, as running "random" software that has little to no boundaries, no verification or similar shouldn't be a thing. Is there a specific reason, you prefer stio servers over http servers? Which servers are you using?

Thanks for the mcpb hint, we will look into it.

This is actually a huge milestone and can be similar to ArtifactHUB in the CNCF space. ArtifactHUB generally is a great place to publish and look up Helm charts. Especially verified and and official badges help a lot.

[0]: https://artifacthub.io/

The general challenge with auth is which IdP to use in the backend.

This is actually a huge milestone and can be similar to ArtifactHUB in the CNCF space. ArtifactHUB generally is a great place to publish and look up Helm charts. Especially verified and and official badges help a lot.

[0]: https://artifacthub.io/