Product · Supply chain

The container base images we actually run in client infrastructure.

One hardened base (ce-base, Debian 13) plus the handful of data-plane services continuous.engineering deploys repeatedly, each scanned, signed, and published to GHCR. Provided as-is, unsupported, and in the open for transparency, not as a general-purpose distribution.

View on GitHub → Browse GHCR packages →
The images

A small, curated set. Nothing speculative.

Base

ce-base:trixie

Rides debian:trixie-slim via the GCR mirror. Non-root, security-patched, setuid/setgid stripped, with ca-certificates, curl, and tini. Shell and apt retained on purpose: debuggable and extendable, not minimized for its own sake. Every other image in the set builds FROM it.

Debian 13Non-root (65532)Shell retained
Data plane

ce-postgres:18

Rides the official postgres:18-trixie image via the GCR mirror. Deliberately not rebuilt from source, so it keeps the battle-tested initdb and first-boot machinery, with our hardening, scan, and signature layered on top.

Messaging

ce-nats:2.14.4

NATS server, binary pulled straight from the vendor's GitHub release and sha256-verified. Config-less: bring your own nats.conf.

Object store

ce-garage:2.3.0

Garage S3 object store, static binary pulled from the vendor release host and sha256-verified. Config-less: bring your own garage.toml.

Edge & ingress

ce-caddy:2 - one strong Caddy

Edge gate and dynamic-routing ingress from a single image. xcaddy-built on a pinned Go toolchain, carrying ratelimit, l4, and jwt modules plus importable hardened snippets. Dual-mode via CADDY_MODE: static Caddyfile or admin-API dynamic. No caddy-docker-proxy, no Docker socket exposure.

Services

ce-python:3.13

Python 3.13 straight from Debian 13, plus uv (pinned) and the OpenTelemetry SDK. The base every CE Python service builds from.

Exact pins live in VERSIONS.env, the single source of truth the build reads. Rebuilt daily for the Go-binary images, weekly for the full set.

Security posture

Hardened at the layer. Not the smallest image, the most auditable one.

01

Off Docker Hub, entirely. OS and app bases come through mirror.gcr.io (Google's mirror of the Docker official images, same content, no rate limit). Standalone binaries (NATS, Garage, Go) come straight from the vendor's own release host.

02

Everything pinned by digest or verified by checksum. Base images are pinned by sha256: digest. Downloaded binaries are sha256sum --check --strict verified against the value recorded in VERSIONS.env. No floating :latest in a build.

03

Security-patched at build time. apt-get upgrade runs in every base build. Go-binary images rebuild daily; the whole set rebuilds weekly, and on any change, to absorb upstream fixes.

04

Non-root by default. ce-base ships a nonroot user (uid/gid 65532, matching the distroless convention) and defaults USER 65532. Images opt back into root only where genuinely required, and drop back down.

05

Reduced privilege-escalation surface. setuid/setgid bits are stripped from the base filesystem. Nothing in a service container should need them.

06

Scanned, reported, and published, on a soft gate. Every image is Trivy-scanned for OS and library CVEs. The gate is deliberately soft: a CVE finding does not fail the build, because Trivy's vulnerability database flaps CVEs in and out on a roughly 10-minute timescale, and a hard gate can never stay reliably green. Instead: build to the best of our capability, scan, report loudly, publish, and clear fixable CVEs on the rebuild cadence. SARIF goes to the repo's Security tab, a full per-image report is attached as a run artifact, and every job summary lists fixable CRITICAL/HIGH counts.

07

Signed and attested. Every published digest is Cosign keyless-signed via Sigstore/OIDC, with an SBOM and build provenance attached as attestations. Verifiable by anyone, no account needed.

08

Downstream, not theoretical. These images are the base layer under other live products, not a standalone artifact: IAAS runs on them, and the browser-agent container behind Racchabanda Mirage is built directly on ce-base.

Verify it yourself

Nothing here asks for trust you can't check.

Verify signature + inspect SBOM 
# Anyone can verify the signature, no account needed:
cosign verify \
  --certificate-identity-regexp '.*' \
  --certificate-oidc-issuer https://token.actions.githubusercontent.com \
  ghcr.io/continuous-engineering/ce-base:trixie

# Inspect the attached SBOM:
cosign download sbom ghcr.io/continuous-engineering/ce-base:trixie

# Pull directly, no login, no Docker Hub involvement:
docker pull ghcr.io/continuous-engineering/ce-base:trixie

Pin by digest in anything you actually ship: ghcr.io/continuous-engineering/ce-base:trixie@sha256:<digest>

Status: as-is, unsupported

Our choices, for our regulated-client work. Not a general distribution.

✕

No support, no warranty, no SLA. Provided "as is."

✕

Opinionated versions: tags track what we deploy, not the newest upstream release.

✕

We may retag, re-pin, or remove images at any time to serve client needs. If you depend on these, pin by digest and vendor your own copy.

Running client infrastructure
Continuous Engineering

This is what your containers are built from.

If continuous.engineering operates infrastructure for you, these are the images underneath it. Ask Maya which base a given service rides on, or open the repo directly.

← Back to Solutions