Getting started with Minimus Community, no sign-up required

Key takeaways

• Minimus Community is the free tier of Minimus hardened container images, giving you thousands of minimal, source-built images with near-zero known CVEs at build time.
• You can pull your first image with no account and no credit card: one docker pull command against the Minimus registry at reg.mini.dev.
• The fastest path from zero to a running container is to copy a ready-made pull command from the Minimus image gallery, then run it locally with docker run.
• Community covers the images and their signed SBOMs for free; remediation SLAs, FIPS 140-3 and STIG compliance tooling, and custom private image builds belong to Enterprise.

Minimus Community is the free tier of Minimus hardened container images, and you can start pulling images directly without creating an account. Minimus community free images are minimal, built from source, and ship with near-zero known CVEs (Common Vulnerabilities and Exposures), so you get a production-grade base image from your first docker pull against the registry at reg.mini.dev.

Free container images usually come with a catch: a rate limit, an account wall, or a stripped-down demo that quietly drops half the tags. Community's catch is narrower than that. You trade nothing at the door, and the images you pull are the same hardened, minimal builds Minimus ships to paying teams, not a cut-down sample.

This guide is task-shaped. By the end you will have found an image in the gallery, pulled it, and confirmed it runs locally. If you build software for a living, the hardened images for developers workflow is the lens to read this through: fewer packages in the base, fewer findings in the scanner, less time spent triaging CVEs you never introduced.

What Minimus Community is and what it gives you for free

Minimus Community is the no-cost tier of the Minimus hardened image catalog, built for individual developers and open source maintainers who want minimal images without a sales conversation. You get free access to hundreds of application and infrastructure images, each built from upstream source with only the packages required to run the workload.

‍

What you get on the free tier:

• Hundreds of hardened, minimal images covering common runtimes, data stores, and infrastructure components.
• Daily rebuilds from source, so you are pulling current digests instead of stale ones.
• A cryptographically signed SBOM (Software Bill of Materials) for every image version, listing the packages inside it.

The depth of the catalog and the economics of "free" are covered elsewhere, so this article stays on the act of getting started. Open source maintainers can also apply for expanded access through the Minimus Open Source Program, which provides qualified projects with free hardened images. The point for now is narrow: Community is real images, not a teaser.

No account required: how to pull images directly

You can pull Minimus Community images with no account, no token, and no credit card. The registry lives at reg.mini.dev, and a single command gets you the image:

docker pull reg.mini.dev/nginx:latest

That is the whole step. There is no docker login, no sign-up form, and no email confirmation between you and a working image. Docker resolves reg.mini.dev as the registry host, pulls the latest hardened nginx build, and stores it in your local image cache like any other pull.

Minimus publishes most images in matched pairs: a lean production tag, latest, and a debug variant, latest-dev, that adds a shell and tooling for poking around inside the container. Pull the dev variant when you need to troubleshoot:

docker pull reg.mini.dev/nginx:latest-dev

Those two tags are what the free tier pulls; pinning a numbered version like nginx:1.29.0 comes with a paid image subscription, covered in the Community versus Enterprise section below. For setup details, authentication options for paid tiers, and Kubernetes pull configuration, the Minimus pull documentation is the canonical reference.

How to find the right image in the Minimus gallery

Browse the catalog to find the image you need, then copy its pull command straight from the page. The Minimus image gallery lists every available image by name, so searching for nginx, postgres, or python takes you to that image's page in one step.

Each image page is built for a first-time user. On a given page you will find:

1. The available image lines and version tags, including production and -dev variants.
2. A ready-to-run pull command you can copy without typing the registry path yourself.
3. The signed SBOM and current vulnerability report for that version.

Read the version tags before you pull. The free tier pulls the latest and latest-dev tags, where latest floats to the newest hardened build. Pinning a numbered version such as 1.29.0 in your Dockerfile or compose file, for reproducible builds, is part of a paid image subscription. Once you have the image name and a tag you can pull, the command is identical to the one in the previous section.

Pulling your first hardened image: nginx, postgres, or python

Pull the image, run it, and confirm it serves traffic. The steps are identical whether you start with nginx, postgres, or python, so this walkthrough carries one of them through end to end: the hardened Minimus nginx image. Each step is a complete, copy-pasteable command.

Step 1 — Pull the image. Fetch the latest hardened build from the registry:

docker pull reg.mini.dev/nginx:latest

‍

Step 2 — Run the container. Start it and map a local port to the port nginx listens on. Minimus ships nginx as a non-root image, so it listens on 8080 rather than the privileged port 80:

docker run --rm -p 8080:8080 reg.mini.dev/nginx:latest

‍

Step 3 — Confirm it is serving. In a second terminal, send a request to the port you mapped:

curl -I http://localhost:8080

‍

A 200 OK response means the hardened image is running and serving exactly as the standard nginx image would. The substitution is meant to be boring: same behavior, smaller footprint. If you have ever scanned a stock public nginx image, you know the scanner lights up with dozens of findings before you have written a line of config. The first thing most developers notice with the hardened build is how quiet that report gets.

What near-zero vulnerabilities means for a developer pulling their first image

Near-zero CVEs means a hardened image ships with few or no known vulnerabilities at build time because it contains only the packages the application needs to run. A CVE is a publicly catalogued software flaw; most of the CVEs in a typical container image come from packages that were never required to run your app, like shells, package managers, and build tools left over in the base.

Minimus reaches near-zero by building from upstream source and excluding everything that is not a runtime dependency. Fewer packages mean a smaller attack surface, which is the same minimal-footprint principle NIST SP 800-190 recommends for container images. The exact CVE-reduction figures and the math behind them are covered in the near-zero CVE images breakdown, so this article does not re-derive them. For your first pull, the practical effect is what matters: the image you just ran starts from a clean scan instead of a backlog.

How Community differs from Enterprise

Community and Enterprise pull the same hardened images; the difference is how many versions you can pull and what you can build around them. The free tier pulls the latest and latest-dev tags of any image. A paid image subscription unlocks every version and tag of that image, including stable and mainline lines, numbered versions you can pin, FIPS 140-3 variants, and all future versions released over the subscription term.

‍

The images, their signed SBOMs, and the daily rebuilds from source are identical on both tiers, so what you pull on Community is the same hardened build a paying team runs. If you are a developer evaluating hardened images or maintaining an open source project, the free tags cover you. If you need to pin versions across a pipeline, build custom private images,, or mirror images into an air-gapped registry, those come with a subscription. The full picture of what the platform does is laid out in the Minimus platform overview.

Start pulling

Getting started with Minimus Community takes one command: docker pull reg.mini.dev/nginx:latest, then docker run, and you have a hardened image running with no account in the way. From there, browse the Minimus image gallery for the runtimes and data stores your stack actually uses, and pin the versions you depend on.

When you are ready to add, custom images, or] remediation SLAs, you can get started with a Minimus account or read the setup details in the Minimus documentation. For a first pull, you already have everything you need.

Frequently asked questions

Do I need an account to pull Minimus Community images?

No. Minimus Community images pull directly from the registry at reg.mini.dev with no sign-up, no token, and no credit card. Run docker pull reg.mini.dev/nginx:latest and the image lands in your local cache.

Are Minimus Community images really free?

Yes. The Community tier provides thousands of hardened, minimal images and their signed SBOMs at no cost. Paid Enterprise features such as remediation SLAs, and custom image builds are separate from the free image access.

Can I use Minimus Community images in production?

Yes. Community images are production builds rather than demo images. The same hardened images, signed SBOMs, and daily rebuild process are used across both Community and Enterprise tiers. The main differences are access to additional image versions, , custom image capabilities, and remediation SLAs.

What is a signed SBOM and why does it matter?

A signed Software Bill of Materials (SBOM) is a machine-readable inventory of the packages included in a container image. Signing helps verify that the SBOM has not been altered, while the package inventory provides visibility into exactly what software is present in the image for security, compliance, and vulnerability management purposes.

Does using a hardened image eliminate the need for vulnerability scanning?

No. Hardened images reduce the number of known vulnerabilities present at build time by minimizing unnecessary packages and reducing attack surface. Teams should still scan images, monitor dependencies, manage secrets, and follow secure deployment practices as part of a broader container security program.