Coder Legion - Recent posts tagged charts

Fastchart 1.X, why I rewrote it after 0.2 release

Fri, 22 May 2026 12:16:54 +0000

Couple of weeks ago I shipped fastchart 0.2.0 and wrote it up here. One extension, 19 chart types, server-side rendering through ext/gd.

The idea was right, but execution not quite there.

After the launch I spent a few days actually looking at the output side by side with what plutovg can do on the same primitives. The libgd-rendered charts were fine for what libgd is, which is a 1990s 2D rasterizer with no subpixel-precise anti-aliasing. Diagonal lines were jaggy. Glyph edges grainy at small sizes. The output read as "a chart drawn by ext/gd in 2026" instead of "a chart." A couple of Reddit threads (r/PHP and r/laravel) pointed at the same thing without me having to ask.

So I rewrote it. fastchart 1.1.1 is the current stable of that rewrite, following a number of stabilization tweaks and refinements, the end result being SVG promoted to the canonical render format, and the chart-family count up from 19 to 26.

What was wrong with the libgd output

libgd's anti-aliasing is gdAntiAliased plus the alpha channel. It works for solid-fill regions. It falls apart on the boundary between two filled regions of different colors, on glyph rendering at body-text sizes, and on rotated text where the rotation axis isn't a 45° multiple.

Specific cases I kept hitting:

Diagonal series lines in a LineChart showed visible stair-stepping at 1px stroke width. libgd's gdImageLine with gdAntiAliased blends against the canvas background, not the local color, so a red line crossing a blue series region looked correct on the white margin and wrong inside the plot area.
45° rotated X-axis labels (the default when categorical labels are long) had a noticeable diagonal moiré along the baseline. Different from the line issue: this came from libgd's FreeType bridge, which renders each glyph straight then resamples the resulting bitmap. The double rasterization loses sharpness.
StockChart hollow candles drew the body outline with the same primitive as the wick, so the body edges and the wick had the same line weight even when they shouldn't. The fix would have been a separate primitive; libgd has no concept of stroke vs fill weight at the polyline level.

None of these are libgd bugs. They are libgd doing exactly what libgd has always done. They are also not things I can fix in a wrapper.

Why SVG won

The shortest path from "I want sharper output" to "the output is sharper" is to stop rasterizing in the render path at all. SVG is text. The render path appends strings into a smart_str. The reader (a browser, an inkscape, a plutovg) does the rasterization at the resolution and pixel density it wants.

That solves the visual-quality complaint by default. It also gives back DPI-independent output: a chart embedded in a PDF or rendered at retina density on a Mac no longer needs setDpi(192) to look right.

Not everyone wants or needs SVG, so the architecture needs a path for traditional image formats too (PNG / JPG):

Every chart family builds an SVG document.
renderSvg() returns the document bytes.
renderPng() / renderJpeg() / renderWebp() flatten the SVG's <text> elements to glyph outline paths via FreeType, run the result through plutovg + plutosvg (vendored, both MIT-licensed), and encode the rasterized RGBA buffer with libpng / libjpeg-turbo / libwebp.

Same chart object, four render methods, four outputs. No second code path for rasters; the raster encoders sit downstream of the same vector builder.

The cost is that fastchart now links against four codec libs instead of one. The benefit is libgd is gone, both as a build dependency (no libgd-dev apt package required) and as a runtime requirement (the chart classes no longer touch GdImage at all).

The 1.x arc

1.0.0: the rewrite

The architectural pivot. SVG canonical, libgd dropped, plutovg + plutosvg vendored. Seven new chart families lifted the family count from 19 to 26: BulletChart, ParetoChart, CalendarHeatmap, SunburstChart, SankeyChart, MarimekkoChart, VectorChart. All seven were sitting in the same private-extensions queue as the 0.2.0 set; pulling them into the public repo was easier once the architecture was settled.

Breaking changes from 0.2.0: no more GIF support, and no more GdImage canvas input/output.

1.0.(1-2): build portability

1.0.1 added prebuilt binaries via PIE for Windows (PHP 8.3 / 8.4 / 8.5, NTS + TS, x64 + x86) and Linux x86_64 / arm64 + macOS arm64 (PHP 8.4 / 8.5 NTS). 1.0.2 fixed a libjpeg soname mismatch that broke the Linux prebuilts on Debian-based PHP, including every official php:X.Y-cli Docker image. The fix statically links libjpeg-turbo from a configure-time source build, with -Wl,--exclude-libs=ALL so the static symbols stay local to fastchart.so and don't collide with the system ext/gd in the same process.

1.1.0: features on the new pipeline

AreaChart::setBandMode(bool) for confidence-interval and min-max envelope fills. PolarChart::setInterpolation(INTERP_SMOOTH) for Catmull-Rom-subdivided polar curves. PolarChart::addVectors() to overlay arrow vectors in (angle, radius) data space. Funnel::setStyle(STYLE_CONE) for a pyramid with front-facing ellipse-arc edges. BubbleChart::setYAxisScale(SCALE_LOG). And Chart::setImageMap() + getImageMap() for HTML image-map hot-spots on BarChart, PieChart, and ScatterChart, with allowlisted URL schemes (http / https / mailto / / / #) and HTML-escaped tooltip text.

1.1.1: hardening

Shipped today. No new APIs, no breaking changes. Fourteen fixes to improve code quality. A non-exhaustive sample:

PolarChart::addVectors() rejects NaN / Inf at the boundary now, matching every other polar setter. The float-to-int cast it was feeding is UB per C11 §6.3.1.4p1.
MarimekkoChart::setColumns() running-sum overflow. Each individual segment value was isfinite-guarded, but the per-column sum and cross-column total could overflow to +Inf from two segments at 1e308 each. Columns whose running sum is non-finite are now silently dropped.
StockChart STYLE_VECTOR climax-deque ring-buffer overflow. After 11 strictly-decreasing pushes the deque tail wrapped to the head and every subsequent bar got misclassified as a climax. The stale-front drop now runs before the push.
JPEG encoder local pointers carry volatile across setjmp(). Per C99 §7.13.2.1 a register-spilled local that libjpeg's longjmp clobbers is UB; the cleanup branch could leak or double-free.
fc_ft_measure() was a 1 / 2 / 3-byte UTF-8 decoder. Non-BMP codepoints (emoji, CJK extensions, mathematical alphanumeric symbols) contributed 0 to the measured width, so chart layout reservations came up systematically narrow on labels containing emoji. 4-byte branch added.
Time-axis arithmetic on setOhlcv timestamps near LLONG_MIN..LLONG_MAX overflowed signed zend_long in four call sites. Promoted to double arithmetic; out-of-range double-to-zend_long casts clamped.
Vendor refresh: plutosvg 0.0.7 to 0.0.8, plutovg 1.3.2 to 1.3.3. Most of fastchart's local patches (UTF-8 BOM handling, FT include, sprintf to snprintf, bilinear tile sampling) are now upstream. Preserved fastchart-only: the stb_image PNG palette zero-init and the STBI_ONLY_PNG / STBI_ONLY_JPEG cut that drops ~70% of the stb image-loader binary.

Full list in CHANGELOG.md.

Outside contributions

Along the way the 1.x cycle caught the attention of Remi Collet, who runs the rpms.remirepo.net PHP RPM repository (the standard PHP RPM source for RHEL / Fedora / CentOS). Three merged PRs landed between 1.1.0 and 1.1.1: a test-path correction so the suite finds the build directory regardless of out-of-tree builds, a fix for an undefined $ext_builddir that broke the Fedora PHP build glue, and an additional Fedora-family font-path probe (/usr/share/fonts/lato/, /usr/share/fonts/TTF/) for MINIT's default-font detection. The cumulative effect is that fastchart now builds and runs cleanly under Remi's RPM packaging.

Performance: what each format actually costs

Median in-memory render time at 1920×1080 on a single core, Intel i9-13950HX, PHP 8.4 debug build, default font and DPI. SVG is the canonical output; PNG / WebP / JPG add their rasterize + encode cost on top of the SVG build.

Chart	SVG ms	PNG ms	WebP ms	JPG ms
AreaChart	5.7	71.7	54.4	34.5
BarChart	11.0	75.8	57.0	38.8
BoxPlot	4.4	65.0	47.5	31.6
BubbleChart	2.6	90.9	62.7	38.6
GaugeChart	1.2	69.4	49.7	29.1
LineChart	5.4	74.2	55.5	34.3
PieChart	2.8	71.6	51.9	33.0
StockChart	8.4	80.8	63.3	41.0

SVG sits between 1.2 ms and 11 ms across all 19 measured types. There is no rasterizer in that path; the backend appends strings into a smart_str and returns the bytes. The raster encoders split into three bands: JPG fastest at 25 to 41 ms (libjpeg-turbo with 4:2:0 subsampling), WebP middle at 41 to 63 ms (libwebp with WEBP_PRESET_DRAWING + method=2 + multi-thread, roughly 2× faster than the simple API the rewrite started with), PNG slowest at 62 to 91 ms (libpng's deflate dominates). All four formats stay under 95 ms at 1080p on one thread.

Full table for all 19 measured chart types in the README perf section. Reproduce with php -d extension=./modules/fastchart.so docs/bench/bench.php.

Composing without a shared canvas

The 0.2.0 differentiator was draw(GdImage $canvas): hand fastchart a gd canvas you owned, it drew into it, you composited multiple charts on one image. That API is gone in 1.x because v1.x owns its pixel buffer.

The replacement is drawSvgFragment() plus the static svgToPng / svgToJpeg / svgToWebp rasterizers:

$line = (new FastChart\LineChart(800, 600))
    ->setTitle('Daily active users')
    ->setSeries([['data' => $values]]);

$bar = (new FastChart\BarChart(800, 600))
    ->setTitle('Quarterly revenue')
    ->setSeries([['data' => $bars]]);

// Stitch two fragments into one outer SVG document.
$outer = <<<SVG
<?xml version="1.0" encoding="UTF-8"?>
<svg xmlns="http://www.w3.org/2000/svg" width="1600" height="600" viewBox="0 0 1600 600">
  <g transform="translate(0,0)">{$line->drawSvgFragment()}</g>
  <g transform="translate(800,0)">{$bar->drawSvgFragment()}</g>
</svg>
SVG;

// Take the stitched SVG either as bytes or rasterized in one call.
file_put_contents('/tmp/dashboard.svg', $outer);
file_put_contents('/tmp/dashboard.png', FastChart\Chart::svgToPng($outer));

Same dashboard story as the 0.2.0 example, no shared canvas. The rasterizer sees the full composed document and antialiases across fragment boundaries cleanly.

On Linux with a standard fonts package installed (Ubuntu's fonts-lato, Debian's fonts-dejavu, etc.) fastchart's MINIT auto-probes a default. On macOS or in minimal containers, add ->setFontPath('/path/to/font.ttf') on each chart so labels render.

The SVG-canonical pipeline also gave a freebie: svgToPng / svgToJpeg / svgToWebp rasterize any caller-supplied SVG bytes through the same plutovg + encoder path, not just fastchart's own output. If you need to convert an arbitrary SVG to PNG / JPG / WebP from PHP without shelling out to ImageMagick, rsvg-convert, or Inkscape, that's now in-process. The caveat is text: plutosvg has no text engine, so <text> elements in caller-supplied SVG render blank. Either pre-flatten to <path> (Inkscape's "Object to Path" works) or accept the limitation. Hard caps apply: 16 MB input, output dimensions capped at 4096 px and 16 Mpx, embedded data:image/ URIs rejected (plutosvg's loader bypasses the dim cap on those), <use> elements rejected (the cycle detector doesn't count fan-out, so nested <g><use/>×10 can hit billion-laughs expansion). Contract at docs/specs/svg-to-raster.md.

Try it

Full SVG + PNG + JPG + WebP gallery for every chart family at iliaal.github.io/fastchart/v1-gallery.html. Source PHP shown above each row.

pie install iliaal/fastchart

Repo: github.com/iliaal/fastchart. BSD-3, PHP 8.3+, NTS or ZTS.

What 0.2.0 got right

The 0.2.0 framing held: PHP doesn't need a Node sidecar for charts. The breadth held: 19 chart types covering Cartesian, financial, non-Cartesian, and specialised shapes is roughly the surface most dashboards need. The fluent OO API held. What didn't hold was libgd underneath it. libgd is fine for what libgd is; it isn't a 2026 chart rasterizer. A few releases later, fastchart isn't built on top of libgd anymore, and the output reads accordingly.

fastchart 0.2.0: Native PHP Charts, Barcodes, and QR Codes in One Extension

Tue, 12 May 2026 14:46:50 +0000

(new FastChart\StockChart())
    ->setSize(1200, 600)
    ->setTitle('AAPL last 90 days')
    ->setTheme(FastChart\Chart::THEME_DARK)
    ->setOhlcv($ohlcvRows)
    ->setMovingAverages([20, 50, 200])
    ->setVolumePane(true)
    ->setCandleStyle(FastChart\Chart::STYLE_HOLLOW)
    ->renderToFile('/tmp/aapl.png');

That's a server-side OHLCV candlestick chart with three moving averages, a volume pane, and a hollow candle style. Roughly 68 ms on a single core at 1920×1080. No microservice, no Node sidecar, no JavaScript runtime. PHP, gd, fastchart.

fastchart 0.2.0 shipped two days ago. 19 chart types behind a fluent OO API, plus a Symbol family (Code 128 barcodes and QR codes) that landed in this release. The repo is at github.com/iliaal/fastchart.

Why charts in PHP again

Twenty years ago, Rasmus and I shipped the initial release of PECL/GDChart in January 2006. It wrapped Bruce Verderaime's gdchart C library from users.fred.net/brv/chart/. The PECL page is still up at https://pecl.php.net/package/GDChart.

Both projects died. Verderaime's gdchart library hasn't moved since the mid-2000s; the homepage at users.fred.net/brv/chart/ has been a tombstone for almost as long. The PECL extension followed. One release, then nothing.

The PHP charting ecosystem since then has been thin. JpGraph kept moving but active development went to the commercial fork; the OSS branch is calcifying. pChart is unmaintained. Many PHP teams that need server-side charts in 2026 either reach for a Node or Python microservice (Chart.js via Puppeteer, matplotlib via subprocess) or accept that "server-side rendering" means "render in the browser and screenshot it." Neither is good.

Between PECL/GDChart and now, I've kept needing charts and graphs in PHP. Mostly charts, occasionally barcodes and QR codes. Each new project I'd reach for the easy options first: command-line tools wrapped through shell_exec, pure-PHP libraries when they were fast enough, more recently chart.js renders shipped through a Puppeteer or headless-Chrome wrapper. Those work until they don't. When scale showed up the wrapper started dominating request latency, and I'd write a little PHP extension that handled the specific case causing pain.

Roughly six of those extensions accumulated over the years. Each did one thing. One generated QR codes for serial numbers on physical labels. One drew two chart types for an internal reporting dashboard. One was just OHLC candlesticks with moving averages. None of them shipped. They lived in private repos, solved the immediate problem, and never got cleaned up enough to release.

fastchart is the attempt to close that gap publicly. One extension, the breadth of shapes I've kept needing, a fluent OO API, BSD-licensed. StockChart got the deepest treatment in this release (seven candle styles, the full indicator stack) because the most recent of the six private extensions was the trading-chart one and it carried over almost verbatim. The other eighteen chart types and the Symbol family came from cleaning up and merging the rest.

What's in 0.2.0

Nineteen chart classes plus a two-class Symbol family for barcodes and QR codes. Five output formats. Two render paths. The full surface is 105 public methods covered by 97 tests. PHP 8.3+ minimum, NTS or ZTS.

The chart classes split into four shapes:

Cartesian. Line, Area, Bar (vertical, horizontal, stacked, grouped, floating, layered), Scatter, Bubble.
Financial. A deep StockChart class: seven candle styles (CANDLE, BAR, DIAMOND, I_CAP, HOLLOW, VOLUME, VECTOR), SMA/EMA/WMA overlays, a volume pane, and indicator panes (RSI, MACD, Bollinger Bands, Parabolic SAR, Stochastic, OBV).
Non-Cartesian. Radar, Polar, Surface, Contour.
Specialised. Pie (with donut hole and leader lines), Gauge, LinearMeter, Gantt (with dependencies and milestones), BoxPlot, Treemap, Funnel, Waterfall, Heatmap.

The Symbol family added in 0.2.0:

Code 128. ISO/IEC 15417. Auto-switches between A/B/C subsets to minimize encoded length. Mod-103 checksum appended automatically. Optional human-readable payload rendered below the bars.
QR Code. ISO/IEC 18004. Four error-correction levels (ECC_L/M/Q/H), versions 1 through 40. Encoder is the vendored nayuki/QR-Code-generator C library under MIT.

Output formats are the standard gd set plus the modern ones: PNG, JPEG, WebP, AVIF, GIF.

Why barcodes and QR codes in a chart library

Because they all render to a gd canvas, they all serve the same use case (server-side image generation in PHP), and they share the same painful problem: the existing PHP-native options are mostly dead or third-party packages with their own dependency stacks.

The unifying thread is gd, not "chart." If you're rendering a dashboard tile, a sales report PDF, an invoice with a scannable serial number, or a shipping label with a barcode, you're producing an image on the server. PHP has had ext/gd since 4.0.0. fastchart treats ext/gd as the substrate and adds higher-level shapes on top. The Symbol classes don't claim to be charts; they live in their own family parallel to Chart, with shared base setters and the same render-format set.

The public options before fastchart were mostly pure-PHP libraries shipping their own glyph tables and rasterizers, or wrappers around command-line tools like qrencode. Both work. Both add a dependency surface that a pie install doesn't cover. fastchart pulls QR and Code 128 into the same .so as the charts. One install, one dependency (gd), one fluent API.

The compose path

Charts let you hand fastchart a \GdImage canvas you own. It draws into your canvas and returns the same canvas back. Symbols don't accept a caller-owned canvas (a barcode's quiet zone makes compositing inside an existing image ambiguous); they render fresh and you imagecreatefromstring() to composite afterwards.

The composability is the differentiator from JpGraph, pChart, and most JS-bridged solutions. They own the canvas. You get a finished PNG file back and composite at the file or page level, never at the pixel level. fastchart's two-path design covers both:

// Path 1: "give me a file."
(new FastChart\LineChart(800, 600))
    ->setSeries([['data' => $values]])
    ->renderToFile('/tmp/line.png');

// Path 2: "draw onto my canvas." Two charts side by side on the same image.
$canvas = imagecreatetruecolor(1600, 900);

(new FastChart\LineChart(1600, 900))
    ->setTitle('Daily active users')
    ->setSeries([['data' => $values]])
    ->setPlotRect(80, 60, 720, 820)
    ->draw($canvas);

(new FastChart\BarChart(1600, 900))
    ->setTitle('Quarterly revenue')
    ->setSeries([['data' => $bars]])
    ->setPlotRect(880, 60, 1520, 820)
    ->draw($canvas);

// Stamp something gd-native on top.
$font = '/usr/share/fonts/truetype/dejavu/DejaVuSans-Bold.ttf';
imagettftext($canvas, 24, 0, 20, 40, $white, $font, 'Dashboard');

imagepng($canvas, '/tmp/dashboard.png');

A four-tile dashboard, a chart embedded in a PDF page, a chart and its legend baked together on a sprite, same primitives, no separate render passes, no temp files.

Performance

Every chart type renders under 100 ms at 1920×1080 on a single core. The lighter types break 100 renders per second per core at dashboard-tile size (640×480). Numbers from my workstation (Intel i9-13950HX, PHP 8.4 NTS), default font and DPI.

Chart	640×480 ms	1920×1080 ms	1080p ops/sec
AreaChart	24	76	13
BarChart	39	84	12
BoxPlot	16	60	17
BubbleChart	13	62	16
ContourChart	9	52	19
Funnel	14	52	19
GanttChart	18	61	16
GaugeChart	10	60	17
Heatmap	9	56	18
LineChart	21	66	15
LinearMeter	9	50	20
PieChart	13	59	17
PolarChart	10	53	19
RadarChart	15	61	16
ScatterChart	17	60	17
StockChart	21	68	15
SurfaceChart	8	50	20
Treemap	18	60	17
Waterfall	18	61	16

These are not "we render faster than Chart.js running in Puppeteer" numbers. Headless-browser rendering is slow for completely different reasons (process startup, JS runtime, layout, paint). The honest framing is that fastchart removes the JS-render path entirely from server-side image generation. The benchmark is a sanity check that the C path is fast enough to stop reaching for a sidecar, not a marketing claim.

Bench source is at docs/bench/bench.php. Reproduce locally with php -d extension=gd -d extension=./modules/fastchart.so docs/bench/bench.php.

Install

pie install iliaal/fastchart

Or build from source against the PHP install you want to extend:

phpize
./configure --enable-fastchart
make -j
make test
sudo make install

PHP 8.3 or newer, plus ext/gd. fastchart declares ZEND_MOD_REQUIRED("gd") so the engine orders MINIT correctly regardless of php.ini / conf.d / -d extension= load order. (Earlier 0.1.0 didn't, and docker-php-ext-enable's alphabetical conf.d ordering caused fastchart to load before gd. That was the only thing 0.1.1 fixed.)

Twenty years later

The 2006 ext-gdchart was a hundred lines of glue around roughly 1,000 lines of upstream library. Single chart family, single output format, a tiny config surface. It worked. It died the moment its upstream did.

The bet with fastchart is the opposite: own enough of the substrate that the project's lifespan isn't bound to anything external besides gd, which has been in PHP since 4.0.0. Nineteen chart types, two symbol types, the whole stack lives in this repo. No third-party chart library to outlast, no microservice to keep alive, no JS toolchain to drag along.

Twenty years between PHP charting extensions is long enough.

Helm Chart Testing in Production: Layers, Tools, and a Minimum CI Pipeline

Sat, 14 Feb 2026 09:43:36 +0000

When a Helm chart fails in production, the impact is immediate and visible. A misconfigured ServiceAccount, a typo in a ConfigMap key, or an untested conditional in templates can trigger incidents that cascade through your entire deployment pipeline. The irony is that most teams invest heavily in testing application code while treating Helm charts as “just configuration.”

Chart testing is fundamental for production-quality Helm deployments. For comprehensive coverage of testing along with all other Helm best practices, visit our complete Helm guide.

Helm charts are infrastructure code. They define how your applications run, scale, and integrate with the cluster. Treating them with less rigor than your application logic is a risk most production environments cannot afford.

The Real Cost of Untested Charts

In late 2024, a medium-sized SaaS company experienced a 4-hour outage because a chart update introduced a breaking change in RBAC permissions. The chart had been tested locally with helm install --dry-run, but the dry-run validation doesn’t interact with the API server’s RBAC layer. The deployment succeeded syntactically but failed operationally.

The incident revealed three gaps in their workflow:

No schema validation against the target Kubernetes version
No integration tests in a live cluster
No policy enforcement for security baselines

These gaps are common. According to a 2024 CNCF survey on GitOps practices, fewer than 40% of organizations systematically test Helm charts before production deployment.

The problem is not a lack of tools—it’s understanding which layer each tool addresses.

Testing Layers: What Each Level Validates

Helm chart testing is not a single operation. It requires validation at multiple layers, each catching different classes of errors.

Layer 1: Syntax and Structure Validation

What it catches: Malformed YAML, invalid chart structure, missing required fields

Tools:

helm lint: Built-in, minimal validation following Helm best practices
yamllint: Strict YAML formatting rules

Example failure caught:

# Invalid indentation breaks the chart
resources:
  limits:
      cpu: "500m"
    memory: "512Mi"  # Incorrect indentation

Limitation: Does not validate whether the rendered manifests are valid Kubernetes objects.

Layer 2: Schema Validation

What it catches: Manifests that would be rejected by the Kubernetes API

Primary tool: kubeconform

Kubeconform is the actively maintained successor to the deprecated kubeval. It validates against OpenAPI schemas for specific Kubernetes versions and can include custom CRDs.

Project Profile:

Maintenance: Active, community-driven
Strengths: CRD support, multi-version validation, fast execution
Why it matters: helm lint validates chart structure, but not if rendered manifests match Kubernetes schemas

Example failure caught:

apiVersion: apps/v1
kind: Deployment
spec:
  replicas: 2
  template:
    metadata:
      labels:
        app: myapp
    spec:
      containers:
      - name: app
        image: nginx:latest
# Missing required field: spec.selector

Configuration example:

helm template my-chart . | kubeconform \
  -kubernetes-version 1.30.0 \
  -schema-location default \
  -schema-location 'https://raw.githubusercontent.com/datreeio/CRDs-catalog/main/{{.Group}}/{{.ResourceKind}}_{{.ResourceAPIVersion}}.json' \
  -summary

Example CI integration:

#!/bin/bash
set -e

KUBE_VERSION="1.30.0"

echo "Rendering chart..."
helm template my-release ./charts/my-chart > manifests.yaml

echo "Validating against Kubernetes $KUBE_VERSION..."
kubeconform \
  -kubernetes-version "$KUBE_VERSION" \
  -schema-location default \
  -summary \
  -output json \
  manifests.yaml | jq -e '.summary.invalid == 0'

Alternative: kubectl --dry-run=server (requires cluster access, validates against actual API server)

Layer 3: Unit Testing

What it catches: Logic errors in templates, incorrect conditionals, wrong value interpolation

Unit tests validate that given a set of input values, the chart produces the expected manifests. This is where template logic is verified before reaching a cluster.

Primary tool: helm-unittest

helm-unittest is the most widely adopted unit testing framework for Helm charts.

Project Profile:

GitHub: 3.3k+ stars, ~100 contributors
Maintenance: Active (releases every 2-3 months)
Primary maintainer: Quentin Machu (originally @QubitProducts, now independent)
Commercial backing: None
Bus Factor: Medium-High (no institutional backing, but consistent community engagement)

Strengths:

Fast execution (no cluster required)
Familiar test syntax (similar to Jest/Mocha)
Snapshot testing support
Good documentation

Limitations:

Doesn’t validate runtime behavior
Cannot test interactions with admission controllers
No validation against actual Kubernetes API

Example test scenario:

# tests/deployment_test.yaml
suite: test deployment
templates:
  - deployment.yaml
tests:
  - it: should set resource limits when provided
    set:
      resources.limits.cpu: "1000m"
      resources.limits.memory: "1Gi"
    asserts:
      - equal:
          path: spec.template.spec.containers[0].resources.limits.cpu
          value: "1000m"
      - equal:
          path: spec.template.spec.containers[0].resources.limits.memory
          value: "1Gi"

  - it: should not create HPA when autoscaling disabled
    set:
      autoscaling.enabled: false
    template: hpa.yaml
    asserts:
      - hasDocuments:
          count: 0

Alternative: Terratest (Helm module)

Terratest is a Go-based testing framework from Gruntwork that includes first-class Helm support. Unlike helm-unittest, Terratest deploys charts to real clusters and allows programmatic assertions in Go.

Example Terratest test:

func TestHelmChartDeployment(t *testing.T) {
    kubectlOptions := k8s.NewKubectlOptions("", "", "default")
    options := &helm.Options{
        KubectlOptions: kubectlOptions,
        SetValues: map[string]string{
            "replicaCount": "3",
        },
    }
    
    defer helm.Delete(t, options, "my-release", true)
    helm.Install(t, options, "../charts/my-chart", "my-release")
    
    k8s.WaitUntilNumPodsCreated(t, kubectlOptions, metav1.ListOptions{
        LabelSelector: "app=my-app",
    }, 3, 30, 10*time.Second)
}

When to use Terratest vs helm-unittest:

Use helm-unittest for fast, template-focused validation in CI
Use Terratest when you need full integration testing with Go flexibility

Layer 4: Integration Testing

What it catches: Runtime failures, resource conflicts, actual Kubernetes behavior

Integration tests deploy the chart to a real (or ephemeral) cluster and verify it works end-to-end.

Primary tool: chart-testing (ct)

chart-testing is the official Helm project for testing charts in live clusters.

Project Profile:

Ownership: Official Helm project (CNCF)
Maintainers: Helm team (contributors from Microsoft, IBM, Google)
Governance: CNCF-backed with public roadmap
LTS: Aligned with Helm release cycle
Bus Factor: Low (institutional backing from CNCF provides strong long-term guarantees)

Strengths:

De facto standard for public Helm charts
Built-in upgrade testing (validates migrations)
Detects which charts changed in a PR (efficient for monorepos)
Integration with GitHub Actions via official action

Limitations:

Requires a live Kubernetes cluster
Initial setup more complex than unit testing
Does not include security scanning

What ct validates:

Chart installs successfully
Upgrades work without breaking state
Linting passes
Version constraints are respected

Example ct configuration:

# ct.yaml
target-branch: main
chart-dirs:
  - charts
chart-repos:
  - bitnami=https://charts.bitnami.com/bitnami
helm-extra-args: --timeout 600s
check-version-increment: true

Typical GitHub Actions workflow:

name: Lint and Test Charts

on: pull_request

jobs:
  lint-test:
    runs-on: ubuntu-latest
    steps:
      - name: Checkout
        uses: actions/checkout@v3
        with:
          fetch-depth: 0

      - name: Set up Helm
        uses: azure/setup-helm@v3

      - name: Set up Python
        uses: actions/setup-python@v4
        with:
          python-version: '3.11'

      - name: Set up chart-testing
        uses: helm/chart-testing-action@v2

      - name: Run chart-testing (lint)
        run: ct lint --config ct.yaml

      - name: Create kind cluster
        uses: helm/kind-action@v1

      - name: Run chart-testing (install)
        run: ct install --config ct.yaml

When ct is essential:

Public chart repositories (expected by community)
Charts with complex upgrade paths
Multi-chart repositories with CI optimization needs

Layer 5: Security and Policy Validation

What it catches: Security misconfigurations, policy violations, compliance issues

This layer prevents deploying charts that pass functional tests but violate organizational security baselines or contain vulnerabilities.

Policy Enforcement: Conftest (Open Policy Agent)

Conftest is the CLI interface to Open Policy Agent for policy-as-code validation.

Project Profile:

Parent: Open Policy Agent (CNCF Graduated Project)
Governance: Strong CNCF backing, multi-vendor support
Production adoption: Netflix, Pinterest, Goldman Sachs
Bus Factor: Low (graduated CNCF project with multi-vendor backing)

Strengths:

Policies written in Rego (reusable, composable)
Works with any YAML/JSON input (not Helm-specific)
Can enforce organizational standards programmatically
Integration with admission controllers (Gatekeeper)

Limitations:

Rego has a learning curve
Does not replace functional testing

Example Conftest policy:

# policy/security.rego
package main

import future.keywords.contains
import future.keywords.if
import future.keywords.in

deny[msg] {
  input.kind == "Deployment"
  container := input.spec.template.spec.containers[_]
  not container.resources.limits.memory
  msg := sprintf("Container '%s' must define memory limits", [container.name])
}

deny[msg] {
  input.kind == "Deployment"
  container := input.spec.template.spec.containers[_]
  not container.resources.limits.cpu
  msg := sprintf("Container '%s' must define CPU limits", [container.name])
}

Running the validation:

helm template my-chart . | conftest test -p policy/ -

Alternative: Kyverno

Kyverno offers policy enforcement using native Kubernetes manifests instead of Rego. Policies are written in YAML and can validate, mutate, or generate resources.

Example Kyverno policy:

apiVersion: kyverno.io/v1
kind: ClusterPolicy
metadata:
  name: require-resource-limits
spec:
  validationFailureAction: Enforce
  rules:
  - name: check-container-limits
    match:
      resources:
        kinds:
        - Pod
    validate:
      message: "All containers must have CPU and memory limits"
      pattern:
        spec:
          containers:
          - resources:
              limits:
                memory: "?*"
                cpu: "?*"

Conftest vs Kyverno:

Conftest: Policies run in CI, flexible for any YAML
Kyverno: Runtime enforcement in-cluster, Kubernetes-native

Both can coexist: Conftest in CI for early feedback, Kyverno in cluster for runtime enforcement.

Vulnerability Scanning: Trivy

Trivy by Aqua Security provides comprehensive security scanning for Helm charts.

Project Profile:

Maintainer: Aqua Security (commercial backing with open-source core)
Scope: Vulnerability scanning + misconfiguration detection
Helm integration: Official trivy helm command
Bus Factor: Low (commercial backing + strong open-source adoption)

What Trivy scans in Helm charts:

Vulnerabilities in referenced container images
Misconfigurations (similar to Conftest but pre-built rules)
Secrets accidentally committed in templates

Example scan:

trivy helm ./charts/my-chart --severity HIGH,CRITICAL --exit-code 1

Sample output:

myapp/templates/deployment.yaml (helm)
====================================

Tests: 12 (SUCCESSES: 10, FAILURES: 2)
Failures: 2 (HIGH: 1, CRITICAL: 1)

HIGH: Container 'app' of Deployment 'myapp' should set 'securityContext.runAsNonRoot' to true
════════════════════════════════════════════════════════════════════════════════════════════════
Ensure containers run as non-root users

See https://kubernetes.io/docs/concepts/security/pod-security-standards/
────────────────────────────────────────────────────────────────────────────────────────────────
 myapp/templates/deployment.yaml:42

Commercial support:
Aqua Security offers Trivy Enterprise with advanced features (centralized scanning, compliance reporting). For most teams, the open-source version is sufficient.

Other Security Tools

Polaris (Fairwinds)

Polaris scores charts based on security and reliability best practices. Unlike enforcement tools, it provides a health score and actionable recommendations.

Use case: Dashboard for chart quality across a platform

Checkov (Bridgecrew/Palo Alto)

Similar to Trivy but with a broader IaC focus (Terraform, CloudFormation, Kubernetes, Helm). Pre-built policies for compliance frameworks (CIS, PCI-DSS).

When to use Checkov:

Multi-IaC environment (not just Helm)
Compliance-driven validation requirements

Enterprise Selection Criteria

Bus Factor and Long-Term Viab

Helm 4.0 Features, Breaking Changes & Migration Guide 2025

Fri, 13 Feb 2026 11:03:08 +0000

Helm is one of the main utilities within the Kubernetes ecosystem, and therefore the release of a new major version, such as Helm 4.0, is something to consider because it is undoubtedly something that will need to be analyzed, evaluated, and managed in the coming months.

Helm 4.0 represents a major milestone in Kubernetes package management. For a complete understanding of Helm from basics to advanced features, explore our .

Due to this, we will see many comments and articles around this topic, so we will try to shed some light.

Helm 4.0 Key Features and Improvements

According to the project itself in its announcement, Helm 4 introduces three major blocks of changes: new plugin system, better integration with Kubernetes ** and internal modernization of SDK and performance**.

New Plugin System (includes WebAssembly)

The plugin system has been completely redesigned, with a special focus on security through the introduction of a new WebAssembly runtime that, while optional, is recommended as it runs in a “sandbox” mode that offers limits and guarantees from a security perspective.

In any case, there is no need to worry excessively, as the “classic” plugins continue to work, but the message is clear: for security and extensibility, the direction is Wasm.

Server-Side Apply and Better Integration with Other Controllers

From this version, Helm 4 supports Server-Side Apply (SSA) through the --server-side flag, which has already become stable since Kubernetes version v1.22 and allows updates on objects to be handled server-side to avoid conflicts between different controllers managing the same resources.

It also incorporates integration with kstatus to ensure the state of a component in a more reliable way than what currently happens with the use of the --wait parameter.

Other Additional Improvements

Additionally, there is another list of improvements that, while of lesser scope, are important qualitative leaps, such as the following:

Installation by digest in OCI registries: (helm install myapp oci://...@sha256:<digest>)
Multi-document values: you can pass multiple YAML values in a single multi-doc file, facilitating complex environments/overlays.
New --set-json argument that allows for easily passing complex structures compared to the current solution using the --set parameter

Why a Major (v4) and Not Another Minor of 3.x?

As explained in the official release post, there were features that the team could not introduce in v3 without breaking public SDK APIs and internal architecture:

Strong change in the plugin system (WebAssembly, new types, deep integration with the core).
Restructuring of Go packages and establishment of a stable SDK at helm.sh/helm/v4, code-incompatible with v3.
Introduction and future evolution of Charts v3, which require the SDK to support multiple versions of chart APIs.

With all this, continuing in the 3.x branch would have violated SemVer: the major number change is basically “paying” the accumulated technical debt to be able to move forward.

Additionally, a new evolution of the charts is expected in the future, moving from v2 to a future v3 that is not yet fully defined, and currently, v2 charts run correctly in this new version.

Is Helm 4.0 Migration Required?

The short answer is: yes. And possibly the long answer is: yes, and quickly. In the official Helm 4 announcement, they specify the support schedule for Helm 3:

Helm 3 bug fixes until July 8, 2026.
Helm 3 security fixes until November 11, 2026.
No new features will be backported to Helm 3 during this period; only Kubernetes client libraries will be updated to support new K8s versions.

Practical translation:

Organizations have approximately 1 year to plan a smooth Helm 4.0 migration with continued bug support for Helm 3.
After November 2026, continuing to use Helm 3 will become increasingly risky from a security and compatibility standpoint.

Best Practices for Migration

To carry out the migration, it is important to remember that it is perfectly possible and feasible to have both versions installed on the same machine or agent, so a “gradual” migration can be done to ensure that the end of support for version v3 is reached with everything migrated correctly, and for that, the following steps are recommended:

Conduct an analysis of all Helm commands and usage from the perspective of integration pipelines, upgrade scripts, or even the import of Helm client libraries in Helm-based developments.
Especially carefully review all uses of --post-renderer, helm registry login, --atomic, --force.
After the analysis, start testing Helm 4 first in non-production environments, reusing the same charts and values, reverting to Helm 3 if a problem is detected until it is resolved.
If you have critical plugins, explicitly test them with Helm 4 before making the global change.

What are the main new features in Helm 4.0?

Helm 4.0 introduces three major improvements: a redesigned plugin system with WebAssembly support for enhanced security, Server-Side Apply (SSA) integration for better conflict resolution, and internal SDK modernization for improved performance. Additional features include OCI digest installation and multi-document values support.

When does Helm 3 support end?

Helm 3 bug fixes end July 8, 2026 and security fixes end November 11, 2026. No new features will be backported to Helm 3. Organizations should plan migration to Helm 4.0 before November 2026 to avoid security and compatibility risks.

Are Helm 3 charts compatible with Helm 4.0?

Yes, Helm Chart API v2 charts work correctly with Helm 4.0. However, the Go SDK has breaking changes, so applications using Helm libraries need code updates. The CLI commands remain largely compatible for most use cases.

Can I run Helm 3 and Helm 4 simultaneously?

Yes, both versions can be installed on the same machine, enabling gradual migration strategies. This allows teams to test Helm 4.0 in non-production environments while maintaining Helm 3 for critical workloads during the transition period.

What should I test before migrating to Helm 4.0?

Focus on testing critical plugins, post-renderers, and specific flags like --atomic, --force, and helm registry login. Test all charts and values in non-production environments first, and review any custom integrations using Helm SDK libraries.

What is Server-Side Apply in Helm 4.0?

Server-Side Apply (SSA) is enabled with the --server-side flag and handles resource updates on the Kubernetes API server side. This prevents conflicts between different controllers managing the same resources and has been stable since Kubernetes v1.22.

Data Analysis - Basic Visualizations

Wed, 07 Jan 2026 20:55:59 +0000

Building on the concepts from our post on "Descriptive Statistics," we will now explore the most common charts for data visualization: "Descriptive Statistics", below, we will know the most basic ways to visualize the data or information to be analyzed. Specifically:

Pie chart
Line chart
Treemap & Subburst
Histograms & Bar charts
Density plot
Boxplots
Violin plots
Scatter plots
Pareto chart

Note: All the examples (except for the line graphs due to its features) are based on the train.csv dataset file, which is a subset of 891 representative individuals of the population of the Titanic used for the training of models of Machine Learning.

Pie charts

Pie charts are useful to represent the numerical proportions of the values of the data of a variable or feature with respect to its total. This type of graphs present a vast catalogue of variants and are widely used due to their simplicity of preparation and interpretation. However, these charts are often overused and misused. For more on this topic, see this excellent article on why pie charts are so controversial about the right use of pie charts and why these charts are so hated).

Example: Proportions of Titanic passengers by socioeconomic status

Line charts

Line charts are ideal for displaying how a variable changes over a continuous interval, such as time. Generally, they are used to represent trends or relationships (in a group with more variables) between the data during a continuous time interval.

Note: In order to visualize a use case in a continuous time interval, the following dataset from the Open data initiative of the Government of Spain has been used [the population data by Autonomous Communities from 1997 to 2017.](https://datos.gob.es/es/catalogo/ea0010587-poblacion-por-comunidades-y-ciudades-autonomas-y-tamano-de-los-municipios-anual-comunidades- autonomas-official-figures-of-population-of-the-Spanish-municipalities-revision-of-padron-municipal-identifier-api-2915) *

Example: Spanish population since 1997
Example: Spanish population by Autonomous Communities since 1997

Treemaps & Sunbursts

Treemaps and sunburst graphs are visualizations to represent hierarchical data and summarize the information in areas proportional to the corresponding values.

In the case of treemaps, the representation consists of rectangles with an area proportional to the value of the corresponding data with respect to the total.

Example: Proportion of passengers according to their socioeconomic status classified by gender (treemap)

In the case of sunburst, the representation consists groups of rings according to the level represented, which are divided into proportional sections corresponding to the value of the data they represent.

Example: Proportion of passengers according to their socioeconomic status classified by gender (sunburst)

On the example represented, you can quickly see information about the hierarchical data represented as for example that the number of male passengers was almost 2 / 3 of the crew, as well as that male passengers and low socioeconomic status represented something more than 1 / 3 of the crew.

Histograms & Bar charts

Looking over the information already collected in the post "Descriptive Statistics", where these two type of representations widely used in data analysis are explained, we can check that their main objective is to represent the distribution of the data with respect to a variable or characteristic of the dataset. Thus, the histograms allow to visualize continuous data and the bar diagrams represent discrete data.

Example: Passenger distribution by price of the ticket

Example: Passenger distribution by socioeconomic status

As we saw in the post "Descriptive Statistics", representing on these graphs measures of descriptive statistics (such as the mean or the median), we can characterize the distribution of the variable under analysis and thereby extract more information about it.

Density plot

As known as Kernel density plots, they serve to visualize the distribution of data in a continuous interval. This type of graphics is a variation of the histograms where the shape of the distribution is smoothly represented.

Example: Distribution of the age of Titanic passengers

Boxplots

The boxplots or whisker plots serve to represent a variable or characteristic depending on its range and its quartiles.

Note: The quartiles are the values that divide a list of ordered numbers into 4 parts in equal percentages

The boxplot consists of a box that includes the data from the first quartile (Q1 - 25% of the data under it) to the third quartile (Q3 - 75% of the data under it) of the values of the variable represented (Interquartile Range - IQR). Within said box, the median is represented with an horizontal line and optionally, the average is represented by an asterisk or a star.

In addition to the box, this plot also shows 2 horizontal lines (or "fences") that represent the maximum and minimum typical values of our variable, and from which the outliers of the distribution are visualized using points.

Statistical note: The outliers are those that are numerically distant from the rest of the data of the variable. Taking the Interquartile Range (IQR), outliers are considered those that are below Q1 - 1.5 IQR or above Q3 + 1.5 IQR.

Example: Distribution of Titanic passengers by age

Violin plots

Violin plots are used to visualize simultaneously the distribution of the data and its probability density. These visual graphs consist of a combination of a boxplot and a density plot. In this plot, the Intercuartile range is represented by a thick black line or small box, the typical data are represented with a thin black line and the median is visualized with a white point.

Example: Distribution and density of Titanic passengers by age

Scatter plots

Scatter plots consist of visualizations that show the relationship of 2 variables of a dataset on two Cartesian axes. They are quite useful since they allow extracting information about the correlation between these variables.

Example: Representation of ticket price by age and gender of the passenger

Pareto charts

The Pareto charts serve to visually represent those distributions or datasets related to the Pareto principle or the 80 / 20 rule.
Pareto principle: also known as the 80 / 20 rule, establishes that generally in a dataset related by a cause-effect relationship, approximately 80% of the results or consequences come from 20% of the causes.

Example: Representation of income data for tickets sold for the socioeconomic status

Example: Representation of income data for tickets sold for passengers

Regarding the example, we can see the usefulness of this graph given that it is quickly visualized that 90% of the ticket sales revenues of the Titanic come from tickets sold to passengers of high socioeconomic status. Or in a more detailed way about the second graph, approximately 80% of the revenue from ticket sales came from ~ 20% of the crew's passengers.

Sources of interest:

Kaggle – Titanic Machine Learning from Disaster
Open data initiative of the Government of Spain – datos.gob.es
Medium (Clément Viguier) – The hate of pie charts harms good data visualization...
Course “Essential Statistics for Data Analysis using Excel” perteneciente al Microsoft Data Science Program
The Data Visualisation Catalogue - The Data Visualisation Catalogue