DEV Community: Amaresh Pelleti

GitHub Copilot AI Credits: How Usage-Based Billing Works

Amaresh Pelleti — Wed, 22 Jul 2026 10:11:13 +0000

Originally published on DevToolHub.

Your Copilot bill works differently now. On June 1, 2026, GitHub moved every Copilot plan from premium requests to usage-based billing, and GitHub Copilot AI Credits became the meter that decides how much model usage you get each month. The subscription prices didn't change — what you get for them did.

If you use Copilot Chat, the CLI, or the coding agent daily, this affects you directly. Here's what changed, what each plan now includes, and how to keep the bill predictable.

[IMAGE: articles/images/2026-07-13-github-copilot-ai-credits-featured.png | alt: "github copilot ai credits usage-based billing meter across Copilot plans"]

AI Credits Replace Premium Requests

The old model gave you a monthly pool of Premium Request Units, where each interaction with a premium model cost a fixed number of requests. That's gone. Under usage-based billing, Copilot now bills by actual token consumption — input, output, and cached tokens — at the published API rate for each model.

One AI credit equals $0.01 USD. So a $10 Copilot Pro plan carries 1,000 base credits of model usage.

Two things disappeared along with premium requests. First, the fallback experience: Copilot no longer drops you to a lower-cost model when you run out of quota. When your credits are gone, you either buy more, upgrade, or wait for the monthly reset. Second, the fixed per-request cost — a short chat message and a long agentic session used to cost the same premium request. Now they don't, because billing follows tokens.

GitHub Copilot AI Credits by Plan

Subscription prices stayed the same, and a new Max tier was added at the top:

Plan	Price	Base credits	Flex allotment	Total monthly
Copilot Pro	$10/month	1,000	500	1,500
Copilot Pro+	$39/month	3,900	3,100	7,000
Copilot Max	$100/month	10,000	10,000	20,000
Copilot Business	$19/user/month	$19 in credits	—	pooled per org
Copilot Enterprise	$39/user/month	$39 in credits	—	pooled per org

The flex allotment is extra headroom on top of your base credits — Pro effectively gets $15 worth of model usage for its $10 price. Business and Enterprise credits pool across all users in the organization, so a heavy user can draw from what a light user doesn't touch.

⚠️ Note: Business and Enterprise plans get promotional credits through August 2026 — $30/month for Business and $70/month for Enterprise instead of the standard $19 and $39. If your team's usage looks fine right now, re-check it in September when the promo ends.

The Free plan includes 2,000 code completions and a small credit allowance, with model access through auto model selection only. Student accounts keep unlimited completions.

What Consumes AI Credits (and What Stays Unlimited)

Code completions and next edit suggestions remain unlimited on every paid plan. They don't touch your credits at all. If your Copilot usage is mostly tab-completion while you type, this whole change barely affects you.

Credits are consumed by:

Copilot Chat — every conversation, scaled by length and model choice
Copilot CLI and the cloud coding agent
Copilot Spaces and Spark
Third-party coding agents running through your Copilot subscription
Copilot code review — which burns both AI credits and GitHub Actions minutes

That last one surprises people. Automated code review on a busy repo is a recurring cost on two meters at once, so check both if you've wired it into every pull request.

How Token-Based Billing Actually Works

Because billing follows tokens, the same feature can cost very different amounts depending on how you use it. Three factors drive the number:

Conversation length. Each message in a chat re-sends context. Long-running conversations consume more input tokens per message, so ten short chats cost less than one marathon session covering the same questions.

Agentic features. The coding agent makes multiple model calls per task — planning, editing, verifying. A single "fix this issue" instruction can fan out into dozens of calls. In practice, agentic workflows are where credits drain fastest.

Model selection. Frontier models bill at higher API rates than smaller ones. Paid plans get a 10% discount on model costs when you use auto model selection instead of pinning a specific model.

Unused credits don't roll over. Your allowance resets to the full monthly amount at 00:00 UTC on the first day of each calendar month, and whatever you didn't use is forfeited.

Annual Plans Keep the Old Pricing — For Now

Monthly Pro and Pro+ subscribers were migrated automatically on June 1, 2026. Annual subscribers weren't. If you're on an annual plan, you stay on premium request pricing until your plan expires — but GitHub raised the model multipliers for annual holdouts on the same date, so the old pricing isn't quite what it used to be.

When an annual plan expires, the account transitions to the Free tier with the option to upgrade back into a usage-based plan. There's no path to renewing into premium requests.

Keeping Your Copilot Bill Predictable

When your included credits run out mid-month, you have three options: upgrade to a higher plan (you're charged only the price difference), set a budget for additional usage, or wait for the reset. Additional usage is billed at $0.01 per credit and can be capped — once you hit the cap, Copilot's premium features pause until you pay for consumed credits or the month rolls over.

For organizations, the billing docs cover budget controls at the enterprise, cost center, and individual user level, plus the choice to allow or block overage spending entirely. Set these before rollout, not after the first surprising invoice.

Three habits that stretch a credit allowance:

Use auto model selection unless you have a real reason to pin a model — the 10% discount adds up
Start new chats instead of continuing long conversations — shorter context means fewer input tokens
Reserve agentic workflows for tasks that justify the fan-out, and lean on unlimited completions for routine coding

If the math stops working for your usage pattern, it's worth comparing against Copilot alternatives or a dedicated agentic tool — the Claude Code vs Codex comparison covers the two most common candidates. And if you're staying, the Copilot tips and tricks guide helps you get more out of the features that are still unlimited.

[IMAGE: articles/images/2026-07-13-github-copilot-ai-credits-diagram.png | alt: "token metering flow splitting into included credits, overage budget, and unlimited completions lane"]

Frequently Asked Questions

Q: Did GitHub Copilot prices increase in 2026?
A: The subscription prices stayed the same — Pro is $10, Pro+ is $39, Business is $19/user, Enterprise is $39/user. What changed is the metering: premium requests were replaced by AI credits billed on token consumption. A new Copilot Max tier was also added at $100/month with 20,000 total credits.

Q: Do code completions use GitHub Copilot AI credits?
A: No. Code completions and next edit suggestions are unlimited on all paid plans and never consume credits. Only chat, CLI, agents, Spaces, Spark, and code review draw from your credit allowance.

Q: What happens when my AI credits run out?
A: Premium features pause unless you've set a budget for additional usage. You can upgrade plans (paying only the difference), buy additional usage at $0.01 per credit up to your budget cap, or wait for the monthly reset on the first of the month at 00:00 UTC.

Q: Do unused Copilot AI credits roll over to the next month?
A: No. Unused credits are forfeited and your allowance resets to the full monthly amount on the first day of each calendar month.

Q: I'm on an annual Copilot plan — am I affected?
A: Not immediately. Annual subscribers keep premium request pricing until their plan expires, though model multipliers increased on June 1, 2026. After expiry, the account moves to the Free tier with the option to upgrade into a usage-based plan.

Quick Summary:

GitHub Copilot AI Credits replaced premium requests on June 1, 2026 — billing now follows token consumption at each model's published API rate
1 credit = $0.01; Pro gets 1,500 total monthly credits, Pro+ gets 7,000, the new $100 Max tier gets 20,000
Code completions and next edit suggestions stay unlimited on all paid plans
Auto model selection gives paid plans a 10% discount on model costs
Business/Enterprise promo credits ($30/$70 per month) end in August 2026 — recheck team budgets in September
Unused credits don't roll over; overage can be capped with a dollar budget

Check your projected usage in the Copilot billing dashboard before the promotional credits expire — that's the number that predicts your September invoice.

Google Cloud Data Agent Kit: Build Pipelines from Your IDE Without the Boilerplate

Amaresh Pelleti — Mon, 20 Jul 2026 15:57:40 +0000

Originally published on DevToolHub.

Writing data pipeline code is repetitive. You pull raw files from Cloud Storage, figure out the schema, decide whether to push through BigQuery or Spark, write the SQL or PySpark, wire up the orchestration, add the governance checks — and repeat this for every new dataset. Most of that work is boilerplate that follows known patterns.

Google Cloud Data Agent Kit is an open-source suite of AI skills, MCP tools, and IDE plugins that drops into VS Code and Claude Code to handle that boilerplate for you. You describe what you want to do with your data. The agents figure out the execution path.

[IMAGE: articles/images/2026-07-05-google-cloud-data-agent-kit-featured.png | alt: "google cloud data agent kit in VS Code IDE showing BigQuery pipeline generation with AI agents"]

What the Google Cloud Data Agent Kit Actually Does

The kit has four distinct layers:

Agentic skills — pre-codified workflows for the tasks you run repeatedly: query optimization, data validation, drift detection, ML model lifecycle management, and governance enforcement. These are the "skills" that agents draw on when you give them a goal.

MCP tools — Model Context Protocol connections that give the agents secure, authenticated access to your cloud data services (BigQuery, AlloyDB, Spanner, GCS) without requiring you to copy credentials into your editor or manually configure connection strings.

IDE plugins — native integrations for VS Code, Claude Code, Gemini CLI, Codex, and Antigravity CLI. The plugin surfaces a Unified Data Hub — a single view of your data estate, including datasets, orchestration pipelines, and active jobs.

Intelligent routing — the agents automatically pick the right compute engine for each task. BigQuery handles SQL-native analytics and ELT. Spark handles custom Python transformations and distributed ML training. You don't configure this — the agent chooses based on what the task requires.

The kit itself is in preview, but the two agents it packages are GA:

Data Engineering Agent — builds pipeline transformations from natural language descriptions and enforces governance rules
Data Science Agent — manages the full model lifecycle from data wrangling through training, scaling across BigQuery Dataframes and Serverless Apache Spark

Installing Google Cloud Data Agent Kit in VS Code and Claude Code

VS Code:

Open the Extensions panel (Ctrl+Shift+X / Cmd+Shift+X)
Search for "Google Cloud Data Agent Kit"
Install and authenticate with your Google Cloud account

Setup takes under a minute and configures the MCP connections automatically.

Claude Code:

Install via the Claude Code Plugin system. Once installed, Data Agent Kit's tools appear in Claude Code's available MCP tools, and you can invoke the Data Engineering Agent directly from the CLI.

Both environments give you access to the same agents and MCP connections — the difference is UX. VS Code gives you the Unified Data Hub sidebar for browsing datasets. Claude Code gives you conversational access from the terminal.

⚠️ Note: You need an active Google Cloud project with BigQuery API enabled. The agents authenticate with your existing gcloud auth credentials — no separate service account setup required for initial testing.

Building a Data Pipeline: What It Looks Like End to End

A real example from the kit's starter pack: starting with raw files in Cloud Storage and ending with batch inference results in Cloud Spanner — without leaving the IDE.

The Data Engineering Agent handled:

Creating a Spark notebook for initial data ingestion
Setting up Iceberg table management in BigQuery for the processed data
Generating a dbt project for the transformation layer
Wiring up an end-to-end orchestration pipeline

The Data Science Agent then:

Trained a XGBoost model on the processed dataset
Ran batch inference at scale
Pushed results to Cloud Spanner

Each step was triggered through natural language in the IDE — "create a pipeline to ingest these GCS files into BigQuery with Iceberg table management" — not by writing the pipeline code manually.

That doesn't mean zero code is involved. The agents generate code that you review and run. But the scaffolding, connection boilerplate, and orchestration wiring is generated rather than hand-written.

Connecting to BigQuery, GCS, and Spanner via MCP

The MCP layer is what makes the agents actually useful rather than just generating generic code. Because the agents connect directly to your cloud services, they can:

Inspect your actual dataset schemas before generating transformation code
Validate that generated SQL runs against your real BigQuery tables
Read GCS file metadata to determine the right ingestion approach
Check existing orchestration jobs before creating new pipeline steps

This matters because a generic AI assistant generating pipeline code doesn't know your actual schema or data. The MCP connection gives the agents context about your real data estate. For a deeper look at how MCP works, see what is Model Context Protocol.

For GCP data management compared to AWS and Azure, Data Agent Kit is a BigQuery-native integration — it works best in environments already invested in GCP data services.

[IMAGE: articles/images/2026-07-05-google-cloud-data-agent-kit-diagram.png | alt: "MCP architecture connecting VS Code to BigQuery, GCS, AlloyDB, and Spark via Data Agent Kit"]

When to Use It and When to Write Pipeline Code Yourself

Google Cloud Data Agent Kit is genuinely useful for:

Prototyping new pipelines — instead of spending an hour setting up the scaffold before you can even test your logic, you describe the data flow and get working code in minutes. Then you refine it.

Repeated ad-hoc data exploration — querying GCS files, visualizing dataset distributions, pulling quick stats without leaving your editor.

Standard transformation patterns — dbt project setup, Iceberg table management, standard ELT flows. These are well-understood patterns that the agents handle reliably.

It's less useful for:

Highly custom orchestration — if your pipeline has unusual scheduling requirements, specific failure recovery logic, or dependencies across multiple data systems with complex ordering, the generated scaffolding becomes a starting point rather than a finished product.

Performance-critical workloads — generated Spark code is correct but not always optimally tuned. You'll still need to profile and optimize queries that run at scale with strict SLA requirements.

The honest framing: this is a tool that eliminates boilerplate, not business logic. The parts of pipeline engineering that require understanding of your specific data, compliance requirements, and performance constraints still require human judgment.

Official documentation: Google Cloud Data Agent Kit extension docs and the GCP blog announcement.

Frequently Asked Questions

Q: Does Google Cloud Data Agent Kit work with non-GCP data sources?
A: The current version focuses on GCP services — BigQuery, AlloyDB, Spanner, GCS, and Serverless Apache Spark. The MCP tools are built specifically for GCP authentication and API patterns. Cross-cloud connections aren't supported in the current release.

Q: Is the Data Agent Kit free to use?
A: The kit itself is open-source and free to install (currently in preview). You pay for the underlying GCP services (BigQuery queries, Spark compute, GCS storage) at standard GCP rates. There's no additional charge for the Data Engineering Agent or Data Science Agent.

Q: Can I use it with Gemini CLI instead of VS Code?
A: Yes. The Data Agent Kit supports Gemini CLI, Claude Code, VS Code, Codex, and Antigravity CLI. The agents and MCP connections work the same across environments.

Q: What happens to my data when the agents access it?
A: The MCP tools use your existing Google Cloud credentials and IAM permissions. The agents don't copy data to external systems — they read metadata and execute queries against your GCP services within the permissions of your authenticated account.

Q: Does this replace dbt or Dataform for transformations?
A: No. The Data Engineering Agent can generate dbt projects as part of a pipeline setup, but it doesn't replace dbt as a transformation framework. It uses dbt for the parts where dbt is the right tool — the same way an experienced engineer would.

Quick Summary:

Google Cloud Data Agent Kit is an open-source suite of AI agents and MCP tools that integrates into VS Code and Claude Code
Two GA agents: Data Engineering Agent (pipelines, transformations, governance) and Data Science Agent (model training, inference)
MCP connections give agents real context about your actual schemas, datasets, and existing jobs — not just generic code generation
Intelligent routing picks BigQuery for SQL analytics and Spark for Python/ML workloads automatically
Best for prototyping, exploration, and standard transformation patterns — complex orchestration still needs manual refinement
Free to install; you pay standard GCP rates for the underlying services

Falco on Kubernetes: Runtime Security with eBPF

Amaresh Pelleti — Mon, 13 Jul 2026 21:17:36 +0000

Originally published on DevToolHub.

Most Kubernetes security tools scan for misconfigurations — pods running as root, missing network policies, RBAC roles that are too permissive. Those checks matter, but they don't tell you what's actually happening at runtime. A container could be perfectly configured and still execute a reverse shell the moment a vulnerability gets exploited.

Falco fills that gap. It runs as a DaemonSet and monitors kernel-level system calls from every container on your nodes using eBPF. When a process does something suspicious — spawns a shell inside a production pod, reads sensitive credential files, opens an outbound connection to an unexpected host — Falco fires an alert in real time.

[IMAGE: articles/images/2026-07-05-falco-kubernetes-runtime-security-featured.png | alt: "falco kubernetes runtime security architecture with eBPF kernel monitoring"]

Falco on Kubernetes: What Runtime Security Actually Catches

The default Falco ruleset covers the threats that show up most in real incident reports:

Shells spawned inside containers — exec into a pod, reverse shell from a web app exploit, interactive session from compromised code
Privilege escalation — a process inside a container attempting to gain root access or modify privileged kernel settings
Sensitive file access — reads from /etc/shadow, /root/.ssh/, or cloud credential files like ~/.aws/credentials
Unexpected outbound traffic — connections to known crypto-mining pools, C2 servers, or external hosts outside your expected egress

Falco doesn't block any of this by default — it alerts on it. The threat detection is real-time because it happens at the kernel system call layer, not by periodically scanning container state.

Installing Falco on Kubernetes with Helm

Add the Falco Helm repository and update:

helm repo add falcosecurity https://falcosecurity.github.io/charts
helm repo update

Basic installation into its own namespace:

helm install falco falcosecurity/falco \
    --create-namespace \
    --namespace falco

By default, Helm deploys Falco as a DaemonSet — one pod per node — with the driver.kind=auto setting, which selects the best available driver automatically.

For most production clusters, you'll want to add Kubernetes metadata collection and Falcosidekick for alert routing:

helm install falco falcosecurity/falco \
    --create-namespace \
    --namespace falco \
    --set driver.kind=modern_ebpf \
    --set collectors.kubernetes.enabled=true \
    --set falcosidekick.enabled=true

This single command gets you: eBPF-based syscall monitoring, Kubernetes pod and namespace metadata enrichment in alerts, and Falcosidekick ready to route alerts to your notification channels.

eBPF vs Kernel Module: Choosing Your Driver

Falco supports three driver options, and the choice has real operational consequences:

Driver	How it works	Best for
`modern_ebpf`	CO-RE eBPF probe, no kernel headers needed	Most production environments, kernel 5.8+
`kmod`	Kernel module loaded at runtime	Older kernels, bare metal with kernel header access
`auto`	Picks the best available driver	Testing, heterogeneous node environments

For most teams running Kubernetes 1.24+ on standard cloud providers (EKS, GKE, AKS), modern_ebpf is the right choice. The CO-RE (Compile Once, Run Everywhere) approach means the probe adapts to different kernel structures at load time without recompilation — which eliminates the kernel header dependency that makes kmod painful to operate.

To install with explicit modern eBPF:

helm install falco falcosecurity/falco \
    --create-namespace \
    --namespace falco \
    --set driver.kind=modern_ebpf

⚠️ Note: modern_ebpf requires kernel 5.8 or later. For older kernels, use kmod or check the official Falco docs for minimum version requirements by driver type.

Also verify your Kubernetes RBAC policies allow Falco's DaemonSet pods to run with the necessary Linux capabilities — specifically SYS_PTRACE for eBPF-based drivers.

Understanding and Customizing Falco Rules

Falco rules are YAML files. Each rule defines a condition (what to look for in the syscall stream), an output message format (what the alert says), and a priority level. The default ruleset covers common threats out of the box, and you can extend it with custom rules for your environment.

Rules are loaded from /etc/falco/ inside the Falco pod. The main default ruleset lives in falco_rules.yaml. You override rules or add new ones in falco_rules.local.yaml — Falco loads local rules last, so they override defaults.

Common starting points for custom rules:

Restricting which namespaces are allowed to spawn processes outside the expected set
Alerting when credentials files are accessed from specific pod labels
Flagging network connections to unexpected IP ranges from production workloads

For exact condition field syntax and the full list of Falco fields (proc.name, container.image.repository, fd.sport, etc.), see the official Falco documentation. The field reference is comprehensive and the conditions are readable once you know the namespace.

For DevSecOps pipeline integration, Falco rules can be version-controlled and deployed via the same Helm chart upgrade path.

Falco Alert Routing with Falcosidekick

Falcosidekick is the standard companion service for routing Falco alerts. It sits between Falco's JSON event stream and your notification systems, with over 50 built-in integrations.

When you enable Falcosidekick in the Helm install, it deploys alongside Falco and picks up the event stream automatically:

helm upgrade falco falcosecurity/falco \
    --namespace falco \
    --set driver.kind=modern_ebpf \
    --set falcosidekick.enabled=true \
    --set falcosidekick.config.slack.webhookurl="https://hooks.slack.com/services/YOUR/WEBHOOK/URL" \
    --set falcosidekick.config.pagerduty.routingKey="YOUR_ROUTING_KEY"

Falcosidekick supports Slack, PagerDuty, Elasticsearch, Splunk, Loki, Datadog, OpsGenie, and many more. You configure each integration through Helm values or a falcosidekick.yaml config file.

[IMAGE: articles/images/2026-07-05-falco-kubernetes-runtime-security-diagram.png | alt: "falco alert routing flow from kernel layer through rules engine to Falcosidekick integrations"]

For alert volume, Falco's priority levels (CRITICAL, ERROR, WARNING, NOTICE, INFO, DEBUG) let you route only high-priority alerts to PagerDuty while sending everything else to Elasticsearch for analysis.

This pairs well with existing cloud security monitoring — Falco covers the runtime layer that static config scanners miss.

Frequently Asked Questions

Q: Does Falco work on managed Kubernetes like EKS, GKE, or AKS?
A: Yes. All three managed providers support running Falco as a DaemonSet. On GKE, you'll need Container-Optimized OS nodes with the right kernel version for modern_ebpf. EKS and AKS support it on Amazon Linux 2 and Ubuntu node pools respectively.

Q: Will Falco slow down my Kubernetes workloads?
A: The modern eBPF driver has minimal overhead — typically 1-3% CPU on nodes under normal load. The syscall monitoring happens in the kernel, separate from your container processes. Heavy filtering of low-priority events through priority levels keeps the overhead manageable.

Q: Does Falco block threats or only alert?
A: By default, Falco only alerts. For active response — killing a pod, triggering a network policy change — you pair Falco with a response engine. Falco's Kubernetes Response Engine project, or a custom Falcosidekick webhook handler, can trigger automated remediation.

Q: How do I update Falco rules without redeploying the DaemonSet?
A: Use falcoctl — the Falco artifact manager — to pull updated rules at runtime. This is the recommended approach for production: falcoctl artifact install ruleset:falco-rules without a full Helm upgrade.

Q: Can I run Falco alongside other security tools like Trivy or kube-bench?
A: Yes, and you should. Falco covers runtime behavior. Trivy covers image vulnerabilities. kube-bench covers CIS benchmark compliance. These tools address different attack surfaces and complement each other.

Quick Summary:

Falco monitors kernel system calls via eBPF — it catches runtime threats that config scanners miss
Install with Helm: driver.kind=modern_ebpf is the right choice for kernel 5.8+ production clusters
Enable collectors.kubernetes.enabled=true to get pod/namespace context in every alert
Falcosidekick routes alerts to 50+ integrations — Slack, PagerDuty, Elasticsearch — with a single Helm value
Custom rules go in falco_rules.local.yaml and load last, overriding defaults
Falco alerts but doesn't block by default — pair it with a response engine for automated remediation

Helm 4 Migration Guide: What Breaks and How to Fix It Before EOL

Amaresh Pelleti — Mon, 06 Jul 2026 15:47:40 +0000

Originally published on DevToolHub.

Helm 4 shipped in November 2025. Eight months later, most teams are still running Helm 3 in production CI/CD because it works. But Helm 3's final feature release lands September 9, 2026, and security patches stop completely on February 10, 2027.

This helm 4 migration is simpler than it looks. Your charts don't need rewriting — Helm 3 Chart API v2 charts are fully compatible with Helm 4. But the automation around Helm has four real breaking points that fail silently if you don't know where to look.

[IMAGE: articles/images/2026-07-05-helm-4-migration-guide-featured.png | alt: "helm 4 migration flow from Helm 3 to Helm 4 upgrade path"]

Why This Helm 4 Migration Matters Now

The EOL timeline has three stages, and they matter differently based on your situation:

September 9, 2026 — Final Helm 3 feature release (limited to Kubernetes client library updates only after this date)
February 10, 2027 — All security patches stop

If your organization runs regulated workloads with requirements around supported software, February 2027 is your hard deadline. But waiting until then means doing this migration under pressure, after 14 months of Helm 4 fixes shipped without you tracking them.

The better path: upgrade now, before September, so you're on supported software when new Kubernetes releases land and need updated client libraries.

What Actually Broke: The Four Real Changes

1. Post-renderers require plugin registration

In Helm 3, you could pass any executable directly to --post-renderer:

helm install myapp ./chart --post-renderer ./scripts/mutate.sh

Helm 4 drops this. Post-renderers must now be registered as named Helm plugins and referenced by plugin name:

helm install myapp ./chart --post-renderer my-post-renderer

If your pipeline calls --post-renderer ./path/to/script.sh, it fails on Helm 4. The error message doesn't say "plugin required," so this is easy to miss in a quick smoke test.

To wrap an existing script as a plugin, create a plugin.yaml:

name: my-post-renderer
version: "0.1.0"
usage: "Custom post-renderer"
description: "Mutation script for Helm output"
command: "$HELM_PLUGIN_DIR/mutate.sh"

Install it with helm plugin install /path/to/plugin-dir, then update your pipeline to reference the plugin name instead of the script path.

2. Registry login requires domain names only

Helm 3 accepted both forms:

helm registry login https://registry.example.com  # Helm 3: works
helm registry login registry.example.com          # Helm 3: also works

Helm 4 accepts domain names only — no protocol prefix:

helm registry login registry.example.com   # Helm 4: correct
helm registry login https://registry.example.com  # Helm 4: fails

Check every CI/CD step that authenticates to a private OCI registry. The HELM_EXPERIMENTAL_OCI=1 environment variable is also gone — OCI is now stable and enabled by default, and setting that flag causes an error.

3. `--atomic` and `--force` are renamed

Two flags that appear constantly in production pipelines are deprecated in Helm 4:

Old flag	New flag
`--atomic`	`--rollback-on-failure`
`--force`	`--force-replace`

The old flags still work in current Helm 4 releases but emit deprecation warnings. They become hard errors in a future minor version. If your pipeline treats warnings as failures — which many do — you'll hit breakage before that happens.

4. Go SDK import path (tool builders only)

If you've built tooling that embeds Helm as a Go library, update your import from helm.sh/helm/v3 to helm.sh/helm/v4. This only applies if you're writing code that imports Helm packages — not if you're using the CLI.

New Defaults That Will Catch You Off Guard

Server-side apply for new installs

Helm 4 uses server-side apply (SSA) for all new helm install operations. SSA handles field ownership conflicts more cleanly than client-side apply, so this is the right default. But it changes behavior in ways that matter.

For existing releases installed with Helm 3, Helm 4 retains client-side apply on upgrades. So you get SSA on new installs and client-side apply on upgrades of existing releases. To force SSA for an existing release, pass --server-side explicitly:

helm upgrade myapp ./chart --server-side

Test this in staging first. SSA applies field management metadata that can surface ownership conflicts if other tools — ArgoCD, kubectl, Terraform — have also been managing those resources.

kstatus changes what `--wait` checks

Helm 4's --wait flag now uses kstatus for readiness detection instead of just checking pod status. kstatus requires the watch verb on Kubernetes resources. If your Helm service account doesn't have watch, --wait fails immediately after you upgrade the binary.

Before upgrading, check your Kubernetes RBAC configuration and ensure the Helm service account includes:

rules:
- apiGroups: ["*"]
  resources: ["*"]
  verbs: ["get", "list", "watch"]

Without watch, the failure looks like a timeout at first glance, not a permissions error.

How to Install Helm 4

Helm 4 and Helm 3 coexist on the same machine, so you can install Helm 4 and test before switching over.

Via install script:

curl -fsSL -o get_helm.sh https://raw.githubusercontent.com/helm/helm/main/scripts/get-helm-4
chmod 700 get_helm.sh
./get_helm.sh

macOS via Homebrew:

brew install helm

Debian/Ubuntu:

curl -fsSL https://packages.buildkite.com/helm-linux/helm-debian/gpgkey | gpg --dearmor | sudo tee /usr/share/keyrings/helm.gpg > /dev/null
echo "deb [signed-by=/usr/share/keyrings/helm.gpg] https://packages.buildkite.com/helm-linux/helm-debian/any/ any main" | sudo tee /etc/apt/sources.list.d/helm-stable-debian.list
sudo apt-get update && sudo apt-get install helm

Fedora/RHEL:

sudo dnf install helm

After installation, run helm version to confirm 4.x, then test your charts against a staging namespace:

helm install test-release ./your-chart --namespace staging --dry-run

Charts from existing Helm 3 deployments work as-is in Helm 4. What you're testing is your pipeline scripts, not the chart files.

Fixing Your CI/CD Scripts for Helm 4

Go through every Helm call in your pipelines. For each one, check these specific patterns:

# Rename --atomic
helm upgrade myapp ./chart --atomic               # OLD — warning now, hard error later
helm upgrade myapp ./chart --rollback-on-failure  # NEW

# Rename --force
helm upgrade myapp ./chart --force                # OLD
helm upgrade myapp ./chart --force-replace        # NEW

# Fix registry login
helm registry login https://my-registry.io        # OLD — fails in Helm 4
helm registry login my-registry.io               # NEW

# Remove the OCI experiment flag entirely
export HELM_EXPERIMENTAL_OCI=1   # Remove this line — setting it causes an error in Helm 4

For post-renderer scripts: wrap each one as a Helm plugin using the plugin.yaml format above. The actual script content doesn't change — only how Helm references it.

For a shift-left security pipeline that validates charts pre-deploy, check whether your static analysis tools (conftest, chart-testing) have released Helm 4 compatible versions.

Helm templates and commands syntax is unchanged in Helm 4 — the template engine, values handling, and chart structure are all the same.

[IMAGE: articles/images/2026-07-05-helm-4-migration-guide-diagram.png | alt: "CI/CD pipeline checklist diagram for upgrading to Helm 4"]

For the official timeline, see the Helm v3 End of Life announcement.

Frequently Asked Questions

Q: Do I need to rewrite my Helm charts for Helm 4?
A: No. Helm 3 Chart API v2 charts work with Helm 4 without changes. The helm 4 migration affects your CI/CD scripts and automation — not the chart files, templates, or values.

Q: Will existing Helm 3 releases break when I upgrade the Helm binary?
A: No. Helm 4 reads existing release history without issues. Upgrades of existing releases stay on client-side apply until you explicitly pass --server-side.

Q: What happens if I don't upgrade before September 9?
A: Helm 3 keeps working — it just won't receive Kubernetes client library updates after September 9. Security patches continue until February 10, 2027. The practical risk is that new Kubernetes API deprecations won't be handled in Helm 3 after that date.

Q: How do I verify whether kstatus will break my --wait?
A: Run kubectl auth can-i watch pods --as=system:serviceaccount:default:helm for your Helm service account. If it returns "no," add watch to the cluster role before migrating.

Q: Does Helm 4 change how classic chart repositories work?
A: No. HTTP chart repos work the same. OCI registry support is now stable and the default — you no longer need HELM_EXPERIMENTAL_OCI=1, and setting it causes an error.

Quick Summary:

Helm 3 final feature release: September 9, 2026. Security patches end February 10, 2027.
Post-renderers must be Helm plugins — executable paths no longer work
helm registry login requires domain names only — drop https://
--atomic → --rollback-on-failure, --force → --force-replace
kstatus for --wait requires the watch RBAC verb — check before migrating
Charts need zero changes — this helm 4 migration is entirely in your CI/CD scripts

PostgreSQL on Kubernetes — Complete Setup Guide with CloudNativePG

Amaresh Pelleti — Tue, 16 Jun 2026 01:13:22 +0000

Originally published on DevToolHub, where I keep this guide updated as CloudNativePG evolves.

Running PostgreSQL in Kubernetes used to be a bad idea. StatefulSets were tricky, persistent volumes were unreliable, and failover meant data loss. Most teams defaulted to managed cloud databases and called it done.

That calculus has changed. CloudNativePG — the CNCF-listed PostgreSQL operator — handles high availability, automated failover, Point-in-Time Recovery, connection pooling, and streaming replication out of the box. In 2026 it's the production-grade way to run PostgreSQL on Kubernetes, and the gap between "self-hosted on K8s" and "managed cloud database" has narrowed significantly.

This guide walks through a complete CloudNativePG setup — from operator install to production-ready cluster.

What the full guide covers

Why CloudNativePG over a plain StatefulSet — what the operator actually does that raw StatefulSets can't
Installing the operator — kubectl and the kubectl-cnpg plugin
Deploying a 3-instance HA cluster — 1 primary + 2 standbys, with PostgreSQL tuning parameters
Connecting your app — read-write vs read-only services, port-forwarding for debugging
Backup and WAL archiving to S3 — ScheduledBackup, retention policies, verifying archiving works
PgBouncer connection pooling — the Pooler resource, transaction vs session mode
RBAC and Network Policies — locking down who can reach the database at the Kubernetes layer
Testing failover — how to simulate a primary failure and what to expect
Point-in-Time Recovery — restoring to an exact timestamp from WAL archives
Common mistakes and best practices — storage sizing, pool mode, pg_hba.conf defaults, synchronous replication

The one thing most guides skip

WAL archiving must be configured before you put data in the database — you can't retroactively enable PITR. Configure backups before your first application write.

So which setup should you use?

CloudNativePG on K8s — right for teams with Kubernetes expertise who want full operational control, PITR, and custom PostgreSQL configuration without paying managed database prices.

Managed PostgreSQL (RDS, Cloud SQL, DigitalOcean Managed Databases) — still wins on operational simplicity. Zero operator to maintain, automatic failover handled for you.

CloudNativePG narrows the gap significantly — but the right call depends on your team's tolerance for database operations.

I keep the full step-by-step guide on DevToolHub, including all YAML manifests and kubectl commands: PostgreSQL on Kubernetes — Complete Setup Guide with CloudNativePG

I write hands-on DevOps and Kubernetes guides at devtoolhub.com. Questions about your setup? Drop a comment.

Ollama Cloud Free vs Pro — Usage Limits, Pricing & What You Actually Get (2026)

Amaresh Pelleti — Thu, 11 Jun 2026 00:39:50 +0000

Originally published on DevToolHub, where I keep this guide updated every time Ollama revises its limits.

Ollama Cloud is one of the most searched topics in the local AI space right now — and the number one question is always the same: what do you actually get on the free tier, and is Pro worth paying for?

This guide covers the plan limits, how usage is actually measured (it's not tokens), and when upgrading makes sense. All data is pulled from the official Ollama pricing page.

What Ollama Cloud is

Ollama Cloud is a managed inference service that runs large open-source models on Ollama's datacenter GPUs — no local GPU required. The key advantage: your existing local Ollama setup works identically with cloud models. No code rewrites, no new SDKs. Just point at a cloud model and run:

ollama run gpt-oss:120b-cloud

Same CLI, same OpenAI-compatible API, different hardware.

The three tiers

	Free	Pro	Max
Price	$0	$20/mo ($200/yr)	$100/mo
Cloud usage	Base quota	~50x Free	Highest
Concurrent cloud models	Limited	3 at a time	More <!-- CHECK exact number against your live post -->
Model access	Lighter cloud models	Full catalog	Full catalog + priority

Running models on your own hardware is always unlimited — the plans only govern cloud usage.

How usage is actually measured (most posts get this wrong)

Ollama doesn't cap you at a fixed number of tokens or requests. Usage reflects actual utilization of their cloud infrastructure — primarily GPU time, which depends on model size and request duration. Two things follow from that:

Limits reset on two clocks: session limits reset every 5 hours, weekly limits reset every 7 days.
Heavier models burn quota faster. Models are grouped into usage levels from level 1 (light models like gpt-oss:20b) up to level 4 (extra-heavy models like deepseek-v4-pro).

Practical tip: on the Free tier, stick to level 1 and level 2 models to stretch your quota. Shorter prompts and prompts that share cached context also consume less.

Concurrency and queueing

Requests beyond your plan's concurrency limit are queued and processed when a slot opens. The queue itself has a fixed depth — if it's full, requests are rejected until a slot frees up. This is the main reason production agent workloads end up on Max: it's about sustained concurrent access, not just raw quota.

Privacy

Prompt and response data is never logged or trained on, and Ollama requires zero-data-retention policies from its hosting partners. Worth knowing if you're considering cloud inference for work data.

So which tier should you pick?

Free — genuinely useful for experimenting with large models you can't fit locally. Stay on level 1–2 models.
Pro ($20/mo) — the right call for daily engineering work. Full catalog, 3 concurrent cloud models, enough quota that most individual developers never hit the wall.
Max ($100/mo) — for production agent and RAG workloads that need sustained, concurrent access to the heaviest models.

And if you'd rather own the hardware: a GPU droplet running self-hosted Ollama flips the economics once your usage is steady — I break down that setup separately.

One warning

Ollama has revised its cloud quotas more than once since launch. I keep the original post on DevToolHub updated against the official pricing page every time the limits change — bookmark that one if you want current numbers.

I write hands-on DevOps and self-hosted AI guides at devtoolhub.com. Questions about your specific workload? Drop a comment.

DEV Community: Amaresh Pelleti

GitHub Copilot AI Credits: How Usage-Based Billing Works

AI Credits Replace Premium Requests

GitHub Copilot AI Credits by Plan

What Consumes AI Credits (and What Stays Unlimited)

How Token-Based Billing Actually Works

Annual Plans Keep the Old Pricing — For Now

Keeping Your Copilot Bill Predictable

Frequently Asked Questions

Google Cloud Data Agent Kit: Build Pipelines from Your IDE Without the Boilerplate

What the Google Cloud Data Agent Kit Actually Does

Installing Google Cloud Data Agent Kit in VS Code and Claude Code

Building a Data Pipeline: What It Looks Like End to End

Connecting to BigQuery, GCS, and Spanner via MCP

When to Use It and When to Write Pipeline Code Yourself

Frequently Asked Questions

Falco on Kubernetes: Runtime Security with eBPF

Falco on Kubernetes: What Runtime Security Actually Catches

Installing Falco on Kubernetes with Helm

eBPF vs Kernel Module: Choosing Your Driver

Understanding and Customizing Falco Rules

Falco Alert Routing with Falcosidekick

Frequently Asked Questions

Helm 4 Migration Guide: What Breaks and How to Fix It Before EOL

Why This Helm 4 Migration Matters Now

What Actually Broke: The Four Real Changes

1. Post-renderers require plugin registration

2. Registry login requires domain names only

3. --atomic and --force are renamed

4. Go SDK import path (tool builders only)

New Defaults That Will Catch You Off Guard

Server-side apply for new installs

kstatus changes what --wait checks

How to Install Helm 4

Fixing Your CI/CD Scripts for Helm 4

Frequently Asked Questions

PostgreSQL on Kubernetes — Complete Setup Guide with CloudNativePG

What the full guide covers

The one thing most guides skip

So which setup should you use?

Ollama Cloud Free vs Pro — Usage Limits, Pricing & What You Actually Get (2026)

What Ollama Cloud is

The three tiers

How usage is actually measured (most posts get this wrong)

Concurrency and queueing

Privacy

So which tier should you pick?

One warning

3. `--atomic` and `--force` are renamed

kstatus changes what `--wait` checks