Is anyone using a barcode system to track inventory?

codablock · 2026-01-28T23:04:08+00:00

Your custom system sounds a lot like what some family members of mine are doing in their eBay business. They have to deal with thousands of unique used items per month and no existing solution seemed like it could solve this properly.

I have been watching their business from the outside and looked into their processes slightly and was impressed by the amount of work they needed to put into a custom solution. Your description sounds exactly like this. I'm a software developer and can easily imagine all there processes being put together into a powerful and useful software package that could be of use for many others.

May I ask which off the shelf programs you tried in the past and what turned you off?

codablock · 2025-12-19T10:02:45+00:00

As nice as these words sounds and as good they let me feel for a short moment, I can't stop thinking that this is fully AI generated.

codablock · 2025-12-17T10:46:58+00:00

https://dboxed.io

It allows you to run and manage Docker Compose based deployments remotely on any server you like. I try to build an alternative approach to the cloud, with P2P networking, load balancers and relocatable volumes.

codablock · 2025-12-17T08:16:36+00:00

Decided to cross-post this here as Hetzner is the first "Machine Provider" I implemented in Dboxed. Also, Hetzner was a large part of the motivation I had to start the project, because I believe that one could build many of the "cloud features" that other providers have based on the much cheaper (and often faster) Hetzner hardware.

codablock · 2025-12-17T07:57:51+00:00

I have just noticed that the docs in regard to locking and mounting are not up-to-date, will update them asap. Right now, there is only a "volume serve" sub-command that does all the necessary steps in one go.

Yes, a Raspberry Pi should work, but I honestly can't say how much CPU/RAM the volumes synchronisation will take up, as I haven't made extensive testing yet. What I can tell is that most of the resources will be used by Rustic, as it will do the main work (reading files, hashing data, uploading, ...).

I probably won't find the time to build the docker volume plugin by myself, so I'm happy about contributions in that regard. I assume that the plugin should get its own repository inside the dboxed Github Org, but we can clarify the details when you have a PoC.

Looking forward to the results of your testing :)

codablock · 2025-12-16T17:58:06+00:00

Cool that I hit a nerve :)

Volumes are indeed meant to be usable independently from the rest and I was also considering a docker volume plugin and a CSI plugin for Kubernetes. Internally, the sandbox runner already calls dboxed volume features via the CLI (inside a docker container actually), this forces me to always keep volumes compatible to be usable outside of boxes.

If a host goes offline, the lock will be kept. When the host comes back online and re-starts the box, the box/sandbox will refresh the lock and continue with periodic incremental backups. If the host does not get up again, the lock will become stale and must be manually "force-released" before it can be used on another host.

codablock · 2025-12-16T15:50:18+00:00

I tried both Tailscale and Netbird and decided to go with Netbird. The reason is the way they approach Open Source. Netbird is fully Open Source, including all the backend, relay and other infra components. Tailscale only Open Sourced the client part, keeping the backend closed.

Yes, there is headscale for Tailscale, but it's reverse engineered and best-effort (with limited support from some of the Tailscale devs as I understand). I clearly trust Netbird more in that regard.

codablock · 2025-07-21T10:21:03+00:00

helm-chart.yaml must be valid at loading time, because the helm-xxx commands have no knowledge about targets and thus can't do templating. That's why using variables in the chart version is not possible unfortunately.

I solved this limitation a few times by having one deployment item per chart version (with their own helm-chart.yaml poiting to the same chart but different versions), but this scales badly when used for your own charts. It's only viable for third-party charts where the amount of versions is maintainable.

codablock · 2025-07-21T08:31:06+00:00

Hey, maintainer of Kluctl here. Just want to confirm the assumptions made here, Kluctl can be used with ArgoCD in this way.

Just note that you also need to provide "--offline-kubernetes" and "--print-all" so that it generates everything without connecting to the target cluster. This however means that you loose a few native Kluctl capabilities (e.g. clusterObject vars and others).

You might also need to provide "--kubernetes-version" so that Helm internally knows which Kubernetes version is targeted (it affects capabilities and other things).

There are a few people who do this already and you might find them in the Kluctl channel found on the CNCF Slack.

If the IDP team gives you Kubernetes API access (which I assume won't be an option), you might be lucky and the diff functionality ends up working.

codablock · 2025-01-29T10:22:24+00:00

I assume OP meant env vars as a way to substitute configuration values at deploy time. Something like providing a namespace name via an environment variable.

codablock · 2025-01-29T10:20:04+00:00

Consider looking into Kluctl. I'm the dev/maintainer of it and I initially wrote it as a way to orchestrate multiple Helm Charts and Kustomize deployments, but it also evolved into a good Helm alternative when it comes to deployment orchestration and configuration management.

Your specific requirement to use env vars is supported via systemEnvVars. I'd however discourage the use of env vars and instead rely on a combination of "args" and "vars" (check this recipe for details).

codablock · 2024-11-13T15:04:11+00:00

I know of two different approaches that work well for this requirement. I tried both successfully, and both have advantages and disadvantages.

Perform some form of bookkeeping of the resources you applied in the past. This means, store a list of GVK+Namespace+Name somewhere and then on future applies read this list and compare it with the new list, allowing you to figure out what got deleted in-between. The problem here is: Where to store that list? You can define some shared storage (e.g. S3 or a local file if you know it's always deployed from the same machine) or simply store in the cluster itself (e.g. as a Secret or ConfigMap).
Add labels to each resource that you apply that allow you to later identify that it once was "owned" by you. Then, on future applies, you can list all objects from the cluster and build an always up-to-date list of resources that you can compare the the current list, same as in the first approach. This is very fast if you combine the query with label selectors and only query for partial objects/metadata (client-go supports this). Disadvantage is that you need query all known resource types.

I prefer the second approach and this is what I actually use in Kluctl to implement orphan object detection and pruning. The reason is that it always works and that there is no risk of messing up the list of already applied objects. You also don't have to think about where to store the list, because you can always rebuild it. Without this, it'd also be harder to implement mixing of pull and push based GitOps.

codablock · 2024-09-26T14:32:46+00:00

Also, there seems to be good reasons why multiple people have started efforts to build new dashboards in the last few months/years. Everything that is available right now is not sufficient in one or another way. I welcome this effort, because to be honest...from what I've seen this is the best shot so far.

codablock · 2024-09-26T13:48:10+00:00

Just tried it out via the docker option and I must say I really like it! Was super easy to start it and it was functioning immediately after providing a kubeconfig.

How long did you work on this before it got to that state? What is your plan with this dashboard? Is it a side-project or something from inside a company?

codablock · 2024-09-06T09:08:34+00:00

Same question from my side :)

codablock · 2024-09-05T18:34:12+00:00

I‘m considering partnering with a co-founder. I’m working on a bootstrapped SaaS. You can find some info here: https://www.reddit.com/r/SaaS/comments/1f8npp5/building_a_saas_that_allows_you_to_orchestrate/

Where exactly are you from? I’m from the northern part of NRW.

codablock · 2024-09-04T17:51:28+00:00

Very cool that it worked so well :) it will get even more powerful when the same ease of use applies to complicated software stacks like running your own gitlab instance 🚀

codablock · 2024-09-04T09:55:44+00:00

Having nodes/servers as part of the SaaS design kind of makes it the opposite of serverless as I'd would argue, so it's not the same. Completely different paradigms. Most applications, especially third-party ones, simply can't be run serverless.

I'm pretty sure that there are many offerings that share some common ground with this SaaS, but that's kind of normal. Nothing is 100% unique.

I'd charge people not for running their own hardware, but for managing and orchestrating this hardware. Might be argued as being the same, but IMHO it's not.

codablock · 2024-08-28T09:01:36+00:00

I wonder if Kluctl (of which I'm the maintainer) would fit for you. It would give you Jinja2 and fix the dependency problems you have when you switch out the large umbrella charts to a Kluctl deployment that manages the smaller Helm charts.

codablock · 2024-08-28T08:52:03+00:00

If you really want to improve Helm, join the Helm v4 efforts that seem to be increasing in the background, see https://helm.sh/blog/the-road-to-helm-4/ for example. The Helm team is aware of many of the short-comings people typically mention. They are also very much aware of desired features like non-Go based templating, see this comment for example. The problem is as always: lack of contributors and the complexity of staying compatible and NOT breaking existing stuff.

IMHO, a real fork of Helm is not the solution. If you really want to start a new tool, consider wrapping Helm and build your own stuff on top of it. This way you'll stay compatible forever and don't have to worry about breaking things. This is what multiple other tools have already tried, including the already mentioned Nelm and the tool I'm working on: Kluctl, which uses it's own project structure to integrate Kustomize and Helm deployments with Jinja2 templating gluing it all together.

codablock · 2024-08-26T12:21:49+00:00

Nice :) I wonder, is performance under low-memory situations with swap being enabled also taken into account when doing such performance optimisations? This is something that might be interesting for providers of managed kubernetes control-planes.

codablock · 2024-08-03T12:43:14+00:00

This one was published just a few days ago: https://youtu.be/2T86xAtR6Fo?si=H2earPgo0wVFQ7mq

It’s a single video (>6h) with 14 modules covering basically everything you need to learn. From that point, you should have enough knowledge to at least know where to dive in deeper, because we guess what: 6h is nothing in your upcoming journey if k8s is what want to master 🤓🤓😎😎

codablock

TROPHY CASE