Enterprise · self-hosted · imageengine-kube

Distributed image delivery, built to scale in Kubernetes.

A complete image optimization and delivery pipeline in your cluster: device-aware routing, HRW-sharded hot and persistent caches, separately scalable compute tiers, and pipeline-wide metrics and tracing. Start with compact evaluation defaults, then plan capacity around your image catalog and real traffic.

Signed with GPG & cosign SBOM + SLSA provenance
install · imageengine-kube
1 · Namespace & secrets
kubectl create namespace imageengine

kubectl create secret generic ie-kube-api-key -n imageengine \
  --from-literal=KEY=<your-api-key>

kubectl create secret docker-registry ie-kube-image-pull -n imageengine \
  --docker-server=https://docker.scientiamobile.com/v2/ \
  --docker-username=<your-email> \
  --docker-password=<your-api-key> \
  --docker-email=<your-email>
2 · Add the Helm repo
helm repo add imageengine https://kube.imageengine.io
helm repo update
3 · Install
helm install imageengine-kube imageengine/imageengine-kube \
  -n imageengine --set provider=aws
EKS provisions an AWS Network Load Balancer for the edge service — make sure the AWS Load Balancer Controller is installed in your cluster.
Built for the enterprise

Architecture for large image workloads.

ImageEngine is more than a standalone image processor. Its delivery, hot cache, orchestration, origin fetching, transformation, and persistent storage are separate components that can be sized for different bottlenecks.

Verifiable supply chain

Every artifact the chart ships is signed and auditable before it ever runs.

✓GPG-signed charts from v0.8.5 onward
✓cosign-signed images for every container
✓SBOM + SLSA provenance shipped alongside
✓Optional Kyverno / sigstore admission enforcement
✓Zero critical vulnerabilities — every image scanned before release

Built to scale

Start with a compact chart and size edge, cache shards, processing and persistent storage independently against production traffic. Full support for x64_64 and ARM64.

✓Horizontal Pod Autoscaling in all the CPU-bound tiers
✓HRW-sharded Varnish and OSC to distribute cache capacity
✓Edge Warm Start available as an opt-in for multi-edge releases
✓Independent tier sizing and regional frontends

Instrumented across the pipeline

Find the bottleneck across image delivery, caching, fetching and processing with your own observability tools.

✓Prometheus metrics from every pod
✓Opt-in OpenTelemetry across all components
✓Optional Sentry per component
✓ECS structured logs in JSON
The architectural difference

Scale the bottleneck, not the whole stack.

ImageEngine Kube packages a distributed delivery pipeline rather than only an image transformation API. Deterministic routing spreads cache capacity across shards, while independent compute tiers handle origin fetching and processing. Cache misses and expensive work need not grow in lockstep with incoming traffic.

Sharded hot and persistent caches
Rendezvous hashing assigns an image's variants to a Varnish shard and assigns origin/derivative objects to persistent OSC shards. Grow capacity without intentionally duplicating the full working set across every cache pod.
Independent scaling boundaries
Size the edge, Varnish, backend, fetcher, processor and OSC separately. Enable CPU autoscaling for backend, fetcher and processor as needed; keep cache shard counts deliberate.
Regional delivery topology
Deploy regional frontend-only edge/Varnish tiers that share a central backend stack. Use private connectivity between tiers; backend storage is not automatically replicated between regions.
Protect expensive work
Hot cache hits bypass processing. Persistent origin and derivative storage reduces repeat work, while admission controls and request coalescing help manage miss-heavy bursts.
Operationally visible
Prometheus metrics cover all six components. Opt-in OpenTelemetry links the Go services, while Varnish forwards trace context on misses; structured logs and optional Sentry add diagnostics.
Capacity planning, not magic numbers
Compact defaults are for evaluation. Plan cache working sets, origin load, shard IO, CPU, memory and tail latency using realistic traffic before committing to production resources.

Optimization, built in.

The full ImageEngine optimization pipeline ships inside the chart — no separate service to wire up.

Instant global cache purging
Flush optimized assets everywhere the moment your source changes.
Rules engine
Codify optimization tweaks once and apply them across your whole library.
ImageEngine Directives
Resize, crop and tune straight from the URL — ?imgeng=/w_1200/h_600.
Modern formats, automatically
AVIF, HEIF and WebP served to every device that supports them.
Client hints
Perfect sizing from the browser's own viewport and DPR signals.
Works with every major CDN
Drop it in front of Cloudflare, CloudFront, Fastly, Akamai and the rest.
Before you install
Active trial or subscription
Your ImageEngine API key authenticates to the control plane and pulls images from docker.scientiamobile.com.
Two Kubernetes secrets
The chart won't create them for you — an API-key secret and a docker-registry pull secret, both in the install namespace.
Helm 3 + a supported cluster
AWS EKS, Azure AKS, DigitalOcean, GKE, Akamai Linode, or any conformant self-managed Kubernetes.
Verify signatures

Trust, but verify.

Every chart and every container image is cryptographically signed. Check them yourself, against our published keys, before anything runs in your cluster.

Chart · GPG
curl -fsSL https://kube.imageengine.io/pubkey.asc \
  | gpg --dearmor > ~/.gnupg/imageengine-kube.kbx

helm install imageengine-kube imageengine/imageengine-kube \
  --verify --keyring ~/.gnupg/imageengine-kube.kbx
Key fingerprint
C3A5 5111 ED91 FEDE 4A82  A4B4 4632 6606 0957 C4B3
Charts published from v0.8.5 onward are signed.
Container images · cosign
curl -fsSLO https://kube.imageengine.io/cosign.pub

cosign verify --key cosign.pub \
  docker.scientiamobile.com/iekube/imageengine-backend.server:<tag>
Every image ships an SBOM and SLSA build provenance alongside its signature.

Verifying every image, reading the SBOM and provenance, and optional in-cluster admission enforcement (Kyverno / sigstore policy-controller) are covered in the security guide.