Provide official Docker image

[regnerisch]

It would be great to have an official Docker image for isms-builder. Pulling the repository and building the image ourselves before publishing it is quite time-consuming.

[coolstartnow]

Thanks for the request!

We're keeping ISMS Builder intentionally simple — no Docker Hub maintenance, no external dependencies.

The Dockerfile is already in the repo:

docker build -t isms-builder .
docker compose up

If building takes too long, we can add a .dockerignore to speed it up — just let us know if that's a real bottleneck.

Alternatively: if the current setup instructions aren't clear, we're happy to improve the docs.

[regnerisch]

With the current workflow, every new release means:

pulling the repository again,
building the Docker image locally or in our own CI,
pushing that image to our own Docker registry,
and only then updating deployments.

With an official Docker image, we could simply switch the version tag — for example from 1.2.3 to 1.2.4 — and immediately get the latest version. That is much simpler, cleaner, and more reproducible.

This workflow also fits much better with Kubernetes or Docker Swarm. In those environments, images are typically pulled directly from a registry. If every team has to build and publish their own image, it creates extra maintenance overhead, more room for inconsistencies, and more complicated rollout/update processes. A central, versioned image avoids that and makes deployments much easier to manage.

So in short: an official Docker image would reduce maintenance, simplify updates, and work much better for container-based platforms like Kubernetes and Swarm.

[coolstartnow]

Thanks @regnerisch for the detailed reasoning — I absolutely understand the use case.

But: that's precisely not what ISMS Builder was built for.

I've spent 40 years in IT infrastructure, 35+ of those in C-level leadership as CIO and later CISO. My entire career has been shaped by one conviction: when it gets complicated, you have the wrong priorities.

ISMS Builder emerged from exactly that philosophy. Confluence was too expensive, every other ISMS tool too bloated, too dependent on external services, too maintenance-heavy. So: build it myself, intentionally simple, intentionally for compliance teams — not for DevOps infrastructure.

That means concretely:

• Target audience: CISOs, risk managers, compliance departments. They can run a docker build.
• No external service dependency: Not even for an "official" Docker Hub image. That binds me to maintenance obligations the project deliberately avoids.
• Resource reality: I maintain ISMS Builder alone — in parallel to my day job, with no dedicated budget. An "official" Docker image isn't just conceptual complexity; it's real maintenance burden: base-image updates, security patches, registry management. Those are recurring, never-ending tasks. For a two-person team that's already a problem; for one person, it's impossible without dropping everything else.

What that concretely means:

If I start maintaining Docker images today, tomorrow comes: "Can we have Helm charts?" The day after: "GitOps support?" — that becomes an endless loop of enterprise features I neither have time for nor want to allocate energy toward. My time is better invested in core features: Issue #42 (race condition), Asset Protection Goals (#29), NIS2 integration.

This isn't a rejection of your use case. It's a deliberate decision because:

1. An "official" Docker image means committing to infrastructure support: Helm charts, GitOps, registry monitoring, base-image tracking, and all the follow-up requests.
2. I'm not the right person for that — more importantly: it's not the right resource allocation. ISMS Builder is a compliance tool, not a DevOps artifact.
3. Kubernetes is a different problem — the person who needs it should be the one building (or delegating) the infrastructure for it.

Alternative:

If this is a real blocker for you: build your own image, or start a community project. That's exactly what AGPL was designed for — the community can take it and run with it without asking me.

I'm happy to help with better Dockerfile documentation, .dockerignore optimizations, or tips for "Kubernetes-ready" deployment patterns. But outsourcing infrastructure complexity — that's the point where the project loses its soul.