# Takumi Images Beta Released

Takumi Images is now available in beta. It provides maintained container images that are continuously rebuilt and scanned so your applications can start from base images where known vulnerabilities have already been addressed.

The images are published through the OCI registry `images.flatt.tech`.

![Takumi Images](/docs/_md-assets/967459f364-og-image.jpg)

## Overview

Development teams are being asked to apply security updates more frequently, while software supply chain attacks increasingly target the update process itself. Takumi Images is designed to reduce that operational tension: you can move to maintained base images without rebuilding your own patch pipeline for common runtime images.

When a corresponding image is available in the catalog, you can switch the base image reference and pull the latest Takumi image when updates are published, instead of investigating base-image packages, selecting patched dependency versions, and rebuilding those images yourself.

## Getting Started

When the catalog includes a Takumi image that corresponds to your current base image, migration usually only requires changing the `FROM` line in your Dockerfile:

```diff
- FROM node:latest
+ FROM images.flatt.tech/takumi/node:latest
```

After migration, pull the image again to receive the latest rebuilt image:

```bash
docker pull images.flatt.tech/takumi/node:latest
```

For details, see the [Takumi Images documentation](https://shisho.dev/docs/t/images/).

## Included Value

Takumi Images makes base-image maintenance easier in three ways.

First, each image contains less by default. Takumi Images focuses on the main program and the minimum runtime libraries required to run it. This helps reduce scanner noise from dependencies that are inherited from the base image rather than from your application code.

Second, the provider handles the base-image side of the investigation. For software included in Takumi Images, the provider triages vulnerability impact and also checks upstream code for malware before incorporating updates. This reduces the amount of base-image findings and update-source risk that users have to track themselves.

Third, each image is published with verifiable supply chain metadata:

- Signed image artifacts
- SBOM attestations
- SLSA Provenance attestations
- VEX attestations for vulnerability findings assessed by the provider

These attestations let you inspect what is in the image, where it came from, and the current assessment for findings reported against the base image.

## Roadmap

We plan to expand the image catalog further, focusing on databases, language runtimes, and middleware, and to provide image variants that address compliance requirements.

We also plan to detect vulnerability information before CVE IDs are assigned, incorporate those fixes early through nightly builds, and support international compliance requirements.